What is the objective of this page?
| Info |
|---|
To help users to improve S2S CMA MARS requests performance via the WebAPI.  A good understanding of the MARS efficiency issues is essential especially for users that are interested in downloading large amounts of data.
|
How is the S2S reforecast data organised in MARS?
| Info |
|---|
In general it is organised, as a huge tree, with the indentation below, showing different levels down that tree: - centre (CMA, 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)
- model version date (2014-05-01 or ...)
- hindcast dates (2014-01-01 or 2014-01-02 or 2014-01-03, ...)
- time-steps
- members (for perturbed forecast)
|
What would be the natural way to group requests?
| Info |
|---|
The idea is to request as much data as possible from the same tape file. The natural way to group requests would be:
all parameters, all levels, all members, all time-steps for 1 hindcast date for a type of level for a type  Note the following:
- 'all' means 'all' that the user wants. It doesn't have to be all parameters.
- If a user is interested only on z500, he may request more hindcast dates in one go, since the overall request will not be so big.
|
Best practise to iterate over all hindcastDates of several hindcastYears for CMA
| Info |
|---|
for hindcastYear in hindcastYears
for hindcastMonth in hindcastMonths
for hindcastDay in hindcastDays
hindcastDate = hindcastYear-hindcastMonth-hindcastDay
S2S-request(hindcastDate) |
Web-API examples:
A CMA reforecast request for all the available hindcastDates
...
...
