[petsc-dev] Plex XDMF/HDF5 I/O

[Matthew Knepley]

On Wed, Jan 17, 2018 at 6:49 AM, Vaclav Hapla <vaclav.hapla at erdw.ethz.ch>
wrote:

> For DMPlex and PETSCVIEWERHDF5, DMView produces a HDF5 file consisting
> basically of these 3 parts:
> 1) vertices (HDF5 group /geometry)
> 2) "native" Plex topology as a serialization of the Plex graph
> 3) traditional topology as connectivity of vertices, XDMF-compatible (HDF5
> group /viz/topology)
> So the topology is stored redundantly in two different ways 2 and 3.
>
> 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.
>
> 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 https://github.com/nschloe/meshio. The writer code can be
> copy-pasted from plexhdf5.c (function DMPlexWriteTopology_Vertices_HDF5_Static)
> and the reader can be implemented relatively easily using
> DMPlexCreateFromCellListParallel (see preview at
> https://bitbucket.org/haplav/petsc/commits/4719ef6a33f5f9a4a1b8c81c7a6e6e
> d0426097f1?at=haplav/feature-dmplex-distributed-hdf5-read).
>
> 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.
>

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
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
it easier to select which part gets output using formats.


> There's still a question how to store non-homogenous meshes (with
> different cell shapes). I can see two possible ways:
> 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."
> 2) XDMF allows "mixed" topology (http://www.xdmf.org/index.
> php/XDMF_Model_and_Format#Arbitrary) 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.
> It will also require generalising DMPlexCreateFromCellListParallel().
>

  2) Still sounds easier to me.


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

We did this in Pylith originally, and eventually threw it away. Its much
less flexible and harder to maintain.

  Thanks,

    Matt


> Any comments on this?
>
> Thanks
>
> Vaclav




-- 
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.caam.rice.edu/~mk51/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180117/0d819257/attachment.html>