From: Derek G. <fri...@gm...> - 2013-11-08 00:08:37
|
BTW - I'm a long way down this path now.... I am almost finished with write(). I'll work on read() tonight... Hopefully there will be a pull request in the morning... Derek On Thu, Nov 7, 2013 at 1:30 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > 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 <fri...@gm...> > 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) < > ben...@na...> wrote: > > On Nov 7, 2013, at 10:37 AM, Cody Permann <cod...@gm...> > > 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 > > Lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > > > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-11-08 15:05:14
|
Excellent. I maintain a lot of the complicating factors in the current format are appropriate given its goals, and I think your need will be better served with this new approach. -Ben On Nov 7, 2013, at 6:08 PM, "Derek Gaston" <fri...@gm...<mailto:fri...@gm...>> wrote: BTW - I'm a long way down this path now.... I am almost finished with write(). I'll work on read() tonight... Hopefully there will be a pull request in the morning... Derek On Thu, Nov 7, 2013 at 1:30 PM, Kirk, Benjamin (JSC-EG311) <ben...@na...<mailto:ben...@na...>> wrote: 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 <fri...@gm...<mailto:fri...@gm...>> 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) <ben...@na...<mailto:ben...@na...>> wrote: > On Nov 7, 2013, at 10:37 AM, Cody Permann <cod...@gm...<mailto:cod...@gm...>> > 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 > Lib...@li...<mailto:Lib...@li...> > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > |
From: Roy S. <roy...@ic...> - 2013-11-08 17:04:37
|
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 |