CDO

Hi,

Can you please upload:

1) a sample of your data (must be < 50MB or a link to download the data)?, and
2) output of "cdo -V"

Those info may help the CDO guys here to identify the problem!

Cheers,
J.

Hi Jaison,

cdo -V yields:

Climate Data Operators version 1.5.3 (http://code.zmaw.de/projects/cdo)
Compiler: gcc -std=gnu99 -g -O2 -pthread
 version: gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)
    with: PTHREADS Z
Compiled: by root on xxx.xxx.xxx.xxx (x86_64-unknown-linux-gnu) Jan 23 2012 11:47:55
     CDI library version : 1.5.3 of Jan 23 2012 11:47:51
 CGRIBEX library version : 1.5.1 of Aug 29 2011 20:30:27
  netCDF library version : "3.6.3" of Jan  7 2012 19:23:06 $
 SERVICE library version : 1.3.0 of Jan 23 2012 11:47:42
   EXTRA library version : 1.3.0 of Jan 23 2012 11:47:39
     IEG library version : 1.3.0 of Jan 23 2012 11:47:41
    FILE library version : 1.7.1 of Jan 23 2012 11:47:40

Ok I've had to create a smaller input file (ccam_NCEP.200901.nc).
I process with CDO monmean and I get the switched levels in Grads for ccam_NCEP.200901_mon.nc.

I saw there was an error in a previous version (https://code.zmaw.de/boards/1/topics/581).
Could this be it?

Hi,

I don't think there is something wrong.

It looks fine to me, but when I open the processed file in Grads, the vertical coordinates are switched.
Z=1 corresponds to the highest sigma, i.e. 0.004, and Z=18 is 0.995.

I'm a bit confused here, as far as CDO is concerned the vertical axis z=1 corresponds to the top-of-the-atmosphere => lowest sigma(?); and z=18 means the lowest layer => highest sigma(?). I think GrADS is reading the file correctly, (and you don't need to invert the axis I guess). May CDO gurus can help you with more info or if I'm wrong.

Cheers,
J.

Thanks for having a look Jaison!

If CDO does see z=1 being the top of the atmosphere then yes that would be a problem.
Just to clarify, when I state z=1 I'm talking about "set z 1" in Grads. i.e. the first z level in the file.
In the input file, this corresponds to the first layer, i.e. level 1, which has a sigma coordinate of 0.995, which is closest to the surface.
If CDO is seeing the first level as the top of the atmosphere then that is a problem.

I've just tried using 1.5.5 win32:

Climate Data Operators version 1.5.5 (http://code.zmaw.de/projects/cdo)
Compiler: i586-mingw32msvc-gcc -std=gnu99 -g -O2
 version: i586-mingw32msvc-gcc (GCC) 4.2.1-sjlj (mingw32-2)
    with: PTHREADS Z PROJ.4
Compiled: by ubuntu on ubuntu (i686-pc-linux-gnu) May 18 2012 10:42:14
     CDI library version : 1.5.5 of May 18 2012 10:41:58
 CGRIBEX library version : 1.5.2 of May 11 2012 14:32:49
  netCDF library version : "3.6.3" of Jan  7 2011 09:12:06 $
    HDF5 library version : 1.8.4
 SERVICE library version : 1.3.0 of May 18 2012 10:41:34
   EXTRA library version : 1.3.0 of May 18 2012 10:41:28
     IEG library version : 1.3.0 of May 18 2012 10:41:32
    FILE library version : 1.8.0 of May 18 2012 10:41:28

and I get the same "inverted" levels.
In other words, "set z 1" in Grads gives me a sigma coordinate of 0.004, a height of 1000s of meters, a very low temperature and pressure.
All these things are telling me I'm looking at the top most level in the model, whereas "set z 1" should be giving me the surface most layer.

Update:
I have also tried opening the file in IDV.
There the vertical coordinate is assumed to be height (basically something like 0.004m to 0.995m).
Does CDO cater for sigma coordinates?

Hi,

The "set z" equivalent command in cdo (I think) is sellevidx, so -sellevidx,1 give what you want.

OR

you may try converting your input to GRIB and then generate a grads descriptor file with cdo: gradsdes1

then most likely CDO and GrADS select the levels in the same way

more info is here https://code.zmaw.de/embedded/cdo/1.5.5/cdo.html#x1-5950002.15.1

Cheers,
Jaison

Hi,

-sellevidx seems to merely select 1 level.
I need the entire vertical.

However I used -sellevidx to do some rudimentary testing:

"-sellevidx,1" does give me in Grads the level corresponding to sigma 0.995 and

"-sellevidx,18" gives me the level corresponding to sigma 0.004.

But, if I do "-sellevidx,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18" then the resultant file gets the inverted levels.

So CDO is correctly reading the indices/levels.
It seems when writing out a 3D file the vertical coordinate system is assumed to be altitude, which increases with height.
And the file is written assuming that convention, instead of the sigma convention, where the higher value (0.995) is supposed to be level ID 1.

Well that's what I assume.
I know VERY little about CDO.

I see a routine "setzaxis" in the manual.
Hybrid model levels are mentioned.
Maybe this will solve my problem.
I think it is similar to what you suggest with the GRIB conversion.

thanks.

Hi,

But, if I do "-sellevidx,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18"

(just for your info) there is short-cut to the above command:

cdo -sellevidx,1/18 does the same job

Cheers,
J.

PS: the same trick works for other operators and other values.

I had the same problem, but NCO solved it in my case.

ncatted -a positive,lev,o,c,"down" ifile.nc ofile.nc

Cheers.