...
Warning | ||||
---|---|---|---|---|
The new MARS client with the MIR interpolation library is currently in BETA, and it is meant for tests only. Do not use it for any operational purpose. You can try the new MIR-enabled MARS client on any ECMWF computing platform with:
You are encouraged to test this new version of the MARS client and report any issues to advisory@ecmwf User Support.int . If you are using the the ECMWF WebAPI you can test it by adding an extra keyword to your requests:
|
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 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
24 July 2018
MARS/MIR (0.10.0) is released. This new version of MARS/MIR remains a BETA version and is not yet ready for operational use. It introduces two important changes versus previous versions of MARS/MIR:
- 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.
Users are encouraged to test this new version of MARS/MIR and report any issues found to User Support. The release of a "ready for production" MARS/MIR is anticipated for the end of August/early September 2018.
Important dates
- June August/September 2018: Release of a MARS/MIR which will be considered ready for production. The old MARS/EMOSLIB client would still be the default.
- Autumn Late autumn 2018: MARS/MIR becomes the default version at ECMWF. The old MARS/EMOSLIB would will still be accessible, but there will be no further updates to it.
...
Info | ||
---|---|---|
| ||
Unlike EMOSLIB, MIR does not use any special processing for precipitation fields. |
Warning |
---|
|
Subareas
MIR brings a number of improvements in the subarea and cropping operations.
...
Two new MARS keywords, TRUNCATION and INTGRID, are introduced which superseed supersede the RESOL keyword. RESOL is still supported, but will eventually considered will be deprecated.
TRUNCATION
Describes how to treat the incoming SH, before the transformation is passed to TRANS library.
Value | RESOL equivalent | Description |
---|---|---|
NONE | AV | Disables any truncation before the transformation |
AUTO | AUTO | Truncation is derived from the intermediate grid. This is the default behaviour |
number | number | Specific truncation to be applied, e.g. TRUNCATION=179 truncates input SH field to T179 |
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. |
INTGRID
Describes the intermediate grid to which the transform is performed. It may be coincident with the target grid, in which case there isn't a second interpolation and the transform is direct to target grid.
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
Concept 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.
...
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, also the original EMOSLIB behaviour is also shown for each case:
MIR Behaviour | EMOSLIB Behaviour | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
...
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. |
Usage of IFS spectral transform library
...
Warning |
---|
Starting with MARS/MIR (0.10.0) relative humidity on pressure levels is transformed with "RESOL=AV" by default. This improves the quality of the output field but will make the retrieval of relative humidity more expensive when the target grid is at a relatively low resolution. Users wishing to override this behaviour can specify "RESOL=AUTO". |
Waves
Due to the differences mentioned above, the nearest neighbour method selects different points due to the difference in the computation of the distance (3D versus 2D). Different treatment of neighbouring missing values produces a smoother interpolation close to coasts.
...
Performance for subareas
When defining extracting certain subareas, MIR tends to may be slower compared to EMOSLIB. At the moment, MIR does the interpolation on a global grid and performs the cropping operation later, whereas EMOSLIB will only interpolate on the subarea defined. This may be optimised in future versions Significant enhancements have been implemented in MARS/MIR (0.10.0) which address the performance of spectral transformations to subareas. Further optimisations for grid point interpolations to subareas may be provided in future releases.