Add support for VTKHDF

[Lgt2x]

Describe your changes

VTKHDF is the new-generation HDF5-based file format for VTK. F3D can read both legacy and XML VTK format, so it would make sense to also add support for VTKHDF.

VTKHDF is still under development, so all VTK 9.X versions may not have full support.

Test data generated from ParaView 5.13.3.

Checklist for finalizing the PR

• I have performed a self-review of my code
• I have added tests for new features and bugfixes
• I have added documentation for new features
• If it is a modifying the libf3d API, I have updated bindings
• If it is a modifying the default versions, I have updated timestamp

Continuous integration

Please check the checkbox of the CI you want to run, then push again on your branch.

• Style checks
• Fast CI
• Coverage cached CI
• Analysis cached CI
• WASM CI
• Android CI
• macOS Intel cached CI
• macOS ARM cached CI
• Windows cached CI
• Linux cached CI
• Other cached CI

[Lgt2x]

Well I guess pipelines should somehow rebuild their VTK with the added option

[mwestphal]

Well I guess pipelines should somehow rebuild their VTK with the added option

Indeed, you need to increase cache value in cache-vtk step in .github/actions/vtk-install-dep/action.yml
I'll take care of the android/wasm stuff.

[Lgt2x]

Indeed, you need to increase cache value in cache-vtk step in .github/actions/vtk-install-dep/action.yml

We may want to document that somewhere

[Lgt2x]

mh CI is still not happy about it

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.88%. Comparing base (35c4854) to head (a292fb2).
Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2170   +/-   ##
=======================================
  Coverage   95.88%   95.88%           
=======================================
  Files         127      127           
  Lines       11115    11118    +3     
=======================================
+ Hits        10658    10661    +3     
  Misses        457      457           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mwestphal]

Indeed, you need to increase cache value in cache-vtk step in .github/actions/vtk-install-dep/action.yml

We may want to document that somewhere

The CI workflow is basically not documented from a dev POV, There are more critical things to do imo.

[mwestphal]

mh CI is still not happy about it

Our CI tests against VTK 9.2.6, which is not compatible with VTKHDF.
Lets not add VTKHDF reader when VTK_VERSION is <= 9.3.0

If you can find the exact data it started working because you know the MR lets do that, but its not critical and you can cut off at 9.3.0

Of course you need to put that in the native plugin CMakeLists.txt and in the testing logic as well.

[mwestphal]

Since hdf5 cannot be enabled on android, I think this should go into its own hdf or vtkhdf plugin. What do you think @Meakk ?

[Meakk]

Since hdf5 cannot be enabled on android, I think this should go into its own hdf or vtkhdf plugin. What do you think @Meakk ?

I think we moved exodus to its own plugin because of hdf. Maybe we can put it there and rename the exodus plugin to extra or hdf?

[mwestphal]

That'd be possible indeed, but we need to deprecate the exodus plugin manually in the libf3d. That is doable though.

[Lgt2x]

I think we moved exodus to its own plugin because of hdf. Maybe we can put it there and rename the exodus plugin to extra or hdf?

Exodus does not depend on HDF as far as I'm aware

[Meakk]

Exodus does not depend on HDF as far as I'm aware

I think it does: https://github.com/Kitware/VTK/blob/b4f4b646ff1f4761d2003fec94a08d0debf00c7e/ThirdParty/exodusII/vtk.module#L10

[Lgt2x]

Oh right, I can make a hdf plugin then. I'm not familiar with f3d's deprecation mechanism, do you have an example?

[mwestphal]

I'm not familiar with f3d's deprecation mechanism, do you have an example?

There is no dedicated deprecation mechanism for option values, so it will have to be handled manually.

The best way is probably to handle that in engine::loadPlugin with a deprecated name to new name conversion and a warn.

That can wait, you can start by creating the plugin first and add support for vtkHDFReader in it, then move exodus into it.

[github-actions]

You are modifying libf3d public API! ⚠️Please update bindings accordingly⚠️!
You can find them in their respective directories: python, java, webassembly.

[Lgt2x]

Moved the reader to a hdf plugin as suggested, exodus reader to be moved there

[mwestphal]

That was fast ^^, let me know if you need help with the deprecation of the exodus plugin.

[Lgt2x]

Deprec and testing done, let me know if it is what you had in mind

[mwestphal]

nice, some small changes needed

Please note this will also require changes in the f3d-superbuild

[Lgt2x]

Please note this will also require changes in the f3d-superbuild

About that, I have 2 possibilities in mind:

• Use the existing ENABLE_EXODUS option to activate the new hdf f3d plugin, that does not contain only exodus anymore.
• Create a new dummy project (f3dhdf for instance) that depends on exodus and hdf5 and activates building the plugin

What is the preferred way?

EDIT: created a new dummy project here: f3d-app/f3d-superbuild#241

[mwestphal]

Please resolve discussions when you adress them :)

[mwestphal]

I've edited the PR descr for the new CI workflow template. Please check the checkboxes for CI when you want.

[mwestphal]

One last comment