Discussion:
[Libmesh-users] Multiple meshes
Salazar De Troya, Miguel
2017-05-23 15:18:04 UTC
Permalink
Hello,

I want to use different discretization for the control and the state variable in an optimization problem. Is this possible in libMesh? I could imagine that having two different meshes would be expensive because for each Gaussian point in the state mesh we would have to find the corresponding element/s in the control mesh. Maybe both meshes could be actually the same mesh data structure, but they are defined by different depth levels. For instance, the control elements could be children of a state element. Is this feasible to implement?

Miguel
Salazar De Troya, Miguel
2017-05-24 16:13:14 UTC
Permalink
What’s the current functionality for “subactive” elements? Right now, I am only interested in having the control mesh defined as constant monomial elements, maybe this special case could be easier to implement. I 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.

Miguel

--
Post by Salazar De Troya, Miguel
I want to use different discretization for the control and the state
variable in an optimization problem. Is this possible in libMesh?
You can get uniformly different discretizations by using different
finite element types, but for any truly independent adaptive
refinement you'll need multiple Mesh objects.
Post by Salazar De Troya, Miguel
I could imagine that having two different meshes would be expensive
because for each Gaussian point in the state mesh we would have to
find the corresponding element/s in the control mesh.
Right. Trying to do this on the fly with point locators would turn
your O(N) assembly functions into O(N log N), so you'd want to keep a
lookup table cached.
Post by Salazar De Troya, Miguel
Maybe both meshes could be actually the same mesh data structure,
but they are defined by different depth levels. For instance, the
control elements could be children of a state element. Is this
feasible to implement?
Yes, but not easily. This was actually one of the goals behind the
idea of "subactive" elements, and it would be possible to redefine the
ancestor/active/subactive methods to take a "view number", while
adding additional complexity to the refinement_flag settings to
accomodate multiple views...

But this would require changes in hundreds of places in libMesh. I
wouldn't recommend trying it until *after* you have multi-Mesh
results, and even then only if you're sure you need more memory
efficiency.
---
Roy
Roy Stogner
2017-06-28 19:44:38 UTC
Permalink
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, Miguel
What’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, Miguel
Right 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, Miguel
I 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
Continue reading on narkive:
Loading...