On Wed, Dec 5, 2018 at 8:51 AM Stogner, Roy H <royst...@ices.utexas.edu> wrote:
> > 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. > OK, that makes sense. I am exclusively calculating their interactions on the same pid, so that explains why it works fine. > > 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 > OK, I'll look into that at some stage, thanks for the suggestion. > > 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. > We currently do node-to-node (when the nodes line up perfectly) as well as node-to-surface and surface-to-surface, which are two different approaches that both handle the case where the nodes don't line up. Surface-to-surface is the case you have in mind, and in that case I couple the 3D elements directly (which is a bit of overallocation as discussed above, coupling boundary elements as you described would be more precise). Node-to-surface involves coupling a "slave node" with a "master side", and that's the case where we use the NodeElem coupling, i.e. couple the slave NodeElem to the master NodeElems. Best, David _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
