ECMWF’s free and open real-time data is moving to 0.1° (approximately 9 km), the highest model resolution, delivering on the commitment agreed by Council. We expect this to go live by the end of October 2026.
Files get considerably bigger. If you download whole files where you only need a few fields, we recommend switching to .index files and HTTP byte-range requests, or using the ecmwf-opendata Python package. Your bandwidth bill will thank you.
To keep volumes manageable we are reducing the bits-per-value on forecast fields and splitting pressure-level and surface-level data into separate files. Analysis fields are unchanged.
We operate a dynamic limit on the number of concurrent connections to the open data portal, to protect our production pipeline. This means you may occasionally see a time-out. If that happens, retry, or use one of the cloud mirrors.
Full access instructions, including the file-naming convention, are on the ECMWF open data page, which we will update as the change goes live. ECMWF open data remains free of charge under the Creative Commons CC-BY-4.0 licence.
This is a very exciting development! Could you share a little more about what the transition will look like, and if you will communicate a specific cycle/date for the transition? Will there be any period of overlap where both 0.25 and 0.1 degree data are disseminated, as there was with the 0.4 to 0.25 transition?
Thank you very much for making the higher resolution available! Couple of questions:
Are you publishing a 0.1° grid (~11 km) of the original O1280 grid or the native O1280 grid? From my experience, the 0.1° grid required roughly 30% more data. Additionally, grid cells at coastal lines, urban areas, and in complex mountainous terrain are distorted because data from multiple grid cells with different properties get averaged (land/ sea fraction, soil type, vegetation/surface type, albedo, surface roughness). If possible, the native O1280 grid would be highly appreciated both in terms of data bandwidth and precision. The trade-off of limited tooling around the O1280 will quickly be solved by the community to allow popular libraries to generate maps.
Does the publish time remain unchanged? Because all data is published at once with 1 hour delay to the operational schedule, this forces users to download all data as fast as possible (=> maximum peak bandwidth). If the publishing time could be changed to a “rolling” 1-hourly delay (delay for each timestep), this would reduce the peak bandwidth and make it easier to download for users.
Are there any changes to the list of variables?
If I am not mistaken, the CCSDS compression already uses scale factors of around 32 (0.03K) for 2m temperature. How much further will you reduce precision? Some variables like accumulated total precipitation use different scale factors for different time-steps. Precision is reduced with larger lead-time. This can lead to strange artefacts resulting in negative precipitation of around -0.1mm. With reduced precision such artefacts will become more prominent. If possible, could you use fixed precision manually defined for each variable?
This sounds good. However, I think the questions below are important, so if you could either answer them or point to the documentation when it is available that would be very helpful:
Does this apply to both the IFS deterministic and IFS ensemble data sets?
Will the latency of the data be the same as is the case now with the 0.25° data
Will 0.25° data be published alongside 0.1° for a transition period, and if so for how long?
What will the new directory and file naming be for the split pressure-level and surface files, and will each have its own .index file?
Will the packing type change (e.g. to CCSDS/template 5.42), or only the bits per value?
Thanks, all, for the questions — I’ll answer them here together, since there’s a lot of overlap.
Timing and overlap (@Hans Mohrmann)
We’re aiming to complete the transition on 13 October, from the 06 UTC cycle, though this may slip to the 14th or 15th depending on operational priorities on the day. There will be an overlap period: as with the 0.4°→0.25° transition, we don’t plan to discontinue 0.25° at this stage, so both resolutions will be disseminated in parallel for a while.
Grid, publish time, variables and precision (@Patrick Zippenfenig)
Grid: a regular lat/lon grid at 0.1°, not the native O1280 reduced Gaussian grid.
Publish time: the 0.1° data will publish 2 hours after dissemination, while the existing 0.25° stays at end-of-schedule (or earlier, subject to adjustment once we understand the network load of the 0.1° feed). Staggering the two feeds is partly deliberate — it spreads the peak load rather than concentrating everything in one window. We won’t do a rolling (step-by-step) release at this stage, but we may revisit it as we learn how the 0.1° feed behaves.
The intent is that users can choose between earlier availability but coarser resolution, or finer resolution with some latency.
Variables: yes — 6 additional variables, with the list on the open-data page updated shortly (later this week). It will enable the Forecast-in-a-Box service to run.
Precision: we’re reducing bits-per-value and will publish the chosen values in the documentation. To your point on parameters such as accumulated precipitation using different scale factors per time-step — we’ve deliberately defined a bits-per-value per parameter, rather than a flat percentage across the board, precisely so that sensitive and derived fields aren’t degraded. Extensive work has gone into ensuring no parameter is significantly degraded.
Coverage, latency, naming and packing (@Brian Gaze)
Deterministic + ensemble: yes, this applies to all products we currently serve, both IFS deterministic and ENS.
Latency: 0.1° latency will be 2 hours; the 0.25° feed remains as now, and we may bring it earlier in future (to be confirmed).
Transition overlap: yes, 0.25° will be published alongside 0.1°, at least for a while.
Naming: the directory and file-naming details for the split pressure-level and surface files will be added to the documentation later this week.
Packing: the packing type will change to CCSDS, with the bits-per-value reduction applied as well.
One practical heads-up on the CCSDS change: moving from simple to CCSDS (AEC) packing means anyone on an older or minimally-built GRIB stack (eccodes, cfgrib, wgrib2, GDAL) should check that their decoder is built with AEC/CCSDS support, or they may hit decode failures. We’ll note this in the documentation too.
A general note
This open-data service runs on a best-endeavours basis — no guarantee of timeliness and no dedicated support. It’s designed to serve a large community openly. For operational dependencies or complete, full-precision datasets, we’d encourage you to use the ECMWF Service Charge scheme via dissemination.
Thanks very much for the information. One follow-up question, please: are you saying that the 0.25° feed will remain exactly as it is at the moment, with no changes to the packing type? In other words, does that only apply to the 0.1° datasets?
If I can also provide some general feedback from my perspective:
I personally don’t see much value in having the ensemble data available at 0.1°. The additional latency is a bigger factor, so I would sooner have the 0.25° data earlier. In general terms, having higher-resolution ensemble data is valuable for a regional system, such as MOGREPS-UK (run by the UK Met Office), but not so much for global models.
There is more value in having the 0.1° data for the deterministic model, although even there, the additional latency would possibly more than offset the advantages.
I fully understand that people have different use cases, and points 1 and 2 above relate specifically to mine.
@Emma, sorry to follow up, but are you able to address the point about the packing types? Will the 0.25° feed will remain exactly as it is at the moment?