On Fri, Jul 7, 2017 at 11:01 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> > > 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. > OK, thanks for the explanation, that's what I thought. David ------------------------------------------------------------------------------ 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
