Hi everybody,
The latest (December 2024) ECMWF Seasonal Forecast (monthly on single levels) appears to have a different dimension convention than the one in November, as well as all the other forecasting centres for this forecasting time. It specifically is about the ‘forecast_reference_time’ versus ‘time’, and whether it is an active dimension, or just a coordinate which is passed along with the data.
For ECMWF 2024-12 I receive the following dimensions:
esf_cds_12
<xarray.Dataset> Size: 79MB
Dimensions: (number: 51, forecastMonth: 6, latitude: 180, longitude: 360)
Coordinates:
- number (number) int64 408B 0 1 2 3 4 5 6 7 … 44 45 46 47 48 49 50
time datetime64[ns] 8B 2024-12-01
- forecastMonth (forecastMonth) int64 48B 1 2 3 4 5 6
- latitude (latitude) float64 1kB 89.5 88.5 87.5 … -87.5 -88.5 -89.5
- longitude (longitude) float64 3kB 0.5 1.5 2.5 3.5 … 357.5 358.5 359.5
Whereas for 2024-11 I got:
esf_cds_11
<xarray.Dataset> Size: 79MB
Dimensions: (number: 51, forecast_reference_time: 1,
forecastMonth: 6, latitude: 180, longitude: 360)
Coordinates:
- number (number) int64 408B 0 1 2 3 4 5 … 46 47 48 49 50
- forecast_reference_time (forecast_reference_time) datetime64[ns] 8B 2024…
- forecastMonth (forecastMonth) int64 48B 1 2 3 4 5 6
- latitude (latitude) float64 1kB 89.5 88.5 … -88.5 -89.5
- longitude (longitude) float64 3kB 0.5 1.5 2.5 … 358.5 359.5
The other forecasting centres (DWD for example) also produce a dimension format similar to ECMWF November:
dsf_cds_12
<xarray.Dataset> Size: 78MB
Dimensions: (number: 50, forecast_reference_time: 1,
forecastMonth: 6, latitude: 180, longitude: 360)
Coordinates:
- number (number) int64 400B 0 1 2 3 4 5 … 45 46 47 48 49
- forecast_reference_time (forecast_reference_time) datetime64[ns] 8B 2024…
- forecastMonth (forecastMonth) int64 48B 1 2 3 4 5 6
- latitude (latitude) float64 1kB 89.5 88.5 … -88.5 -89.5
- longitude (longitude) float64 3kB 0.5 1.5 2.5 … 358.5 359.5
Is this an intentional change for ECMWF for this month?
Kind regards,
Maarten
Hi Maarten!
and welcome to the User Forum 
I have tried (unsuccesfully) to reproduce your issue, and everything seems to be working to me.
If you try the following request:
dataset = "seasonal-monthly-single-levels"
request = {
"originating_centre": "ecmwf",
"system": "51",
"variable": ["2m_temperature"],
"year": ["2024"],
"month": ["12"],
"leadtime_month": [ "1", "2", "3", "4", "5", "6" ],
"data_format": "netcdf",
"product_type": ["monthly_mean"]
}
client = cdsapi.Client()
client.retrieve(dataset, request).download()
you will get a netCDF file containing forecast_reference_time as you can see from an ncdump of the file:
netcdf seas5_20241201 {
dimensions:
number = 51 ;
forecast_reference_time = 1 ;
forecastMonth = 6 ;
latitude = 180 ;
longitude = 360 ;
variables:
int64 number(number) ;
number:long_name = "ensemble member numerical id" ;
number:units = "1" ;
number:standard_name = "realization" ;
int64 forecast_reference_time(forecast_reference_time) ;
forecast_reference_time:long_name = "initial time of forecast" ;
forecast_reference_time:standard_name = "forecast_reference_time" ;
forecast_reference_time:units = "seconds since 1970-01-01" ;
forecast_reference_time:calendar = "proleptic_gregorian" ;
int64 forecastMonth(forecastMonth) ;
forecastMonth:long_name = "months since forecast_reference_time" ;
forecastMonth:units = "1" ;
[...]
data:
forecast_reference_time = "2024-12-01" ;
}
It might be a long shot, but I wonder whether for some reason the system might have cached a wrong file. Could you repeat your request but adding:
"nocache" : "123",
where “123” should be a numeric random string (so it changes everytime you run a request ensuring you don’t get data from the cache).
If that doesn’t fix your issue, having your exact api request could be useful to try to reproduce it.
I hope that helps.
Regards,
Hi Eduardo,
Thank you for looking into it. I noticed this issue when selecting a request through the Dataset Download Form.
Your request example does work as I would have expected it to, and retracing my steps does also no longer give the faulty file. I’m not sure what went wrong, but it appears to have been resolved.
When I look back into my requests, it is also the only request from that series of requests (besides the other 7 forecasting centres that did behave as expected) that is now marked as ‘expired’, where the others I can still download again. Perhaps there was indeed a change in the available dataset since then.
Thanks again for your help!
Kind regards,
Maarten