Adding vtkhdf option to write vtk data

[jon-proximafusion]

Description

As discussed in #3113 it would be great to have a method of writing VTKHDF files for mesh tally data.

This PR allows users to write .hdf file VTKHDF compatible files with the existing UnstructuredMesh.write_data_to_vtk() method. This has a few advantages over the legacy vtk files we currently write.

It would be particularly useful for those of us who can't make use of the vtk package in their environment. We have this issue at the moment and can't import cadquery along with openmc due to slightly different vtk packages. It is super useful that vtk is an optional dependency in openmc and not mandated. This use of h5py lets us avoid using the vtk package while still being able to write VTKHDF files

For interested people the VTKHDF roadmap is here, the ability to read these files (ending with hdf) was introduced in Paraview 5.13.0 release notes.

All credit goes to the Kitware developers and particularly @mwestphal who introduced me to this feature

Fixes # (issue)
partly addresses #3113

Checklist

• I have performed a self-review of my own code
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[pshriwise]

Looks really nice @shimwell! It will be a great option to have. I'll review as soon as I am able.

[jon-proximafusion]

@pshriwise just to mention we are working on adding for more VTK based file formats in addition to this VTKHDF.

We are also looking at adding VTU.

So we are building on this branch with another feature.

We won't make a PR for the VTU work till this VTKHDF PR has been merged or rejected, but I just wanted to let you know so you can take that into account when reviewing.

[rherrero-pf]

Related PR to enable export flexibility #3290

[shimwell]

@pshriwise I've solved the merge conflicts and i think this one is ready for review when you have time.

[jon-proximafusion]

Just resolved a small conflict.

[shimwell]

@pshriwise just wondering if you have had time to review this PR

[shimwell]

I have been tinkering with python 3.14 as I couldn't resist the option to run without the famous gil.

I have got openmc working for the most parts and also produced a wheel.

https://github.com/shimwell/wheels/blob/main/openmc/openmc-0.15.3-cp314-cp314-manylinux_2_28_x86_64.whl

The one thing I could not get working was any functions that import VTK. It appears there is no pypi release for VTK yet.

https://pypi.org/project/vtk/#files

This brought me back to the PR I made in January where I provided an option to write vtkhdf files which does not need the VTK package.

#3252

I think this PR is even more useful now as it offers the a route to get even more of OpenMC working with python 3.14 by avoiding the use of the VTK package.

I'm also thinking we should do the dame sort of vtkhdf5 for all the meshes when writing VTK format files and then look to make hdf5 the default in follow up PRs

[pshriwise]

I started a review but started having larger questions...

The new format looks pretty lightweight -- not bad to implement manually which is nice. I'm a little hesitant to take on maintaining writing these files manually when the vtkHDFWriter exists. Can you elaborate on this situation a bit?

We have this issue at the moment and can't import cadquery along with openmc due to slightly different vtk packages.

And I'll also apologize for how long it's taken for me to get back to this. Thanks for your patience @shimwell!

[jon-proximafusion]

Can you elaborate on this situation a bit?

We have this issue at the moment and can't import cadquery along with openmc due to slightly different vtk packages.

My understanding is that Conda enforces packages are compiled with the same compiler / settings while pypi places no such restrictions on this. So installing cadquery, vtk, openmc both from pypi results in a binary incompatibility. Cadquery therefore makes and distributes its own version of vtk called cadquery-vtk that is built in a compatible way. They build and bundle VTK because the glibc version for the VTK package installed through pip is too new for many systems. There are related issues on this here. In summary it would be nice if we can write vtk format files but avoid using vtk. A we already have hdf5 as a dependency this provides a route to writing vtk format files without using vtk.

I didn't know about the vtkHDFWriter but if it uses the vtk package then this wouldn't solve the issues as I'm trying to avoid vtk package use.

[mwestphal]

Can you elaborate on this situation a bit?

We have this issue at the moment and can't import cadquery along with openmc due to slightly different vtk packages.

My understanding is that Conda enforces packages are compiled with the same compiler / settings while pypi places no such restrictions on this. So installing cadquery, vtk, openmc both from pypi results in a binary incompatibility. Cadquery therefore makes and distributes its own version of vtk called cadquery-vtk that is built in a compatible way. They build and bundle VTK because the glibc version for the VTK package installed through pip is too new for many systems. There are related issues on this here. In summary it would be nice if we can write vtk format files but avoid using vtk. A we already have hdf5 as a dependency this provides a route to writing vtk format files without using vtk.

I didn't know about the vtkHDFWriter but if it uses the vtk package then this wouldn't solve the issues as I'm trying to avoid vtk package use.

Hi,

VTK and VTKHDF maintainer here.

I confirm that VTKHDF is designed to be usable without the need for using vtkHDFWriter and linking against VTK. Using hdf5 directly and following the VTKHDF spec is a perfectly valid approach and we take great care for retro compatibility and documentation of format change.

I also confirm that VTK does not provide a 3.14 wheel yet but should soon start doing so, at least for VTK 9.6.

hth,

[pshriwise]

I didn't know about the vtkHDFWriter but if it uses the vtk package then this wouldn't solve the issues as I'm trying to avoid vtk package use.

Indeed not, but its existence required me to ask :)

@mwestphal thanks for taking the time to confirm the VTKHDF design intent and viability of a sustainable independent implementation for writing these files.

I'm going to give this some more thought, but am leaning toward going forward with it.

[pshriwise]

Thanks for the refactor! It looks much cleaner to me. A few more comments to think over @shimwell.

[shimwell]

Thanks for the review, I have made the suggested changes.

[paulromano]

After thinking over this one, I'm on board despite my reluctance to support this code in OpenMC when equivalent functionality is availability out of vtk package directly. I've personally experienced the pain of dealing with the vtk Python package and would be keen on not having to bring it in as a dependency.

Looks like CI is failing due to the issue below:

[mwestphal]

After thinking over this one, I'm on board despite my reluctance to support this code in OpenMC when equivalent functionality is availability out of vtk package directly. I've personally experienced the pain of dealing with the vtk Python package and would be keen on not having to bring it in as a dependency.

Looks like CI is failing due to the issue below:

As a VTK and VTKHDF maintainer, I'm glad to hear that because this is exactly for this usercase that VTKHDF was designed, to NOT require VTK to be needed and yet still being able to output ParaView/VTK compatible data.

[pshriwise]

I took the liberty of making a few changes here @shimwell. Please let me know if they're alright with you.

• changed name of the new test function. It was shadowing another test function name and hiding an error with the type of file format written for vtk/vtu extensions.
• added the test mesh file to the local directory to simplify path construction
• running test in temporary directory so the repository doesn't contain

I've got some changes lined up to enable hex element writing, but I'll save those for a follow-on PR after this goes in.

[shimwell]

Thanks Patrick.

[pshriwise]

Thanks for making us aware of this capability and for the contribution, @shimwell! Once we support all meshes maybe we remove the need for the vtk module altogether. We'll see!

[shimwell]

super, thanks for the improvements and approving. If there are no objections I can merge this in tomorrow.