The planned horizontal resolution upgrade employs the so-called cubic reduced Gaussian grid (with spectral truncation denoted by TC) instead of the current linear reduced Gaussian grid (denoted by TL) where the shortest wave is represented by four rather than two grid points. By increasing the number of grid points used to represent the shortest wave, more resolution is added in grid-point space while keeping the spectral truncation constant,
To reduce further the computational cost, the new IFS cycle implements a modification to the grid, the octahedral reduced Gaussian grid (with spectral truncation denoted by TCO). The octahedral grid is a form of the reduced Gaussian grid but applying a new rule for computing the number of points per latitude circle.
In this page, we refer to the reduced Gaussian grid as described by Hortal and Simmons (Use of Reduced Gaussian Grids in Spectral Models; ECMWF Tech. Memo. 168, 1990 - see also Hortal M., and A.J. Simmons, 1991, Mon. Wea. Rev. 119 1057-1074) and used by the IFS up to cycle 41r1 as the original reduced Gaussian grid. The new octahedral form of the reduced Gaussian grid is described in this page.
|Table of Contents
Gaussian grid descriptions
Descriptions of the Gaussian grids introduced for the planned horizontal resolution upgrade and used for HRES and ENS are available:
The descriptions provide the latitude values and the number of longitude points at each latitude for both the original and octahedral reduced Gaussian grids.
The number of points at each latitude is encoded as the PL array in the Grid description section of the GRIB header of a grid point field. This is accessible with grib_api as the pl key.
As of grib_api 1.14.0, a new computed key isOctahedral is introduced which allows users to query the grid type. For an octahedral grid, isOctahedral=1; otherwise, isOctahedral=0.
From grib_api 1.14.4 onwards, the computed key gridName can be used to query the grid name. For an octahedral with 1280 latitudes between pole and equator gridName=O1280; for an original reduced Gaussian grid with 640 latitudes between pole and equator, gridName=N640 while the corresponding regular Gaussian grid has gridName=F640.
For further background information see:
Frequently asked questions
Will the change to the octahedral grid affect me if I use regular lat-lon data ?
No, users of regular lat-lon data will be unaffected by the change of model grid. They will, however, benefit from the increase of the model horizontal resolution.
Will ECMWF make data available on the original regular and reduced Gaussian grids ?
Yes, users will still be able to request data, both in dissemination and MARS, on the original regular and reduced Gaussian grids. Note, however, that this will be interpolated from the values on the octahedral reduced Gaussian model grid. See also I make computations involving flux parameters or accumulated fields (for example, to de-accumulate precipitation) and am advised to work on the model grid: which grid should I use ?
I use point data (e.g., for meteograms, vertical profiles, etc) - what do I need to do ?
Users of point data should note that the coordinates of the nearest grid point will have changed. Users should take particular care for coastal points for which the nearest grid point may have changed from a land point to a sea point or vice versa.
Are the new land-sea mask and orography for the octahedral grid available ?
Yes, the new land-sea masks and orography fields for HRES at TCO1279 (O1280), ENS Leg A at TCO639 (O640) and ENS Leg B TCO319 (O320) are available for download:
I use the orography in spectral representation - will I be affected ?
Although the spectral resolution for HRES remains constant, the spectral orography has changed. If you have this as a static file then this should be updated with the new version.
Do I need to upgrade the version of GRIB API I use in order to decode data on the octahedral grid ?
Version 1.12.3 of grib_api can decode fields on the octahedral grid correctly. As of grib_api 1.14.0, a new computed key isOctahedral is introduced which allows the grid type to be queried. For the octahedral grid, isOctahedral=1; otherwise, isOctahedral=0.
Can GRIBEX decode data on the octahedral grid ?
GRIBEX is no longer supported by ECMWF and will therefore not be upgraded to support the octahedral grid.
What should I check in my program to make sure it will work with the octahedral grid ?
Any GRIB decoding program that makes use of the PL array to obtain the number of longitude points on each latitude circle should be able to handle the octahedral grid. Programmers should note that the largest number of points at any one latitude circle increases from 4N in the original Gaussian grid to 4N+16 in the octahedral grid and adjust any data structures accordingly to cater for this.
For performing computations with accumulated fields, users are advised to request data on the octahedral grid.
Is there any change to the vertical resolution as part of the planned resolution upgrade ?
No, only the horizontal resolution is increased. The vertical resolution remains at L137 for HRES and L91 for ENS.
What will happen if I retrieve data from MARS using grid=av ?
Users retrieving data from MARS with the keyword, grid=av ("archived value") will retrieve data on the model grid. For data from the upgraded model this will be the octahedral grid.
What will happen if I retrieve data from MARS using grid=1280 ?
This behaviour is unchanged. By default, users retrieving data from MARS with the keyword, grid=1280 will retrieve data on the regular Gaussian grid with 1280 latitude lines between the pole and equator (equivalent to grid=F1280).
Will ERA-Interim fields also use the cubic octahedral grid ?
No, the horizontal resolution upgrade applies only to ECMWF HRES and ENS operational forecasts, including the monthly extension. It will affect the additional runs in support of the Optional Programme for Boundary Conditions (BC).
Will the ECMWF System 4 Seasonal Forecasts (SEAS) also use the octahedral grid ?
No, the horizontal resolution upgrade applies only to ECMWF HRES and ENS operational forecasts, including the monthly extension.