On Mon, 1 May 2017, David Knezevic wrote:
OK, thanks for this info. Based on this I think I will just keep the
GhostingFunctor in place, since I already have it implemented. I'm
only using ReplicatedMesh at the moment, but I'd like to have to
option to switch to DistributedMesh in the future.
Yeah; the only reason to ever *not* use a GhostingFunctor is
efficiency, and even that's questionable. You might be able to "push"
a few connections manually with less CPU time than is necessary to
"pull" queries. But even with the "pull" model it's only the sparsity
coupling calculation that has to query elements one by one; everything
else asks about huge ranges so if you're only adding an algebraic or
geometric functor then you can amortize a bit.
I looked into this a bit further. I removed the GhostingFunctor
associated with "non-local" DofConstraintRows to see what would
happen, and when I did that I ran into the issue that we discussed
in a previous thread (subject "Dof constraints and
GhostingFunctor"), and which led to your PR #1120.
So I believe what happens is that for most cases we do not need to
use a GhostingFunctor to "accompany" a non-local DofConstraintRow,
however there are special cases (e.g. when the non-local
DofConstraintRow "touches" another non-local term like the interface
terms in misc_ex9) in which the GhostingFunctor is required.
Does that sound right to you?
Hmm... if we have local constraints which depend on non-local
constraints, then that gets taken care of automatically without
ghosting functors.
I guess the misc_ex9 case is special because we have non-local
Jacobian terms? That means:
1. We need a coupling functor or a manually augmented sparsity pattern
to get the matrix preallocation right.
2. We need a coupling functor or an algebraic functor to get the
non-local-terms-which-depend-on-non-local-constraints part right.
Otherwise I guess the constraints communication code doesn't realize
that those constraints are relevant? I'm not sure I understand this,
though; if you're working on a ReplicatedMesh then IIRC the constraint
equations are all replicated too.
This case works fine if I specify the dof A/dof B coupling via
DofMap::add_coupling_functor, so I guess the safe rule-of-thumb that
I'll follow from now on is to use
DofMap::add_coupling_functor whenever I have a "non-local"
constraint.
That's what it's here for!
In theory we *ought* to be able to use the existing augmentation
functions to do what the coupling functors do, but it's such a big
PITA that I hope nobody bothers now that there's a better alternative.
---
Roy
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
