Check compatibility of various HDF5 versions (1.10 vs 1.12)

[lerandc]

No description provided.

[noahschnitzer]

@lerandc have there been compatibility issues with hdf5 v1.12? In our lab we have run into issues compiling prismatic on macs where dependencies were installed with homebrew (where the default hdf5 is v1.12) but none compiling on macports with hdf5 v1.10?

@masmeaton

[lerandc]

Hey @noahschnitzer -- I forgot about this floating issue which I've now implicitly tested by having to rebuild my compiling workflow, I'm using hdf5 1.12.0 on an Unbuntu station and it is working fine. which components are you trying to compile, and what errors specifically are coming up? I have an inkling of memory regarding homebrew hdf5 issues, @sezelt does anything come to mind or am I misremembering?

[noahschnitzer]

Sorry I misstated, we were actually able to compile with hdf5 1.12.0, but saw the following behavior:

• running with 3d option worked as expected, generating a single .h5 file output
• running with 4d option from command line causes an hdf5 error
• running with 4d option in pyprismatic generated separate .h5 files for each real space pixel.

The hdf5 error encountered running prismatic -i SI100.xyz -4D true :

HDF5-DIAG: Error detected in HDF5 (1.12.0) thread 0:
#000: H5F.c line 849 in H5Fflush(): unable to flush file
major: File accessibility
minor: Unable to flush data from cache
#1: H5VLcallback.c line 3764 in H5VL_file_specific(): can't reset VOL wrapper info
major: Virtual Object Layer
minor: Can't reset object
#2: H5VLint.c line 2320 in H5VL_reset_vol_wrapper(): no VOL object wrap context?
major: Virtual Object Layer
minor: Bad value
libc++abi.dylib: terminating with uncaught exception of type H5::LocationException

[lerandc]

interesting, thanks for bringing this up! i'll try to see if i can recreate this behavior-- for more clarification, can you confirm which commit this was compiled against (master or dev branch)?

for a sanity check on the command line error, can you try specifiying new and unique output file name? I am wanting to check if this is coming up everytime consistently or if the file is locked by another process in some weird way or by some exit behavior of prismatic

[sezelt]

@lerandc all my homebrew/hdf5 issues were related to cmake not finding it, throwing a wrench in the build phase (as @noahschnitzer said in the first message). I've never had @noahschnitzer second message problems.

I'm still not sure what the exact problem was, it just kinda fixed itself after I ignored it for a long time, so maybe it was upgrading hdf5 for other reasons, maybe it was upgrading cmake, ...?

[masmeaton]

Hi @lerandc, I downloaded the most recent commit from the master branch.

I tried running the SI100.xyz file from the command line with all variations of -4D true and -3D (true/false/default) with a unique output file name every time and the result was (seemingly randomly): a successful run, the above HDF5 error or a segmentation fault.

@noahschnitzer

[lerandc]

I've tested on 1.10(.5) and 1.12 and both seem to work, so closing this issue. @masmeaton sorry to have let this slipped, did these issues ever sort out or make sense?