Page History

A good understanding of the MARS efficiency issues is essential especially for downloading large amounts of data.

The aim of this page is to help users to improve their MARS requests performance focusing in CMA reforecast data using the ECMWF WEB APIIn this area we are only focusing on MARS efficiency issues ie to investigate and present what is the most efficient way to loop over several requests for retrieving CMA reforecast data.

The It is every important for a user to understand how the S2S data is organised in MARS.

In general it is organised in MARS as a huge tree, with the indentation below, showing different levels down that tree:

• centre (ECMWF, NCEP, JMA, ...)
  • realtime or reforecast
    •  type of data (control forecast or perturbed forecast)
      • type of level (single level or pressure level or potential  temperature)
        • dates (2015-01-01 or 2015-01-05 or 2015-01-08, ...)
          •  time-steps
            • members (for perturbed forecast)
              • levels (for pl or pt)
                • parameters

with aiming The idea is to be in the same tape file, all time-steps, all members, all parameters for a type of level, a type, a date

The Following the previous paragraph the natural way to group requests would be:
all parameters, all levels, all members, all time-steps for 1 date.

Note the following:

1. 'all' means 'all' that the user wants. It doesn't have to be all parameters.
2. If a user is interested only on z500,  he may request more dates in one go, since the overall request will not be so big.

Taking under consideration what has been presented explained above,  if you need to loop in a MARS request, follow the hierarchy below

• date (year and month loop)
  
  • hindcast date
    • number (EPS only)
      • level
        • parameter (inner loop)

for each year from 2010 to 2014

    for months April, June
        for each hindcast date
            API request