Hi Roy,
Thanks for your comments, I've replied below:
On Tue, Dec 4, 2018 at 5:01 PM Stogner, Roy H <royst...@ices.utexas.edu>
wrote:
>
> On Tue, 4 Dec 2018, David Knezevic wrote:
>
> > I use NodeElems with GhostingFunctor to couple unconnected nodes (i.e. I
> > attach NodeElems to the nodes that I want to couple), and this works
> well.
> > However, I realized that this approach requires me to set the
> processor_id
> > in the NodeElem to match the processor_id of the Node that it points to,
> as
> > per the code below:
> >
> > for (const auto & elem : mesh.active_element_ptr_range())
> > {
> > if(elem->type() == NODEELEM)
> > {
> > elem->processor_id() = elem->node_ref(0).processor_id();
> > }
> > }
> >
> > This seems reasonable to me, but I just wanted to check if this is an
> > expected requirement?
>
> Huh. I need to think about that.
>
> For a mesh to be consistent, each Node is required to have the same
> processor id as at least *one* of the elements which use it, but
> presumably you're tacking NodeElems onto an existing mesh which
> already satisfies that requirement, in which case the processor id of
> the NodeElems can be anything and still be valid.
>
Yes, that's right, I'm tacking NodeElems onto an existing mesh
> For geometric ghosting to work, the processor id of the NodeElem
> determines which processor can also see its ghosted elements. But
> you're just using NodeElem as a hack to get just the right amount of
> coupling working, so geometry is irrelevant here I assume, in which
> case we still have no restrictions on NodeElem pid.
>
Yep, geometry is irrelevant for me. Also, I'm using ReplicatedMesh
currently, so I gather that geometric ghosting is not an issue anyway.
> For algebraic ghosting to work... we loop over active_local_elements
> when building the send_list... and that might be a problem for you,
> huh?! It seems like not only would you need a NodeElem to have the
> right pid for that, but on domain boundaries where two processors'
> elements share a Node, you could need a NodeElem with *each* pid?!
>
> Well, either that or you'd need to use higher-dimensional boundary
> elements. So then NodeElem would be the way to go for boundary
> coupling only on a 1-D mesh; you'd need Edge2/Edge3 elements on a 2D
> mesh, and quads or tris on a 3D mesh. And each boundary element
> would need to match pid with its interior_parent() - it sounds like
> BoundaryInfo::add_elements() may be the safe way to work on these
> sorts of problems.
>
Hmm, ok... well this is interesting. I've used the approach I described a
lot on 3D meshes (e.g. for node-to-surface contact couplings between
surfaces of a 3D mesh) and I haven't run into any problems with it so far.
I do think I have tried cases where I have NodeElems on domain boundaries
where two processors'
elements share a Node, and I haven't had any issues with that. It would be
interesting to reproduce the issue that you have in mind in a test case to
confirm that it really is a problem or not.
The simplest change would be if I just coupled the 3D elements on the
surface directly rather than the nodes on the surface of those elements.
That would be easy enough, but I figured that the approach that I'm
currently using is nicer since it doesn't overallocated the sparsity
pattern (e.g. there is no coupling needed between the inner nodes on the
elements on the surface).
David
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
