| Warning |
|---|
MARS/MIR will become the default client at ECMWF on 29 January 2019 |
| Tip | ||||||
|---|---|---|---|---|---|---|
The new MARS client with the MIR interpolation library is used by default at ECMWF since 29 January 2019. now considered ready for production and suitable for operational use. It is not yet the default version. You can use the new MIR-enabled MARS client on any ECMWF computing platform with :
If you are using the the ECMWF WebAPI you can test it by adding an extra keyword to your requests:
If using Metview, you can use MIR interpolation with the following commands before starting it:
You are encouraged to test this new version of the MARS client and report any issues to servicedesk@ecmwf.int. no extra options or settings. Please report any issues with this new version of the MARS client to servicedesk@ecmwf.int. |
MIR stands for Meteorological Interpolation and Regridding and is a library of routines for interpolation and regridding of meteorological fields. This new piece of software is replacing the veteran EMOSLIB when it comes to perform those operations in MARS. Beyond thisMIR stands for Meteorological Interpolation and Regridding and is a library of routines for interpolation and regridding of meteorological fields. This new piece of software is replacing the veteran EMOSLIB when it comes to perform those operations in MARS. Beyond this, MIR’s flexible design facilitates scalability improvements and additional features. These include efficiency gains, a high degree of user configurability, and support for a wider range of grids than in the current package. See the related article in the ECMWF newsletter no.152 for a more complete description of this new library.
...
| Table of Contents | ||
|---|---|---|
|
News
29 January 2019
MARS/MIR becomes the default version at ECMWF. The old MARS/EMOSLIB version can still be accessed specifying the relevant options. See below for details.
1 1 November 2018
MARS/MIR (1.0.0) is released. This new version of MARS/MIR is the first version considered ready for operational use.
...
- Improvements have been made to enhance the performance of spectral to grid transformations when the target is a subarea.
- Interpolation of unclassified parameters will fail .
Important dates
- 1 November 2018: MARS/MIR is considered ready for operations, but it is not the default version at ECMWF.
- 29 January 2019: MARS/MIR becomes the default version at ECMWF, with the exact date to be confirmed at a later stage. The old MARS/EMOSLIB will still be accessible through mars -e, but there will be no further updates to it.
Questions and Answers
| Expand | ||
|---|---|---|
| ||
The EMOSLIB interpolation package was written in the 1980s and much has changed since then: the model grid resolution has steadily increased, a variety of grid types have been introduced, and many new parameters have been added over the years, often associated with different processing requirements. Both software and hardware technologies, such as programming languages, design paradigms, supporting libraries and hardware architectures, have evolved significantly. These aspects, together with new numerical methods and ECMWF's improved understanding of user requirements, have prompted ECMWF to design the new, extensible and easy-to-maintain MIR package |
| Expand | ||
|---|---|---|
| ||
No, all existing valid MARS requests will also work when using MIR. Some new keywords will be introduced for new features such as:
|
- (this behaviour was reverted in 22 August).
Questions and Answers
| Expand | ||
|---|---|---|
| ||
The EMOSLIB interpolation package was written in the 1980s and much has changed since then: the model grid resolution has steadily increased, a variety of grid types have been introduced, and many new parameters have been added over the years, often associated with different processing requirements. Both software and hardware technologies, such as programming languages, design paradigms, supporting libraries and hardware architectures, have evolved significantly. These aspects, together with new numerical methods and ECMWF's improved understanding of user requirements, have prompted ECMWF to design the new, extensible and easy-to-maintain MIR package |
| Expand | ||
|---|---|---|
| ||
No, all existing valid MARS requests will also work when using MIR. Some new keywords are introduced for new features such as:
|
| Expand | ||
|---|---|---|
| ||
You don't need to specify any specific options, as it is the current default. |
| Expand | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
You can replace your standard mars calls adding the extra option:
If using the WebAPI, you can add the keyword:
If using Metview greater than 5.4, you need to define the environment variable:
|
| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
MIR has undergone a thorough validation process and tests to ensure its quality and correctness. However, since the implementations and strategies used in both packages are different, you may see some differences when using MIR instead of EMOSLIB. How significant those differences will be will depend on each specific case. Here is an example. The same 2m temperature field on a native O1280 grid has been interpolated to a 0.1/0.1 latitude-longitude grid using both methods. Plots have been produced for both, together with a third one with the differences greater than half a degree Celsius between them.
|
| Expand | ||
|---|---|---|
| ||
At the moment MIR is only made available through the MARS client. In the medium term, a standalone command line tool based on MIR may become available. Other release options may also be considered in the future. |
| Expand | ||
|---|---|---|
| ||
The goal of the first full release of MIR is to replace the old EMOSLIB functionality. As such, MIR implements only linear and nearest-neighbour interpolation methods. It does not provide any support for conservative remapping. Other interpolation methods may be provided in future releases. This means that MIR may not produce sufficiently accurate results when upscaling from a high-resolution model grid to low resolution grids. For example, using MIR to remap the surface geopotential field from the operational HRES forecast at ~9km to a 1x1 regular lat-lon grid gives a mean bias error of ~16m and a mean absolute error of ~166m when compared to a reference field created by area-averaging the 100 m Shuttle Radar Tomography Data (STRD) grid points over the Alpine Domain. If the the remapping is performed with the the Climate Data Opertors (CDO) remapcon operator.then the mean bias error is ~-2m and the mean absolute error is ~7.5m. [ECMWF thanks Reto Stöckli of the Federal Office of Meteorology and Climatology MeteoSwiss for providing this information.] | ||
| Expand | ||
|
| No Format |
|---|
mars -m |
| title | Can I keep using the old MARS/EMOSLIB version? |
|---|
You can replace your standard mars calls adding the extra option:
| No Format |
|---|
mars -e |
If using the WebAPI, you can add the keyword:
| No Format |
|---|
ppengine=emos |
| title | Will I get different results? |
|---|
MIR has undergone a thorough validation process and tests to ensure its quality and correctness. However, since the implementations and strategies used in both packages are different, you may see some differences when using MIR instead of EMOSLIB. How significant those differences will be will depend on each specific case.
Here is an example. The same 2m temperature field on a native O1280 grid has been interpolated to a 0.1/0.1 latitude-longitude grid using both methods. Plots have been produced for both, together with a third one with the differences greater than half a degree Celsius between them.
| title | Can I get MIR as a standalone library? |
|---|
At the moment MIR is only made available through the MARS client. In the medium term, a standalone command line tool based on MIR may become available. Other release options may also be considered in the future.
Highlights and main differences
...
| Info | ||
|---|---|---|
| ||
| Unlike EMOSLIB, MIR does not use any special processing for precipitation fields. | ||
| Warning | ||
| Starting with MARS/MIR (0.10.0) interpolation of an unclassified parameter will fail. precipitation fields. |
Subareas
MIR brings a number of improvements in the subarea and cropping operations.
...
EMOSLIB cannot handle interpolations from a regular latitude-longitude grid to a reduced gaussianGaussian, but MIR does not have that limitation. Interpolations from any global regular or reduced gaussian or latitude-longitude grids to regular or reduced gaussian or regular latitude longitude grids are now supported in MIR.
...
| Value | RESOL equivalent | Description | ||
|---|---|---|---|---|
| NONE | - | Disables the use of an intermediate grid
| ||
| AUTO | - | An intermediate FULL Gaussian grid is used, derived from the output GRID, by looking at the equivalent resolution. This is the default behaviour | ||
Onumber | Onumber | Use the specified Octahedral Gaussian grid as an intermediate grid | ||
| Fnumber | Fnumber | Use the specified Full (regular) Gaussian grid as an intermediate grid | ||
| Nnumber | Nnumber | Use the specified Reduced Gaussian grid as an intermediate grid | ||
| OFF | OFF | reserved MARS value that resets the value inherited, effectively removing the keyword from the request. In this case results in AUTO being applied. |
Different treatment for RESOL=AV
The concept of "RESOL=AV" ("Archived Value") when going to a lower resolution is different. With MIR, RESOL=AV specifies that the transformation is made first to the corresponding octahedral reduced Gaussian grid (i.e., T1279 → O1280 or T639 → O640) followed by grid point interpolation to the user-specified grid.
Default truncation values for "RESOL=AUTO" (Automatic Truncation) have also changed. MIR uses a formula to truncate the spectral series to correspond to the equivalent linear Gaussian grid, replacing the fixed table used in EMOSLIB. Transformations to regular latitude-longitude grids then use an intermediate full (regular) Gaussian grid.
...
This diagram illustrates an example transformation going from T1279 to a regular lat-lon 1.0/1.0 grid. Depending on the values of RESOL and GRID, MIR will follow different paths. As a reference, the original EMOSLIB behaviour is also shown for each case:, the original EMOSLIB behaviour is also shown for each case:
| MIR Behaviour | EMOSLIB Behaviour | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
| Path | Keywords | New keywords | MIR Behaviour | EMOSLIB Behaviour |
|---|
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
| Red | RESOL=AUTO, GRID=1.0/1.0 | TRUNCATION=AUTO, INTGRID=AUTO, GRID=1.0/1.0 | Default Behaviour. Transformation from T1279 to an intermediate F90 full (regular) Gaussian grid (with an automatic truncation to T179) followed by a grid-to-grid interpolation from the F90 grid to 1.0/1.0. | Default Behaviour. Direct transformation from T1279 to 1.0/1.0, with an automatic truncation to T213 according to EMOSLIB's truncation table | |
| Green | RESOL=AV, GRID=1.0/1.0 | TRUNCATION=NONE, INTGRID=O1280, GRID=1.0/1.0 | Transformation from T1279 to the corresponding intermediate reduced octahedral Gaussian O1280, before going to 1.0/1.0. | Direct transformation from T1279 to 1.0/1.0, with no truncation. | |
| Blue | RESOL=179, GRID=F90, and then GRID= | ||||
| Path | Keywords | New keywords | MIR Behaviour | EMOSLIB Behaviour | |
| Red | RESOL=AUTO, GRID=1.0/1.0 | TRUNCATION=AUTO179, INTGRID=AUTOF90, GRID==1.0/1.0 | Transformation from T1279 to the F90 full (regular) Gaussian grid (with a user-specified truncation to T179) followed by a grid-to-grid interpolation from the F90 grid to 1.0/1.0 | Default Behaviour. Transformation from T1279 to an intermediate F90 full (regular) Gaussian grid (with an automatic truncation to T179) followed by a grid-to-grid interpolation from the F90 grid to 1.0/1.0. | Default Behaviour. Direct transformation from T1279 to 1.0/1.0, with an automatic truncation to T213 according to EMOSLIB's truncation table |
| Green | RESOL=AV, GRID=1.0/1.0 | TRUNCATION=NONE, INTGRID=AUTO, GRID=1.0/1.0 | Transformation from T1279 to the corresponding intermediate reduced octahedral Gaussian O1280, before going to 1.0/1.0. | Direct transformation from T1279 to 1.0/1.0, with no truncation. | Blue | RESOL=179, GRID=F90, and then GRID=1.0/1.0 | TRUNCATION=179, INTGRID=F90, GRID=1.0/1.0 | Transformation from T1279 to the F90 full (regular) Gaussian grid (with a user-specified truncation to T179) followed by a grid-to-grid interpolation from the F90 grid to 1.0/1.0. | Same as in MIR, but a separate MARS request is needed for each of the two steps.
| . | Same as in MIR, but a separate MARS request is needed for each of the two steps. |
| Anchor | ||||
|---|---|---|---|---|
|
| Expand | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||
With EMOSLIB spectral fields are by default automatically truncated before interpolation to grid fields to reduce data volumes and spurious aliased values. When automatic truncation is applied MARS issues a warning message like INTFB: Resolution automatically set to .... The truncation can be controlled using the keywords truncation and intgrid. Users wanting to post-process at the full archived resolution can specify truncation = none in the request.
| ||||||||||||||||||||
| Note | ||
|---|---|---|
| ||
When doing spectral to grid transformations, MIR may produce smoother fields compared to EMOSLIB. This is due to the fact that MIR uses the intermediate gaussian grid, while EMOSLIB does this transformation directly. |
...