DegenerateMapping exception for bad Jacobians and/or Newton convergence in FEMap #4286
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
When an application can catch this, they should get to choose whether they can handle it silently or need to bug the user with the details.
This saves us a few lines of preprocessor macros and should produce the same binary output in both configurations I ran across these while grepping for places where changing exception types might get us into any trouble.
We should really also be classifying inverse_map failures as std::runtime_error rather than std::logic_error, but it's possible for Newton to fail (at least in theory; I haven't seen it in practice myself) on a non-singular and non-inverted mapping.
So let's throw DegenerateMapping instead, and again we'll stuff data into the exception where code can catch it in the best case and it'll still get to stderr eventually in the worst case.
|
Job Coverage, step Generate coverage on 1f8de15 wanted to post the following: Coverage
Warnings
This comment will be updated on new commits. |
||||||||||||||||||||||||||
Member
Author
|
Good MOOSE framework: "A zero mapping Jacobian isn't necessarily an error; it's an exception that we can often catch and recover from." Evil MOOSE test suite: "If a zero mapping Jacobian doesn't output the exact phrase |
roystgnr
added a commit
to roystgnr/moose
that referenced
this pull request
Nov 6, 2025
An error message calling 0 a negative number should have been noticed as a bug to fix, not a feature to insist upon! Refs #0 - see libMesh/libmesh#4286
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
In idaholab/moose#31758 I took the position that we should avoid making it harder to fix the issue where we report problematic element mappings as LogicError exceptions even though they're not logic errors; after a little thought, this isn't a hard issue and I could probably spend more time arguing about hypothetically fixing it than it would take to actually fix it.
In the near term, I think a good migration path here is for user code to
catch (std::exception & e)but then check whethere.what()matches"Jacobian"to determine whether it's caught a mapping issue rather than a real internal error or assertion failure.