Consider removing VTK as a Python dependency.

[MicahGale]

Description

Background

1. Python releases a minor release (e.g., 3.14) annually in October.
2. OpenMC has adopted SPEC 0, which means supporting about 3 minor releases of Python.
3. vtk has held up the process of supporting Python 3.13 and 3.14 for OpenMC due to its slow adoption of the latest Python Minor release. This is because:
   1. vtk is a compiled Python package, which must be compiled against a specific python version
   2. vtk does not distribute source tar balls on PyPI, so pip cannot compile it on its own.
   3. vtk does not seem to have plans in place to plan for and be ready for minor releases of Python annually.
4. vtk is not used extensively in the Python code base. I only found the following examples:
   1. openmc.tracks.write_to_vtk
   2. openmc.plots.voxel_to_vtk
   3. openmc.mesh._create_vtk_structured_grid
   4. These all seem to be only used for dumping data to a .vtk file, not reading one.

Therefore

Be it resolved that, an internal vtk file template engine be made inside of OpenMC, and that vtk be removed as a dependency.

Alternatives

Some alternatives:

1. Status quo, and just work with vtks release schedule for OpenMC's release schedule.
2. Ship OpenMC without testing vtk support for the latest Python release, this is low risk, but does mean that OpenMC will be broken for some users.
3. Switch to using VTKHDF, though this would lead to a change in behavior for end users as hdf5 and not vtk files would be output.
4. Work with Kitware to improve their release and planning system for working with release candidates of Python minor releases.

Compatibility

If vtk is re-implemented internally the goal would be to not change the external API at all.

[shimwell]

Just a small note on alternatives point number 3. The vtkhdf files made can be opened like normal with paraview like vtk/vtu files.

[MicahGale]

Ok I misunderstood it's features then, so that could be a better alternative.

[pshriwise]

Noting here that while UnstructuredGrid and PolyData are supported in the VTKHDF5 format, I don't see StructuredGrid here: https://docs.vtk.org/en/latest/vtk_file_formats/vtkhdf_file_format/index.html

ImageData is supported, which would take care of openmc.RegularMesh, but not the other structured mesh types.

[MicahGale]

Quick update: a release candidate was just released for VTK: https://pypi.org/project/vtk/9.6.0rc2/#files. I also noticed that vtk wheels are ~150 MB. Even if we resolve this issue for 3.14 I think the wheel size justifies this move still.