Upstreaming a reader for zCFD mesh files

Development
1

Hi all, we’d like to get a reader for zCFD native mesh files into VTK/ParaView, to replace the plugin we ship today. Our results are already VTKHDF, so it’s only the mesh format that needs one. Before we start, we’d like to know what you’d want from it.

The format is a single HDF5 file with a mesh group. Cells are defined only by their faces, so arbitrary polyhedra are fine, and are pretty simply defined:

  • numCells, numFaces: attributes
  • nodeVertex: node coordinates, (nodes, 3) float64
  • faceType: nodes per face
  • faceNodes: each face’s node ids, flattened, 0-based
  • faceCell: left (owner) and right cell per face. A boundary face’s right cell is ≥ numCells.
  • faceInfo: zone id per face

Face normals point out of the left cell. We’re publishing a detailed full spec with our docs bump at our next release, which should line up nicely if we’re aiming for 6.2.1 (or whichever release suits).

The plan is a reader using only VTK’s own HDF5. It would output the volume as polyhedra plus one surface per boundary zone, with zone selection. It would come with a small test mesh. The current plugin’s embedded Python and file write-back would both go.

A few questions:

  1. VTK IO module plus a ParaView proxy, or straight into ParaView?
  2. Preferred output type? Partitioned dataset collection, or something else?
  3. .h5 clashes with plenty of other formats. Is a CanReadFile check on the mesh group enough?
  4. Anything you need for tests: size limits on test data, baseline images?
  5. Anything on licensing or maintenance we should sort out up front?

Happy to share sample files.

2

Hi @T-Wainwright

This sounds like a great fit for VTK/ParaView.

Is this format documented online somewhere ? That would increase its visibility and relevance in VTK.
I did found mentions in Mesh Conversion — zCFD User Guide v2024.11.9510 documentation but not to the level of details you are sharing above.

TBH just a dedicated format spec page in your docs would be enough.

Other than that, I think is would be a nice fit.

VTK IO module plus a ParaView proxy, or straight into ParaView?

Two possibilities:

  • ParaView plugin only → less work, can be integrated almost as is, less visibility
  • VTK IO module + ParaView proxy → more refactoring for sure ( style, modernisation, integration in the VTKHDF framework, testing) but then its fully integrated

Preferred output type? Partitioned dataset collection, or something else?

For composite, Partitioned dataset collection is the way to go.

.h5 clashes with plenty of other formats. Is a CanReadFile check on the mesh group enough?

You may want to go the VTKHDF route and use your own extension, but if not possible, you can write a more complex CanReadFile that will check more deeply the mesh format, but I defer to @Louis_Gombert on that.

Anything you need for tests: size limits on test data, baseline images?

Definitely small samples of data, ideally under 1Mb will be needed. Baseline will be generated by the tests themselves.

Anything on licensing or maintenance we should sort out up front?

As long as you agree to the provide the source code as BSD, then you can keep the copyright on it, but note the VTK/ParaView copyright will be added as well on it.

Once its in VTK/ParaView, maintenance is done by VTK/ParaView maintainers but complex operation (lets say a refactoring needed by a deprecation of an API in VTK) may require contributors (aka you or a contracted company by you, which could be Kitware) to dig in and fix it as this may be too much for standard maintenance work.