On Sun, Apr 30, 2017 at 10:19 AM, David Knezevic <[email protected] > wrote:
> 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? > P.S. There are also cases where I need to use DofMap::add_coupling_functor to "accompany" a DofConstraintRow in order to get the sparsity pattern right, i.e. I get the "New nonzero at (X,Y) caused a malloc" PETSc error if I remove the GhostingFunctor. A simple case when this occurs is when when I have dof A constrained in terms of dof B via a DofConstraintRow, dof B is on an isolated node (the node belongs to a NodeElem only), and I have a Dirichlet constraint on dof B. This case works fine if I specify the dof A/dof B coupling via DofMap::add_coupling_functor, so I guess the safe rule-of-thumb that I'll follow from now on is to use DofMap::add_coupling_functor whenever I have a "non-local" constraint. 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
