On Wed, Nov 6, 2013 at 6:36 PM, Kirk, Benjamin (JSC-EG311) <benjamin.kirk@nasa.gov> wrote:
OK, so I've reminded myself of where this was left off - the parallel I/O for the equation systems is in place, while for the mesh it is not implemented yet. I'll review where things was left off, and I don't think it'll be that difficult to implement what you're looking for.

Note: I'm not that worried about parallel IO... mostly I just need all of the element and node numbering preserved if I write out XDA and then read it back in (i.e., I need the exact same Mesh and vector layout).  For now, just getting that working for SerialMesh would be useful.

Further, the way that the XDA writer in EquationSystems::read() and EquationSystems::write() can destroy your current node and element numbering (i.e., you call it and after it finishes your node and element numbering can be different for the system you called it on!).  This is happening because of the combination of "globally_renumber_nodes_and_elements()" and "fix_broken_node_and_element_numbering()" calls in those routines.

fix_broken_node_and_element_numbering() will destroy any non-contiguous, non-zero starting numbering - or any numbering where the numbering of nodes doesn't match the order they are added to the mesh.  Note that last one: that is a serious one as we're getting ready to start using the node and element "maps" in Exodus that will effectively renumber nodes and elements after they are added to the mesh.  So just writing out an EquationsSystem will destroy our numbering...

Basically, the node and element numbering cannot be inferred from the XDA file.  It might not start at 0.  It might not be contiguous and it might not be assigned in the "perfect" order...