On Tue, 4 Dec 2018, David Knezevic wrote:

> Yep, geometry is irrelevant for me. Also, I'm using ReplicatedMesh
> currently, so I gather that geometric ghosting is not an issue
> anyway.

That's correct.

> 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.

I guess it depends how you add the coupling terms.  If you're
currently giving each NodeElem the same pid as its node, and if you're
also exclusively *calculating* their interactions on that pid, then
you should be fine.  I was thinking about the case where you specify
interactions as integral terms along the element boundaries.

> 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.

It would.  4 quads in 2D should be sufficient.  This might be a
good idea if you have time, even if it is currently working, just as
defense against me accidentally breaking it in the future.  :-D

> 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).

That's right.  If you were using integral terms (which is what you
want for general contact problems, right, where the nodes might not
line up perfectly?) then the boundary element approach should get the
sparsity pattern right, though.
---
Roy


_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Reply via email to