Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Any requested data manipulation or post-processing is carried out by the MARS client, except in the case of a local Member State's client where data is first processed at ECMWF prior to its transmission over the network. The post-processing is carried out by a set of routines present in the EMOSLIB library. Please, refer to the field Field interpolation software  routines for in-depth details about such post-processing.

...

Most of the data at ECMWF is global. A subarea sub-area can be created using the area keyword by defining its latitude and longitude boundaries: North/West/South/East.

Global grids have a grid mesh implicitly based on (0 W, 0 N); the grids do not wrap around at (0 E, 360 W). For example, a 3x3 degree grid has latitudes at 90 N, 87 N,..., 87 S, 90 S and longitudes at 0 E, 3 E,..., 354 W, 357 W. Subareas Sub-areas are created from a global grid using the same implicit origin and spacing; if necessary, the subarea sub-area boundaries are adjusted to fit on the grid mesh by enlarging it.

...

GRIB coded fields have a specified number of bits per packed value which can be changed with keyword accuracy. This might be useful when trying to retrieve fields from MARS identical to those you get from dissemination.

There value can be varied using the accuracy keyword; there is no gain in precision by using a value higher than the number of bits originally used for archiving.

...

The truncation can be controlled using the resol keyword. Default truncations are detailed in the following table.

...

Fields on spherical harmonics or Gaussian grid can be rotated with the directive keyword rotation. The rotation is performed prior to any other conversion. Therefore:

...

A rotated grid-point field is created from an input grid-point field by finding for each rotated grid-point its nearest four neighbours in the unrotated input field and carrying out a bilinear interpolation.

...

  • Whenever possible, use a local filesystemfile system to store the target file (e.g. $SCRATCH on ecgate for external users) as this will avoid unnecessary network traffic.
  • Estimate the data volume to be retrieved before issuing a request. It is easy to retrieve Gigabytes of data. Check that computer resources and limits are adequate for the amount of data to retrieve/interpolate in order to avoid unnecessary processing (MARS will fail if a quota is exceeded or in the case of any Unix problem regarding resources such as memory or CPU time).
  • Estimate the number of fields to be retrieved before issuing a request. Try to retrieve a sensible number, up to tens of thousands of fields.
  • Reduce the number of tapes involved. The number of tapes a MARS request is going to access will have an impact on its scheduling on the server. As a rule of thumb, two or more separate requests accessing files on different tapes are scheduled more efficiently than a single request accessing two or more tapes. A large number of tapes implies more waiting time. Use multiple requests in one MARS call whereby all the data is written to one output file (see section 5.3).
  • When retrieving large datasets (e.g. Re-Analysis), try to retrieve as many data from the same tape file as possible. Then, avoid caching the data on the server by specifying use = infrequent.
  • Avoid constantly accessing the same tape. If a user issues you issue a large number of requests, all accessing data on the same tape, this can keep that tape in the drive for many hours and potentially cause some damage. Once you access a tape read as many fields as possible and if needed use the multi-target feature, see section 6.5 to split the output by level, parameter etc. using the multi-target feature. This would reduce the amount of requests and make your extractions much faster.

...

This report gives users an idea about the resources needed for a request, and can be used for future reference when retrieving similar datasets.

Field order

Users should Do not expect retrieved fields to be returned in any specific sequence in the target fileorder. Depending on the MARS configuration, fields can be retrieved differently. Therefore, user programs processing the target file must take this into account.

...