<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">17. 1. 2018 v 13:04, Matthew Knepley <<a href="mailto:knepley@gmail.com" class="">knepley@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 17, 2018 at 6:49 AM, Vaclav Hapla <span dir="ltr" class=""><<a href="mailto:vaclav.hapla@erdw.ethz.ch" target="_blank" class="">vaclav.hapla@erdw.ethz.ch</a>></span> wrote:<br class=""><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 class="">
1) vertices (HDF5 group /geometry)<br class="">
2) "native" Plex topology as a serialization of the Plex graph<br class="">
3) traditional topology as connectivity of vertices, XDMF-compatible (HDF5 group /viz/topology)<br class="">
So the topology is stored redundantly in two different ways 2 and 3.<br class="">
<br class="">
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 class="">
<br class="">
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" class="">https://github.com/nschloe/<wbr class="">meshio</a>. The writer code can be copy-pasted from plexhdf5.c (function DMPlexWriteTopology_Vertices_<wbr class="">HDF5_Static) and the reader can be implemented relatively easily using DMPlexCreateFromCellListParall<wbr class="">el (see preview at <a href="https://bitbucket.org/haplav/petsc/commits/4719ef6a33f5f9a4a1b8c81c7a6e6ed0426097f1?at=haplav/feature-dmplex-distributed-hdf5-read" rel="noreferrer" target="_blank" class="">https://bitbucket.org/haplav/<wbr class="">petsc/commits/<wbr class="">4719ef6a33f5f9a4a1b8c81c7a6e6e<wbr class="">d0426097f1?at=haplav/feature-<wbr class="">dmplex-distributed-hdf5-read</a>).<br class="">
<br class="">
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 class=""></blockquote><div class=""><br class=""></div><div class="">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 class="">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 class="">it easier to select which part gets output using formats.</div></div></div></div></div></blockquote><div><br class=""></div><div>There's currently only one format PETSC_VIEWER_HDF5_VIZ. Do you mean having more values like PETSC_VIEWER_HDF5_VIZ (just the XDMF data), PETSC_VIEWER_HDF5_PLEX (just the serialized Plex) and PETSC_VIEWER_HDF5_ALL (the two combined)?</div><div><br class=""></div><div>Maybe PETSC_VIEWER_HDF5_XDMF would be clearer than PETSC_VIEWER_HDF5_VIZ as it would contain exactly data needed for XDMF in the binary HDF5 form.</div><div><br class=""></div><div>Thanks</div><div>Vaclav</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </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 class="">
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 class="">
2) XDMF allows "mixed" topology (<a href="http://www.xdmf.org/index.php/XDMF_Model_and_Format#Arbitrary" rel="noreferrer" target="_blank" class="">http://www.xdmf.org/index.<wbr class="">php/XDMF_Model_and_Format#<wbr class="">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 class="">
It will also require generalising DMPlexCreateFromCellListParall<wbr class="">el().<br class=""></blockquote><div class=""><br class=""></div><div class=""> 2) Still sounds easier to me.</div><div class=""> </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 class="">py afterwards.<br class=""></blockquote><div class=""><br class=""></div><div class="">We did this in Pylith originally, and eventually threw it away. Its much less flexible and harder to maintain.</div><div class=""><br class=""></div><div class=""> Thanks,</div><div class=""><br class=""></div><div class=""> Matt</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any comments on this?<br class="">
<br class="">
Thanks<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
Vaclav</font></span></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class="">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br class="">-- Norbert Wiener</div><div class=""><br class=""></div><div class=""><a href="http://www.caam.rice.edu/~mk51/" target="_blank" class="">https://www.cse.buffalo.edu/~knepley/</a><br class=""></div></div></div></div></div>
</div></div>
</div></blockquote></div><br class=""></body></html>