I’ve just tested out the new 3.3.1 release (Windows, AppImage HDFViewApp-3.3.1-win10_64-vs17.zip), having previously used the AppImage 3.3.0 without issues.
When comparing 3.3.0 and 3.3.1 side-by-side on the same computer, I see that 3.3.1 fails to open any actual NetCDF data, only giving me the following error message popup:
An error occured while loading data for the table:
failed to read scalar dataset: Can’t open directory or file
The text console in the bottom shows
*** Error: unable to load table data ***
Metadata information on all variables is still shown for those files, though (as far as I can tell).
When opening HDF5 files, I see that some variable data can be read as expected, but for some others it fails with the above error as well. So far I cannot spot why it works for some variables and not for others.
The exact same files and variables are all readable on version 3.3.0.
Could this be related to any VC runtime package missing? As far as I can tell they are all installed. Did I miss anything else that could explain this?
No, I cannot explain it as 3.3.1 fixed some issues that should allow additional combinations of datatypes to work. In addition, 3.3.1 did pass all our existing tests, so we must be missing a file of your datatypes.
Would it be possible to send us a sample file?
While I can’t share the original data I have been testing this with at this point, I have found at least one file which shows the same problem and is publicly available. It can be found here: ptcuo005457_2D_HOMO_notps_3energies.h5 - Peter Grünberg Institut – Quantum Nanoscience (PGI-3)
It is relatively small and only contains four variables. I can open all of them in 3.3.0 and none in 3.3.1. Hope this helps to narrow it down.
As for NetCDF: All version 3 files I tested seem to work, the problem is with the version 4 - and thus HDF5 files. So my best guess is that it’s the same problem.
Your file has the datasets compressed with gzip! I wonder if the windows hdf5 binary that we used to build HDFView on windows did not have gzip included.
Interesting! That would certainly explain why NetCDF3 still worked (no compression supported) and why most of our NetCDF4 and HDF5 fail, as they are usually compressed. I assume you’ll fix this in a new release?
