I agree, I don't see much point to it either. We don't use it for our other codes either, if only for the shear size of ASCII output of 20+ variables over hundreds of millions of grid points.
PyLith takes the same approach we do (our code is in Fortran, the code I'm trying to write is independent of that). They manage the HDF5 data themselves and write the XDMF file using standard IO. I was looking for the 'PETSc' way of doing it, something that lets you call VecView(vec, viewer) that generates the heavy data and XML file together. If there is not interest in that approach, I can just write the routines to make the XML in the code. Tim ----- Original Message ----- From: "Jed Brown" <jedbr...@mcs.anl.gov> To: gtg085x at mail.gatech.edu Cc: "For users of the development version of PETSc" <petsc-dev at mcs.anl.gov> Sent: Saturday, December 3, 2011 3:24:47 PM Subject: Re: [petsc-dev] XDMF viewers On Sat, Dec 3, 2011 at 14:22, Tim Gallagher < tim.gallagher at gatech.edu > wrote: You do need HDF5 to store "heavy" data, but XDMF can also store data in the XML file as "light" data for small datasets. I see no point to this because then you can't write the file incrementally. You can't write incrementally with binary-appended VTK-XML either, but at least you can use binary IO. <blockquote> Inclusion in PETSc could go two ways -- the first would be using the XDMF library which handles reading/writing both light and heavy data. Or, the XDMF viewer can be built on top of the HDF5 viewer already there. In that case, the heavy data will be written using the HDF5 viewer and then there would be code to write the XML data in the XDMF format. This is the approach we use in our code -- we write the HDF5 files using the HDF5 API, then write with standard IO the XML file. </blockquote> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20111203/c8741d5f/attachment.html>
