Would it be possible for me to send you the mesh in CPR format just right before calling test_unflagged() in MeshRefinement::refine_and_coarsen_elements()? Would that help to debug this issue? Not sure if the mesh in CPR actually stores the flags for refinement.
Thanks Miguel On 1/7/19, 11:51 AM, "Salazar De Troya, Miguel via Libmesh-users" <[email protected]> wrote: On 1/4/19, 3:37 PM, "Stogner, Roy H" <[email protected]> wrote: On Thu, 3 Jan 2019, Salazar De Troya, Miguel via Libmesh-users wrote: >> Running an example with 10 processors (works in serial) fails with the error: >One of our examples? No. My own example so to speak. Sorry for the confusion. >> !libmesh_assert_pass' failed >> >> The program stops at libmesh_assert(test_unflagged(true)) in >> MeshRefinement::refine_and_coarsen_elements(). The remaining stack >> trace when TotalView stops is as follows (sorry for the rudimentary >> copy and paste, it’s all I can do now): >> >> MeshRefinement::test_unflagged (bool libmesh_dbg_var(libmesh_assert_pass)) >> std::ostream & operator << (std::ostream & os, const Elem & e) >> Elem::print_info (std::ostream & os) >> std::string Elem::get_info () >> bool DofObject::valid_id () <-- Stops here. >That's... baffling. At that point _coarsen_elements should have >coarsened (and cleared flags of) anything flagged to coarsen, then >_refine_elements should have refined (and cleared flags of) anything >flagged to refine, then there should obviously be nothing left to >coarsen or to refine. >Hmm... the flag clearing in coarsening is actually done when the >parents get coarsen() called. Is it possible that we're screwing up >make_coarsening_compatible somewhere and leaving a child marked >COARSEN without properly marking its parent COARSEN_INACTIVE? I noticed there are two test_unflagged() in MeshRefinement::refine_and_coarsen_elements(). It is the first one where the problem is (where the condition (coarsening_changed_mesh || refining_changed_mesh) is met). >> Please let me know if you need more details. I will keep investigating. >There's no output from that print_info? There is no more output. I should apologize because the "stack trace" that I sent is not the one for the processor that failed (I'm a newbie at TotalView). This is the one for the processor that failed: libmesh_assert(!libmesh_assert_pass); in MeshRefinement::test_unflagged (bool libmesh_dbg_var(libmesh_assert_pass)) (mesh_refinement.C 467) libMesh::write_traceout() in MacroFunctions::report_error() libMesh::print_trace(traceout); gdb_worked = gdb_backtrace(out_stream); int fd = mkstemp(temp_file); and then I see two frames with what looks assembly language from the file libc.so.6 >I don't know what I can do about this unless I can reproduce it. I >could suggest some asserts that might catch the hypothesis above. Could you please suggest those assertions? Sending the code could be a bit cumbersome. Thanks --- Roy _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
