Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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 )'(
netcdfgroup
archives: