Fix distributed periodic constraints bug #2590
Conversation
Finding cycles of constraints is easier when there's only one in the cycle. This turned out to be a red herring for the bug I'm investigating but it might be a good idea later.
This helped pin down a bug, and has been cleaned up enough we ought to be able to leave it in for good.
It turns out that, without ghosting of all point neighbors, we can't trust find_point_neighbors to return a complete set for partition boundary points on a distributed mesh, which means we can't necessarily look at a complete set of element ids to disambiguate which side should constrain which. Looking at the specific points themselves to disambiguate constraints fixes the problem for me, at least on the case where it manifested, systems_of_equations_ex9.C with 21 processors.
|
I can reproduce the failure here; it's definitely a real regression, if not due to this patch then triggered by this patch. |
|
Ouch. The regression appears to be merely triggered by this patch; the old code could hypothetically end up failing on corners with multiple periodic boundaries as well, if the element ids ended up being assigned in a particularly perverse way; we've just been lucky enough (hopefully!?!) not to see that. In hindsight this probably should have been a fix or at least an assertion rather than a comment... |
|
This PR has been marked "do not merge" since we are no longer accepting PRs into the |
I noticed some time ago that there was a regression in periodic boundary conditions on distributed mesh on some weird corner case (I could run libMesh "make check" on up to 20 procs, before triggering an assertion failure in one example with 21 procs), but I've only just now managed to track down the problem - when I reduced the amount of default ghosting libMesh does (to include side neighbors but not all point neighbors) I missed one bit of code that was still occasionally depending on
seeing point neighbors.