hdf5 file produced by vtk hdf writer crashes paraview

[HuntFeng]

Hi thanks for the hard work here!

I'm a newbie to this repo, I'm not familiar with the correct usage.

I have the following code to write 2D point field evolving with time to a hdf5 file.

#include <gridformat/gridformat.hpp>

int main() {
      GridFormat::ImageGrid<2, double> grid {
          { 1.0, 1.0 }, // domain size
          { 10, 12 } // number of cells (pixels) in each direction
      };
      GridFormat::VTKHDFTimeSeriesWriter writer {
          grid,
          "hdf5_test"
      };
      for (double t = 0.0; t < 1; t += 0.1) {
          writer.set_point_field(
              "point_field",
              [&](const GridFormat::Point<GridFormat::ImageGrid<2, double>>& point) {
                  return t;
              }
          );
          const auto written_file = writer.write(t);
      }
    return 0;
}

This HDF5 file crashes Paraview when I changes the time in paraview. According to Paraview support, they said

I reproduce your crash, we reach an assert:
vtkStructuredPointBackend.h:103: vtkStructuredTPointBackend
Assertion `this->ArrayX->GetNumberOfTuples() == 2' failed
I believe you miss the PointDataOffsets group in the Steps/, you can check how we do that in the transient_wavelet.hdf (which is the data used to check this feature in the testing suite of VTK) :
transient_wavelet.hdf

I wonder what is this PoinDataOffsets group here and how do I set that?

[dglaeser]

Hi @HuntFeng and thanks a lot for posting this issue! I can reproduce your error and will have a look. Unfortunately, the documentation on the file formats is not optimal, so I will have to dig through the VTK code.

A few comments I can already make at this point:

• which paraview version are you using? With 5.12.1 I can successfully open the file produced with your code. With Paraview 5.13.1 I can no longer open it. So I will look into the code to see what changed.
• 5.12.1 was the version I originally tested the code with. Unfortunately, back then the python VTK version did not yet have this reader, so I had not included regression tests for the vtk hdf time series, but I will do so asap after finding a fix for this issue.
• this only seems to affect the ImageData variant (i.e. for structured grids). If you explicitly write it as unstructured vtk hdf transient file, then you can also open it with 5.13. To do so, simply replace

GridFormat::VTKHDFTimeSeriesWriter writer { ...

with

GridFormat::VTKHDFUnstructuredTimeSeriesWriter writer { ...

• I am unsure about the reply you got from the mailing list. In any case, as a user you should not have to write the PointDataOffsets group, this is something the writers/readers automatically check. I will dig through the updated documentation and the VTK code and try to find a fix for the issue.

Thanks again for pointing this out, I hope I can find a solution quickly.

[dglaeser]

Ah I just thought that since you have an open thread with the ParaView support already - could you maybe add there that the file works with paraview5.12 (only if this is the case for you, too, of course) and ask them directly if they made some changes to the vtk hdf transient image data format? That would be great, thanks!

[HuntFeng]

@dglaeser Thanks for the quick reply.

which paraview version are you using? With 5.12.1 I can successfully open the file produced with your code. With Paraview 5.13.1 I can no longer open it. So I will look into the code to see what changed.

I can confirm this. With Paraview 5.12.1 I can open the hdf5 file produced by my code too and is able to visualize different time steps. With Paraview 5.13 I can still open it and visualize the first time step but it crashes once I change the time step.

this only seems to affect the ImageData variant (i.e. for structured grids). If you explicitly write it as unstructured vtk hdf transient file, then you can also open it with 5.13. To do so, simply replace ...

• Changing from GridFormat::VTKHDFTimeSeriesWriter to GridFormat::VTKHDFUnstructuredTimeSeriesWriter indeed works in Paraview 5.13!

[HuntFeng]

One dumb question here, in the above code at the line of const auto written_file = writer.write(t);

VScode throws me error messge

no instance of overloaded function "GridFormat::APIDetail::UnavailableWriter::write [with Asserter=GridFormat::VTKHDFAsserter]" matches the argument listC/C++(304)
test.cpp(20, 42): argument types are: (double)
test.cpp(20, 42): object type is: GridFormat::VTKHDFUnstructuredTimeSeriesWriter

I can compile the code without issue though. Is this something I should worry about or not?

[dglaeser]

One dumb question here, in the above code at the line of const auto written_file = writer.write(t);

VScode throws me error messge

no instance of overloaded function "GridFormat::APIDetail::UnavailableWriter::write [with Asserter=GridFormat::VTKHDFAsserter]" matches the argument listC/C++(304) test.cpp(20, 42): argument types are: (double) test.cpp(20, 42): object type is: GridFormat::VTKHDFUnstructuredTimeSeriesWriter

I can compile the code without issue though. Is this something I should worry about or not?

It's something that VSCode shows but you don't get that error when compiling, right? (I guess not since you can successfully run your application)...

The code that gives you this message is only there to give users more descriptive compiler errors when e.g. HDF5 is missing (which is a requirement for the writer you are using). I think I know what's going on, though. Would you mind trying if this disappears when you use the code on this branch: #296

BTW, I opened an issue in VTK to try to get help with finding out what's going on: https://gitlab.kitware.com/vtk/vtk/-/issues/19628

[dglaeser]

Update: it loooks like it's a bug on the VTK side: https://gitlab.kitware.com/vtk/vtk/-/issues/19628#note_1630421

EDIT: ah well the referenced discussion was the one you opened :D... thanks!

[HuntFeng]

Thanks a lot! I saw the Paraview issue on gitlab https://gitlab.kitware.com/vtk/vtk/-/issues/19628 also. You offer me great help.

I'll also try your new branch and see if the linter error goes away.

EDIT: I decided to open a new issue #297 to track the linter error for better organization.