On Nov 6, 2013, at 9:47 PM, "Derek Gaston" <fried...@gmail.com> wrote:
> I think I may be missing the reason why we are renumbering. To me, I just > want a direct representation of the current mesh in XDA form... For the serialized solution XDA, it is all about M->N restarts. Forget the mesh for the moment, its not relevant to this case. Building a cube on 1 or 10 processors, has historically produced a different element/node ordering in libMesh. Same thing will happen if you invoke different partitioners on the same mesh. Same thing will happen if you build a square with 4 elements vs. building one and refining it once. We need a way to restart the same solution on topologically the same mesh regardless of the ordering, and the serialized solution format is designed to handle that need. So at the moment the parallel solution I/O stuff proceeds from that history. I agree if we are limiting the parallel restart capability to (1) always require an associated mesh and (2) only work in the M->M case, we can likely remove the reordering. The mesh is different - we do not reorder it explicitly, but we write the elements by level so that can change the "natural" ordering with refinement. This was done as a logical way to get the refinement tree out and also not require additional IDs. As I mentioned yesterday for the parallel mesh case I expect we'll need Ids in any case. I'm also open to constructing some kind of integer graph instead to represent the refinement hierarchy, but I don't clearly see what that looks like so we need to think about it. It may be as easy as the current parent index bit, but read after the elements... -Ben ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
