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.
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.
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.
---
Roy
_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
