#78 Incorrect min/max on a dimension

[Maksym Petrenko]

Back by a popular demand, here comes my new issue. I have a file that has a 'time' dimension in it and a similarly named variable. Time has exactly 2 values, 946684800 and 946695600. When I try to run this:

ncap2 -v -O -o aaa -s 'ymin=min(time);ymax=max(time);time0=time(0);time1=time(1);print(ymin);print(ymax);print(time0);print(time1)' g4.areaAvgTimeSeries.MAI3CPASM_5_2_0_T.1000hPa.20000101-20000101.179W_89S_179E_89N.nc

I get this, where min and max are obviously wrong:

ymin = 1893380400

ymax = 1893380400

time0 = 946684800

time1 = 946695600

What am I doing wrong and is there a way to get around it? My config:

NCO netCDF Operators version "4.4.8" last modified 2015/02/09 built Apr 8 2015 on miniyosemite.local by brew
ncks version 4.4.8
Linked to netCDF library version 4.3.3.1, compiled Apr 9 2015 00:56:35
Copyright (C) 1995--2015 Charlie Zender
This program is part of NCO, the netCDF Operators.
NCO is free software and comes with a BIG FAT KISS and ABOLUTELY NO WARRANTY
You may redistribute and/or modify NCO under the terms of the
GNU General Public License (GPL) Version 3 with exceptions described in the LICENSE file
GPL: http://www.gnu.org/copyleft/gpl.html
LICENSE: http://nco.cvs.sf.net/nco/nco/LICENSE
Homepage: http://nco.sf.net
User Guide: http://nco.sf.net/nco.html
Configuration Option: Active? Meaning or Reference:
Check _FillValue Yes http://nco.sf.net/nco.html#mss_val
Check missing_value No http://nco.sf.net/nco.html#mss_val
DAP clients Yes http://nco.sf.net/nco.html#dap
Debugging: Custom No Pedantic, bounds checking (slowest execution)
Debugging: Symbols No Produce symbols for debuggers (e.g., dbx, gdb)
GNU Scientific Library Yes http://nco.sf.net/nco.html#gsl
HDF4 support Unknown http://nco.sf.net/nco.html#hdf4
Internationalization No http://nco.sf.net/nco.html#i18n (pre-alpha)
MPI parallelization No http://nco.sf.net/nco.html#mpi (beta)
netCDF3 64-bit files Yes http://nco.sf.net/nco.html#lfs
netCDF4/HDF5 available Yes http://nco.sf.net/nco.html#nco4
netCDF4/HDF5 enabled Yes http://nco.sf.net/nco.html#nco4
OpenMP SMP threading No http://nco.sf.net/nco.html#omp
Optimization: run-time No Fastest execution possible (slowest compilation)
Parallel netCDF3 No http://nco.sf.net/nco.html#pnetcdf (pre-alpha)
Regular Expressions Yes http://nco.sf.net/nco.html#rx
Shared libraries built No Small, dynamically linked executables
Static libraries built Yes Large executables with private namespaces
UDUnits conversions Yes http://nco.sf.net/nco.html#udunits
UDUnits2 conversions Yes http://nco.sf.net/nco.html#udunits

[Charlie Zender]

Hi Maxim,
Thank you for reporting this bug. I can reproduce the problems you report, and hope to write soon with a workaround and/or fix.
cz

[Charlie Zender]

Hi Maxim,
For now the workaround is to use the equivalent GSL function, e.g.,
ncap2 -v -O -s 'lat_min1=min(lat);lat_min2=lat.gsl_stats_min();lat_max1=max(lat);lat_max2=lat.gsl_stats_max();' ~/nco/data/in.nc ~/foo.nc
Same for max. This is high priority and we will try to fix ASAP, but GSL will work for now.
c

[Charlie Zender]

Problem is now fixed. I believe it crept-in within the last year. The workaround above will work with any affected version. The fix is now committed and will be in all future versions. The problem was due to a new method of enforcing the policy that NCO not do any arithmetic except for averaging (with ncwa) on variables it thinks are coordinates. I like this policy, except it should not be enforced in ncap2, where presumably the user knows what they are doing and is free to do whatever they want with coordinates. Please give a try if you can. Feedback welcome.

[Maksym Petrenko]

Thanks Charlie, I tried gsl_stats with time and it seems to work properly. I will use it our codes instead of the regular min/max - it takes us a while to upgrade any of the operational software.

[Maksym Petrenko]

Just a thought - it would be nice if the enforcer threw an exception / exit on all attempted policy violations, would make debugging much easier.

[Charlie Zender]

no feedback so closing this issue.