Open lindsayad opened 5 years ago
How big is the mesh here? Can you set up a failure case I can use to reproduce the problem?
This is 951 elements. This is from a pretty involved example with a moose application that is relatively unknown and one that we don't even test. I'll see if I can produce a more minimal example using just MOOSE object, but it might take be a while to get around to it.
On Fri, Feb 8, 2019 at 9:42 AM roystgnr notifications@github.com wrote:
How big is the mesh here? Can you set up a failure case I can use to reproduce the problem?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/libMesh/libmesh/issues/2026#issuecomment-461865767, or mute the thread https://github.com/notifications/unsubscribe-auth/AJxgcLaMEiQ48in_h_SXZiFRQSKcmFzgks5vLakKgaJpZM4aqnal .
This may have something to do with #1678. We had a user come to us with a parallel
DisplacedProblem
simulation running with--distributed-mesh
that fails with a PETSc error like:The problem occurs when we try to sync the
displaced_system.current_local_solution
with theundisplaced_system.current_local_solution
. The global and local sizes of these vectors are the same; however, the_send_list
is different. The_send_list
is larger for theundisplaced_system
because the number of elements to ghost is larger by two elements (for both processes: 67 vs 65 for processor 0; 65 vs 63 for processor 1). I latched onto one of the elements (element 1448) that is ghosted for theundisplaced_system
on processor 0 but not for thedisplaced_system
. 1448 is a neighbor of element 664 in the undisplaced system, but not in the displaced system!An lldb summary:
This corresponds to the the undisplaced equation systems:
This corresponds to the displaced systems:
Summary
The zeroth neighbor of element 664 for
undisplaced
has a totally different id and centroid than the zeroth neighbor for thedisplaced
systems.Important notes
skip_find_neighbors = true
toUnstructuredMesh::copy_nodes_and_elements
, then there is no issue whatsoever, so for me this points to something happening inUnstructuredMesh::find_neighbors
.TET4
but that (as shown by the lldb session) contains lower dimensionalTRI3
elements. The issue here is happening for aTRI3
element and neighbors, but perhaps the presence of the higher dimensionality elements is playing a role?