Issue when retrieving "Seasonal forecast anomalies on single levels"

Datasets and Usage C3S - Datasets and Usage
,
1

Hello there,
When downloading seasonal forecast anomalies from NCEP and JMA following the API request code, and selecting multiple initial months across multiple years, the variable “month” is missing in the retrieved data (name expected in the netcdf: “Forecast_reference_time”).
There is no such issue when downloading similar data from Météo_France, ECMWF, UKMO, DWD or CMCC.

Less important but still annoying, if I select year=2025 and month=[01’, ‘02’, ‘03’, ‘04’, ‘05’, ‘06’, ‘07’, ‘08’, ‘09’, ‘10’, ‘11’, ‘12’], I run into an error because there is data available only for months 1 to 6.
No such error when doing the same for older years for which months are missing: the request retrieves the available months without complaining.

Thanks in advance for your help/guidance

2

Hi Constantin,

On the first issue you mention, could you provide an example API request NCEP or JMA which results in the behaviour you are seeing?

The issue for 2025 is simply that the real-time forecasts are initialised and published on the CDS each month, for example the next forecast start date, July 2025, for leadtime months 1-6 (July to December), will be available next week.

Thanks for the questions.

3

Thanks for your reply.

On the second point, I was aware of this. I just meant to point out that the request does not fail when it asks 12 months in years < 2025 , even if the the system has data for, say, only two months (November and December for example) of that particular year. It would be convenient if the behaviour was similar for 2025. But again, this is a minor issue.

Now, for the main point here is an example of a request that provides a file without any “month” dimension :

import cdsapi

dataset = “seasonal-postprocessed-single-levels”
request = {
“originating_centre”: “jma”,
“system”: “3”,
“variable”: [
“2m_temperature_anomaly”,
“total_precipitation_anomalous_rate_of_accumulation”
],
“year”: [“2023”],
“month”: [
“01”, “02”, “03”,
“04”, “05”, “06”,
“07”, “08”, “09”,
“10”, “11”, “12”
],
“leadtime_month”: [
“1”,
“2”,
“3”,
“4”
],
“data_format”: “netcdf”,
“product_type”: [“ensemble_mean”]
}

client = cdsapi.Client()
client.retrieve(dataset, request).download()

4

Hi Christopher,

The issue is still there. Is there a workaround to get the “month” dimension in NCEP or JMA data ? (See my example request)
Thank you

Constantin

5

I can see now that retrieving the data in grib allows to get the correct dimension. It fails if want a netcdf format.

Then, with the “-T” option of grib_to_netcdf, I can get more or less what I want, but the metadata is completely ruined (no more “forecast_reference_time” nor “forecastMonth”), and the result is not consistent with the data from the other centers (ECMWF, MF, CMCC, UKMO, DWD).

Thanks in advance for your guidance!

Constantin

6

Hi Constantin,

Indeed, you are right, this is due to inconsistency in the conversion to netCDF performed by the CDS (which is labeled as experimental for this reason). The recommended approach is to retrieve grib format and apply a conversion yourself.

For example, you could use xarray to read in the data, manipulate it, and then save it in netcdf format. We have relevant examples in the tutorials, which includes the addition of a ‘valid_time’ coordinate: Seasonal Forecast Verification — C3S Training

I hope this helps, and sorry for the delayed response.

Chris

7

You are right, it takes just 3 lines of python/xarray code to fix the metadata

Thanks a lot, problem solved !