With the release of HDF5 1.10, we are faced with a couple issues. First and foremost, netcdf4 files written using the 1.10 library (compiled with or without 1.10 API, it makes no matter) cannot be read by a libnetcdf compiled against HDF5 1.8.x. This has serious implications for the Unidata datastreams, so long as there are nodes using 1.8 trying to read data generated by nodes using 1.10.
The full changes from HDF5 1.8 to 1.10 can be found here, at the time of this writing:
The API compatibility report may be found here:
49.2% incompatibility!
It appears that there may be command line tools (5hformat_convert) for re-writing the index data so that 1.10 generated files can be read by 1.8, but lit review is required to determine if this is true. There is also a new function that is listed as "yet to be documented", e.g. H5[D/F]format_convert.
This issue is opened to track progress on how we mitigate these changes for our user community.
With the release of HDF5 1.10, we are faced with a couple issues. First and foremost,
netcdf4files written using the1.10library (compiled with or without 1.10 API, it makes no matter) cannot be read by alibnetcdfcompiled against HDF5 1.8.x. This has serious implications for the Unidata datastreams, so long as there are nodes using1.8trying to read data generated by nodes using1.10.The full changes from HDF5 1.8 to 1.10 can be found here, at the time of this writing:
The API compatibility report may be found here:
49.2% incompatibility!
It appears that there may be command line tools (
5hformat_convert) for re-writing the index data so that 1.10 generated files can be read by 1.8, but lit review is required to determine if this is true. There is also a new function that is listed as "yet to be documented", e.g.H5[D/F]format_convert.This issue is opened to track progress on how we mitigate these changes for our user community.