[petsc-dev] DMplex reader / viewers

[Jed Brown]

Blaise A Bourdin <bourdin at lsu.edu> writes:

> Hi,
>
> It looks like DMplex is steadily gaining maturity but I/O is lagging
> behind. As far as I understand, right now, PETSc can _read_ a mesh in
> exodus format, and write binary VTS format, but many issues remain,
> IMHO:
>    - The exodus reader relies on a hard-coded nodeset named “marker”. Generating such a nodeset is not trivial
>      (at least not for complex meshes generated with Cubit / Trelis).

Agreed.

>    - Reading from or writing to exodus files is not supported.

Reading works.  (typo?)

>    - The VTS viewer only allows to read and write _all_ fields in a DM. This may be overkill if one only 
>      wants to read boundary values, for instance.

Would it be okay to create a sub-DM containing the boundary fields and
write that Vec?

>    - The VTS viewer loses all informations on exodus nodesets and cell sets. These may have some significance
>      and may be required to exploit the output of a computations.

I consider VTS to be quick-and-dirty, but not a proper solution.

>    - VTS seems to have a concept of “blocks”. My understanding is that the parallel VTS viewer uses blocks to
>      save subdomains, and that continuity of piecewise linear fields across subdomain boundaries is lost. 
>      It is not entirely clear to me if with this layout, it would be possible to reopen a file with a 
>      different processor count.

I don't use PVTS (write many files and an index file to stitch them
together).  Instead, I write one file containing multiple blocks.  They
should be consistent at interfaces.

> I can dedicate some resources to improving DMplex I/O. Perhaps we can
> start a discussion by listing the desired features such readers /
> writers should have. I will pitch in by listing what matters to me:
>    - A well documented and adopted file format that most post-processors / visualization tools can use

Suggestions?  I haven't met a file format that wasn't garbage, though
some are less trashy than others...

>    - Ability to read / write individual fields

I prefer sub-DM/subvecs.  If you don't like that, can you suggest an
alternative interface?

>    - Preserve _all_ information from the exodus file (node / side /
>    cell sets), 

Seems attainable for everything that DMPlex can encode.

>    do not lose continuity of fields across subdomain boundaries.

I think this is correct now.

>    - Ability to reopen file on a different cpu count
>    - Support for higher order elements

Do you know a format that does this?  I couldn't find one and thus wrote
my own HDF5 format and VisIt plugin.  We could do that for DMPlex, but
it's something that people have to install.  Using common formats
(especially VTS) is easy.

> Am I missing something? If not, we can follow up with discussion on formats and implementation.

One attribute I didn't like about my format was that my data model was
more relational than hierarchical, for which queries are cumbersome to
write in HDF5.  I think the normalized relational model is valuable, so
I would consider instead doing a sqlite index backed by "dumb" HDF5 or
even MPI-IO objects.


Do you include material properties in mesh files?  This is common with
systems like Abaqus, and has been a workflow impediment for us in the
past.  I'd be happy to hold that information outside the mesh file, but
it needs to be represented and associated somehow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140121/cf18b5df/attachment.sig>