> I did try to post this on sourceforge (several times) - it appears to
> be broken. Feel free to farm it out to anyone who you think may assist.
since you tried sf, i'll answer this personally.
but sf works for tens of 1000s of people, so followup here.
> I'm trying to obtain the mean of two variables using
> ncflint tmax.nc tmin.nc tmean.nc
> The inputs are float variables (with scale and offset values). The
> output is reported as a float (using ncdump -h) but stored as (unscaled)
> integer values. That is, the result is "correct" to within a floor
> operation (validated with 3rd party software).
> Is this intended behaviour?
No, this is unintended.
Arithmetic operators are intended to store the results as
the unpacked type of the inputs.
Thanks for pointing it out.
It's now TODO nco1078. I'll try to fix before next release.
I've already created a regression test to demonstrate the problem.
>Can you suggest how to get genuine
> float-valued means?
For now the only workaround is to unpack the variables before
using ncflint, i.e., use ncpdq -U first, then do ncflint.
Looks like I spoke too soon.
I cannot reproduce the problem you are having.
So I suspect you are using an old version of NCO.
Please update to 4.2.2.
Here is a test that shows the interpolated variable is correctly upacked into a floating point type:
ncks -h -O -C -v pck_3 -p ~/nco/data in.nc ~/foo1.nc
ncks -h -O -C -v pck_5 -p ~/nco/data in.nc ~/foo2.nc
ncrename -h -O -v pck_5,pck_3 ~/foo2.nc
ncflint -h -O -v pck_3 ~/foo1.nc ~/foo2.nc ~/foo3.nc
ncks -C -H -m -v pck_3 ~/foo3.nc
The in.nc necessary to reproduce this is at
Log in to post a comment.