I just remembered one of the reasons why I left it on hold. It is
because of the partitioning. I will have to keep the same
partitioning on both meshes to avoid high communication costs. The
partitioning criteria should be given by the state mesh, which has
more degrees of freedom.
Okay, I can empathize with this - just a few months ago I put some
code to the effect of "forget it, just force the second mesh to be
replicated and we'll make a serialized solution copy when we need it"
in a MOOSE postprocessor, as a workaround for the lack of a libMesh
facility to synchronize the partitioning in two different meshes.
This obviously isn't something we're going to add short-term, but if
there's more than one current use case maybe it's something to think
about.
It would be easy to add a "CopyPartitioner" subclass that pulls
partitioning from a second mesh. We'd do a point lookup in mesh 2
with the centroid of each element we find in mesh 1, then use in mesh
1 the processor id of the mesh 2 element we find. If the user really
needs full overlap while using AMR, though, we'd also need ghosting
functors in both meshes to make sure that child elements don't get
deleted when they might be needed by a paired mesh, even if they're
not immediate neighbors of local elements in their own mesh. That
would hairier.
---
Roy
Gah, this got buried so deep in my inbox... are you still working on
it?
Post by Salazar De Troya, MiguelWhat’s the current functionality for “subactive” elements?
We can retain coarsened-away elements, in theory indefinitely
including through distributed mesh reidstribution and further
adaptivity, until mesh "contraction" is performed, but in practice
that currently happens within every EquationSystems::reinit() and so
it's probably hiding bugs.
Post by Salazar De Troya, MiguelRight now, I am only interested in having the control mesh defined
as constant monomial elements, maybe this special case could be
easier to implement.
Possibly, since there's no hanging nodes to worry about, but the
question of how to modify Elem::RefinementFlag etc. to indicate
multiple different "active()" element definitions would remain.
Post by Salazar De Troya, MiguelI am not sure how a lookup table could be an efficient
implementation if I want to refine the mesh multiple times. Are
there any examples you can think of?
I am thinking that I could have two different meshes being exact
copies at the beginning, and then keep a siblings relationship
between the elements. For each element in the state mesh, I will
look for its sibling in the control mesh and see their children.
Because the siblings are the same element, those children would be
like the state mesh’s children. This is assuming I don’t do a
different coordinates change on each mesh.
Exactly. Go up the tree saving which_child_am_i() at each step, and
when you get to the top do a lookup on that, then go down the tree of
the other mesh(s).
---
Roy