The only issue I can see is the need to do two conversions when starting with e.g. a gmsh format... gmsh -> xml -> h5
I suppose that just raises the need for a more general conversion tool. Chris On 3 Jan 2014 21:43, =?ISO-8859-1?Q?Nico_Schl=F6mer?= <[email protected]> wrote: > > For what it's worth, as a user I always found the mere existence of > yet another mesh file format confusing. XDMF supports lossless I/O for > meshes, so naturally I'm in favor of this approach. (Not sure how well > mesh generators support XDMF, but there certainly is a chance for > better support than the custom XML format.) > > --Nico > > On Fri, Jan 3, 2014 at 7:27 PM, Garth N. Wells <[email protected]> wrote: > > The handling of XML IO in parallel in DOLFIN is presently inconsistent and > > extremely slow for large files. Moreover, the code is clumsy. Now that we > > have proper parallel IO support via HDF5 (and XDMF) and MPI-IO, I would > > like to propose that XML IO be simplified to be serial only. Only XML > > meshes are presently read in a memory scalable fashion. To read meshes in > > parallel, supporting the below two implementations is suggested: > > > > 1. Recommended approach: Use XDMF/HDF5 format. To convert existing meshes: > > - (simple) If mesh fits into memory, read XML mesh into DOLFIN and use > >DOLFIN to write XDMF file. > > - (general) Use new dolfin-xml-to-hdf5 Python script to convert XML > >files to XDMF/HDF5. Script uses SAX XML parser, so memory limitations are > >not a problem for large meshes. > > > > 2. Supported approach: DOLFIN reads XML mesh file on one process only and > > distributes mesh to all processes. This will be considerably faster than > > the present parallel implementation, which uses a slow SAX parser, but it > > is limited to problems for which the mesh fits into memory on a process. > > > > Most users will require no code changes but will see a speed-up. For large > > XML files that don’t into memory on one process, HDF5/XDMF should really be > > used because it is orders of magnitude faster for large problems. The > > proposed change means that the XML SAX parser can be removed and libxml > > will no longer be a DOLFIN dependency. > > > > Any objections? > > > > Garth > > _______________________________________________ > > fenics mailing list > > [email protected] > > http://fenicsproject.org/mailman/listinfo/fenics > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
