Sounds good.  Feel free to grab anything useful from here:
https://github.com/libMesh/libmesh/tree/checkpoint


On Nov 7, 2013, at 2:26 PM, Derek Gaston <fried...@gmail.com>
 wrote:

> I'm thinking a new object: CheckpointIO
> 
> So you do CheckpointIO.write()/read()
> 
> Cody and I are starting on this now - I'll provide a pull request once we get 
> a ways in so you can comment.
> 
> Derek
> 
> 
> 
> On Thu, Nov 7, 2013 at 12:27 PM, Kirk, Benjamin (JSC-EG311) 
> <benjamin.k...@nasa.gov> wrote:
> On Nov 7, 2013, at 10:37 AM, Cody Permann <codyperm...@gmail.com>
>  wrote:
> 
> > Yes I did, and we are still tweaking it even now.  I just add the nodeset 
> > information a few days ago so lets figure out what we need in the current 
> > version before the next release!
> 
> If at all possible I'd like to treat the "unique ids" the same way we do the 
> other stuff:
> 
>  XdrIO io(mesh);
>   io.partition_map_file_name() = ".";
>   io.unique_ids_file_name() = "n/a";
>   io.write("mesh.xda");
> 
> We can then write the (id,uid) in the connectivity block, and also along with 
> the coordinates.
> 
> As for the header stuff, how about we target something more like this:
> 
> libMesh-0.9.2+ parallel  type_size=8 sid_size=8 eid_size=8 side_size=8 
> bid_size=8
> 1000  # number of elements
> 1331  # number of nodes
> .         # boundary condition specification file
> .         # subdomain id specification file
> .         # unique id specification file
> n/a     # processor id specification file
> n/a     # p-level specification file
> 0        # subdomain id to name map
> 1000     # n_elem at level 0, [ type sid uid (n0 ... nN-1) ]
> 
> 
> Or maybe just
> libMesh-0.9.2+ parallel  id_size=8
> …
> 
> I think we can make better use of the "version" string for extensibility, 
> basically treating it instead as a "feature" string.
> 
> ---------------------------------------------------------------------
> 
> As for Derek's concern, I tend to agree that the current XDA file format has 
> to address a lot of concerns that overcomplicate it for what he wants.  I'll 
> add another restriction:  If we are limiting the parallel restart capability 
> to
> 
> (1) always require an associated mesh,
> (2) only work in the M->M case, and
> (3) don't worry about version compatibility,
> 
> a new feature is desirable and not too hard.
> 
> I recommend
> 
> XdrIO io(mesh);
> 
> io.checkpoint("foo.xda");
> ...
> io.restore("foo.xda");
> 
> and likewise for the EquationSystems.
> 
> Agreed?
> 
> -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
> 


------------------------------------------------------------------------------
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

Reply via email to