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

[Vaclav Hapla]

> 17. 1. 2018 v 13:04, Matthew Knepley <knepley at gmail.com>:
> 
> On Wed, Jan 17, 2018 at 6:49 AM, Vaclav Hapla <vaclav.hapla at erdw.ethz.ch <mailto: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 <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/4719ef6a33f5f9a4a1b8c81c7a6e6ed0426097f1?at=haplav/feature-dmplex-distributed-hdf5-read <https://bitbucket.org/haplav/petsc/commits/4719ef6a33f5f9a4a1b8c81c7a6e6ed0426097f1?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 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)?

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.

Thanks
Vaclav

>  
> 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 <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/20180124/7685f6df/attachment.html>