> On the other hand, while I don't think "unchanging element ordering" > is a feature worthy of regression testing itself, it might be a useful > feature to make other regression tests easier. Running "diff > current.gmv gold.gmv" would certainly be easier than trying to reorder > the results before verifying them, and we could use your new space > filling curve code to provide a canonical order in which to write > output.
The real problem is with parallel files. It is so much easier if the partitioning is deterministic.... I just write my local solution values to disk and then read them back in. This present issue allows processor X to have M elements, dump a restart file, and then restart with the same mesh on the same number of processors and now processor X has N elements, never mind that they may be in a totally disjoint part of the domain... It actually seems somewhat important when comparing the serial mesh and parallel mesh... The serial mesh does not impose this ordering, while the parallel mesh does. So, after a repartition you can have a different domain decomposition depending on which mesh you are using. That just seems wrong... Of course, we could force the serial mesh to use the same numbering scheme, which might be worthwhile for its own reasons. I'm leaning toward the space-filling curve unique global ordering to solve this problem anyway. If the elements have a partition-independent ordering going in to the partitioner then the same graph results and hence the same partition. The catch-22 I need to go fix is that each processor loops over its local nodes/elements to create the curve, which is less than useful before there is a partition... Anyway, better left 'till tomorrow. ------------------------------------------------------------------------- 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
