GribStream

GribStream Blog

ECMWF IFS Cycle 50r1 is now live on GribStream

|
ifsoper ifsenfo ifswave ifswaef

GribStream is now processing ECMWF IFS Cycle 50r1 in the existing IFS datasets, with the model boundary at the 06 UTC run on May 12, 2026.

ECMWF implemented IFS Cycle 50r1 on May 12, 2026, and GribStream is processing the new cycle in the existing ECMWF IFS datasets.

The boundary is exact:

  • 2026-05-12 00 UTC and earlier: IFS Cycle 49r1
  • 2026-05-12 06 UTC and later: IFS Cycle 50r1

That means you do not need to move to a new GribStream dataset code to follow the upgrade. Continue using IFS Oper, IFS ENS, IFS Wave, and IFS Wave ENS. The history remains in the same datasets, and the model cycle changes at the operational boundary ECMWF published.

Why 50r1 matters

This is a real Earth-system upgrade, not a cosmetic release.

ECMWF describes 50r1 as a broad update to the IFS forecast model and data assimilation system. The largest structural change is a new ocean and sea-ice configuration based on NEMO4-SI3, with stronger coupling between the atmosphere, ocean, sea ice, and waves.

That matters because many high-value forecasts are not purely atmospheric. Coastal precipitation, sea surface temperature, sea ice, wave height, tropical systems, and near-surface winds all depend on how the model moves information across the air-sea boundary.

ECMWF highlights several areas of expected improvement:

  • better inland propagation of convective precipitation, reducing the tendency for some convective rainfall to stay too stationary
  • improved tropical upper-air temperature and wind forecasts
  • improved humidity and temperature behavior near the tropopause
  • reduced Southern Ocean sea-surface temperature warm bias
  • better Western Boundary Current representation, including regions such as the Gulf Stream
  • more realistic 10 m ensemble wind spread
  • updated wave physics, including wave interaction with sea ice and ocean currents

For customers, the practical point is simple: verification windows that cross May 12 should be split. A forecast initialized at 2026-05-12 06 UTC is not from the same model cycle as one initialized at 2026-05-12 00 UTC.

What changed in GribStream

GribStream keeps the upgrade inside the same dataset timeline.

Requests against the IFS /timeseries and /runs endpoints continue to work across the model boundary. When your request lands before the boundary, it reads the historical 49r1 data. When it lands on or after the 06 UTC run on May 12, it reads 50r1.

We also refreshed the model inventories and catalog metadata so newly visible ECMWF fields are discoverable through the public model pages and catalog endpoints.

The wave inventory is the most visibly expanded. Compared with the final 49r1 06 UTC run we checked, the 50r1 IFS wave feeds now expose:

  • h1012, h1214, h1417, h1721, h2125, h2530: significant wave height grouped by wave-period band
  • cdww: coefficient of drag with waves
  • wmb: model bathymetry

We did not see any existing GribStream IFS parameter disappear at the 50r1 boundary in the public open-data indexes we process.

There is a separate point worth making carefully. ECMWF's full 50r1 implementation page lists additional new MARS/dissemination parameters, including wbt, fscov, cur, and many ocean and sea-ice fields on o2d and o3d levels. Those are not the same thing as "available in the public open-data files GribStream ingests today." As of the 50r1 public open-data indexes checked for this update, those additional fields were not present as new GribStream queryable parameters.

That absence should not be read as deprecation. ECMWF explicitly documents one discontinued parameter in the 50r1 notes: vegdiff, replaced by cur. The other official 50r1 additions are simply not present in the current public open-data feed we process. If ECMWF adds them to public open data, or if GribStream onboards another ECMWF feed that contains them, they can be added to the same catalog workflow.

What did not change

ECMWF says 50r1 does not change the horizontal or vertical resolution or forecast steps for the affected medium-range atmospheric and wave forecasts.

That is useful for continuity. Your spatial extraction logic, lead-time selection, and ordinary point or grid queries should not need to change just because the model cycle advanced.

The thing that does change is the forecast system behind the values. For backtests, alerts, or model-comparison dashboards, treat 2026-05-12 06 UTC as a model-version boundary.

Sources

Related models

ifsoper ifsenfo ifswave ifswaef
Try GribStream