Trixi2Vtk test results for P4estMesh on macOS are unverified

[efaulhaber]

The generated VTK files in the macOS CI tests of Trixi2Vtk (only the P4estMesh tests) have different hashes than on Linux and Windows. I made the tests pass like this, but it needs to be verified that the results are okay.

The elixirs that need to be tested are examples/p4est_2d_dgsem/elixir_euler_source_terms_nonperiodic.jl and examples/p4est_3d_dgsem/elixir_advection_amr_unstructured_curved.jl. For both of them, the solution at t=0.0 needs to be converted with Trixi2Vtk and compared to the results of another OS.

[ranocha]

I don't have access to Mac OS, so I can't do anything here... @sloede?

[sloede]

Similar here. I asked @efaulhaber to create this issue such that we not forget about it. In general, I think we need a more robust way to check the results of Trixi2Vtk (xref #680), e.g., by writing to ASCII VTK and verifying that the contents match.

The fact the macOS creates different hashes could be the result of something completely unrelated to VTK, e.g., because the used zlib version does something slightly different etc.

[efaulhaber]

@andrewwinters5000 just converted a file on macOS for me. Interestingly, this file has the same hash as the files generated in CI by Linux and Windows. Any ideas why macOS in CI generates a different file?

[sloede]

No idea, no. The only thing I can think of is something like differing zlib libraries etc. but also that seems to be far-fetched.

One thing you could try is to write the VTK files without compression and/or as ASCII and then compare to see if there are actual differences in the files and from where: https://github.com/jipolanco/WriteVTK.jl#additional-options

[ranocha]

We will compare the VTK files directly using some tolerance, correct?
We might look at other codes doing similar things, e.g.,

• https://gitlab.dune-project.org/quality/dune-testtools/-/blob/master/python/dune/testtools/wrapper/fuzzy_compare_vtk.py
• https://gitlab.dune-project.org/quality/dune-testtools/-/merge_requests/133

[sloede]

We will compare the VTK files directly using some tolerance, correct?

Yes, that's the plan!