netCDF Operators NCO version 5.1.7 burst forth
http://nco.sf.net (Homepage, Mailing lists, Help)
http://github.com/nc/ncoo (Source Code, Issues, Releases)
What's new?
Version 5.1.7 simplifies netCDF codec invocation in ncremap/ncclimo,
ensures ncremap places gridcell vertices on the same branch cut at
longitude discontinuities, and fixes two issues with Intel compilers.
Skip this release if these issues are of no import to you.
Work on NCO 5.1.8 has commenced and aims to add support for Zarr S3
stores, and to polish support for new codecs..
Enjoy,
Charlie
NEW FEATURES (full details always in ChangeLog):
A. ncremap and ncclimo now support the same API for codec invocation
as the binary NCO operators, i.e., --cmp_sng=<compression_string>.
For example, the following commands instruct the regridder to apply
the Shuffle filter, then Granular BitRound quantization, then
Zstandard lossless compression:
ncremap -7 --cmp='shf|gbr|zst' --map=map.nc in.nc out.nc
ncremap -7 --cmp='shf|gbr=3|zst=3' ... # Explicit levels
ncclimo -7 --cmp='shf|gbr|zst' ...
ncclimo -7 --cmp='shf|gbr=3|zst=3' ... # Explicit levels
NB: single quotes above protect the pipe "|" separator from the shell.
The second command is equivalent to the first since the default
number of significant digits to retain during quantization is 3,
and the default Zstandard compression level is also 3.
The resulting compression metadata can be viewed with, e.g.,
zender@spectral:~$ ncks --hdn -C -v FSNT -m ~/foo.nc
netcdf foo {
...
variables:
float FSNT(time,lat,lon) ;
FSNT:_QuantizeGranularBitRoundNumberOfSignificantDigits = 3 ;
<--- Quantization
FSNT:_Storage = "chunked" ;
FSNT:_ChunkSizes = 1, 180, 360 ;
FSNT:_Filter = "32015,3" ; <---Zstandard
FSNT:_Shuffle = "true" ; <---Shuffle
...
} // group /
http://nco.sf.net/nco.html#cmp
http://nco.sf.net/nco.html#zst
http://nco.sf.net/nco.html#gbr
B. ncremap now always places gridcell vertices on the same branch cut
at longitude discontinuities. Consider a quadrilateral gridcell that
crosses the Greenwich Meridian and that has vertice longitudes at,
(enumerated in counter-clockwise order), occur at [359, 1, 1, 359].
This enumeration has the advantage of keeping all longitudes within
the same 360 degree domain [0..360] as the longitude centers. However,
it violates the spirit of the CF Conventions which (seem to) prefer
that all vertice longitudes have values on the same "branch cut",
i.e., [-1, 1, 1, -1]. The CF enumeration has the advantage that the
vertices can be linearly averaged to find the gridcell center.
NCO now always uses the CF-preferred method when writing longitude
vertices to the output file. NB: the NCO weight generator still
places the vertices in the old order in the map-file. We plan to
fix that in the next release. Well-behaved regridders (like NCO's)
do the right thing no matter what longitude vertice convention is
employed in the map-file. Thanks to Steven Po-Chedley and Jill Zhang
(LLNL) for bringing this issue to our attention.
BUG FIXES:
A. The previous version (5.1.6) failed to compile with Intel compilers
due to an OpenMP issue. This issue has been fixed. Thanks to Matthew
Thompson (GSFC) for pointing this out.
B. Intel compilers could not compile the previous version (5.1.6) even
when NCO was configured with configure --disable_openmp. This issue
has also been fixed. Thanks to Timothy Brown (AWS) for pointing this
out.
Full release statement at http://nco.sf.net/ANNOUNCE
--
Charlie Zender, Earth System Sci. & Computer Sci.
University of California, Irvine 949-891-2429 )'(
