On Wed, 20 Mar 2019, Alexander Lindsay wrote:
> In MOOSE we often have two meshes, a reference (un-displaced) and a > displaced mesh. We want to be able to sync ghosting between the two meshes. > Currently I am running into issues when I am running a displaced problem > with AMR. IIRC I worked on something only slightly harder than this once, with OversampleOutput.C, and gave up to work on more low-hanging fruit first, which can't be a good sign. > I first call the reference EquationSystems::reinit which coarsens, > constricts the mesh, and then refines. Now when I call the displaced > EquationSystems::reinit, during coarsening we call DofMap::distribute_dofs > which calls through to our ghosting functors. We set up a proxy ghosting > functor which essentially loops over the ghosting functors and elements of > the reference mesh, determining what elements were ghosted on the reference > mesh **and then** ghosts the corresponding element IDs on the displaced > mesh. This works great except when we have AMR. The problem is that the > mesh constriction of the reference mesh has deleted its inactive elements > and then renumbered. We are calling distribute dofs on the displaced mesh > **before** we've done the same constriction, so we have an out-of-sync > correspondence between the reference and displaced element numbering. > > Does anyone have a suggestion for a good solution here? What's the best way > to sync_ghosting()? I'm not sure what the best way is, but let me think... Doesn't MOOSE already require unique_id support enabled? If so then it wouldn't cost anything extra to keep your corresponding elements mapped to each other by unique_id() and forget about shifting id() numbers. Even without unique_id support you can always (locally) use Elem* to uniquely identify an element... but the trouble here is that element deletion (including through coarsening) invalidates any such map. Perhaps you could do a trick we use when syncing mid-refinement data, and identify elements via a pointer to the *parent* element plus a short int for which child of that parent they are? Except that would *only* work for the removal of elements remoted by AMR, not repartitioning ... and it would even leave dangling pointers in some AMR cases, just not in the case where elements were disappeared by coarsening. If you refine an element and you only own its child(ren) on one side then you can end up remoting *all* elements adjacent to the other side, straight up the hierarchy. I guess you'll never be *asked* for a map lookup leading the elements that have been remoted, but having dangling pointers floating around still terrifies me. Would it make sense to combine the parent+child_number lookup with a delayed delete_remote_elements() behavior? You could always turn off automatic deletion of remote elements, then call it manually, on the displaced mesh *before* the original mesh, after mesh modification operations. --- Roy _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
