Hi Roy I just wanted to follow up on this thread regarding this:
> 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. > I looked into this a bit further. I removed the GhostingFunctor associated with "non-local" DofConstraintRows to see what would happen, and when I did that I ran into the issue that we discussed in a previous thread (subject "Dof constraints and GhostingFunctor"), and which led to your PR #1120. So I believe what happens is that for most cases we do not need to use a GhostingFunctor to "accompany" a non-local DofConstraintRow, however there are special cases (e.g. when the non-local DofConstraintRow "touches" another non-local term like the interface terms in misc_ex9) in which the GhostingFunctor is required. Does that sound right to you? 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
