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." -J ------------------------------------------------------------------------- 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
