Software upgrade for data extraction of a geographical area from selected ERA5 and Seasonal forecast datasets

Announcements C3S - Announcements
, , , , ,
1

On 25th of February 2026 , as part of regular operational software upgrades, the software handling area extraction for regular lat-lon gridded datasets will be updated to a new version to correct a behaviour that caused an interpolation of the data during the area extraction.

What is the reason for this change?

Until now, area extraction has triggered an interpolation onto a new grid whose south west corner is that given in the supplied area. This interpolation has been identified as undesirable behaviour. In order to preserve the original values it has been decided the software should instead only crop the existing data, returning just those grid points that lie inside the area without modification.

What will be the effect on the data?

Requests that specify a geographical area may now return data on a slightly different grid which will be displaced from the original grid by up to one grid length, and the number of grid points returned may also differ.

Please refer to our Knowledge Base article on Software upgrade for geographical area extraction from data on regular lat-lon grids, which graphically explains the change in behaviour and also provides a workflow to help users identify whether or not this change is affecting their requests.

Which datasets are affected?

The change described above will apply exclusively to data requested for a specific area, and only in cases where the latitude and longitude of the user-provided bounding box do not exist in the original global dataset before area extraction, regardless of how the data was downloaded (i.e. either using the web interface or the API service), and for the following ERA5 and seasonal forecast datasets ONLY:

ERA5 datasets:

Seasonal Forecast datasets:

What should users do if they have downloaded sub-area data (as described above) from the listed datasets?

If your requests are affected by this software upgrade, then the recommendation is to download a new data sample (from date of implementation on 25 February 2026) and compare it with the data previously downloaded. This will allow you to decide on whether or not any modifications are needed to your workflows following the software upgrade. Please refer to our Knowledge Base article for additional information.

For any enquiries on this topic, please contact us (ECMWF login required).

ECMWF Support
on behalf of the Data Stores Service

2

A reminder that tomorrow, Wednesday 25th of February 2026, the software handling area extraction for regular lat-lon gridded datasets will be updated to a new version to correct a behaviour that caused an interpolation of the data during the area extraction.

3

We are pleased to confirm that earlier today the software handling area extraction for regular lat-lon gridded datasets has been successfully updated to a new version hence correcting a behaviour that caused an interpolation of the data during the area extraction.

Some users may now find that their requests are unexpectedly failing following the software update. For example, attempting to request a point location will now fail as there is no data in the area requested. Please refer to our Knowledge Base article for details.

For ERA5 and ERA5-Land point extractions, please use the post-processed ERA5 hourly time-series data on single levels from 1940 to present and ERA5 Land hourly time-series data from 1950 to present.

4

Thanks for this message and for the warning in the earthkit api, it saved me a lot of troubleshooting when i was unable to merge previously downloaded netcdf files with files downloaded today after the change.

However, it seems that maybe there is some CDS server side caching going one. I tried downloading ERA5-Land hourly with same extent and parameters before and after today. Before today I had downloaded months starting 2024-01 and later. Then today I tried downloading for first time files for 2023-12 and earlier and thats where i got differences. So i did a fresh download again today after the change covering both 2023-12 (which had not previously been downloaded so probably not cached on server) and 2024-01 (previously downloaded so seemingly stuck on old cache), and indeed they get different coordinates:

2023-12:

<xarray.Dataset> Size: 456MB
Dimensions: (valid_time: 744, latitude: 389, longitude: 394)
Coordinates:

  • valid_time (valid_time) datetime64[ns] 6kB 2023-12-01 … 2023-12-31T23:…
  • latitude (latitude) float64 3kB 5.1 5.0 4.9 4.8 … -33.5 -33.6 -33.7
  • longitude (longitude) float64 3kB -74.0 -73.9 -73.8 … -34.9 -34.8 -34.7
    number int64 8B …
    expver (valid_time) <U4 12kB …
    Data variables:
    tp (valid_time, latitude, longitude) float32 456MB …
    Attributes:
    GRIB_centre: ecmf
    GRIB_centreDescription: European Centre for Medium-Range Weather Forecasts
    GRIB_subCentre: 0
    Conventions: CF-1.7
    institution: European Centre for Medium-Range Weather Forecasts
    history: 2026-02-25T11:49 GRIB to CDM+CF via cfgrib-0.9.1…

2024-01:

<xarray.Dataset> Size: 457MB
Dimensions: (valid_time: 744, latitude: 390, longitude: 394)
Coordinates:

  • valid_time (valid_time) datetime64[ns] 6kB 2024-01-01 … 2024-01-31T23:…
  • latitude (latitude) float64 3kB 5.166 5.066 4.966 … -33.63 -33.73
  • longitude (longitude) float64 3kB -74.04 -73.94 -73.84 … -34.84 -34.74
    number int64 8B …
    expver (valid_time) <U4 12kB …
    Data variables:
    tp (valid_time, latitude, longitude) float32 457MB …
    Attributes:
    GRIB_centre: ecmf
    GRIB_centreDescription: European Centre for Medium-Range Weather Forecasts
    GRIB_subCentre: 0
    Conventions: CF-1.7
    institution: European Centre for Medium-Range Weather Forecasts
    history: 2026-02-24T21:53 GRIB to CDM+CF via cfgrib-0.9.1…

