Simple mesh fixes #4380
Open
Simple mesh fixes #4380
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This wasn't failing the test, because the kernel here didn't need the unprepared data, but we'd like to simply assert that we're not assembling or solving on unprepared meshes.
Otherwise the mesh still thinks its fully prepared even when it isn't and we can't assert valid_is_prepared() on it.
We've added some tricky interior_mesh options that our copy_nodes_and_elements code wasn't handling correctly, and it was possible for a clone() of such a mesh to fail its operator== assertion.
This must have been an atavism from a previous refactoring.
We never caught this before because we were never doing much subsequent mesh modification to the output, but as soon as we start heavier testing we run into code that screams about the inconsistent parent/child id ordering.
This was supposed to be a pure virtual function eventually, and it's time to start moving that way.
We're making that pure virtual in non-deprecated builds now.
2008. This has been buggy since I wrote it in 2008. And yet it took a double-refinement test on a distributed mesh plus an extra layer of dbg-mode internal consistency checks to catch the bug.
I went to double-check that this was the macro I wanted, and the behavior did match my recollection but didn't match my comment
|
Job Coverage, step Generate coverage on da90cb8 wanted to post the following: Coverage
Warnings
This comment will be updated on new commits. |
||||||||||||||||||||||||||
Member
Author
|
Test failures unrelated |
jwpeterson
approved these changes
Feb 4, 2026
Member
jwpeterson
left a comment
jwpeterson
left a comment
There was a problem hiding this comment.
This looks good to me, but it seems like I might need to add
mesh.get_boundary_info().regenerate_id_sets();
and
mesh.cache_elem_data();
calls in some of my own code? I'm curious how you figured out where those calls were missing/needed?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Okay, "simple" might be overselling a couple commits here, but this is at least the largest collection of the most straightforward bugfixes that I could pull out of #3759.
Other than the new
InfElem::is_child_on_*unit testing, I'm not able to strip out the test coverage for these fixes; I'm afraid that depends on the refactoring in #3759, and I'm hoping to merge the refactoring last, after it's been decluttered via this and another PR.