sp2gpl interpolation doesn't agree with MARS
Added by Paolo Davini about 6 years ago
Hi all,
I have an issue with the sp2gpl operator.
I retrieved daily 500hPa ERA-Interim zonal wind data from ECMWF, in both original spectral grid (T255) and MARS-interpolated (0.75x0.75).
Then I convert the spectral one to gaussian using sp2gpl: surprisingly the results are considerably different from the MARS-interpolated one, showing large bias at high latitudes.
Here is the commands I run:
$ cdo info -sp2gpl -seltimestep,1/5 ERAINT_U500_6hrs_n128_plev_1979.grib cdo info: Started child process "sp2gpl -seltimestep,1/5 ERAINT_U500_6hrs_n128_plev_1979.grib (pipe1.1)". cdo(2) sp2gpl: Started child process "seltimestep,1/5 ERAINT_U500_6hrs_n128_plev_1979.grib (pipe2.1)". -1 : Date Time Level Gridsize Miss : Minimum Mean Maximum : Parameter ID 1 : 1979-01-01 00:00:00 50000 131072 0 : -19.440 4.5696 48.697 : 131.128 2 : 1979-01-01 06:00:00 50000 131072 0 : -17.670 4.4856 45.198 : 131.128 3 : 1979-01-01 12:00:00 50000 131072 0 : -17.648 4.5019 44.526 : 131.128 4 : 1979-01-01 18:00:00 50000 131072 0 : -19.655 4.4748 42.504 : 131.128 5 : 1979-01-02 00:00:00 50000 131072 0 : -19.851 4.5500 39.764 : 131.128 cdo(3) seltimestep: Processed 328960 values from 1 variable over 6 timesteps [0.62s] cdo(2) sp2gpl: Processed 328960 values from 1 variable over 5 timesteps [0.63s] cdo info: Processed 655360 values from 1 variable over 5 timesteps [0.63s 203MB] $ cdo info -seltimestep,1/5 ERAINT_U500_6hrs_0.75_plev_1979.grib cdo info: Started child process "seltimestep,1/5 ERAINT_U500_6hrs_0.75_plev_1979.grib (pipe1.1)". -1 : Date Time Level Gridsize Miss : Minimum Mean Maximum : Parameter ID 1 : 1979-01-01 00:00:00 50000 115680 0 : -37.974 6.4651 59.054 : 131.128 2 : 1979-01-01 06:00:00 50000 115680 0 : -34.108 6.0382 55.031 : 131.128 3 : 1979-01-01 12:00:00 50000 115680 0 : -35.313 5.9434 54.314 : 131.128 4 : 1979-01-01 18:00:00 50000 115680 0 : -38.177 5.9522 53.772 : 131.128 5 : 1979-01-02 00:00:00 50000 115680 0 : -36.499 6.1959 54.112 : 131.128 cdo(2) seltimestep: Processed 578400 values from 1 variable over 6 timesteps [0.17s] cdo info: Processed 578400 values from 1 variable over 5 timesteps [0.17s 71MB]
The mean values are totally different: here is the map of the differences, as long as I interpolate them on a common grid:
Many explanation pops up to my mind, in decreasing order of probability:- I am doing something wrong with the MARS request (but they are identical but for the grid!) or in the spectral to gridpoint conversion.
- I am missing some well-known behaviour of sp2gpl, as some environmental variable which affects this operator.
- CDO is not taking into account some kind of weights at high latitudes, underestimating values up there.
- There is something weird with MARS interpolation routine.
Do you have any suggestion? I can attach a sample of the data as well in the case it may help
Last note, I am using CDO 1.9.3
$ cdo -V Climate Data Operators version 1.9.3 (http://mpimet.mpg.de/cdo) CXX Compiler: g++ -g -O2 -fdebug-prefix-map=/build/cdo-g3Qjnd/cdo-1.9.3+dfsg.1=. -fstack-protector-strong -Wformat -Werror=format-security -fopenmp CXX version : g++ (Ubuntu 7.3.0-1ubuntu1) 7.3.0 C Compiler: gcc -g -O2 -fdebug-prefix-map=/build/cdo-g3Qjnd/cdo-1.9.3+dfsg.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -pedantic -fPIC -fopenmp C version : gcc (Ubuntu 7.3.0-1ubuntu1) 7.3.0 F77 Compiler: f77 -g -O2 -fdebug-prefix-map=/build/cdo-g3Qjnd/cdo-1.9.3+dfsg.1=. -fstack-protector-strong F77 version : unknown Features: 187GB C++14 Fortran DATA PTHREADS OpenMP45 HDF5 NC4/HDF5/threadsafe OPeNDAP SZ UDUNITS2 PROJ.4 MAGICS CURL FFTW3 SSE2 Libraries: HDF5/1.10.0 proj/4.93 curl/7.58.0 Filetypes: srv ext ieg grb1 grb2 nc1 nc2 nc4 nc4c nc5 CDI library version : 1.9.3 GRIB_API library version : 2.6.0 NetCDF library version : 4.6.0 of Feb 9 2018 19:21:24 $ HDF5 library version : library undefined EXSE library version : 1.4.0 FILE library version : 1.8.3
Replies (1)
RE: sp2gpl interpolation doesn't agree with MARS - Added by Paolo Davini about 6 years ago
Ok,
I have just find out that this is not CDO, but a MARS "known" bug.
For anybody who may be interested:
https://www.ecmwf.int/en/faq/which-representation-should-u-and-v-wind-components-be-retrieved-archive
Cheers,
P