Skip to content

Conversation

roystgnr
Copy link
Member

I don't recall whether @YaqiWang hit this bug or whether I found it while investigating the issues he did hit in #4180, but either way thanks go to him for pushing at a mix of capabilities that hadn't been properly tested and working before.

Previously, we couldn't correctly serialize a distributed boundary mesh, because the Elem Packing code would try to find interior parents by id in the wrong mesh. Now we can, by keeping track of the "interior mesh" (which defaults to this) for any given mesh.

Unit tests here fail (when running on a few ranks) without the preceding commits' fixes.

roystgnr added 3 commits May 28, 2025 09:22
When working with a BoundaryInfo-generated mesh whose interior_parent()
pointers point back to a *different* mesh, we need to be able to get
at that different mesh if we want to be able to serialize and
unserialize interior parent data.
This fixes a bug with serialization (or redistribution, probably) of
distributed boundary meshes
@moosebuild
Copy link

moosebuild commented May 28, 2025

Job Coverage, step Generate coverage on 9c92a9b wanted to post the following:

Coverage

cb15e0 #4182 9c92a9
Total Total +/- New
Rate 63.59% 63.60% +0.01% 94.44%
Hits 75701 75719 +18 34
Misses 43340 43336 -4 2

Diff coverage report

Full coverage report

This comment will be updated on new commits.

@YaqiWang
Copy link
Contributor

Is this related the assertion I hit with mesh refinement when using BoundaryInfo::sync?

roystgnr added 3 commits May 29, 2025 16:25
This'll make it easier to test synchronization after refinement rather
than just before.
Support for this was attempted back in September 2003, but our only
coverage was for refinement after sync, not before.  This may be a new
winner in the "Longest-Unfixed libMesh Bug" competition.
@roystgnr
Copy link
Member Author

The first three commits fix and add test coverage for subsequent serialization of a distributed BoundaryInfo::sync() target mesh, but the second three now fix and add test coverage for the bug you hit with BoundaryInfo::sync() of a refined source mesh.

roystgnr added 7 commits June 5, 2025 17:16
This is going to be a non-manifold mesh, and we don't really support
those, but when we do mesh distribution and adaptivity on them then we
*really* don't really support those.
prepare_for_use() will helpfully notice remote_elem interior_parent()
links that can be updated, and will do so even if we set them remote
because we knew they can't be updated for good.
Even with a ReplicatedMesh, trying to consistently refine etc. when we
have four edge elements meeting at all these points gets to be too much.
@roystgnr
Copy link
Member Author

roystgnr commented Jun 7, 2025

This isn't as sweeping as I'd hoped it would be, because as soon as we mix interior and exterior sidesets we run into the "libMesh doesn't properly support non-manifold connections" problem for which I've never been able to come up with an efficient fix, but it does fix a bunch of use cases and add much better test coverage.

@roystgnr roystgnr merged commit 28ff000 into libMesh:devel Jun 7, 2025
20 checks passed
@roystgnr roystgnr deleted the interior_parent_parallel branch June 7, 2025 18:36
@roystgnr
Copy link
Member Author

roystgnr commented Jun 9, 2025

The test coverage is so much better, in fact, that it's failing on the devel->master merge. I can replicate it and am looking into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants