On Wed, 16 Apr 2008, John Peterson wrote: > On Wed, Apr 16, 2008 at 8:52 AM, Derek Gaston <[EMAIL PROTECTED]> wrote: >> On Wed, Apr 16, 2008 at 6:44 AM, Roy Stogner <[EMAIL PROTECTED]> wrote: >> > I wonder if we should do something to help catch such problems even in >> > opt mode. Testing a whole SerialMesh for consistency might be >> > overkill for an "optimized" code, but we might take one message's >> > latency hit to at least make sure that n_nodes() and n_elem() are the >> > same after a completed refinement. Thoughts, anyone? >> >> This seems reasonable to me. You are already taking time out to do >> some adaptivity of the mesh... a tiny latency in that to make sure >> your mesh is consistent seems reasonable. > > A general ParallelMesh::check_parallel_consistency() function, or > whatever you'd like to call it, seems like it would be appropriate. > If nothing else it could be used during debugging to see just where > the Mesh first becomes "inconsistent."
This would be something to be run on SerialMesh as well; as Tim pointed out, even when the library is trying to keep the mesh identical on every processor, all it takes is a non-identical set of user-specified refinement flags to foil us. We've got a couple of "libmesh_assert_valid_whatever()" functions to check parallel consistency, but those are for debug mode only and aimed at catching internal library code errors; this new refinement check would be something aimed at catching application code errors too. --- Roy ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
