I understand what you're saying - but the current format is so very close to what I actually currently need.  If it had element and node ids in it and tried to restore those ids when you loaded the file I believe that it would do everything I currently need it to do.

Can we do something simple in the interim like a configure option to write IDs to the XDA file?

After we have that working we can take a look at doing something better.  For instance, I currently have these patches that add Silo ( https://wci.llnl.gov/codes/silo/ ) support to libMesh (from a developer at Livermore)... maybe we can take a look at what he's done and improve upon it and make it our official format (one nice thing is that Paraview and ViSit actually read that format - so you could actually look at the files you dump out... and it natively supports AMR).

But - I really just need a quick fix for now to allow progress to continue on my current task...

Derek



On Thu, Nov 7, 2013 at 5:40 AM, Kirk, Benjamin (JSC-EG311) <benjamin.kirk@nasa.gov> wrote:
On Nov 6, 2013, at 9:47 PM, "Derek Gaston" <friedmud@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