<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Jul 20, 2018 at 5:34 AM Lawrence Mitchell <<a href="mailto:wence@gmx.li">wence@gmx.li</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">Dear petsc-dev,<br>
<br>
I'm once again revisiting doing "proper" checkpoint-restart cycles.  I would like to leverage the existing PETSc stuff for this as much as possible, but I am a bit lost as to what is implemented, and what is missing.<br>
<br>
I have:<br>
<br>
- A (distributed) DMPlex defining the topology<br>
<br>
- Some number of fields defined on this topology, each described by:<br>
<br>
  - a Section (with a point permutation set)<br>
  - a Vec of coefficients<br>
  - Some extra information that describes what the coefficients mean, but let's assume I know how to handle that.<br>
<br>
(Aside, for Vecs with a block size > 1, I actually have a section that indexes the blocks, which probably means I need to unroll into an unblocked version first).<br></blockquote><div><br></div><div>Sections usually are {point --> {dofs}}. Not sure how it uses blocks instead of points.</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">
I would like:<br>
<br>
- To be able to dump the DMPlex, and fields, on N processes<br></blockquote><div><br></div><div>I think the current HDF5 does what you want.</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">
- To be able to load the DMPlex, and fields, on P processes.  In the first instance, to get things going, I am happy if P=1.<br></blockquote><div><br></div><div>I think this also works with arbitrary P, although the testing can be described as extremely thin.</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">
For dumping, I think I can do DMView(dm) in PETSc "native" format, and that will write out the topology in a global numbering.<br></blockquote><div><br></div><div>I would use HDF5.</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">
For the field coefficients, I can just VecView(vec).  But there does not appear to be any way of saving the Section so that I can actually attach those coefficients to points in the mesh.<br></blockquote><div><br></div><div>Hmm, I will check this right now. If it does not exist, I will write it.</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">
I can do PetscSectionCreateGlobalSection(section), so that I have a the global numbering for offsets, but presumably for the point numbering, I need to convert the local chart into global point numbers using DMPlexCreatePointNumbering?<br></blockquote><div><br></div><div>No, all Sections use local points. We do not use global point numbers anywhere in Plex.</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">
For load, I can do DMLoad(dm), which only loads on rank-0 for now. </blockquote><div><br></div><div>I do not think that is true.</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"> Then VecLoad for the coefficients, and (presumably) a putative PetscSectionLoad so that I can associate coefficients to points in the topology.<br></blockquote><div><br></div><div>Okay, I am remembering more now. I just use the PetscDS to automatically create the Section, and pray that</div><div>it matches the Vec that we saved. This is a real design limitation, since the Section is associated with the DM</div><div>not the Vec, you have to assume all stored Vecs were created with the default Section in the DM. Now, if this</div><div>is true, then you could just load the Section, set it as the default for the DM, and load the Vec.</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">
So it feels like the crucial part of this is a native (HDF5) based viewing for PetscSection.<br></blockquote><div><br></div><div>Yep. I thought this worked, but maybe I only decided it should work.</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">
For each section (I'm ignoring fields, because those are just sections anyway), there are two explicit, and one implicit, pieces of information:<br>
<br>
1. The number of dofs per point<br></blockquote><div><br></div><div>Yep.</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">
2. The offset of the dof (this is the global numbering)<br></blockquote><div><br></div><div>No, you should store the local Section. You use the SF for the DM to automatically get the global section.</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">
3 (implicit). The association of the local chart numbering to the global chart.<br></blockquote><div><br></div><div>Above.</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">
Saving the first two is easy, how best to save the last so that I can load easily.  My thought is to, for each point in the section chart, save a three-tuple: (global-point-number, dofs-per-point, global-dof-number)<br></blockquote><div><br></div><div>Hmm, I have to think a little bit more. Where are you at  with this now?</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">
Then, I can easily read this data in and correctly map from the on-disk coefficients into any section I might have built on the newly loaded DM.<br>
<br>
Does this all sound reasonable?  Or have I missed either an existing implementation, or other issues?<br>
<br>
Cheers,<br>
<br>
Lawrence</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>