#100 ncap2 does not like certain variable names

[Maksym Petrenko]

I have the following .nc file and a cdl script. I do the following:

ncap2 -v -O -S test.cdl test.nc out.nc

I get the following error:
ERROR: nco_def_var() failed to nc_def_var() variable "Ny"
nco_err_exit(): ERROR Short NCO-generated message (usually name of function that triggered error): nco_def_var()
nco_err_exit(): ERROR Error code is -42. Translation into English with nc_strerror(-42) is "NetCDF: String match to name in use"
nco_err_exit(): ERROR NCO will now exit with system call exit(EXIT_FAILURE)

However, once I rename Nx to Nax and Ny to Nay - everything works fine! My version:

NCO netCDF Operators version 4.6.7 built by brew on Sierra.local at May 26 2017 18:28:32
ncap2 version 4.6.7
Linked to netCDF library version 4.4.1.1 compiled May 24 2017 09:46:12
Copyright (C) 1995--2017 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: https://github.com/nco/nco/tree/master/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)
ESMF Library No http://nco.sf.net/nco.html#esmf
GNU Scientific Library Yes http://nco.sf.net/nco.html#gsl
HDF4 support No 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

Shots and power tools

[Charlie Zender]

Wow, that's bizarre, yet reproducible. We'll get right on this to see what's happening. Thanks for the bug report, Maksym. This falls under Henry's purview, so I hope he'll chime-in soon.

[Maksym Petrenko]

You are alwasy welcome, Charlie :)

[Maksym Petrenko]

It also seems that although renaming variables lets the code to go through, the results of the computation are still incorrect. The attached is a full version of the code. At the end of the script, Nofx and Nofy are both 0, wich is incorrect (they should be equal 5).

[Maksym Petrenko]

Never mind. Nofx being equal to 0 is a different bug it seems - on line 17, NCO seems to think Nofx (5) is equal to the fill value (9.96920996839e+36). I think I've seen this before, but don't remember details. 4.2.1.1 does not seem to have these problems.

[henry Butowsky]

HI Maksym,
have solved the second part.
the var time has no missing value so when you call
*miss=double(v1.get_miss());
it return the default fill value for type nc_DOUBLE
which is defined in netcdf.h file as
#define NC_FILL_DOUBLE (9.9692099683868690e+36)
and this is what is getting propagated through your expressions
instead of the _FillValue for OMAEROe_003_AerosolOpticalThicknessMW_388_0

I am still working on why ncap2 doesnt like the var 'Ny'

for now you can put Nx and Ny in there own block as a workaround.
below is my script we corrections mentioned above

*v1=double('time');
*v2=double('OMAEROe_003_AerosolOpticalThicknessMW_388_0');
*miss=double(v2.get_miss());
v1.change_miss(miss);
// v2.change_miss(miss);
*mask0=double(v1);mask0=1.;
*mask1=double(v1*0+1);
*mask2=double(v2*0+1);
Ntotal=mask0.total();
{
Nx    =mask1.total();
Ny    =mask2.total();
}

...Henry

[Maksym Petrenko]

Henry, not sure I understand. Shouldn't everything still work even if miss defaults to 9.9692099683868690e+36? See the extended version of the script(options_test.nc.cdl). When the script reaches this line:

if (Nofx<0 || Nofx==miss) Nofx=0;

Nofx is equal to 5 and miss is 9.9692099683868690e+36. However, Nofx==miss return true and, as a result, Nofx gets assigned 0. Why is that?

[Maksym Petrenko]

Also, it used to work fine in 4.2...

[henry Butowsky]

consider the mini script,

defdim("tt",5);
tt[tt]={1.0,2.0,3.0,4.0,5.0};
tt.set_miss(-20.0);

if(tt==-20.0)
  print("tt equals miss\n");
else
  print("tt doent equal miss\n");

if you the above script like in your script the statment "tt equals miss" is printed which seems paradoxical.

what is happening is that the expression tt==-20.0 gets evaluated as ( -20.0, -20.0, -20.0,-20.0, -20.0)
when this is put in the "if" statement all the missings evaluate to false and so the statemnt is true-

if you delete or unset the missing value from tt then you can make more meaningfull

defdim("tt",5);
tt[tt]={1.0,2.0,3.0,4.0,5.0};

if(tt==-20.0)
  print("tt equals miss\n");
else
  print("tt doent equal miss\n");

so now tt== -20.0 returns ( 0.0,0.0,0.0,0.0 .0.0)
which when put in if statment evalutes to false

[henry Butowsky]

Hi Maksym,
there was an issue with a new feature I added to the aggregate methods like total(), max(), min()
that write to Ouptut an attribute cell_methods" . it was causing the mesterious behavoir with Ny / Nx,

plase run your script with the --no_cll_mth flag e.g

ncap2 --no_cll_mth -O -S test.cdl test.nc foo.nc
And I put a fix in repo ASAP

...Henry

[henry Butowsky]

another way of thinging about it is with a mixed result
e.g

[Charlie Zender]

This appears to have been fixed and fix will be in 4.6.8