On Thu, Apr 20, 2017 at 8:06 PM, Roy Stogner <[email protected]> wrote:
> > On Thu, 20 Apr 2017, David Knezevic wrote: > > The context here is that I'm using DofConstraintRows to connect >> non-conforming elements together, like a mortar method. >> > > "like a mortar method" may be an overstatement here. IIRC one big > advantage of mortar methods is that you can preserve conservation > while still not worrying about "locking", since the connection between > sides is only weakly enforced; if you enforce exact constraint > equations then you have to be careful about how. Yeah, it was a bit of an abuse of notation on my part :) This "pointwise" approach can lead to suboptimal convergence rates, and weak enforcement is certainly the standard approach in the literature. But pointwise matching is common in engineering practice (e.g. Nastran provides this type of capability with "rigid ties"), which is my motivation for working on it. > > 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. >> > > On a ReplicatedMesh you should be fine. That change will break on a > DistributedMesh - after you set the constraints, the DofMap will > distribute the dependencies... but without the GhostingFunctor (or > manually setting the paired elements to not be remoted), by the time > you're ready to check which dofs are constrained, the elements they > live on will have been remoted and it'll be too late. > > The PeriodicBoundary code now handles both ghosting and constraint > construction, but it also relies on your coarse sides all matching > precisely. I'd like to write a more "general" class to make that > sort of combined ghosting+constraint code easier for other uses too, > but I fear I can't imagine enough different types of use case, so > whatever I could write now would inevitably miss some capability. > 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. 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
