On Fri, Jul 7, 2017 at 10:31 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> > On Fri, 7 Jul 2017, Manav Bhatia wrote: > > I am working on a case where I need to dynamically add/remove constraints >> on dofs. >> >> I see the method DofMap::add_constraint_row to add a constraint >> row. Is there a corresponding method to delete these constraints >> for the dofmap? >> > > Not a good one, IIRC, and I'm sure you'd have seen it if there was one > I'm forgetting. I think all you could do at the moment is clear > everything then re-add the constraints you want to retain, which > sounds like an awful idea, until you read about the alternatives > below... > > We'd be happy to add a patch which adds this functionality (assuming > it comes with a lot of unit testing so we don't break it again out > from under you!), but I'm afraid that at the moment it's probably much > harder than you're imagining to get it right in the general case: > > For efficiency's sake, we currently pre-expand constraints. So e.g. > if DoF A depends on B and C, and C depends on D and E, and E depends > on F and G, after (re-)initialization time the final constraint row > will have A depending on B, D, F, and G. If you were to then remove > the constraint on C, the constraint on A would now be incorrect, and > what's worse, there would be no easy way to tell it was incorrect, > because in the expanded version there is no remaining A->C connection! > > 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. > > Alternatively, we could keep two constraints data structures, one > pre-expanded and one unexpanded, and use the latter to regenerate > (just the relevant parts of) the former whenever a constraint is > removed. I'm not sure whether this would be easier or harder than the > first option. > 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? 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? 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
