Very cool work.... I'm still waiting for parallel IO as well... ;-)
Derek On Nov 30, 2007 2:56 PM, Benjamin Kirk <[EMAIL PROTECTED]> wrote: > **please read if you want to be able to read your existing restart files!** > > ...are now supported. It is not required to serialize the mesh to write a > restart file from a parallel mesh during an application run. Similarly, it > is possible to read a restart file onto an EquationSystems object and mesh > which are not serial. > > The new format is visually identical to the old one with two important > differences: > (1) there is a version line at the beginning of the file, and > (2) the ordering of the output vectors is different. > > If you want to read an old restart file use the --read_legacy_restart_format > command-line option. Only the new format is written. > > The key to doing this was to come up with a partition-agnostic DOF ordering > which could be used to write the same file independent of the partitioning. > I have chosen to use the libHilbert space-filling-curve keys to produce this > ordering. > > The approach is as follows: > > (1) take the distributed mesh and compute partition-agnostic > DofObject::id()s for the nodes/elements using the Hilbert keys. > (2) > for each system > for each variable in the system > for a block of nodes > for each node in the block of nodes > read/write the solution for this block in hilbert-indexed order > end > end > for a block of elems > for each elem in the block of elems > read/write the solution for this block in hilbert-indexed order > end > end > end > end > > The blocking allows a single file to be written through processor 0 > independent of the problem size. Of course, the performance of the write > will scale with the single-node I/O. (there is an easy parallel option > which could be added.) > > The hilbert indexing is what enables the partiton-agnostic IDs, which in > turn enable a file written on N processors to be restarted on M processors. > > Now, currently the hilbert indices are temporarily stored in the > DofObject::id() locations. This requires overwriting the valid numbering > with an invalid numbering and then restoring the original. I thought about > it for a while and chose this approach over adding a DofObject::global_id() > or something like that, although that may be something to consider for the > future. > > Thoughts? > > -Ben > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Libmesh-devel mailing list > Libmesh-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
