On Fri, 8 Nov 2013, Kirk, Benjamin (JSC-EG311) wrote:
I maintain a lot of the complicating factors in the current format
are appropriate given its goals,
I didn't want to start a flamewar before (and also I've been wrecked
by illness and deadlines), but I mostly agree.
and I think your need will be better served with this new approach.
I think Derek's separate CheckpointIO class idea is freaking
brilliant. When I futzed around in our XDR stuff long ago (to add p
adaptivity) I thought about trying to make precise numbering
restoration work, but I could only figure out how to make it work in a
subset of cases (most critically, M->M would have been a requirement)
and I didn't want to lead users to expect fixed numbering and then
then be disappointed the first time they wanted to e.g. rescale a
restarted run. Using a separate I/O class seems like a perfect way to
futz around with repeatable numbering without implying any false
promises to users, and try different ideas without breaking backward
compatibility... and maybe with room to experiment we'll have
something good enough to replace the XDRIO class eventually.
I do still think we ought to consider extensions to the HDF5-based
ExodusII for our next format, but realistically I know our next format
will be designed by whoever has the motivation and puts in the effort
to do it. ;-)
---
Roy
------------------------------------------------------------------------------
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
