<div dir="ltr"><div dir="ltr">On Mon, May 11, 2020 at 1:29 PM Daniel R. Shapero <<a href="mailto:shapero@uw.edu">shapero@uw.edu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Gotcha, that all makes sense and thanks for the reply!</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>I don't think it's such a huge deal. We are redoing things anyway, so its just another requirement.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 11, 2020 at 3:24 AM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Sun, May 10, 2020 at 10:03 PM Daniel R. Shapero <<a href="mailto:shapero@uw.edu" target="_blank">shapero@uw.edu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div style="text-align:left">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.<br></div><div style="text-align:left"><br></div><div style="text-align:left">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.<br></div><div style="text-align:left"><br></div><div style="text-align:left">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?</div></div></blockquote><div><br></div><div>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</div><div>copied that design. It would be possible to namespace everything, and fix the XDMF generator to understand that.</div><div><br></div><div>Vaclav, should we roll this into the HDF5 parallel reading/writing update?</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="text-align:left">Thanks!</div><div style="text-align:left">Daniel<br></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>