-
Notifications
You must be signed in to change notification settings - Fork 301
Simple mesh fixes #4380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
roystgnr
wants to merge
16
commits into
libMesh:devel
Choose a base branch
from
roystgnr:simple_mesh_fixes
base: devel
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Simple mesh fixes #4380
+176
−20
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.