On Thu, 17 Nov 2016, Cody Permann wrote:
> This question is probably for you. I'm curious if we've gained or could
> potentially gain a method for looping over all "coupled" elements (if this
> is the right terminology). Let me try to clarify what I mean since we've
> used the wrong terminology for so long and I'm probably still using it
> incorrectly here.
We don't really *have* a right terminology set in stone, since it
wasn't until this summer that we realized how complicated the problem
really is. But the working terminology is in comments and APIs, so if
we're about to start using those APIs more heavily and any of the
names sound stupid to you, speak now or forever hold your peace.
For a long time I've been referring to elements as "local"
(owned by the current rank), "ghosted" (non-local, but present as a
copy on the current rank), or "semilocal" (either local or ghosted).
But now if you really want to get specific those last two definitions
ought to be for "geometrically ghosted" elements, and we could also
talk about "algebraically ghosted" (a.k.a. "evaluable") elements
(which are present in the mesh and which also have all of the
coefficients of basis functions they support present in system
solution vectors) and "coupling ghosted" (a.k.a. "coupled") elements
(which are present in the mesh and which have entries in the sparsity
pattern coupling their DoFs to local elements' DoFs, not just on
shared interelement boundaries).
Oh, and if you *really* want to get specific then you have to keep in
mind that the same element can be algebraically ghosted with respect
to one system on it but not another, or even with respect to one
variable within a system but not another.
> I want to loop over all elements that are part of what I would call the
> normal ghosted set of elements where both geometric and algebraic
> information is available due to domain decomposition.
Including the local elements as well? This is what I've been calling
"algebraically semilocal" or "evaluable" elements.
> Looking at your Ghosted Functor base class, this might be your C(K)
> elements? Actually, I'm a little hazy on the difference between C(K)
> and G(K) so maybe you can clarify.
I'll start by putting in a quick commit to fix up that comment; I
appear to have screwed up the wording there at one point.
Let {K} be the set of elements local to your rank.
G({K}) is the geometrically ghosted stuff. Very important for getting
ParallelMesh working back in the day, but not what you care about.
E({K}) is the evaluable stuff, a subset of G({K}). This is what you
care about if you're trying to evaluate a solution on an element.
C({K}) is the coupling-ghosted stuff, a subset of E({K}). This is
what you care about if you're trying to fill in a Jacobian entry whose
integral is supported on an element.
> John was suggesting that constraints might be the difference between
> these two sets?
Nope. There's still separate code for getting constraint dependency
dofs onto the send_list for MPI communication. That process depends
on the above definitions (we look for dependencies of any DoF
supported on E({K}) now) but not vice-versa.
> In MOOSE we previously (but incorrectly) called this set, the
> "semi-local elements".
Right. My vote would be to go with "evaluable" or "coupled" elements
now, depending on which of E({K}) and C({K}) you care about. You
probably don't even have any problems where E({K}) differs from C({K})
(Derek was skeptical that such problems could exist until I provided a
couple examples) but best to think about the matter too early rather
than too late.
> If this predicate or iterator doesn't exist,
It does, for E({K}). That's MeshBase::evaluable_element_begin/end.
Initializing it takes a DofMap (to handle the "definitions of
evaluable are different on different systems" problem). It optionally
takes a variable index (to handle the "definitions of evaluable are
different on different variables" problem), but if you don't give it
such an index then it will return all elements that are evaluable for
*some* variable.
> should we create it,
If the above isn't what you need, then yes; just let me know what you
want instead. We don't currently have an iterator for only the
ghosted parts of E({K}), or for E(S) where S is a set of elements
other than the local elements {K}, or for C({K}). Adding an iterator
over E({K})-{K} would be easy; any of the rest would be much trickier.
---
Roy
------------------------------------------------------------------------------
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
