On Fri, 7 Jul 2017, David Knezevic wrote:
It would be reasonable to (optionally) forgo this pre-expansion, but
a bit of other code would have to be added to handle the unexpanded
case. Dependency constraint equations would have to be communicated
properly on DistributedMesh while leaving the dependent constraints
unmodified, the send_list construction would have to be able to handle
indirect dependencies, and enforce_constraints_exactly() would have to
either walk through dependency trees or iterate up to the maximum tree
depth, just off the top of my head.
Just wondering: Don't we already have code for the "unexpanded
case", i.e. the "called_recursively" codepath in
DofMap::build_constraint_matrix_and_vector?
We do, and I don't know of any reasons it wouldn't work correctly on
ReplicatedMesh still. (except for bit rot over the years since we
used it, but that would be straightforward to debug)
But IIRC we've never used that codepath in DistributedMesh, and it
wouldn't work with the current DistributedMesh, which only stores the
(expanded) constraints corresponding to (either local or semilocal,
IIRC the latter) DoFs. If a DistributedMesh processor knows that A
depends on B and C, and C is a constrained remote DoF that this
processor only receives via the send_list, then DistributedMesh won't
currently store the constraint equation for C, so the constrain_foo
code paths won't see a constraint there, so they'll get the result
wrong. We'd need to modify the distributed case code in DoFMap to
make sure that all processors with constrained DoFs have direct
permanent storage of all dependency constraints, not just the
temporary knowledge that they currently use while expanding the
dependent constraints.
Though my understanding is that the "called_recursively" code
doesn't get used at the moment because of the constraint
pre-expansion that you mentioned, is that right?
I believe so.
---
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
