...
Cause
This is known issue when downloading forecast data in the NetCDF format:
For example, from for the ERA-Interim archive one can download data from four dataset there are two daily forecasts (00:00, 0612:00), with 3-hourly forecast steps. So one could specify in a data retrieval script:
No Format |
---|
"date":"2016-12-01" "type":"fc" "time": "00:00/12:00", |
"step": "0/3/6/9/12/15", |
With the above specification you get data for the following validity times:
- time 00:00 + step 0 → validity time
In this case you will get data for:
- 2016-12-01, 00:00 (
- time 00:00 + step 0)step 3 → validity time 2016-12-01, 03:00 (
- time 00:00 + step 36 → validity time 2016-12-01, 06:00
- time 00:00 + step 9 → validity time ) 2016-12-01, 0609:00 (
- time 00:00 + step 612 → validity time 2016-12-01, 12:00
- time 12:00 + step 0 → validity time ) 2016-12-01, 0612:00 (
- time 0612:00 + step 03 → validity time 2016-12-01, 15:00
- time 12:00 + step 6 → validity time ) 2016-12-01, 0918:00 (
- time 0612:00 + step 3)
- 9 → validity time 2016-12-01, 21:00
- time 12:00 + step 12 → validity time 2016-12-02, 00:00
So in this example you get two values at validity time 2016-12-01, 0612:00.
The NetCDF format (generated by MARS) only supports a single, one-dimensional time dimension, so a specific time can not have two values.
This is why trying to retrieve this data in NetCDF format results in an error.
Possible workarounds
- Download the data in its native GRIB format, then convert the GRIB files to NetCDF following these guidelines. The GRIB format supports multiple data values at any one validity time.
- If you are only interested in the analysis, but not forecasts, download data only for step 0
- If you need overlapping forecast, download for each time option separately, for example:
- first with time = 00:00 and all required steps
- then with time = 06:00 and all required steps
- then with time = 12:00 and all required steps
- then with time = 18:00 and all required steps
...