[petsc-users] HDF5 viewer + groups

[Matthew Knepley]

On Mon, May 11, 2020 at 1:29 PM Daniel R. Shapero <shapero at uw.edu> wrote:

> 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.
>

I don't think it's such a huge deal. We are redoing things anyway, so its
just another requirement.

  Thanks,

     Matt


> 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/>
>>
>

-- 
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/5cafeaa2/attachment.html>