On Tue, May 2, 2017 at 12:00 PM, Roy Stogner <[email protected]> wrote:
> > > On Mon, 1 May 2017, David Knezevic wrote: > > 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. >> > > Yeah; the only reason to ever *not* use a GhostingFunctor is > efficiency, and even that's questionable. You might be able to "push" > a few connections manually with less CPU time than is necessary to > "pull" queries. But even with the "pull" model it's only the sparsity > coupling calculation that has to query elements one by one; everything > else asks about huge ranges so if you're only adding an algebraic or > geometric functor then you can amortize a bit. > > 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? >> > > Hmm... if we have local constraints which depend on non-local > constraints, then that gets taken care of automatically without > ghosting functors. > > I guess the misc_ex9 case is special because we have non-local > Jacobian terms? That means: > > 1. We need a coupling functor or a manually augmented sparsity pattern > to get the matrix preallocation right. > > 2. We need a coupling functor or an algebraic functor to get the > non-local-terms-which-depend-on-non-local-constraints part right. > Otherwise I guess the constraints communication code doesn't realize > that those constraints are relevant? I'm not sure I understand this, > though; if you're working on a ReplicatedMesh then IIRC the constraint > equations are all replicated too. > > 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. >> > > That's what it's here for! > > In theory we *ought* to be able to use the existing augmentation > functions to do what the coupling functors do, but it's such a big > PITA that I hope nobody bothers now that there's a better alternative. > Thanks very much for your comments. It seems the first issue I hit when I turn it off are sparsity pattern errors, as discussed in your points 1 and 2 above. I think the GhostingFunctor stuff is great, and I will happily always use it for all non-local couplings. My motivation for turning it off was only that I wanted to understand better which terms needed it and which terms didn't, and to understand if non-local constraints had different requirements than other types of non-local couplings. 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
