MeshModifiers

Alex Lindsay

unread,

Sep 30, 2015, 1:46:12 PM9/30/15

to moose...@googlegroups.com

I've been playing around with meshing in the past couple of days, and I've developed a series of questions (Feel free to answer none, one, or all :-)

1) Is there a way to sequentially order execution of mesh modification? For example I wanted to create a SubdomainBoundingBox and then SideSetsBetweenSubdomains. If I included both of these in my input file, ran with --mesh-only, and then viewed the resulting mesh, I noticed that my sideset did not get created. However, if I ran with just SubdomainBoundingBox, then fed the resulting mesh back in as an input, and then ran with only SideSetsBetweenSubdomains, I got my desired sideset.

2) Running SideSetsBetweenSubdomains produces not only a new sideset but also a new nodeset. Would it not make sense to also give the nodeset the same boundary_name as the sideset instead of leaving it unnamed? Just add the following line at the end of SideSetsBetweenSubdomains.C?:

for (unsigned int i=0; i<boundary_ids.size(); ++i) {
boundary_info.sideset_name(boundary_ids[i]) = boundary_names[i];
boundary_info.nodeset_name(boundary_ids[i]) = boundary_names[i];
}

3) Is it possible to reproduce the mesh used in the mortar test case conforming_two_var.i (2blk-conf.e) using GeneratedMesh and MeshModifiers? E.g. is it possible to insert a subdomain block with element type EDGE2 between two subdomain blocks of element type QUAD4? And then have unique boundary ID's for the QUAD4 blocks on either side of the EDGE2 interface? I'm guessing that the answer with the current architecture is no, but could it be implemented? We don't currently have a cubit/trellis license (looking into it). I've tried a few things in Salome but no success yet. May also try gmsh.

Alex

Wang (Non-US), Yaqi

unread,

Sep 30, 2015, 1:57:35 PM9/30/15

to moose-users

Question 3: yes. We have something in our internal export-controlled module called SplitConformingMeshForMortar, here is the list of valid params for the modifier:

template<>
InputParameters validParams<SplitConformingMeshForMortar>()
{
  InputParameters params = validParams<MeshModifier>();
  params.addRequiredParam<unsigned int>("num_subdomains", "Number of subdomains for mortar FEM");
  params.addRequiredParam<std::vector<unsigned int> >("num_subdomain_blocks", "Number of blocks on all subdomains");
  params.addRequiredParam<std::vector<SubdomainName> >("subdomain_blocks", "The block names of all blocks of all subdomains");
  params.addParam<std::vector<std::string> >("subdomain_names", "Subdomain names");
  return params;
}

I actually sent a PR in moose for add this but decided this is too special for my own cases. You can ask MOOSE developers that if it is proper to promote this into moose.

Best,

Yaqi

Andrs, David

unread,

Sep 30, 2015, 2:21:39 PM9/30/15

to moose...@googlegroups.com

On Wed, Sep 30, 2015 at 11:46 AM, Alex Lindsay <adli...@ncsu.edu> wrote:

I've been playing around with meshing in the past couple of days, and I've developed a series of questions (Feel free to answer none, one, or all :-)

1) Is there a way to sequentially order execution of mesh modification? For example I wanted to create a SubdomainBoundingBox and then SideSetsBetweenSubdomains. If I included both of these in my input file, ran with --mesh-only, and then viewed the resulting mesh, I noticed that my sideset did not get created. However, if I ran with just SubdomainBoundingBox, then fed the resulting mesh back in as an input, and then ran with only SideSetsBetweenSubdomains, I got my desired sideset.

See "depends_on" parameter of MeshModifier class.

2) Running SideSetsBetweenSubdomains produces not only a new sideset but also a new nodeset. Would it not make sense to also give the nodeset the same boundary_name as the sideset instead of leaving it unnamed? Just add the following line at the end of SideSetsBetweenSubdomains.C?:

for (unsigned int i=0; i<boundary_ids.size(); ++i) {
boundary_info.sideset_name(boundary_ids[i]) = boundary_names[i];
boundary_info.nodeset_name(boundary_ids[i]) = boundary_names[i];
}

AFAIK, node sets are created from side sets by libMesh automatically, so that's probably what you are seeing. I guess the name does not get copied.

If you are creating a named side set, why do you care about the node set name? You need the side set, right?

--

David

Alex Lindsay

unread,

Sep 30, 2015, 3:49:20 PM9/30/15

to moose...@googlegroups.com

On 09/30/2015 02:21 PM, Andrs, David wrote:

On Wed, Sep 30, 2015 at 11:46 AM, Alex Lindsay <adli...@ncsu.edu> wrote:

I've been playing around with meshing in the past couple of days, and I've developed a series of questions (Feel free to answer none, one, or all :-)

1) Is there a way to sequentially order execution of mesh modification? For example I wanted to create a SubdomainBoundingBox and then SideSetsBetweenSubdomains. If I included both of these in my input file, ran with --mesh-only, and then viewed the resulting mesh, I noticed that my sideset did not get created. However, if I ran with just SubdomainBoundingBox, then fed the resulting mesh back in as an input, and then ran with only SideSetsBetweenSubdomains, I got my desired sideset.

See "depends_on" parameter of MeshModifier class.

Perfect. Thank you

2) Running SideSetsBetweenSubdomains produces not only a new sideset but also a new nodeset. Would it not make sense to also give the nodeset the same boundary_name as the sideset instead of leaving it unnamed? Just add the following line at the end of SideSetsBetweenSubdomains.C?:

for (unsigned int i=0; i<boundary_ids.size(); ++i) {
boundary_info.sideset_name(boundary_ids[i]) = boundary_names[i];
boundary_info.nodeset_name(boundary_ids[i]) = boundary_names[i];
}

