GribStream

GribStream Blog

ECMWF IFS Cycle 50r2: vollständige GRIB2-Umstellung und was Sie jetzt testen sollten

|
ifsoper ifsenfo aifsoper aifsenfo

ECMWF sagt, dass IFS Cycle 50r2 alle Parameter auf GRIB2 umstellen wird. Hier sind der aktuelle Zeitplan, die Migrationsdetails und praktische Checks für Wetterdaten-Pipelines.

ECMWFs Nutzerkommunikation rund um IFS Cycle 50r2 zeigt auf eine große Änderung: die Umstellung auf eine ausschließlich GRIB2-basierte Darstellung für Parameter.

Die technischen ECMWF-Seiten ergänzen wichtige Details zu Timing und Migrationsverhalten, die in kurzen Zusammenfassungen leicht übersehen werden.

Update, 11. Mai 2026: ECMWFs Migrationsseite legt die operative Einführung von IFS Cycle 50r2 jetzt in Q1 2027, mit Full-GRIB2-Testdaten in MARS in Q2 2026 und Dissemination-Testdaten in Q3 2026.

Was ECMWF bestätigt hat

Aus ECMWFs User-Impact-Update vom Januar 2026:

  • IFS Cycle 50r2 wird eine vollständige GRIB2-Umstellung enthalten.
  • Diese Umstellung wird für Nutzer der betroffenen Produkte als nicht optional beschrieben.

Zeitplan: was aktuell gilt

ECMWFs Migrationsdokumentation liefert einen detaillierteren Zeitplan als die meisten Kurzbeiträge:

  • Statisches Test-Dataset ist seit September 2025 verfügbar.
  • MARS-Test-Dataset ist für Q2 2026 gelistet.
  • Dissemination-Test-Dataset ist für Q3 2026 gelistet, nach 50r1.
  • Operative 50r2-Implementierung ist aktuell als Q1 2027 angegeben, vorläufig.

Separat hat ECMWF 50r1 und AIFS v2 am 12. Mai 2026 implementiert. Damit bleibt 50r2 klar als späteres technisches Upgrade getrennt.

Migrationsdetails, die in echten Pipelines wichtig sind

ECMWFs GRIB2-Migrationsbeispiele zeigen konkrete Key/Value-Unterschiede, die strikte Parsing- und Filterlogik brechen können:

  • Legacy-GRIB1-artige Parameterreferenzen, etwa 165.128, wechseln zu GRIB2-nativen Parameter-IDs.
  • Manche Behandlung von Level-Typen ändert sich, zum Beispiel levtype=sol in den Beispielen.
  • Chemistry-bezogene Keyword-Nutzung ändert sich in Beispiel-Requests.
  • GRIB2-Ausgabe kann CCSDS-Kompression verwenden, was Decoder-Support verlangt. In vielen Stacks bedeutet das: sicherstellen, dass libaec-Support vorhanden ist.

Wenn Sie eigene Extraktion, Filterung oder alte Key-Matching-Logik pflegen, können hier subtile Fehler auftreten.

Was das für GribStream-Nutzer bedeutet

GribStream unterstützt bereits IFS Operational, IFS Ensemble, AIFS Operational und AIFS Ensemble.

Kurz gesagt: Wenn Sie die GribStream-API nutzen, ist das größtenteils unser Problem, nicht Ihres. Sie sollten sich nicht mit GRIB-Template-Interna beschäftigen müssen, nur damit Ihre Anwendung weiterläuft.

Wir ingestieren ECMWF Open Data bereits als GRIB2, und unser Extraktionspfad verarbeitet die Kompressionstemplates, die wir in der Praxis sehen, einschließlich CCSDS/AEC. Sie sollten Ihre Anwendung also nicht umbauen müssen, nur weil ECMWF diese GRIB2-Umstellung auf der Quellseite abschließt.

Direkt relevant bleibt das vor allem für Nutzer, die Rohdateien außerhalb des API-Pfads verarbeiten: eigene Decoder, eigene Key-Matching-Logik oder direkte MARS-/Dissemination-Requests.

Praktische Empfehlungen:

  • GribStream-API-Nutzer: Requests stabil halten und fachliche Kennzahlen rund um das Umstellungsfenster validieren.
  • Rohdatei-Nutzer: Decoder und ecCodes-Toolchains aktuell halten.
  • Rohdatei-Nutzer: Parser-Annahmen gegen ECMWF-Test-Datasets validieren und Parallelchecks vor und nach dem Wechsel ausführen.

Quellen

Verwandte Modelle

ifsoper ifsenfo aifsoper aifsenfo
GribStream ausprobieren