Gotcha, that all makes sense and thanks for the reply! Is adding a namespace mechanism to HDF5 viewers worthwhile from your end? I totally understand if not and we can probably design around that from the Firedrake side, e.g. restricting to only one mesh per checkpoint file.
On Mon, May 11, 2020 at 3:24 AM Matthew Knepley <[email protected]> wrote: > On Sun, May 10, 2020 at 10:03 PM Daniel R. Shapero <[email protected]> wrote: > >> I'm trying to improve the checkpointing functionality in the Firedrake >> library, which currently uses the HDF5 viewer to store PetscVec objects. >> The problem with this approach is that a lot of context about the stored >> vector (e.g. the mesh and finite element space that it came from) is lost >> and we'd like to save that too. >> >> In order to make a sensible hierarchy inside the file, I'd like to be >> able to write a DMPlex to a group, say `/meshes/<mesh_name>`, within the >> file rather than at the root `/`. I tried using the >> `PETScViewerHDF5PushGroup` function; I thought that this will change the >> current group of the file to whatever name you give and all subsequent >> dataset writes will go under that group until you call the matching pop. >> This doesn't seem to be the case and all of the mesh data gets written >> under `/`. From reading the source code, it looks like the HDF5 writer >> pushes the group `/topology` to write out the DMPlex cells (and likewise >> for coordinates etc) which then clobbers whatever I pushed before it >> instead of concatenating. >> >> I've attached a minimal example using petsc4py to demonstrate. I get the >> same results when I use some extra functionality in Firedrake to ensure >> that the `/meshes` group is created in the first place, which I can then >> verify with h5ls. >> >> Is there a way to do what I want and if so how? If there isn't, is that >> because no one has needed this before or is there a fundamental reason why >> you shouldn't be doing this in the first place? >> > > The reason is the impedence mismatch with visualization formats. > VTK/ExodusII/etc are all based on a single mesh and multiple vectors in a > file, so I > copied that design. It would be possible to namespace everything, and fix > the XDMF generator to understand that. > > Vaclav, should we roll this into the HDF5 parallel reading/writing update? > > Thanks, > > Matt > > >> Thanks! >> Daniel >> > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ > <http://www.cse.buffalo.edu/~knepley/> >
