This went off-list, but until I have GhostingFunctor documentation in
a better state I should probably at least have decent questions and
answers accessible to Google.
On Thu, 17 Nov 2016, Cody Permann wrote:
I know you dive into more detail in the next paragraph but I want to
make sure I'm clear of your term semilocal. IIRC, prior to this new
code commit, semilocal in libMesh was exactly the set containing all
nodal neighbors of the local set.
All nodal neighbors of *ancestors* of the local set, too. That was
obviously grossly inefficient in heavy AMR cases, but I'm afraid I'm
still digging up DistributedMesh bugs triggered by code which was
assuming it would be able to access all those.
This means it's actually a superset of both C(K) and E(K), correct?
Correct, and generally a strict superset too.
OK, so now I know exactly what I need for my GrainTracker work. I'm
not sure how much you are up on that but I've decided that I just
need local_active_elements for initiating my flood fill algorithm
(that's what I've always been using so no change there). I'll start
using the new "evaluable" call though as I visit elemental neighbors
which is safer than the current logic of visit iif the current
element is owned by the current processor.
Objects owned by the current processor should always be evaluable, but
the converse isn't true, so yeah, once you get one layer out then
you're no longer guaranteed evaluability unless you test.
Later I need to create (or more accurately, expand) a halo region
around each partial feature found with the flood algorithm. This
halo width is user definable, but in practice is fixed for every
problem I've ever run at "2". I believe with the proper expansion
logic near processor boundaries, I can get away with a G(K) set
width of "halo_width - 1" which means that I should already be able
to see the elements that I need for all my current cases without any
additional work. If a user wanted to play with a larger width
though, it'd be handy to have the geometric functor I need.
Do you mean halo_width + 1, not -1?
We (MOOSE developers) need to design how these functors are created
and attached to libMesh. We need need some guidance on when this has
to occur (i.e. Does this happen before/after EquationSystems.init(),
is that a strict requirement?).
Ah; good question!
So here's the big current limitation in theory: at the moment, on a
DistributedMesh, we can only handle things automatically if the
definition of G() is constant or shrinking after the Mesh is first
prepared for use; we can never automatically handle an *expansion* of
G(). (well, not *never*, but trying to fit a problem into the
exceptions wouldn't be worth the effort).
In practice, where this gets tricky is that the default G() definition
may *require* expansion, so you need to make sure to do all of that
before prepare_for_use() gets called. Take a look at the
adaptivity_ex5 changes for a subtle example: we need to set up
PeriodicBoundaries *before* the Mesh is read, because if we don't then
a DistributedMesh won't know that periodic neighbors exist and it will
throw them away.
Likewise, if you're adding an algebraic ghosting functor, then you
have to do it not only before EquationSystems::init() but also before
Mesh::read(). If that's not possible (does Moose get the
EquationSystems built before the Mesh is read?), then what you'd have
to do is also hand the same functor to the Mesh as a geometric
ghosting functor.
The limitation with E() and G() is less onerous: algebraic and
coupling functors get used by ImplicitSystem initialization, so they
need to be available at that time. But in those cases you can always
expand the E() or C() functor definition (up to the limit of G()) at
any time, so long as you reinit() afterward.
What information would be available at the time the functor is
invoked?
Geometrically, pretty much everything. You get handed a list of
elements (which is often a one-element list), and you hand back
elements which are connected to them, and the whole mesh is available
for you to look at at this time.
Algebraically, there's a chicken-and-egg problem; obviously if you
need to be able to return a sane coupling definition during
EquationSystems::init() then you're not going to be able to rely on
the system solution during that first step. You could use solution
data during later reinit(), though you'd only have access to the
ghosted data made available by the previous functor's results.
I'm staring at the API and still don't think I fully understand what
I need to do to create my new functor. Let's take the case where I
simply want to expand the thickness of ghosted elements around each
partition. I understand that the global set that I need can be
constructed from all of the edge neighbors of all existing ghosted
elements. I could simply repeat that process n-1 one times for an
arbitrary thickness n and do some set operations to remove existing
ghosted elements.
Pretty much. Take a look at the algorithm in DefaultCoupling (which
gives you n layers of side neighbors) or PointNeighborCoupling (which
gives you n layers of point neighbors) for examples. In hindsight I
could probably refactor those to use a common base class, which you
could then derive from too to make your FeatureCoupling simpler; let
me know if that would help.
The functor though operates on a range of elements, what is that
range.
That's the tricky bit. You need to be able to return valid results
for any range. When we're deciding how to delete remote elements from
a DistributedMesh, we'll query functors about all active local
elements. When we're deciding how to redistribute elements on a
repartitioned DistributedMesh, we'll query functors about subsets of
active local elements which are destined to move to different
processors. When we're building a sparsity pattern we'll query
coupling functors about only one element at a time!
---
Roy
------------------------------------------------------------------------------
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
