<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 17, 2018 at 6:49 AM, Vaclav Hapla <span dir="ltr"><<a href="mailto:vaclav.hapla@erdw.ethz.ch" target="_blank">vaclav.hapla@erdw.ethz.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For DMPlex and PETSCVIEWERHDF5, DMView produces a HDF5 file consisting basically of these 3 parts:<br>
1) vertices (HDF5 group /geometry)<br>
2) "native" Plex topology as a serialization of the Plex graph<br>
3) traditional topology as connectivity of vertices, XDMF-compatible (HDF5 group /viz/topology)<br>
So the topology is stored redundantly in two different ways 2 and 3.<br>
<br>
I'm now a member of the team developing the Salvus application, and we would like to use XDMF-compatible HDF5 as our native format. I would be glad if PETSc took care of this completely instead of coding it just for Salvus.<br>
<br>
Looking how it is now in PETSc, I'm tempted to implement a new separate Viewer for reading and writing purely this HDF5 flavor, i.e. parts 1 and 3. It also looks to me easier for parallel I/O and support by external tools like <a href="https://github.com/nschloe/meshio" rel="noreferrer" target="_blank">https://github.com/nschloe/<wbr>meshio</a>. The writer code can be copy-pasted from plexhdf5.c (function DMPlexWriteTopology_Vertices_<wbr>HDF5_Static) and the reader can be implemented relatively easily using DMPlexCreateFromCellListParall<wbr>el (see preview at <a href="https://bitbucket.org/haplav/petsc/commits/4719ef6a33f5f9a4a1b8c81c7a6e6ed0426097f1?at=haplav/feature-dmplex-distributed-hdf5-read" rel="noreferrer" target="_blank">https://bitbucket.org/haplav/<wbr>petsc/commits/<wbr>4719ef6a33f5f9a4a1b8c81c7a6e6e<wbr>d0426097f1?at=haplav/feature-<wbr>dmplex-distributed-hdf5-read</a>).<br>
<br>
It would of course not support any possible DMPlex instance, but what is supported by XDMF forms a sensible subset for practical use. The current HDF5 could be kept as a native PETSc format allowing storing any possible DMPlex. But I would then remove part 3 from this format, getting rid of "Visualization topology currently only supports..." errors currently thrown by DMView.<br></blockquote><div><br></div><div>Here is my original argument for storing both. HDF5 is intended to be extensible in this way, since its has a directory structure. Keeping a single file</div><div>is much easier than two different files if you want both sets of information, and there is much shared between the two. I would have suggested making</div><div>it easier to select which part gets output using formats.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There's still a question how to store non-homogenous meshes (with different cell shapes). I can see two possible ways:<br>
1) Store separate "sections" of a mesh, each section with homogenous cell shape. Matt: "This might mean that you need to permute the numbering to group cells of the same shape, which is already making me feel tired."<br>
2) XDMF allows "mixed" topology (<a href="http://www.xdmf.org/index.php/XDMF_Model_and_Format#Arbitrary" rel="noreferrer" target="_blank">http://www.xdmf.org/index.<wbr>php/XDMF_Model_and_Format#<wbr>Arbitrary</a>) where cell shape is specified per cell. The problem is that each row representing a cell would have different number of values. This is not nice for current ISView/VecView with fixed block size.<br>
It will also require generalising DMPlexCreateFromCellListParall<wbr>el().<br></blockquote><div><br></div><div>  2) Still sounds easier to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Later on I would consider generating the XDMF XML file directly by this Viewer without having to call the python script $PETSC_DIR/bin/petsc_gen_xdmf.<wbr>py afterwards.<br></blockquote><div><br></div><div>We did this in Pylith originally, and eventually threw it away. Its much less flexible and harder to maintain.</div><div><br></div><div>  Thanks,</div><div><br></div><div>    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any comments on this?<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888"><br>
Vaclav</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><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.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div>
</div></div>