Sideset Nodeset generation cleanup

[permcody]

Rationale

MOOSE currently generates nodesets automatically for every sideset in the mesh. This is useful because it allows developers to apply nodal boundary conditions naturally to sidesets where they logically make sense without having to create explicit nodesets in the mesh generator. Additionally, this means that adaptivity works properly for generated nodesets.

The problem is that if somebody creates unrelated sidesets and nodesets with the same IDs or names, they might be clobbered by MOOSE. We'd like to maintain the behavior of generating nodesets but do it in a way that's consistent and safe. Also, with the explosion of sideset generation mesh modifiers, it would be nice if developers didn't have to explicitly create nodesets. This function should be handled by the framework.

Description

No test cases have been created for this capability, but we need to cleanup all of the existing modifiers, and add error messages if clobbering is about to occur. All of this needs to be documented as well. These features are important and rather mysterious to developers.

Impact

More robust framework behavior.

Tagging @YaqiWang and @friedmud. See if I've captured this ticket accurately.

[YaqiWang]

I think node set ID and side set ID are managed separately in Exodus and in libMesh. User can always generate a node set from a side set on his own. libMesh currently always generate node set when a side set is generated, right?

[permcody]

That's not a libMesh function, but a MOOSE function. We do it to make applying any kind of BC easy and consistent.

[friedmud]

I'm interested in what you're thinking here. Make sure you think about how this will be presented downstream to visualization tools as well.

I don't really see the need for this. We could just provide a warning (or applications could optionally turn it into an error) if a mesh contains a nodeset with the same numbering as a sideset. We really just shouldn't allow that (or only allow it with a specified option in the Problem block)

On Thu, Oct 5, 2017 at 3:09 PM Cody Permann notifications@github.com wrote:

That's not a libMesh function, but a MOOSE function. We do it to make applying any kind of BC easy and consistent.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/10029#issuecomment-334563091, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1JMZujOoc5MjzmOHAG60aKB3E7_44Dks5spSl1gaJpZM4PvVQE .

[permcody]

@friedmud - I'm fine with that solution. At the very least the behavior of MOOSE should be documented so that people know not to overlap numbering. Then we run like we always have. I recall offsetting all of our nodeset IDs by 1000 way back in the day. At any rate, we've lost consistency along the way and need to clean it even if we like the old behavior as is.

[friedmud]

The offsetting by 1000 is something we did in the mesh generator (for the fuel rod mesh generator) not something MOOSE did... and we did it for this reason: to keep our own generated nodesets separate from anything MOOSE would generate.

After more thought on this topic I agree that just having it throw an error if you try to load a mesh with nodesets numbered the same as sidesets is the right answer. Just please also add an option to override that capability (probably in the [Problem] block) in case it really is what you want to do (I have actually done this on purpose before... picked a few nodes that I know will also get all the nodes from the sideset added to it).

[permcody]

Well this just bit a user on the mailing list. Time to move forward and start warning people or better yet throwing errors when we are about to clobber an existing entity: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/moose-users/95fl-wiWIdM/EWDFkQ2iDAAJ

[permcody]

Notes: Implementing this correctly will be a little bit challenging. We don't want to just see if there are collisions among the boundary IDs themselves because this will be two restrictive any any kind of restart or recovery situation where the users are using the default "build node set from side set" option. We'll want to actually check to see if the node set exactly corresponds with the same side set to avoid that problem. With distributed mesh that gets even trickier...

[friedmud]

I think in the case of restart you just wouldn't do the check. Presumably the check was done on the initial startup so the mesh as it's written out in the restart file should be good.

On Mon, Nov 13, 2017 at 2:46 PM Cody Permann notifications@github.com wrote:

Notes: Implementing this correctly will be a little bit challenging. We don't want to just see if there are collisions among the boundary IDs themselves because this will be two restrictive any any kind of restart or recovery situation where the users are using the default "build node set from side set" option. We'll want to actually check to see if the node set exactly corresponds with the same side set to avoid that problem. With distributed mesh that gets even trickier...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/idaholab/moose/issues/10029#issuecomment-344035787, or mute the thread https://github.com/notifications/unsubscribe-auth/AA1JMRrlQa6FSqZY1ei5_5JRh1CHFuimks5s2JyvgaJpZM4PvVQE .

[GiudGiud]

related to #18873