Of course its OK, though a more descriptive variable name than "area" might increase clarity.
It looks close. Not sure that grid_area is actually the grid area, it's just the cosine of the latitude, right? You seem to be using it as a weight. Unclear how that gives you an area in m2. Maybe ask AI go give you the workflow?
Hi Solomon, Personally, I would first convert all the datasets to use the same global grid. For the two +/-70 datasets you could use the ncremap regridder to project them onto global grids. The regions poleward of +/=70 would be missing values, which is fine. Another way to proceed would be to manually create global fields using ncap2. Charlie
Let x be the 0-based index of the corrupt slice. Try ncks -d time,0,x-1 -d time,x+1,2919 in.nc out.nc
I'm not sure exactly when NEP changed the API but nep.h/libnep.a are what NEP uses in the current snapshot, NEP 1.7.x. Hopefully the API is stable now. Unfortunately NEP is evolving so quickly that it does not make sense for NCO to support the older APIs. Maybe you could push back and request to use NEP 1.7.x (which may not have existed when you were given your task).
I had NEP 1.0 working with NCO. Then the API changed, and I just updated to support the current NEP snapshot. Configure NCO's latest snapshot with --enable-nep. It builds/links for me. Unfortunately the LZ4 codec now emits an error. Not sure what broke... zender@maluhia:~$ ncks -r NCO netCDF Operators version 5.3.7-alpha06 "Spidey" built by zender on maluhia at Mar 18 2026 15:55:38 ncks version 5.3.7-alpha06 Linked to netCDF library version 4.10.1-development compiled Mar 16 2026 16:01:06 Copyright...
Please post a small version of the file that reproduces the problematic behavior, and the ncap2 command that demonstrates it.
Hi. There's too many issues here for me to address. Please submit a minimally reproducible example that shows that NCO is doing something wrong or unexpected. Attach the dataset with the command and an explanation of why it does not meet your expectations.