[petsc-users] HDF5 viewer + groups

[Daniel R. Shapero]

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 <knepley at gmail.com> wrote:

> On Sun, May 10, 2020 at 10:03 PM Daniel R. Shapero <shapero at uw.edu> 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/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20200511/3d808872/attachment.html>