CDO

Hi Klaus,

can you upload a test file?

-Karin

Here is a set with testdata, but it's too large for an attachment so I put it on our Exporter facility where it stays for 30 days. You can download the data with http://exporter.nsc.liu.se/b7682581b35d44d7a7fb8a0f61f1a21c or rsync://exporter.nsc.liu.se/b7682581b35d44d7a7fb8a0f61f1a21c

ICMSH*INIT : spectral fields, 3-d (137 levels)
ICM{GG,CL}*INIT : gridpoint fields, 2-d
ICMGG*INUA : gridpoint fields, 3-d (137 levels)

All files in GRIB2

More info about the new ECMWF grids

NB: I just realized that I called these grids sloppily "cubic orthogonal" in the description above, the correct term would be "cubic octahedral," sorry for that.

Try the following for reduced gaussian grids, e.g. ICMCLa0iwINIT

cdo -f grb2 -setgridtype,regular ICMCLa0iwINIT ICMCLa0iwINIT_regular.grb2

And for spectral fields, e.g. ICMSHa0iwINIT

cdo -f grb2 sp2gp,linear ICMSHa0iwINIT ICMSHa0iwINIT_regular.grb2

-Karin

Thanks a lot! Yes, these functions seem to work, I have tested them before, but do they do the correct thing?

Gridpoint fields:
After setgridtype,regular the new fields have size 640x320 which seems to me like a N320 grid, but the reduced octahedral grid has 1296 gridpoints at the equator (ref) Seems like cdo is missing quite a few points there, or?

Spectral fields:
After sp2gp,linear the new fields have size 960x480, is that correct? It is neither 640x320 (N160) nor 1280x640 (N320) so I am a little bit puzzled. Furthermore, I previously used sp2gpl and that would yield a 640x320 grid. Should I use sp2gpl instead?

The operator sp2gpl seems to be an old one because

cdo sp2gpl -h

only shows the usage of sp2gp and gp2sp.

See https://code.mpimet.mpg.de/projects/cdo/embedded/index.html#x1-6870002.13.1

-Karin

The result of sp2gp,linear and sp2gpl is the same. sp2gpl is only an obsolete alias for sp2gp,linear. The number of grid points with your data is 640x320 (F160).
The conversion from a reduced Gaussian grid (N160) to a regular Gaussian grid with setgridtype,regular gives also 640x320 (F160) grid points.
The table is for N320 and not for N160.
I assume that setgridtype,regular also works correctly for cubic octahedral data.
For the spectral transformation of cubic octahedral data the parameter cubic would have to be used instead of linear. The parameter cubic is not documented yet because I could not verify the result with data from ECMWF.

Cheers,
Uwe

Thanks Uwe.

Sorry, the testdata that I provided a few days ago originate accidentially from a TL319 testcase and not Tco319. I am working on getting a proper Tco319 dataset and will eventually let you know how well cdo copes with it, both the spectral and grdipoint part.

Finally, here is a link to a set of correct testdata for the cubic octahedral grid

cdo setgridtype,regular ... works fine
cdo sp2gp,cubic ... works fine

The resulting grid has 1280x640 points, as expected for Tco319

The only thing I am still not happy with is that sp2gp,cubic isn't documented in the on-line help, I just tried and it worked (using cdo 1.9.7.1).

Thanks for link to the data!
The cubic parameter will be documented in the next CDO release.

I'd like to reopen this issue. Last year we tested remapping of Tco grids to regular Gauss grids which worked well. Back then we tested remapping with GRIB files. Now we have changed the model and get output in netCDF instead but still on the Tco grid. To see what the model produces and for that we need to map the output from the Tco to a regular Gauss grid, but unfortunately cdo setgridtype,regular ... doesn't support this transformation. I tested adding -setgridtype,gaussian_reduced but it doesn't help. Any idea?

Attached are examples on the Tco95 grid in GRIB (x.grb) and netCDF (y.nc).

We have made some progress with this command:

cdo setgridtype,regular -setgrid,tco95.txt y.nc y-regular.nc

Wouldn't it be possible to avoid the grid description part by allowing a user to set the grid type to gaussian_reduced, e.g. something like

cdo setgridtype,regular -setgridtype,gaussian_reduced y.nc y-regular.nc

hi Klaus!

You don't need to create the griddes file. Use the datafile instead. CDO will use the first grid from this file:

cdo -L -setgridtype,regular -setgrid,x1.grb y.nc y-regular.nc

I uploaded the the result for comparison.

Thanks, that's helpful. However, it only saves the cdo griddes ... step but instead requires us to keep a GRIB file with reduced Gauss grid at hand. It would be nice if this could be avoided by changing only the grid_type in the netCDF output file to "gaussian_reduced" or possibly better "cubic_octahedral", and then let setgridtype,regular do the rest. This is certainly not trivial, but maybe you cdo wizards have a good idea how to fix this.

hi Klaus!

I thought I would have already answered this yesterday, but my memory got corrupted obviously.

Point is: CDO knows some grids out-of-the-box, but reduced gaussian is not in this list. So in order use this grid, you have to keep some information about it at hand. you can ether use the data file (single timestep is sufficient) or the related griddes file.

Thanks a lot, Ralf. We can live with the situation as it is, no problem. I just thought that maybe in a longer perspective there could be better support for gaussian_reduced grids in cdo, after all it's already partly supported (setgridtype,regular) but not fully (e.g. no setgridtype,gaussian_reduced or setgrid,gaussian_reduced). For the time being I am happy with what we have and for the future I hope for the best.

Thanks a lot for the useful comments.

I also would support having internal support for reduced gaussian grids in cdo, ideally using the shorthand notation as in the Full regular Gaussian grid: FXXX, e.g. NXXX or OXXX .

hi Etienne!

But isn't there a second number needed for the number of latitudes?

Hi Ralph, you need only one number (XXX) which is the number of latitudes, just like for the Full regular gaussian grid.

See in https://confluence.ecmwf.int/display/FCST/Gaussian+grids

The following notation is used when referring to the full (regular), original reduced and octahedral reduced Gaussian grids:

FXXX - full (regular) Gaussian grid with XXX latitude lines between the pole and equator
NXXX - original ECMWF reduced Gaussian grid with XXX latitude lines between the pole and equator
OXXX - octahedral ECMWF reduced Gaussian grid with XXX latitude lines between the pole and equator