IFS Cycle 50r1 and AIFS v2 - Implementation planned for 12 May 2026

Announcements
, , ,
1

We are pleased to confirm that good progress is being made towards the joint operational implementation of IFS Cycle 50r1, AIFS Single v2 and AIFS ENS v2, and the implementation is planned for 12 May 2026. The date will be confirmed closer to the implementation.

We would like to remind all forecast and data users that this upgrade is introducing some significant changes which have the potential to critically impact your processing chains.
If you haven’t done so yet, we urge you to test your processing chains now with the test data provided from the IFS Cycle 50r1 update.
The test data for the AIFS v2 will be provided when the Release Candidate test phase (RCP) starts for the AIFS models. We will announce the start of the RCP in a separate email.

Details on the meteorological content and impact, changes to the configuration of the model systems, the introduction of new parameters, availability of test data, etc. can be found on the following pages:

We want to remind you that there is still time to register for the last webinar on data access and format, testing and practicalities for IFS Cycle 50r1 and AIFS v2 on the 12th March 2026. Click here to sign up.

If you haven’t yet, you can watch the recording of the recent webinar on verification, new products and technical aspects for IFS Cycle 50r1 and AIFS v2 by clicking here.

Please report any issues with this model upgrade and your tests via the ECMWF Support Portal.

2

Can you confirm which snow variables will be included in the next AIFS release? There was some talk about more snow variable; in the implementation notes only snow cover (fscov) is listed, but it looks like the sample files also have snow water equivalent/depth (sd) - is sd also going to be in the final version?

3

Dear Andre,

I can confirm that snow depth will not be included as a new AIFS variable in the version 2.

It was planned to included, however due to some issues that were not resolved in time, it was decided not to include it.

However, before this decision it was included in the test files, so it can still be found in MARS. If it is available in any other test dataset, this is a mistake, and it will be removed.

After 12 May if will NOT be possible to install the snow depth in the dissemination system and it will not be available in the opendata either.

Best regards,
Milana Vuckovic

4

Is it possible to obtain e-suite data for 50r1 for the May 2024 - August 2024 initialization dates that are illustrated in the first figure on this page (where it shows that data used for fine-tuning AIFS v2):

I am specifically interested in comparing the accuracy of AIFS v1.1 when used with 50r1 vs 49r1 analyses for the initial condition during a boreal summer period, and the only 50r1 data that I can find in MARS is for November 2025 - present.

5

Thanks for the clarification, Milana! Nevertheless, we would be quite interested in seeing AIFS SWE forecasts in the future!

6

Hi,

I noticed that the AIFS v2 grid now starts at 0° longitude instead of previously -180° (similar to IFS 0.25). IFS 0.25 remains unchanged. Is this an intentional change?

Before:

  Ni = 1440;
  Nj = 721;
  iScansNegatively = 0;
  jScansPositively = 0;
  jPointsAreConsecutive = 0;
  alternativeRowScanning = 0;
  latitudeOfFirstGridPointInDegrees = 90;
  longitudeOfFirstGridPointInDegrees = 180;
  latitudeOfLastGridPointInDegrees = -90;
  longitudeOfLastGridPointInDegrees = 179.75;
  iDirectionIncrementInDegrees = 0.25;
  jDirectionIncrementInDegrees = 0.25;

After:

  Ni = 1440;
  Nj = 721;
  iScansNegatively = 0;
  jScansPositively = 0;
  jPointsAreConsecutive = 0;
  alternativeRowScanning = 0;
  latitudeOfFirstGridPointInDegrees = 90;
  longitudeOfFirstGridPointInDegrees = 0;
  latitudeOfLastGridPointInDegrees = -90;
  longitudeOfLastGridPointInDegrees = 359.75;
  iDirectionIncrementInDegrees = 0.25;
  jDirectionIncrementInDegrees = 0.25;

Update: The latest 2026-05-13 6z run seems to have reverted back to the old behaviour

7

Is the 850hPa temperature ensemble mean no longer available in the AIFS ENS v2 open data gribs? I’m seeing something like the following being returned:

WARNING - No index entries for type=emWARNING - Did you mean ‘ep’ instead of ‘em’?

8

Hi Brian,

Could you please confirm which specific file(s) you notice T at 850 hPa missing?

Looking at an example file from today’s 00z run (using ecCodes 2.46.0), I can confirm that T at 850hPa for type “em” is present:

% grib_ls -w shortName=t,level=850 20260513000000-240h-enfo-ep.grib2
20260513000000-240h-enfo-ep.grib2
edition      centre       date         dataType     gridType     stepRange    typeOfLevel  level        shortName    packingType  
2            ecmf         20260513     em           regular_ll   6            isobaricInhPa  850          t            grid_ccsds  
2            ecmf         20260513     em           regular_ll   222          isobaricInhPa  850          t            grid_ccsds  
2            ecmf         20260513     em           regular_ll   168          isobaricInhPa  850          t            grid_ccsds
9

Hi Patrick. Thank you for your report. The change in AIFS longitude was an unintended side effect of the implementation. We have now applied a fix, and AIFS v2 open data from 13th May 06 UTC onwards will use longitude starting from -180°. Apologies for any inconvenience caused by this.

10

Hello,

The ECMWF opendata portal has been extremely slow (downloading a few surface params for IFS+AIFS ensemble takes longer than the 6h between forcasts) since around the 50r1 release, just wondering if you were aware of it (or if it was just me) and how quickly it might be resolved.

Thanks,

Stephanie.

11

Hi, is it possible that the 50r1deployment has changed data paths in the CAMS_GLOBAL_ADDITIONAL directory?

