On Thu, Apr 20, 2017 at 4:50 PM, Roy Stogner <[email protected]> wrote:
> > On Thu, 20 Apr 2017, David Knezevic wrote: > > Not sure what you mean by DofCoupling. Do you mean entries in >> the send_list? We do generate any entries needed by >> constraint equations, automatically. >> >> I mean do we need to define a GhostingFunctor subclass in this case >> that specifies the coupling and call DofMap::add_coupling_functor >> (e.g. like we do in miscellaneous_ex9) in this case, or is this >> unnecessary? >> > > In theory it should be unnecessary. > > In more complicated theory... I know we add dependencies to the > send_list for constrained local DoFs, but off the top of my head I'm > not sure about constrained ghost DoFs. That shouldn't make a > difference, though, since those get calculated on their local > processors and then themselves synced via the send_list. > > And in practice? This was one of the first bugs that ever had me > running a debugger on a dozen processors, because that was what it > took to reproduce the "DoF on proc A constrained by a DoF on proc B > which is constrained by a DoF on proc C" case. I think I fixed all > the corner cases years ago, but if you see anything suspicious let me > know. > OK, thanks, that's very helpful. The context here is that I'm using DofConstraintRows to connect non-conforming elements together, like a mortar method. In this case we have slave nodes on one surface that are constrained in terms of master nodes on the other surfaces. These master/slave surfaces are not neighboring (in the elem->neighbor sense), so I assumed that I had to using the GhostingFunctor stuff to make sure everything gets allocated properly, but I gather from your comments that that is not necessary (at least "in theory"), right? I will try removing the GhostingFunctor stuff for this "mortar" app and see if that breaks anything. Thanks! 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 [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
