[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #IJX-817619]: HDF4 chunking (and compression?) support hints



Charlie,

> Yes, those tokens would suffice for most purposes.

Shortly after sending my earlier response, I discussed this with Ward 
and realized that the version information doesn't help to determine 
with which features the netCDF library was configured and built.  

But the new lib/library.settings file already includes all the needed 
information about how the library was configured as well as what version 
of the source was used.  So I'm now convinced that it would be better 
not to have to generate different netcdf.h files for different library
versions, if we can avoid it.  We've tried to make the library.settings
file easily parseable, so the information can be extracted with simple
shell commands.

> We would like to use them thusly:
> 
> #if (__GNUC__ * 100 + __GNUC_MINOR__ * 10 + __GNUC_PATCHLEVEL__ ) < 442
> 
> That works as long as Unidata keeps each token < 10.
> 
> The exception is when Unidata puts a new feature in
> the daily snapshot. Versioning has to be done
> carefully in order to test new features.
> Bumping PATCHLEVEL since the last stable release
> would handle most situations. Or some other way to tell
> it's different than the last stable release.
> 
> The entire macro above needs to be well-behaved on
> older libraries, so we would probably implement
> something at the start like
> #ifndef __GNUC__
> # define __GNUC__ 3
> # define __GNUC_MINOR__ 6
> ...

We are still discussing this, and the issues are more complex
than my original, somewhat superficial, response took into 
account.  Just adding version indicators to netcdf.h no longer
seems like something we can support.  It would involve reworking 
our infrastructure to provide another way of getting at 
information that we're already making available, in the new
libnetcdf.settings file.

--Russ

> Best,
> Charlie
> 
> On 08/29/2014 08:50 AM, Unidata netCDF Support wrote:
> > Hi Charlie,
> >
> >> Now that NCF-272 is fixed, I would like to support it in NCO.
> >> What is the best way? To workaround the now-solved bug,
> >> NCO currently avoids all chunking/compression calls on HDF4 files.
> >> Chunking should now be allowed on HDF4 files as long as
> >> NCO was built with netCDF 4.3.3+.
> >> So...we are in the familiar yet uncomfortable position where
> >> NCO needs to implement version-dependent libnetcdf.a functionality.
> >>
> >> For whatever reason, netCDF does not include a YYYYMMDD date token
> >> (like GCC does) nor a library version token (also like GCC) with
> >> which clients like NCO could implement netCDF version/date specific
> >> workarounds using those as pre-processor conditionals.
> >> In the absence of version/date tokens, the next easiest way for us is if
> >> netcdf.h includes a function-specific indicator token, e.g.,
> >> NC_HAVE_HDF4_CHUNKING
> >> NC_HAVE_HDF4_DEFLATE
> >
> > Would macros such as the__GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__
> > described at
> >
> >    https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
> >
> > suffice for what NCO needs (substituting "NETCDFC" for "GNUC" in the
> > macro names), or do you have a better suggestion?  It seems that just
> > having a version string wouldn't work very well, becasue youy want o
> > know whwther the current version is later than a specific version, and
> > the approach with the macros above allows this.  The alternative of a
> > version date integer such as YYYYMMDD would require developers to know
> > about the correspondence between version numbers and release dates, so
> > I'd prefer not to use that.
> >
> >> Also, it is unclear if netCDF-HDF4 now supports compression
> >> inquiry and/or setting functions. When I filed the original
> >> bug report nc_inq_var_deflate() would crash on HDF4. Does it still?
> >
> > Not sure, we'll have to get back to you on that.
> >
> >> It would be great if such library hints could be in 4.3.3-final.
> >
> > If it's just a matter of defining them in netcdf.h for this and all
> > subsequent releases, we can do that.  We'd define them manually
> > for this release and automate it as part of the release management
> > from now on.
> >
> > --Russ
> >
> >> Thanks,
> >> Charlie
> >> --
> >> Charlie Zender, Earth System Sci. & Computer Sci.
> >> University of California, Irvine 949-891-2429 )'(
> >>
> >>
> >
> > Russ Rew                                         UCAR Unidata Program
> > address@hidden                      http://www.unidata.ucar.edu
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: IJX-817619
> > Department: Support netCDF
> > Priority: Normal
> > Status: Closed
> >
> 
> --
> Charlie Zender, Earth System Sci. & Computer Sci.
> University of California, Irvine 949-891-2429 )'(
> 
> 

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: IJX-817619
Department: Support netCDF
Priority: Normal
Status: Closed