idaholab
Need a callback in FEProblemBase for performing extra work after displaced mesh is updated
Motivation
We have an object constructed from the displaced mesh that should be reintialized after the displaced mesh is updated by DisplacedProblem::updateMesh. Currently, we have to put this reinitialization in several places so that we can have the object in synchronization with the mesh before its operation. This is not ideal. I am think to have a virtual function in FEProblemBase named as onDisplacedMeshUpdate, so that it can be called within DisplacedProblem::updateMesh. We can perform an optimization by letting UpdateDisplacedMeshThread in updateMesh to return a flag indicating whether the mesh is indeed changed or not and call onDisplacedMeshUpdate when mesh is indeed changed. With this, I can add my object reinitialization in onDisplacedMeshUpdate and do not need to worry about its synchronization.
Design
My proposed design is described in the Motivation.
Impact
This will make synchronization of objects depending on the displaced mesh sound.
why does the object need to be reinitialized after the displaced mesh is updated?
and why can't you use the MeshChangedInterface? Does that interface work only for objects?
why does the object need to be reinitialized after the displaced mesh is updated?
The test user object does not, but in Griffin, the sweeper is built on the displaced mesh. When the displaced mesh is updated, we need to reinit the sweeper to reflect the node displacement.
and why can't you use the MeshChangedInterface? Does that interface work only for objects?
That is designed for mesh adaptation. Updating the displaced mesh is not considered as a mesh change, i.e. not trigger meshChanged.
the advantage of interface with a similar design as meshChangedInterface is that it becomes a real moose capability, objects can be made to "do something if mesh displaces". Whereas a simple call back that does nothing by default, and is only essentially implemented in a Griffin executioner, does not really bring new opportunities for users. It also opens the door for Griffin and another app to implement that callback differently and be even more incompatible in a multi-system setup
becomes a real moose capability
I think I like this idea. But it will be a much more significant change in framework. If the moose team wants it, I can give a try and update the PR.
we need to reinit the sweeper to reflect the node displacement
the sweeper depends on the node locations?
That is designed for mesh adaptation
It's not just for mesh adaptation. It's used for things like subdomain ID changes as well
we need to reinit the sweeper to reflect the node displacement
the sweeper depends on the node locations?
Yes.