search

LLNL / H5Z-ZFP

A registered ZFP compression plugin for HDF5
Other
50 stars 22 forks source link

Minor make fixes #104

Closed markcmiller86 closed 1 year ago

markcmiller86 commented 1 year ago
brtnfld commented 1 year ago

We use HDF5 1.10.7 in actions (GCC), and it is skipping the h5repack test.

https://github.com/LLNL/H5Z-ZFP/actions/runs/4207389928/jobs/7302115170

markcmiller86 commented 1 year ago

We use HDF5 1.10.7 in actions (GCC), and it is skipping the h5repack test.

https://github.com/LLNL/H5Z-ZFP/actions/runs/4207389928/jobs/7302115170

Great catch. Do you recall which version of HDF5 h5repack UD= argument to -f option was corrected?

I can adjust the le test to include that range.

brtnfld commented 1 year ago

I'm not 100% sure, but I see entries for UD changes in the HISTORY files for 1.10.1, 1.18.17 and 1.8.19.

markcmiller86 commented 1 year ago

Ok, I thought the problem I was having on the s390x image was that the HDF5 library was too old and I was getting an error in parsing the h5repack -f argument.

Turns out, for these tests where we use h5repack with the -f UD=<...> argument depends on endianess of the machine where the test is run. Thats because we are specifying a base-10 ascii form of the cd_values data that gets passed to the filter.

This isn't a problem for our CI because we know we're running CI little endian. But, for any user in the wild to run make check and have one of these h5repack tests pass, we need to construct the correct command line based on machine endianess. Easiest thing might be to just use the print_h5repack_arg tool.

I am still working this detail out to correct this PR.

markcmiller86 commented 1 year ago

h5repack fixed in #107