idaholab
Group mesh-modifying user objects into a specific mesh modifier / other name syntax
Motivation
@dschwen @hugary1995 and others have built up quite a bit of capabilities in UOs that modify the mesh. This could be consolidated into a system / dedicated syntax for:
- increased visibility
- easiness to use / readability of the input file
- create a clear path for re-meshing during simulations, spurring research in numerical techniques for advanced manufacturing, modeling of complex phenomena (fuel melting? fuel dispersal?)
Design
Either:
- we figure out how to make mesh generators execute outside of the initial mesh generation phase.
This would likely involve:
- creating a new syntax (MeshModifier?)
- registering some of the generators to both syntax
- move some of our UOs from the [UserObjects] syntax into the new one
- when inside the Mesh block, use the meshGeneratorSystem with all its complexities and capabilities (data driven, dependency resolution, saved mesh, output on every step, ...)
- when inside the MeshModifier block, probably just keep the same ordering of execution that the MG system would create.
- create a new system and place new objects, no MGs, there
The tradeoff is likely (partial) code duplication (2) vs code complexity (1). This will likely involve:
- create a new syntax (need a name)
- moving our modifying UOs there
- create a base class for mesh modifiers
- maybe create an interface class that can call a MG from the MM system
Cool things with (2) that make me thing it is the way:
- since we are in the solve we could re-introduce threading to mesh generation. UO base classes can be threaded
- I dont think we need the whole dependency resolution, so we could drop complexity a lot. We could support a single linear branch and that's it. Besides the dependency resolution would be difficult if we have interleaving execute_on options! Imagine mm1 on begin/linear and mm2 on begin/nonlinear and mm3 on linear/nonlinear, with mm3 depending on mm1 and mm2 and mm2 depending on mm1, on their respective flags
- we have a MooseMesh at this point! New capabilities, new routines. Not a ton more than a MeshBase, but could be significant
- we also have access to variables at this point, very different from MGs
- we also have the displaced mesh and the displacement vectors. Probably tons to be done from there in terms of re-meshing
- no need to add execute_on parameters to MGs that we would need to silence. No need to add logic in MGs that only apply to cases during the execution of the simulation
- There is a lot to do in terms of fixing variable values after changing the mesh, projections, initializations, extrapolations etc. This could benefit from a new class
Note that there is some overlap between this and Executor capabilities. We are considering Executor mesh-modification / adaptivity and this new system would be related. It's more straightforward to do this than push people to Executors for this imo.
Impact
Easier for users to see our whole array of in-simulation mesh-modification capabilities Easier for user-devs to contribute and add what they need inside a dedicated system
Thoughts on the names? If I gather a few options here we can submit them to a vote on the moose slack
- MeshModifiers
- ReMeshers
- MeshAdjusters
- MeshTransformers
- MeshAdapters
- DynamicMeshGenerators
- MeshMutators
If I get this right, in the future this would have the ability to call Mesh System objects like SmoothMeshGenerator or ParsedNodeTransformGenerator? Both could be useful for "remeshing" elements that become highly skewed.
Either we use those. (could be tricky, there's a lot that goes in the [Mesh] block) or we add a new MeshSmoother object in the new system
Personally I am leaning into making a new system. See the list of reasons in the initial post
It would be interesting to see the return of MeshModifiers. That might be my vote
My vote would be MeshModifiers.
This could be a thrust area. See some potentially related discussion: https://github.com/idaholab/moose/issues/23371
It would be interesting to see the return of MeshModifiers. That might be my vote
I'd agree.