All downloads were done via earthkit and using the same params and bbox for the two downloads today except the month requested:

{“variable”: [“total_precipitation”], “year”: “2023”, “month”: [“12”], “day”: [“01”, “02”, “03”, “04”, “05”, “06”, “07”, “08”, “09”, “10”, “11”, “12”, “13”, “14”, “15”, “16”, “17”, “18”, “19”, “20”, “21”, “22”, “23”, “24”, “25”, “26”, “27”, “28”, “29”, “30”, “31”], “time”: [“00:00”, “01:00”, “02:00”, “03:00”, “04:00”, “05:00”, “06:00”, “07:00”, “08:00”, “09:00”, “10:00”, “11:00”, “12:00”, “13:00”, “14:00”, “15:00”, “16:00”, “17:00”, “18:00”, “19:00”, “20:00”, “21:00”, “22:00”, “23:00”], “area”: [5.179929280000067, -74.04055289399997, -33.73474359199997, -34.65612964799993], “data_format”: “netcdf”, “download_format”: “unarchived”}

With logs:

2026-02-25 17:02:24,565 INFO Request ID is f4164db7-ced3-4b77-859f-b9982286233e
2026-02-25 17:02:24 INFO: Request ID is f4164db7-ced3-4b77-859f-b9982286233e
2026-02-25 17:02:24,675 INFO status has been updated to accepted
2026-02-25 17:02:24 INFO: status has been updated to accepted
2026-02-25 17:02:38,256 INFO status has been updated to running
2026-02-25 17:02:38 INFO: status has been updated to running
2026-02-25 17:02:45,905 INFO status has been updated to successful
2026-02-25 17:02:45 INFO: status has been updated to successful
2026-02-25 17:02:46 INFO: Downloading https://object-store.os-api.cci2.ecmwf.int:443/cci2-prod-cache-2/2026-02-25/64c3e992b7588e7de5a09b2d191cc2a8.nc

And:

{“variable”: [“total_precipitation”], “year”: “2024”, “month”: [“01”], “day”: [“01”, “02”, “03”, “04”, “05”, “06”, “07”, “08”, “09”, “10”, “11”, “12”, “13”, “14”, “15”, “16”, “17”, “18”, “19”, “20”, “21”, “22”, “23”, “24”, “25”, “26”, “27”, “28”, “29”, “30”, “31”], “time”: [“00:00”, “01:00”, “02:00”, “03:00”, “04:00”, “05:00”, “06:00”, “07:00”, “08:00”, “09:00”, “10:00”, “11:00”, “12:00”, “13:00”, “14:00”, “15:00”, “16:00”, “17:00”, “18:00”, “19:00”, “20:00”, “21:00”, “22:00”, “23:00”], “area”: [5.179929280000067, -74.04055289399997, -33.73474359199997, -34.65612964799993], “data_format”: “netcdf”, “download_format”: “unarchived”}

With logs:

2026-02-25 17:03:18,449 INFO Request ID is 03664f4b-8b36-4651-b444-df6da22005b1
2026-02-25 17:03:18 INFO: Request ID is 03664f4b-8b36-4651-b444-df6da22005b1
2026-02-25 17:03:18,502 INFO status has been updated to accepted
2026-02-25 17:03:18 INFO: status has been updated to accepted
2026-02-25 17:03:33,389 INFO status has been updated to successful
2026-02-25 17:03:33 INFO: status has been updated to successful
2026-02-25 17:03:33 INFO: Downloading https://object-store.os-api.cci2.ecmwf.int:443/cci2-prod-cache-3/2026-02-24/b1986b3af81287fd8cfadeb9140b93db.nc

Indeed there seems to be mention of reusing files from a server side cache. Is this something that can be fixed from your end, or perhaps a parameter that can be passed to the API? I suspect others may be encountering the same error.

I did try deleting all the old relevant downloads from my CDS history, but still same behavior.

Thanks for your reply and also for the amazing service of free open climate data :slight_smile:

5

As an update I was able to get the new version of the data with the correct coordinates by adding a “nocache“ parameter with a unique numeric string, as described here:

unique_numeric_string = str(int(time.time()))
params = {
    "variable": variables,
    "year": str(year),
    "month": [str(month).zfill(2)],
    "day": days,
    "time": [f"{str(h).zfill(2)}:00" for h in range(0, 23 + 1)],
    "area": [ymax, xmin, ymin, xmax],  
    "data_format": "netcdf",
    "download_format": "unarchived",
    “nocache": unique_numeric_string, # <-- add this to invalidate the server cache
}

With this I was able to make sure i have all the new data coordinates regardless of old data cached on the server.

6

It seems the upgrade in the processing caused a stop of the delivery of the AgERA5 dataset - any comments/news on that @Anabelle?