GribStream

Blog GribStream

ECMWF IFS Cycle 50r2 : transition complète vers GRIB2 et tests à faire maintenant

|
ifsoper ifsenfo aifsoper aifsenfo

ECMWF indique qu'IFS Cycle 50r2 déplacera tous les paramètres vers GRIB2. Voici le calendrier le plus récent, les détails de migration et les vérifications pratiques pour les pipelines de données météorologiques.

Les communications de l'ECMWF autour de IFS Cycle 50r2 pointent toutes vers un changement majeur : le passage à une représentation entièrement GRIB2 pour les paramètres.

Les pages techniques ECMWF ajoutent des détails importants sur le calendrier et le comportement de migration, faciles à manquer.

Mise à jour, 11 mai 2026 : la page de migration ECMWF place maintenant l'implémentation opérationnelle d'IFS Cycle 50r2 au T1 2027, avec des données de test entièrement GRIB2 dans MARS au T2 2026 et des données de test de dissémination au T3 2026.

Ce qu'ECMWF a confirmé

D'après la mise à jour utilisateur ECMWF de janvier 2026 :

  • IFS Cycle 50r2 inclura une transition complète vers GRIB2.
  • Cette transition est décrite comme non optionnelle pour les utilisateurs des produits concernés.

Calendrier actuel

La documentation de migration ECMWF donne un calendrier plus détaillé que la plupart des résumés :

  • Un dataset statique de test est disponible depuis septembre 2025.
  • Le dataset de test MARS est listé pour le T2 2026.
  • Le dataset de test de dissémination est listé pour le T3 2026 (après 50r1).
  • L'implémentation opérationnelle 50r2 est actuellement indiquée pour le T1 2027 (provisoire).

Séparément, ECMWF a implémenté 50r1 et AIFS v2 le 12 mai 2026. Cela garde 50r2 clairement séparé comme une mise à niveau technique ultérieure.

Détails de migration qui comptent dans les vrais pipelines

Les exemples de migration GRIB2 de l'ECMWF montrent des différences concrètes de clés et valeurs qui peuvent casser une logique stricte de parsing et de filtrage :

  • Les références de paramètres héritées du style GRIB1 (par exemple 165.128) passent vers des identifiants de paramètres natifs GRIB2.
  • Certaines gestions de type de niveau changent (par exemple les cas levtype=sol dans les exemples).
  • L'usage de mots-clés liés à la chimie change dans les requêtes d'exemple.
  • La sortie GRIB2 peut utiliser la compression CCSDS, ce qui nécessite le support côté décodeur (dans beaucoup de stacks, cela signifie vérifier la présence du support libaec).

Si vous maintenez une extraction personnalisée, du filtrage ou une ancienne logique de matching de clés, c'est là que des défaillances subtiles peuvent apparaître.

Ce que cela signifie pour les utilisateurs GribStream

GribStream prend déjà en charge IFS Operational, IFS Ensemble, AIFS Operational et AIFS Ensemble.

Version courte : si vous utilisez l'API GribStream, c'est surtout notre problème, pas le vôtre. Vous ne devriez pas avoir à vous soucier des templates GRIB internes juste pour garder votre application en fonctionnement.

Nous ingérons déjà les fichiers ECMWF Open Data en GRIB2, et notre chemin d'extraction gère les templates de compression observés en pratique, y compris CCSDS/AEC. Vous ne devriez donc pas avoir à revoir votre application simplement parce qu'ECMWF finalise cette transition GRIB2 en amont.

Là où cela reste directement important, c'est pour les utilisateurs de fichiers bruts hors du chemin API : décodeurs personnalisés, matching de clés sur mesure, requêtes directes MARS ou dissémination.

Conseils pratiques :

  • Utilisateurs de l'API GribStream : gardez vos requêtes stables, puis validez vos métriques métier autour de la fenêtre de transition.
  • Utilisateurs de fichiers bruts : gardez vos décodeurs et toolchains ecCodes à jour.
  • Utilisateurs de fichiers bruts : validez les hypothèses de parsing contre les datasets de test ECMWF et faites des comparaisons côte à côte avant/après le basculement.

Sources

Modèles associés

ifsoper ifsenfo aifsoper aifsenfo
Essayer GribStream