Blaise A Bourdin <bour...@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.
pgpJudgc0hOyr.pgp
Description: PGP signature
