http://nco.sf.net (Homepage, Mailing lists, Help)
http://github.com/nco/nco (Source Code, Issues, Releases)
What's new?
Version 5.1.9 updates ncremap to employ new TempestRemap
weight-generation algorithms (bilinear and integrated bilinear),
updates ncremap to recognize new names for existing algorithms,
changes ncremap's default treatment of filling empty areas with
missing values, and fixes a long-standing bug with ncra and ncrcat
subcycle and interleave options. A notable fix for MS Windows OS
is included as are a few other miscellaneous features and fixes
described below.
Work on NCO 5.2.0 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 supports a new flag, --mpt_mss, to control the values
placed in empty unmasked destination gridcells in sub-gridscale (SGS)
mode. SGS mode interprets every gridcell as being fractionally covered
by an amount contained in sgs_var (e.g., landfrac, seaicefrac).
Empty in this context means unmasked cells where sgs_var is zero,
e.g., no land, or no sea ice. Since ~2020, ncremap has filled empty
SGS cells with the missing value. NCO 5.1.9 changes that behavior so
that, by default, empty SGS cells are filled with zeros. This makes
maps of sea-ice variables, e.g., zero in open ocean and non-zero
where sea ice exists. Users can explicitly request the previous
behavior (missing values instead of zeros) with the --mpt_mss
flag (which stands for "empty missing").
ncremap -P mpasseaice --map=map.nc in.nc out.nc # Empty = 0.0
ncremap -P mpasseaice --mpt_mss --map=map.nc in.nc out.nc # Empty =
_FillValue
http://nco.sf.net/nco.html#mpt_mss
B. ncremap supports new TempestRemap bilinear and integrated bilinear
weight-generation algorithms. The algorithms sport the recommended
names trbilin and trintbilin.
ncremap --alg_typ=trbilin --grd_src=src.nc --grd_dst=dst.nc --map=map.nc
ncremap --alg_typ=trintbilin --grd_src=src.nc --grd_dst=dst.nc --map=map.nc
http://nco.sf.net/nco.html#tr
C. ncremap supports new "standard" names for E3SM v3 regridding
algorithms and for older algorithms. These new names are simply
synonyms for the existing algorithm names. No algorithm names have
been deprecated (yet) so existing commands will still work.
The new names are of the form ToolAlgorithm where Tool is esmf, nco,
tr, or mbtr and Algorithm is the "classic" algorithm name, aave,
bilin, etc.
ncremap --alg_typ=esmfaave --grd_src=src.nc --grd_dst=dst.nc --map=map.nc
ncremap --alg_typ=ncoaave --grd_src=src.nc --grd_dst=dst.nc --map=map.nc
ncremap --alg_typ=traave --grd_src=src.nc --grd_dst=dst.nc --map=map.nc
https://acme-climate.atlassian.net/wiki/spaces/DOC/pages/1217757434/Mapping+file+algorithms+and+naming+convention
D. ncks supports a new flag, --chk_xtn, that reports whether filename
extensions comply with NASA's Dataset Interoperability Working Group
(DIWG) which recommends ".nc", ".h5", and ".he5", depending on the API
used to write the file. To check a file's compliance with the DIWG
recommendation:
$ ncks --chk_xtn ~/nco/data/in.nc
$ ncks --chk_xtn ~/nco/data/in.nc4
$
http://nco.sf.net/nco.htlm/chk_mss
BUG FIXES:
A. NCO versions from 4.9.4--5.1.8 (September, 2020 through October,
2023) contained a bug that affected the subcycle and interleave (SSC
and ILV) hyperslab features. The bug was triggered by invoking the
SSC feature without explicitly providing an ILV parameter. The
software failed to initialize an internal flag that indicated whether
ILV had been invoked. The resulting behavior was compiler-dependent.
Most compilers set the ILV flag to false (as it should have been), but
some compilers set it to true. The bug expressed itself by extracting
only a single timestep, rather than the number of timesteps indicated
by the SSC parameter. This behavior was fixed in NCO version 5.1.9
(November, 2023). There is no workaround to this problem, the solution
is to upgrade.
http://nco.sf.net/nco.html#bug_ilv
B. ncap2 now successfully parses naked numeric constants with the
value -9223372036854775808LL (i.e., NC_MIN_INT64). Previously, the
C++ standard library functions failed when attempting this, and we
still have no idea why. All hail Henry Butowsky for hacking together
a workable implementation. There is no workaround to this problem, the
solution is to upgrade.
C. Depending on how they were compiled, some recent NCO versions
could have expected the wrong path separator on MS Windows OS.
Your installation suffered from this bug if NCO on Windows expected
'/' (the UNIX separator) instead of '\' (the Windows separator).
There is no workaround to this problem, the solution is to upgrade.
Full release statement at http://nco.sf.net/ANNOUNCE
--
Charlie Zender, Earth System Sci. & Computer Sci.
University of California, Irvine 949-891-2429 )'(
