On Sat, 17 May 2008, [EMAIL PROTECTED] wrote: > Here are some questions concerning the parallel mesh. I ran into segmentation > faults after I shifted mesh nodes.
Don't feel bad - I run into segmentation faults *before* shifting mesh nodes. :-P ParallelMesh still has unfixed bugs that are triggered by element coarsening, it's not well tested enough in general, and I don't know when anyone's going to get much time to devote to it again. If you're using it already, you'll have to watch out for ugly bugs. Shifting mesh nodes inconsistently between processors breaks various lookups; both the Hilbert indices that Ben used for I/O and the node synchronization code I used for mesh refinement. It sounds like Ben's code is the one tripping for you, but one or the other would break eventually. > So, which method of the mesh resp. from the MeshCommunication namespace should > I call to fix that problem? MeshCommunication::redistribute seems to be the > obvious candidate. We currently don't have any functions designed to sync ParallelMesh node coordinates. If you want to write one, I'd start with MeshRefinement::make_flags_parallel_consistent() and SyncRefinementFlags from src/mesh/mesh_refinement.C, but instead of a new MeshRefinement method create a new MeshCommunication method, and instead of syncing h then p flags, sync x then y then z coordinates. I committed your hilbert.h ifdef to SVN, by the way; thanks! --- Roy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