AFAIK, node sets are created from side sets by libMesh automatically, so that's probably what you are seeing. I guess the name does not get copied.

If you are creating a named side set, why do you care about the node set name? You need the side set, right?

A good point. There's no functional reason to also name the nodeset. I just like seeing matching names when I look at the mesh information.

For consistency's sake, should the end of AddExtraNodeset.C call nodeset_name instead of sideset_name, especially since in this case libmesh is not automatically creating a sideset? I believe there is no functional difference, but perhaps for consistency/clarity.

Alex

--

David

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CADJmAN-5N2NZJcWKnFMiU-SSeEmXZFpNMZ-YZbJJ2gHB1E2QWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Andrs, David

unread,

Sep 30, 2015, 4:09:13 PM9/30/15

to moose...@googlegroups.com

On Wed, Sep 30, 2015 at 1:49 PM, Alex Lindsay <adli...@ncsu.edu> wrote:

On 09/30/2015 02:21 PM, Andrs, David wrote:

On Wed, Sep 30, 2015 at 11:46 AM, Alex Lindsay <adli...@ncsu.edu> wrote:

I've been playing around with meshing in the past couple of days, and I've developed a series of questions (Feel free to answer none, one, or all :-)

1) Is there a way to sequentially order execution of mesh modification? For example I wanted to create a SubdomainBoundingBox and then SideSetsBetweenSubdomains. If I included both of these in my input file, ran with --mesh-only, and then viewed the resulting mesh, I noticed that my sideset did not get created. However, if I ran with just SubdomainBoundingBox, then fed the resulting mesh back in as an input, and then ran with only SideSetsBetweenSubdomains, I got my desired sideset.

See "depends_on" parameter of MeshModifier class.

Perfect. Thank you

2) Running SideSetsBetweenSubdomains produces not only a new sideset but also a new nodeset. Would it not make sense to also give the nodeset the same boundary_name as the sideset instead of leaving it unnamed? Just add the following line at the end of SideSetsBetweenSubdomains.C?:

for (unsigned int i=0; i<boundary_ids.size(); ++i) {
boundary_info.sideset_name(boundary_ids[i]) = boundary_names[i];
boundary_info.nodeset_name(boundary_ids[i]) = boundary_names[i];
}

AFAIK, node sets are created from side sets by libMesh automatically, so that's probably what you are seeing. I guess the name does not get copied.

If you are creating a named side set, why do you care about the node set name? You need the side set, right?

A good point. There's no functional reason to also name the nodeset. I just like seeing matching names when I look at the mesh information.

Sure. A patch in libMesh would be the right way how to fix this. Your proposed patch would fix it only for this one mesh modifier.

For consistency's sake, should the end of AddExtraNodeset.C call nodeset_name instead of sideset_name

It should.

, especially since in this case libmesh is not automatically creating a sideset? I believe there is no functional difference, but perhaps for consistency/clarity.

We have a flag 'create_sideset_from_nodesets' which is off by default. So if that is on, we would be creating sidesets. However, that's again libMesh level, so the proper name coping would take care of proper names...

--

David

Alex

--

David

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CADJmAN-5N2NZJcWKnFMiU-SSeEmXZFpNMZ-YZbJJ2gHB1E2QWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/560C3CB5.3010801%40ncsu.edu.

Andrew....@csiro.au

unread,

Sep 30, 2015, 5:19:44 PM9/30/15

to moose...@googlegroups.com

If this does what Alex wants, then I’d like it in MOOSE. I find cubit/trelis kind of annoying for this kind of thing, but am frequently forced to use it. The problem with cubit/trelis is that it’s a GUI, and when you’ve got zillions of blocks in a very complicated mesh, you have to zoom in just perfectly and click on just the perfect pixel in order to select the correct sideset/block/etc.

So, Alex, what you want is quite like SideSetBetweenDomains, but instead of producing just a (couple of) sideset(s), you want it to produce another block as well, right?

a

--

You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at http://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABk6%3D%2BYwZSjjVXAzMmvu%3DOjZjpk0QJk%3D4QrNybWn5MXQkZOz6Q%40mail.gmail.com.

Alexander Lindsay

unread,

Sep 30, 2015, 5:28:54 PM9/30/15

to moose-users

Yes, I would love to see that capability intrinsic in Moose. The ability to create an interface block as well as a (couple of) sideset(s). I couldn't have said it better :-)

Wang (Non-US), Yaqi

unread,

Sep 30, 2015, 5:45:17 PM9/30/15

to moose-users

Not only that, you need to disconnect subdomains. You also need to break side sets based on subdomains... Alex, you can create an issue and ask MOOSE team for inputs. MOOSE team has the access of that modifier.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/D2328E0C.1DBAB%25Andrew.Wilkins%40csiro.au.

Alex Lindsay

unread,

Sep 30, 2015, 5:58:11 PM9/30/15

to moose...@googlegroups.com

Before I create the issue, I want to make sure that I'm chasing what I really want to be chasing. What I really want, as outlined by both Yaqi (https://github.com/idaholab/moose/issues/1858) and Derek (https://github.com/idaholab/moose/issues/869), is to effectively realize InteriorNodalBC and InteriorIntegratedBCs at interfaces between different physics domains. It's fairly clear to me from the Moose tests that I can realize my InteriorNodalBC using constraints. Can I realize InteriorIntegratedBCs using mortar and constraints? If so, do I need the interface block, sideset(s), and disconnected subdomains (thanks Yaqi), to do this? I'm sorry that I've been battering the Moose list-serve with this idea for the last week.

Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABk6%3D%2Bbgb0WD8utumRQJSOdbLgZzaWayOFb%3DcLK9e7sVMiPxkw%40mail.gmail.com.

Reply all

Reply to author

Forward