The latest model runs 2026051212 and 2026051300 don’t contain any “prod” files as used to be in previous runs, instead they contain “test” files.
For example, we are expecting the file z_cams_c_ecmf_20260512120000_prod_fc_ml137_120_no2.nc - it doesn’t exist.
Instead, the file z_cams_c_ecmf_20260512120000_test_fc_ml137_120_no2.nc exists.

Are the “test” files equivalent to the expected “prod” files?

Thank you in advance

12

I’ve had a bit of a further look into the opendata server issue, and discovered the issue is only with byte-range requests (the same method ecmwf-opendata package uses to download subsets of the gribs), they proceed at <1MiB/s whereas a full file download with no Range header completes at 15MiB/s.

Stephanie.

13

This issue has been fixed. Please try again. Thank you.

14

When I request GloFAS, it becomes very slow. Even after leaving it overnight, it still doesn’t succeed. It always gets stuck in the “accepted” state, showing that I’m still in the queue. Could you please let me know approximately when this issue might be resolved?

15

Hi Meghan,

I’m still seeing the same problem. If I do something like this:

*from ecmwf.opendata import Client
client = Client(source=“azure”, model=“aifs-ens”)
client.retrieve(
date=0, time=0, stream=“enfo”, type=“em”,
step=300, levelist=850, param=“t”,
target=“test_em_late.grib2”
)
*
I’m seeing the following error returned

\test.py’
No index entries for type=em
Did you mean ‘ep’ instead of ‘em’?
No index entries for param=t
No index entries for levelist=850

PS: The code above is obviously just a snippet, but it replicates the behavior of my full script. I’ve also tried with different Client values.

Thanks

Brian

16

Thanks, Stephanie, that lines up with what we’ve seen before. The byte-range slowness is a long-standing characteristic of the client, not something new in 50r1.

For byte-range requests, the client issues many small requests serially, and each one carries a small start-up latency that adds up quickly when you’re pulling lots of non-contiguous ranges, compared to a single large request. There’s likely also a server-side component, since serving a single contiguous file is generally more efficient than reading and returning many small ranges, though this depends on the server implementation.

At the moment, we have a lot of users accessing the data and we recommend making use of all sources like AWS/Microsoft and Google if you experience slow retrievals.

Best wishes,

Emma

17

Hi, I think this is a bit of a misunderstanding because the client actually only produces 2 HTTP requests per file, it requests many byte-ranges in a single HTTP request (and gets a multi-part response). This method was until the last 2 days ago much faster than downloading the whole file, the client code has not changed, but the responses have slowed down. I think it is unfortunately all on the server side. I appreciate it is a very busy time for ECMWF right now but hopefully this can be looked into.

I have switched to downloading the whole file until this returns to normal (as it is a bit faster) but it still is quite a slowdown compared to previously.

Thanks,

Stephanie.

18

Hi!

After ECMWF updating 50r1, I downloading oped-data from server, but in the 0 step not showing up t2m d2m and tp data.

This is my data extracting.

=== VARIABLE UNITS === z | units: m2 s-2 | Geopotential gh | units: gpm | Geopotential height t | units: K | Temperature q | units: kg kg**-1 | Specific humidity w | units: Pa s**-1 | Vertical velocity vo | units: s**-1 | Vorticity (relative) d | units: s**-1 | Divergence r | units: % | Relative humidity u | units: m s**-1 | U component of wind v | units: m s**-1 | V component of wind sp | units: Pa | Surface pressure tp | units: m | Total precipitation skt | units: K | Skin temperature ptype | units: (Code table 4.201) | Precipitation type ssrd | units: J m**-2 | Surface short-wave (solar) radiation downwards rsn | units: kg m**-3 | Snow density lsm | units: (0 - 1) | Land-sea mask strd | units: J m**-2 | Surface long-wave (thermal) radiation downwards ssr | units: J m**-2 | Surface net short-wave (solar) radiation str | units: J m**-2 | Surface net long-wave (thermal) radiation sf | units: m of water equivalent | Snowfall mx2t3 | units: K | Maximum temperature at 2 metres in the last 3 hours mn2t3 | units: K | Minimum temperature at 2 metres in the last 3 hours u10 | units: m s**-1 | 10 metre U wind component v10 | units: m s**-1 | 10 metre V wind component fg10 | units: m s**-1 | Maximum 10 metre wind gust since previous post-processing sot | units: K | Soil temperature vsw | units: m3 m-3 | Volumetric soil moisture mucape | units: J kg**-1 | Most-unstable CAPE msl | units: Pa | Mean sea level pressure tcc | units: (0 - 1) | Total cloud cover sd | units: m of water equivalent | Snow depth

What am I doing wrong?

19

Hi Brian,

Thanks for sharing these details.

It appears the aifs-ens type=em data was missing for steps after 240 following the implementation of v2. I had checked the file at step 240, where it was present, but your example using step 300 was targeting the missing data.

The data has now been regenerated for all previous runs.

Please let me know if you encounter any further issues.

Best regards,
Meghan

20

I’ve done a bit more testing and:

File: https://data.ecmwf.int/forecasts/20260512/00z/ifs/0p25/enfo/20260512000000-24h-enfo-ef.grib2
Selection: 6 params, 292 ranges, 228.1 MB total to fetch

Streaming up to 20s ...
  received  228.2 MB in 14.8s
  rate      15.38 MB/s (123 Mbps)
  projected 228.1 MB total → ~15s (~0.2 min)

File: https://data.ecmwf.int/forecasts/20260513/00z/ifs/0p25/enfo/20260513000000-24h-enfo-ef.grib2
Selection: 6 params, 282 ranges, 221.9 MB total to fetch

Streaming up to 20s ...
received  8.4 MB in 20.8s
rate      0.40 MB/s (3 Mbps)
projected 221.9 MB total -> ~550s (~9.2 min)

The problem seems to occur only for the 50r1 files, the 49r1 files remain unaffected.