netCDF4 writing

[lesserwhirls]

Related to #534. I feel we need to make a call to the HDF5 lib when we load netCDF-C to ensure 1.8.x compatibility, no if, ands, or buts. hehehe. But seriously, we don't need servers creating netCDF4 files that can only be read if users built netCDF-C with the latest version of the HDF5 lib. Based on the comments in Unidata/netcdf-c#250, this seems like the call we need to make:

https://www.hdfgroup.org/HDF5/doc/RM/RM_H5P.html#Property-SetLibverBounds

The link is sort of slow to load, so here are the docs for the function:

Name: H5Pset_libver_bounds
Signature:
herr_t H5Pset_libver_bounds( hid_t fapl_id, H5F_libver_t low, H5F_libver_t high )
Purpose:
Sets bounds on library versions, and indirectly format versions, to be used when creating objects.
Description:
H5Pset_libver_bounds controls the versions of the object formats that will be used when creating 
objects in a file. The object format versions are determined indirectly from the HDF5 Library 
versions specified in the call.
This property is set in the file access property list specified by fapl_id.

Parameters:
hid_t fapl_id           IN: File access property list identifier
H5F_libver_t low        IN: The earliest version of the library that will be used for writing objects. 
The library version indirectly specifies the earliest object format version that can be used when 
creating objects in the file.
Currently, low must be one of two pre-defined values:

Setting low to H5F_LIBVER_EARLIEST will result in objects being created using the earliest possible 
format for each object. Note that earliest possible is different from earliest, as some features introduced 
in library versions later than 1.0.0 resulted in updates to object formats. With 
low=H5F_LIBVER_EARLIEST, if the application creates an object that requires a feature introduced in 
library versions later than 1.0.0, the earliest possible version that supports the requested feature will be 
used.

The upper bound on the range of possible library versions used to create the object is controlled by the 
high parameter.

This is the default behavior of the library if H5Pset_libver_bounds is not called.

Setting low to H5F_LIBVER_LATEST will result in objects being created using the latest available format 
for each object. This setting means that objects will be created with the latest format versions available 
(within the range of library versions specified in the call), and can take advantage of the latest features 
and performance enhancements. Objects written with the H5F_LIBVER_LATEST setting for low may be 
accessible to a smaller range of library versions than would be the case if the H5F_LIBVER_EARLIEST 
value had been used.

The upper bound on the range of possible library versions used to create the object is controlled by the 
high parameter.

H5F_libver_t high       IN: The latest version of the library that will be used for writing objects. The 
library version indirectly specifies the latest object format version that can be used when creating objects 
in the file.

Currently, high must be set to the pre-defined value H5F_LIBVER_LATEST. H5F_LIBVER_LATEST 
corresponds to the version of the HDF5 Library in use. 

Returns:

Returns a non-negative value if successful; otherwise returns a negative value.

We should be able to use

H5Pset_libver_bounds (file_id, low=H5F_LIBVER_EARLIEST_F, high=H5F_LIBVER_LATEST_F)

and the netCDF4 files we write out will be just fine to read for netCDF-C built with v1.8.x of HDF5. Note that this is what the C library is doing, but rather than wait for their RC to become stable and try to get everyone using the TDS to upgrade their netCDF-C library, this seems like the best sollution.

Couple this issue with #534 (along with any outstanding PRs), and we should try to cut a bug fix release to make sure this gets into the wild asap.

Thanks to @Dave-Allured for digging out this nugget!

[DennisHeimbigner]

Ward has inserted this into the latest netcdf release. However, its semantics are unclear
to me; we are using it because it works, not because we understand it.

[lesserwhirls]

Fixed by latest netCDF-C lib.