...
| Info |
|---|
|
To help users to improve S2S CMA BoM MARS requests performance via the WebAPIIf a user is interested only on z500, he may request more HindcastDates in one go, since the overall request will not be so bigWebAPI.  A good understanding of the MARS efficiency issues is essential especially for users that are interested in downloading large amounts of data.
|
...
| Info |
|---|
In general it is organised, as a huge tree, with the indentation below, showing different levels down that tree: - centre (CMABoM, 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)
- HindcastDates (2014-01-01 or 2014-01-02 or 2014-01-03, ...)
- time-steps
- members (for perturbed forecast)
The idea is to request as much data as possible from the same tape file, all time-steps, all members, all parameters for a type of level, a type, a HindcastDate
|
...
| Info |
|---|
Following the previous paragraph, the natural way to group requests would be:
all parameters, all levels, all members, all time-steps for 1 HindcastDate.  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 HindcastDates in one go, since the overall request will not be so big.
|
What is the best approach to loop over several HindcastDates for a
...
BoM request?
| Info |
|---|
| title | The main idea in brief: |
|---|
|
for HindcastDate in HindcastDate-list (eg, 2010-03-01 to 2010-03-31)
S2S-request(HindcastDate)
Have a look on some CMA BoM re-forecast examples or on the ECMWF Web API Home |
...
If the request is "small" you may request more HindcastDates in one go.
Do you need more CMA BoM re-forecast examples?
