If dolfin-convert gets an HDF5 writer, then we should already have gmsh -> h5.
--Nico On Sat, Jan 4, 2014 at 7:06 PM, Chris Richardson <[email protected]> wrote: > 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
