Newton Scheme FAILED to converge - Following up #16120
-
Hi all, _Building mesh ............................................................................ *** Warning, This code is deprecated and will be removed in future versions: Initializing equation system ............................................................. Warning! Mesh re-partitioning is disabled while using stateful material properties! This can lead to large load imbalances and degraded performance!! Framework Information: Parallelism: Mesh: Nonlinear System: Auxiliary System: Execution Information: and the error logs Time Step 45, time = 0.1, dt = 0.00150267 Postprocessor Values:
Outputting exodus ........................................................................ Assertion `flags_were_consistent' failed. Assertion `flags_were_consistent' failed. Assertion `flags_were_consistent' failed. [[2] ../src/mesh/mesh_refinement.C, line 536, compiled Oct 7 2020 at [3] ../src/mesh/mesh_refinement.C, line 536, compiled Oct 7 2020 at 15:56:30 Thanks in advance! |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
@fdkong or @roystgnr Can you offer some advice on this question? |
Beta Was this translation helpful? Give feedback.
-
The fe_map.C warnings are coming from inverse_map. Typically that means a badly twisted element where the mapping Jacobian goes singular, but we do have an outstanding issue with pyramids that can be triggered near their apex vertex: libMesh/libmesh#2749 The flags_were_consistent failure means that there's an element which has one refinement flag on one processor but a different refinement (or lack-of-refinement) flag on another processor. If you're using a libMesh flagging routine then this is probably a bug in libMesh. If you're using a homebrewed flagging routine that you're certain is correct on local elements, you can call MeshRefinement::make_flags_parallel_consistent() to sync your flags onto ghost elements. |
Beta Was this translation helpful? Give feedback.
-
It might be a good idea to fix the first issue (inverted elements) before we dig into the second one. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the replies. So it looks like comes from a bug... Can you advice on how to proceed? |
Beta Was this translation helpful? Give feedback.
The fe_map.C warnings are coming from inverse_map. Typically that means a badly twisted element where the mapping Jacobian goes singular, but we do have an outstanding issue with pyramids that can be triggered near their apex vertex: libMesh/libmesh#2749
The flags_were_consistent failure means that there's an element which has one refinement flag on one processor but a different refinement (or lack-of-refinement) flag on another processor. If you're using a libMesh flagging routine then this is probably a bug in libMesh. If you're using a homebrewed flagging routine that you're certain is correct on local elements, you can call MeshRefinement::make_flags_parallel_consistent() to sync your…