Mises à jour des modèles de prévisions

[_sb]

Pour ceux que cela intéresse, principalement les frontaliers avec l'Allemagne, le DWD propose en opendata de nombreux paramètres en probabilités (vents à 10 m à plusieurs seuils, jusqu'à 140 km/h (39 m/s), différents niveaux de sévérité des cellules orageuses, neiges, dégel, verglas, niveaux de température min et max, etc). La résolution horizontale est de 1 km seulement. Ce sont des données post-traitées depuis ICON et IFS avec leurs ensembles respectifs puis passées à une moulinette algorithmique.

Ce sont des fichiers GRIB2 qu'il convient donc de traiter pour générer graph ou cartes. Il y a en a de deux types :

- les plus légers contiennent un nombre limité de paramètres et de seuils (entre 400 et 450 Mo une fois décompressé) actualisés toutes les heures

- et les plus lourds (avec « Long » au milieu de leur nom) sont complets (environ 1,6 Go une fois décompressé), actualisés toutes les 5 ou 7 heures.

 

https://www.dwd.de/DE/forschung/wettervorhersage/met_fachverfahren/nwv_anschlussverfahren/warnmos_verfahren_node.html

https://opendata.dwd.de/weather/local_forecasts/warnmos/

 

Carte depuis les données 9z d'hier pour aujourd'hui 16h utc, montrant le domaine :

 

[_sb]

Toujours avec le DWD qui apportera une mise à jour d'ICON et d'ICON ENS mercredi prochain, 22 mai.

- valorisation de l'humidité du sol dans ICON permettant de mieux considérer l'humidité à 2m et donc la température par voie de conséquence. Les résultats sont essentiellement visible dans les zones tropicales et subtropicales.

- introduction de l'humidité du sol dans ICON ENS. Jusque là, l'humidité du sol était déduite des précipitations et secondairement de quelques autres paramètres. Cette introduction dans la phase d'assimilation apporte un traitement à la dispersion des précipitations.

- correction de la friction de surface dans ICON ENS. Le poids des données uv10m est faible dans l'ensemble par rapport au déterministe, se ressentant dans l'évaluation de la friction. Il en résulte un biais de l'uv10m (vent à 10 m) dans les membres. La correction apporte ainsi une amélioration (réduction du biais).

- correction de l'émissivité des océans (rayonnement vers l'atmosphère) grâce à la prise en compte effective de la salinité. Le dernier point ci-dessous est lié à cette correction.

- correction de la radiance

- amélioration du traitement des données de certains satellites

- vérification supplémentaire des détections des nuages par les satellites, avec un résultat positif en basse troposphère tropicale.

 

Par ailleurs, le 1er juillet prochain, modification de la dissémination MOSMIX, qui s'effectuera toutes les heures + 30 minutes au lieu de toutes les heures + 10 mn. En cause, les temps de diffusion des données d'observations  pour de nombreux pays qui obligeait alors le DWD à utiliser le forecast H1 du cycle précédent.

 

[_sb]

ECMWF publie la page centralisant les infos principales pour la prochaine mise à jour d'IFS (déterministe, ensemble, ensemble étendu, vagues) prévue octobre prochain :

https://confluence.ecmwf.int/display/FCST/Implementation+of+IFS+Cycle+49r1

 

Deux webinaires sont planifiés très bientôt :

- le 23 mai : https://events.ecmwf.int/event/415/

- le 11 juin : https://events.ecmwf.int/event/416/

 

[_sb]

Mise à jour d'ICON-D2 le 22 mai prochain :

- Assimilation des données volumétriques de 9 radars bande C de Météo-France

- La suppression d'une correction devenue inutile sur l'humidité observée proche de la saturation

- Correction de l'influence verticale des observations SYNOP dans l'analyse LEKTF

 

Détails :

2024_05_22_ID2_rhtsat_plev_mfradar.pdf

[baro54]

Le 17/05/2024 à 21:55, _sb a dit :

Mise à jour d'ICON-D2 le 22 mai prochain :

- Assimilation des données volumétriques de 9 radars bande C de Météo-France

- La suppression d'une correction devenue inutile sur l'humidité observée proche de la saturation

- Correction de l'influence verticale des observations SYNOP dans l'analyse LEKTF

 

Détails :

2024_05_22_ID2_rhtsat_plev_mfradar.pdf 321.54 Ko · 4 téléchargements

Bonjour petit question sur l assimilation des données volumétrique des radar de mf il y auras t il une amélioration sur la qualité de transmission des données radar sur le site meteoetradar merci 

[_sb]

Je ne comprends pas.

Le DWD récupère ces données depuis MF pour les intégrer à la phase d'assimilation d'ICON-D2. Le DWD ne les rediffuse pas.

[baro54]

Il y a 1 heure, _sb a dit :

Je ne comprends pas.

Le DWD récupère ces données depuis MF pour les intégrer à la phase d'assimilation d'ICON-D2. Le DWD ne les rediffuse pas.

Bonsoir il faudrait peut être les contacter pour en savoir plus 

[_sb]

C'est ta question que je ne comprends pas.

Sinon, tu peux contacter MF, le DWD ou meteoetradar si tu le souhaites...

[_sb]

Concernant les précédentes maj d'ICON et ICON-D2 :

 

https://www.dwd.de/DE/fachnutzer/forschung_lehre/numerische_wettervorhersage/nwv_aenderungen/_functions/DownloadBox_modellaenderungen/icon/pdf_2024/pdf_icon_22_05_2024.pdf?__blob=publicationFile&v=4

 

https://www.dwd.de/DE/fachnutzer/forschung_lehre/numerische_wettervorhersage/nwv_aenderungen/_functions/DownloadBox_modellaenderungen/icon_d2/pdf_2024/pdf_icon_d2_22_05_2024.pdf?__blob=publicationFile&v=2

 

IFS 49r1 : le replay de la présentation d'Andy Brown du 23 mai est disponible.

 

Enfin, l'ensemble du modèle canadien (« GEM ENS » / SGPE en français) aura, à compter du 11 juin, une échéance maximale de 39 jours pour les cycles 0z des lundis et jeudis.

Toujours chez nos amis canadiens, le modèle saisonnier et décennal SPISCan passera de 20 membres actuellement à 40 membres.

D'autres mises à jour concernent les modèles régionaux canadiens.

[_sb]

Le 06/06/2024 à 20:59, _sb a dit :

Enfin, l'ensemble du modèle canadien (« GEM ENS » / SGPE en français) aura, à compter du 11 juin, une échéance maximale de 39 jours pour les cycles 0z des lundis et jeudis.

Toujours chez nos amis canadiens, le modèle saisonnier et décennal SPISCan passera de 20 membres actuellement à 40 membres.

D'autres mises à jour concernent les modèles régionaux canadiens.

 

On peut aussi citer le passage à la version 9.0 du modèle global (« GEM »), la résolution horizontale de l'ensemble qui s'affine de 39 à 25 km et qui passe à la version 8.0, la fin de la version régionale déterministe, l'ajout en open data de l'ozone (sur la totalité de la colonne) dans la version déterministe globale (« O3Eatm »), les simulation vagues nord américaines possèdent désormais 4 cycles (0, 6, 12 et 18Z), le modèle océan-glace opérationnel passe à la version 3.5, etc. Bref, une évolution majeure des différents modèles émis par le Canada.

Comme d'habitude, le CMC publie une doc importante à chaque mise à niveau de ces modèles numériques :

https://eccc-msc.github.io/open-data/msc-data/changelog_nwp_fr/#2024

 

[_sb]

MF organise un webinaire de démonstration des API open data, le 20 juin de 14 à 16h.

https://donneespubliques.meteofrance.fr/

[_sb]

En marge, le DWD a ajouté ce mois-ci quelque paramètres supplémentaires en accès ouvert (ICON-D2, ICON-EU et ICON).

https://opendata.dwd.de/weather/nwp/

[oliver88]

Ce n'est pas une nouvelle récente, mais je n'en ai pas trouvé de plus récente.

 

Statut et plans des e-suites 48t1 et 49t1 à Météo-France.

 

La nouvelle ligne de production de Météo-France nécessite quelques évolutions dans le processus de validation de l'e-suite.
le processus de validation de l'e-suite. Par conséquent, la mise en œuvre opérationnelle de l'e-suite 48t1 a été retardée.
opérationnelle de 48t1 e-suite a été retardée et est prévue en septembre 2024 ou plus tard (date à confirmer).

 

48t1 ARPEGE courant e-suite
➢ Implémentation des schémas d'assimilation (ARPEGE, EDA) sous OOPS (couche orientée objet)
➢ Hybride 4DVAR : covariances anisotropes 3D de ARPEGE-EDA
➢ ARPEGE-EDA : ajout d'un membre non perturbé de contrôle
➢ Assimilation directe des radiances micro-ondes dans des conditions « tout ciel ».
➢ Assimilation des données GNSS-RO de SPIRE, GRACE-C, Sentinel-6
➢ Débiaisage variationnel des données d'avions
➢ Mise à jour du schéma de convection profonde « Tiedtke Bechtold
➢ Interpolations WENO dans la stratosphère (T et q)
➢ Rayonnement : EcRad avec solveur McIca
➢ Inclure l'effet des éclipses solaires sur le rayonnement
➢ SST de Mercator (produit PSY4 1/12°, en cours de migration vers GLO12)
➢ ARPEGE-EPS : Suppression de certains vecteurs singuliers (sur les domaines NH et SH)

 

48t1 AROME current e-suite
➢ Mise en œuvre de schémas d'assimilation (3DEnVar, AROME-EDA 3DVAR, AROME-NWC)
sous OOPS
➢ Schéma variationnel d'ensemble 3D « 3DEnVar », remplaçant 3DVAR
➢ Utilisation de la mise à jour de l'analyse incrémentale (IAU)
➢ AROME-EDA (utilisé pour 3DEnVar) : 50 membres, prévisions à plus long terme
➢ AROME-EPS : 24+1 membres
➢ Assimilation directe des radiances micro-ondes dans des conditions « tout ciel ».
➢ Assimilation des données GNSS-RO de SPIRE, GRACE-C, Sentinel-6
➢ Assimilation des données de vent et de température dérivées de Mode-S
➢ Assimilation des données des diffusiomètres HY-2B et HY-2C
➢ AROME-NWC : assimilation des radiances MeteoSat/RapidScan
➢ SST de Mercator (produit PSY4 1/12°, en cours de migration vers GLO12)
➢ Radiation/aérosols : EcRad avec solveur McIca et nouvelle climatologie des aérosols (IFS-COMPO)
➢ Inclure l'effet des éclipses solaires sur le rayonnement
➢ Précision unique (32b) dans les prévisions de production

 

 

Plus d'informations en pdf Statut et plans des e-suites 48t1 et 49t1 à Météo-France

[oliver88]

Modèle de HARMONIE AROME données  ouvertes DMI, service métrologique Danois. DMI Open Data Developers portal Danish Meteorological Institute - Open Data

La résolution horizontale du modèle est de 2 km, et le domaine du modèle couvre la majeure partie de l'Europe.

 

La nouvelle version de HARMONIE a une meilleure résolution horizontale et verticale. Notre vérification montre que la nouvelle version obtient de meilleurs résultats pour une variété de paramètres tels que les précipitations, le vent et les rafales de vent. 

 

J'obtiens une erreur avec MAGICS 4.15.0 avec certains paramètres,mais les cartes ont l'air bien. J'obtiens cette erreur, lcc invalid latitude.

Exemples de tiers. https://opendatadocs.dmi.govcloud.dk/en/Guides/Third-party_Examples

Script pour téléchargement.https://petergarnaes.github.io/grib-basic-processing-guide/  Ce script télécharge tous les pas de temps, 60 heures, mais c'est une très grande quantité de données, un fichier grib pèse près de 600 mb,car il contient un grand nombre de paramètres.

 

 

 

 

Modifié 24 juillet par oliver88

[_sb]

Oui, le DMI a changé domaines et résolutions de leurs modèles, avec celui montré par @oliver88, et celui sur Islande + Groenland.

Je n'avais pas rencontré de difficultés avec les nouvelles données du DMI (ni avant d'ailleurs). Pour ton erreur, une valeur erronée de iScanPositively ?

[anisodontea]

Bonjour,  je ne sais pas si je suis au bon endroit !: existe-t-il un modèle meteo à  consulter permettant de prévoir le sable du Sahara sur la France ?

Merci 

[Thundik81]

il y a 40 minutes, anisodontea a dit :

Bonjour,  je ne sais pas si je suis au bon endroit !: existe-t-il un modèle meteo à  consulter permettant de prévoir le sable du Sahara sur la France ?

Merci 

 

Classiquement le modèle grec SKIRON, le modèle catalan MONARCH sinon le CAMS.

Voir le centre régional : https://dust.aemet.es/about-us/list-of-models

[oliver88]

Qu'est-ce que l'iScanPositively ?  _sb   Jamais entendu parler.

 

 

 

 

 

 

Modifié 26 juillet par oliver88

[anisodontea]

Il y a 3 heures, Thundik81 a dit :

 

Classiquement le modèle grec SKIRON, le modèle catalan MONARCH sinon le CAMS.

Voir le centre régional : https://dust.aemet.es/about-us/list-of-models

Merci beaucoup bon we

[_sb]

Il y a 7 heures, anisodontea a dit :

Bonjour,  je ne sais pas si je suis au bon endroit !: existe-t-il un modèle meteo à  consulter permettant de prévoir le sable du Sahara sur la France ?

Merci 

 

Il y a 6 heures, Thundik81 a dit :

 

Classiquement le modèle grec SKIRON, le modèle catalan MONARCH sinon le CAMS.

Voir le centre régional : https://dust.aemet.es/about-us/list-of-models

 

Excepté SKIRON, ces modèles sont aussi accessible ici, avec interface minimale de comparaison :

https://dust.aemet.es/

 

Il y a 6 heures, oliver88 a dit :

Qu'est-ce que l'iScanPositively ?  _sb   Jamais entendu parler.

 

iScansNegatively = 0; # ou 1
jScansPositively = 0; # ou 1

 

Par rapport à la définition de la grille. Tu les retrouves dans le dump ci-dessous.

 

Le 24/07/2024 à 21:59, oliver88 a dit :

J'obtiens une erreur avec MAGICS 4.15.0 avec certains paramètres,mais les cartes ont l'air bien.

Je viens d'essayer avec Metview, je n'ai pas de souci particulier. J'ai extrait la variable lcc que je te propose en téléchargement (5,8 Mo) pour test.

Dump (tjrs avec Metview):

#==============   MESSAGE 1 ( length=6122991 )             ==============
GRIB {
  # Meteorological products (grib2/tables/30/0.0.table)  
  discipline = 0;
  editionNumber = 2;
  # Copenhagen (common/c-11.table)  
  centre = 94;
  subCentre = 255;
  # Start of forecast (grib2/tables/30/1.2.table)  
  significanceOfReferenceTime = 1;
  dataDate = 20240725;
  dataTime = 0;
  # Operational products (grib2/tables/30/1.3.table)  
  productionStatusOfProcessedData = 0;
  # Control forecast products (grib2/tables/30/1.4.table)  
  typeOfProcessedData = 3;
  numberOfDataPoints = 3061036;
  # There is no appended list (grib2/tables/30/3.11.table)  
  interpretationOfNumberOfPoints = 0;
  # Lambert conformal (Can be secant or tangent, conical or bipolar)  (grib2/tables/30/3.1.table)  
  gridDefinitionTemplateNumber = 30;
  # Earth assumed spherical with radius of 6 371 229.0 m (grib2/tables/30/3.2.table)  
  shapeOfTheEarth = 6;
  Nx = 1906;
  Ny = 1606;
  latitudeOfFirstGridPointInDegrees = 39.671;
  longitudeOfFirstGridPointInDegrees = 334.578;
  LaDInDegrees = 55.5;
  LoVInDegrees = 352;
  DxInMetres = 2000;
  DyInMetres = 2000;
  # (1=0)  North Pole is on the projection plane;(2=0)  Only one projection centre is used:grib2/tables/30/3.5.table 
  # flags: 00000000
  projectionCentreFlag = 0;
  iScansNegatively = 0;
  jScansPositively = 1;
  jPointsAreConsecutive = 0;
  alternativeRowScanning = 0;
  Latin1InDegrees = 55.5;
  Latin2 = 55500000;
  Latin2InDegrees = 55.5;
  latitudeOfSouthernPoleInDegrees = -90;
  longitudeOfSouthernPoleInDegrees = 0;
  gridType = lambert;
  NV = 182;
  # Individual ensemble forecast, control and perturbed, at a horizontal level or in a horizontal layer at a point in time (grib2/tables/30/4.0.table)  
  productDefinitionTemplateNumber = 1;
  # Cloud (grib2/tables/30/4.1.0.table)  
  parameterCategory = 6;
  # Low cloud cover (%)  (grib2/tables/30/4.2.0.6.table)  
  parameterNumber = 3;
  #-READ ONLY- parameterUnits = %;
  #-READ ONLY- parameterName = Low cloud cover;
  # Forecast (grib2/tables/30/4.3.table)  
  typeOfGeneratingProcess = 2;
  generatingProcessIdentifier = 80;
  # Hour (grib2/tables/30/4.4.table)  
  indicatorOfUnitForForecastTime = 1;
  stepUnits = h;
  forecastTime = 0;
  stepRange = 0;
  # Specified height level above ground (m)  (grib2/tables/30/4.5.table)  
  typeOfFirstFixedSurface = 103;
  #-READ ONLY- unitsOfFirstFixedSurface = m;
  #-READ ONLY- nameOfFirstFixedSurface = Specified height level above ground;
  scaleFactorOfFirstFixedSurface = 0;
  scaledValueOfFirstFixedSurface = 0;
  # Missing (grib2/tables/30/4.5.table)  
  typeOfSecondFixedSurface = 255;
  #-READ ONLY- unitsOfSecondFixedSurface = unknown;
  #-READ ONLY- nameOfSecondFixedSurface = Missing;
  scaleFactorOfSecondFixedSurface = MISSING;
  scaledValueOfSecondFixedSurface = MISSING;
  level = 0;
  # Unperturbed high-resolution control forecast (grib2/tables/30/4.6.table)  
  typeOfEnsembleForecast = 0;
  perturbationNumber = 0;
  numberOfForecastsInEnsemble = 31;
  shortName = lcc;
  name = Low cloud cover;
  cfName = unknown;
  cfVarName = lcc;
  pv(182) =  {
  0, 2718.28, 3747.09, 4915.59, 6184.63, 
  7511.83, 8869.1, 10225.2, 11544.4, 12816, 
  14034.9, 15186.5, 16261.3, 17253.3, 18159.1, 
  18976.9, 19705.3, 20337.9, 20873.9, 21313.5, 
  21656.7, 21904, 22056.5, 22116, 22085.5, 
  21969.8, 21775.4, 21509.3, 21177.9, 20787.5, 
  20344.1, 19853.2, 19320.2, 18749.7, 18146.5, 
  17514.8, 16858.7, 16182.3, 15489.6, 14785, 
  14072.3, 13355.5, 12638.3, 11924.1, 11216.5, 
  10518.6, 9833.55, 9164.24, 8513.37, 7883.43, 
  7276.7, 6695.24, 6140.63, 5614.06, 5116.27, 
  4647.68, 4208.32, 3797.93, 3415.97, 3061.69, 
  2734.1, 2432.11, 2154.46, 1899.85, 1666.91, 
  1454.86, 1262.79, 1089.7, 934.543, 796.183, 
  673.478, 565.264, 470.385, 387.701, 316.106, 
  254.538, 201.987, 157.504, 120.367, 89.8484, 
  65.2266, 45.7887, 30.8389, 19.7047, 11.7436, 
  6.34997, 2.96168, 1.06672, 0.210017, 0, 
  0, 0, 0, 0, 0, 
  0, 0, 0, 0.000157254, 0.000780797
  ... 82 more values
  } 
  numberOfValues = 3061036;
  packingType = grid_simple;
  # A bit map does not apply to this product (grib2/tables/30/6.0.table)  
  bitMapIndicator = 255;
  bitmapPresent = 0;
  values(3061036) =  {
  1.89368, 2.14758, 2.12805, 1.89758, 1.78625, 
  1.55969, 1.27844, 1.04993, 0.860474, 0.499146, 
  0.399536, 0.23938, 0.0030518, 0.0030518, 0.0030518, 
  0.0030518, 0.0030518, 0.0030518, 0.0030518, 0.0030518, 
  0.0030518, 0.0030518, 0.0030518, 0.0030518, 0.0030518, 
  0.0030518, 0.135864, 0.30188, 0.397583, 0.473755, 
  0.567505, 0.725708, 0.737427, 0.788208, 0.854614, 
  0.766724, 0.727661, 0.788208, 0.776489, 0.67688, 
  0.628052, 0.628052, 0.522583, 0.473755, 0.446411, 
  0.469849, 0.481567, 0.475708, 0.493286, 0.633911, 
  0.639771, 0.667114, 0.735474, 0.721802, 0.897583, 
  1.12805, 1.48352, 2.03235, 2.83899, 3.22375, 
  3.60461, 4.02454, 3.98938, 3.72766, 3.7511, 
  3.52258, 3.14563, 3.1593, 3.27258, 3.1925, 
  3.33313, 3.62024, 3.63977, 3.60071, 3.63391, 
  3.57727, 3.39954, 3.20813, 2.89563, 2.58899, 
  2.48352, 2.22961, 1.93469, 1.77063, 1.77844, 
  1.7843, 1.73743, 1.9054, 2.14758, 2.4093, 
  2.70618, 3.05774, 3.41321, 3.71985, 4.01672, 
  4.20227, 4.40735, 4.63782, 4.5929, 4.33118
  ... 3060936 more values
  } 
  #-READ ONLY- maximum = 99.9991;
  #-READ ONLY- minimum = 0.0030518;
  #-READ ONLY- average = 49.8308;
  #-READ ONLY- standardDeviation = 47.9701;
  #-READ ONLY- skewness = 0.0235101;
  #-READ ONLY- kurtosis = -1.94769;
  #-READ ONLY- isConstant = 0;
  #-READ ONLY- numberOfMissing = 0;
  #-READ ONLY- getNumberOfValues = 3061036;
}

 

[oliver88]

On 26/07/2024 at 20:57, _sb said:

 

 

Excepté SKIRON, ces modèles sont aussi accessible ici, avec interface minimale de comparaison :

https://dust.aemet.es/

 

 

iScansNegatively = 0; # ou 1
jScansPositively = 0; # ou 1

 

Par rapport à la définition de la grille. Tu les retrouves dans le dump ci-dessous.

 

Je viens d'essayer avec Metview, je n'ai pas de souci particulier. J'ai extrait la variable lcc que je te propose en téléchargement (5,8 Mo) pour test.

Dump (tjrs avec Metview):

#==============   MESSAGE 1 ( length=6122991 )             ==============
GRIB {
  # Meteorological products (grib2/tables/30/0.0.table)  
  discipline = 0;
  editionNumber = 2;
  # Copenhagen (common/c-11.table)  
  centre = 94;
  subCentre = 255;
  # Start of forecast (grib2/tables/30/1.2.table)  
  significanceOfReferenceTime = 1;
  dataDate = 20240725;
  dataTime = 0;
  # Operational products (grib2/tables/30/1.3.table)  
  productionStatusOfProcessedData = 0;
  # Control forecast products (grib2/tables/30/1.4.table)  
  typeOfProcessedData = 3;
  numberOfDataPoints = 3061036;
  # There is no appended list (grib2/tables/30/3.11.table)  
  interpretationOfNumberOfPoints = 0;
  # Lambert conformal (Can be secant or tangent, conical or bipolar)  (grib2/tables/30/3.1.table)  
  gridDefinitionTemplateNumber = 30;
  # Earth assumed spherical with radius of 6 371 229.0 m (grib2/tables/30/3.2.table)  
  shapeOfTheEarth = 6;
  Nx = 1906;
  Ny = 1606;
  latitudeOfFirstGridPointInDegrees = 39.671;
  longitudeOfFirstGridPointInDegrees = 334.578;
  LaDInDegrees = 55.5;
  LoVInDegrees = 352;
  DxInMetres = 2000;
  DyInMetres = 2000;
  # (1=0)  North Pole is on the projection plane;(2=0)  Only one projection centre is used:grib2/tables/30/3.5.table 
  # flags: 00000000
  projectionCentreFlag = 0;
  iScansNegatively = 0;
  jScansPositively = 1;
  jPointsAreConsecutive = 0;
  alternativeRowScanning = 0;
  Latin1InDegrees = 55.5;
  Latin2 = 55500000;
  Latin2InDegrees = 55.5;
  latitudeOfSouthernPoleInDegrees = -90;
  longitudeOfSouthernPoleInDegrees = 0;
  gridType = lambert;
  NV = 182;
  # Individual ensemble forecast, control and perturbed, at a horizontal level or in a horizontal layer at a point in time (grib2/tables/30/4.0.table)  
  productDefinitionTemplateNumber = 1;
  # Cloud (grib2/tables/30/4.1.0.table)  
  parameterCategory = 6;
  # Low cloud cover (%)  (grib2/tables/30/4.2.0.6.table)  
  parameterNumber = 3;
  #-READ ONLY- parameterUnits = %;
  #-READ ONLY- parameterName = Low cloud cover;
  # Forecast (grib2/tables/30/4.3.table)  
  typeOfGeneratingProcess = 2;
  generatingProcessIdentifier = 80;
  # Hour (grib2/tables/30/4.4.table)  
  indicatorOfUnitForForecastTime = 1;
  stepUnits = h;
  forecastTime = 0;
  stepRange = 0;
  # Specified height level above ground (m)  (grib2/tables/30/4.5.table)  
  typeOfFirstFixedSurface = 103;
  #-READ ONLY- unitsOfFirstFixedSurface = m;
  #-READ ONLY- nameOfFirstFixedSurface = Specified height level above ground;
  scaleFactorOfFirstFixedSurface = 0;
  scaledValueOfFirstFixedSurface = 0;
  # Missing (grib2/tables/30/4.5.table)  
  typeOfSecondFixedSurface = 255;
  #-READ ONLY- unitsOfSecondFixedSurface = unknown;
  #-READ ONLY- nameOfSecondFixedSurface = Missing;
  scaleFactorOfSecondFixedSurface = MISSING;
  scaledValueOfSecondFixedSurface = MISSING;
  level = 0;
  # Unperturbed high-resolution control forecast (grib2/tables/30/4.6.table)  
  typeOfEnsembleForecast = 0;
  perturbationNumber = 0;
  numberOfForecastsInEnsemble = 31;
  shortName = lcc;
  name = Low cloud cover;
  cfName = unknown;
  cfVarName = lcc;
  pv(182) =  {
  0, 2718.28, 3747.09, 4915.59, 6184.63, 
  7511.83, 8869.1, 10225.2, 11544.4, 12816, 
  14034.9, 15186.5, 16261.3, 17253.3, 18159.1, 
  18976.9, 19705.3, 20337.9, 20873.9, 21313.5, 
  21656.7, 21904, 22056.5, 22116, 22085.5, 
  21969.8, 21775.4, 21509.3, 21177.9, 20787.5, 
  20344.1, 19853.2, 19320.2, 18749.7, 18146.5, 
  17514.8, 16858.7, 16182.3, 15489.6, 14785, 
  14072.3, 13355.5, 12638.3, 11924.1, 11216.5, 
  10518.6, 9833.55, 9164.24, 8513.37, 7883.43, 
  7276.7, 6695.24, 6140.63, 5614.06, 5116.27, 
  4647.68, 4208.32, 3797.93, 3415.97, 3061.69, 
  2734.1, 2432.11, 2154.46, 1899.85, 1666.91, 
  1454.86, 1262.79, 1089.7, 934.543, 796.183, 
  673.478, 565.264, 470.385, 387.701, 316.106, 
  254.538, 201.987, 157.504, 120.367, 89.8484, 
  65.2266, 45.7887, 30.8389, 19.7047, 11.7436, 
  6.34997, 2.96168, 1.06672, 0.210017, 0, 
  0, 0, 0, 0, 0, 
  0, 0, 0, 0.000157254, 0.000780797
  ... 82 more values
  } 
  numberOfValues = 3061036;
  packingType = grid_simple;
  # A bit map does not apply to this product (grib2/tables/30/6.0.table)  
  bitMapIndicator = 255;
  bitmapPresent = 0;
  values(3061036) =  {
  1.89368, 2.14758, 2.12805, 1.89758, 1.78625, 
  1.55969, 1.27844, 1.04993, 0.860474, 0.499146, 
  0.399536, 0.23938, 0.0030518, 0.0030518, 0.0030518, 
  0.0030518, 0.0030518, 0.0030518, 0.0030518, 0.0030518, 
  0.0030518, 0.0030518, 0.0030518, 0.0030518, 0.0030518, 
  0.0030518, 0.135864, 0.30188, 0.397583, 0.473755, 
  0.567505, 0.725708, 0.737427, 0.788208, 0.854614, 
  0.766724, 0.727661, 0.788208, 0.776489, 0.67688, 
  0.628052, 0.628052, 0.522583, 0.473755, 0.446411, 
  0.469849, 0.481567, 0.475708, 0.493286, 0.633911, 
  0.639771, 0.667114, 0.735474, 0.721802, 0.897583, 
  1.12805, 1.48352, 2.03235, 2.83899, 3.22375, 
  3.60461, 4.02454, 3.98938, 3.72766, 3.7511, 
  3.52258, 3.14563, 3.1593, 3.27258, 3.1925, 
  3.33313, 3.62024, 3.63977, 3.60071, 3.63391, 
  3.57727, 3.39954, 3.20813, 2.89563, 2.58899, 
  2.48352, 2.22961, 1.93469, 1.77063, 1.77844, 
  1.7843, 1.73743, 1.9054, 2.14758, 2.4093, 
  2.70618, 3.05774, 3.41321, 3.71985, 4.01672, 
  4.20227, 4.40735, 4.63782, 4.5929, 4.33118
  ... 3060936 more values
  } 
  #-READ ONLY- maximum = 99.9991;
  #-READ ONLY- minimum = 0.0030518;
  #-READ ONLY- average = 49.8308;
  #-READ ONLY- standardDeviation = 47.9701;
  #-READ ONLY- skewness = 0.0235101;
  #-READ ONLY- kurtosis = -1.94769;
  #-READ ONLY- isConstant = 0;
  #-READ ONLY- numberOfMissing = 0;
  #-READ ONLY- getNumberOfValues = 3061036;
}

 

Je dois alors modifier les valeurs de jScansPositively et iScansPositively ? J'ai essayé cette commande et rien ne se passe.  grib_set -s swapScanningY=0  IN.grib2  OUT.grib2

J'ai essayé les paramètres 2T, TP, CAPE, 10mWgust, et ce n'est qu'à T2M que cette erreur se produit, on ne sait pas trop pourquoi.  J'ai essayé d'exécuter le script Python de Metview avec un champ 2T problématique, et je n'ai pas vu apparaître la même erreur que dans les MAGICS. La MAGICS est très lente, je pense que c'est dû à une erreur

 

 

Quelle version utilisez-vous de la MAGICS, de la Metview, des ECCODES ?

MAGICS error with 2T variable

Modifié 28 juillet par oliver88

[_sb]

MetView : 5.22, eccodes : 2.36.1, cdo : 2.4.2 sous debian

 

Je n'ai pas regardé plus en profondeur et je n'utilise plus, pour le moment en tout cas, ce modèle.

Sans entrer dans la technique, peux-tu simplement afficher le paramètre qui te pose souci dans MetView avec la configuration par défaut (peu importe si « joli » ou « lisible »). Est-ce que quelque chose s'affiche hormis le fond de carte ?

S'il n'y a que le fond de carte, il est probable que soit jScansPositively soit iScansNegatively soit mal positionné.

 

Si iScansNegatively = 0 alors la latitude du premier point de grille est au nord de la latitude du dernier point de grille

Si iScansNegatively = 1 alors la latitude du premier point de grille est au sud de la latitude du dernier point de grille

 

Si jScansPositively = 0, alors la longitude du premier point de grille est à l'ouest de la latitude du dernier point de grille

Si jScansPositively = 1, alors la longitude du premier point de grille est à l'est de la latitude du dernier point de grille

 

Pour changer avec eccodes :

# exemple à adapter
grib_set -s jScansPositively=0 fichierSource.grib2 fichierDestination.grib2

 

Ça ne sert à rien de modifier ces entrées si les valeurs sont déjà correctes. Donc vérifie Le problème vient d'ailleurs.

 

EDIT : désolé, je viens de me rendre compte que ce n'est pas le paramètre lcc qui t'ennuie (low cloud cover) mais le paramètre 2t.

LCC fait référence à la grille : Lambert Conformal Conic.

Il y a donc un problème d'encodage du message dans le fichier GRIB. Oublie ce que j'ai écrit plus haut.

Essaie simplement de comparer les données de grille encodées pour un message OK avec celles du message défectueux pour éventuellement modifier le champ erroné via grib_set que tu utilises.

 

PS : ouvre un topic spécifique car ce n'est pas le bon sujet ici !

Modifié 29 juillet par _sb

[_sb]

Mise à jour mineure d'ICON le 31 juillet 9z :

https://www.dwd.de/DE/fachnutzer/forschung_lehre/numerische_wettervorhersage/nwv_aenderungen/_functions/DownloadBox_modellaenderungen/icon/pdf_2024/pdf_icon_31_07_2024.pdf?__blob=publicationFile&v=2

[_sb]

Pour signaler la mise à disposition par le DMI des données marées en open data pour les côtes du Danemark, des Féroé et du Groenland.

Les données sont accessibles comme toujours sur le portail des données ouvertes de l'État danois : https://opendatadocs.dmi.govcloud.dk/DMIOpenData

[_sb]

Échange policé à ECMWF entre le Machine Learning (ML) et les modèles physiques dans la prévision numérique du temps :

https://www.ecmwf.int/en/about/media-centre/focus/2024/machine-learning-and-physics-weather-forecasting-discussion-0

 

Sur la même thématique, l'apport de ML peut améliorer (corriger) le modèle physique :

https://www.ecmwf.int/en/about/media-centre/news/2024/how-physics-based-forecasts-can-be-corrected-machine-learning

 

Toujours chez ECMWF, la lettre trimestrielle est parue :

https://www.ecmwf.int/en/newsletter/180/editorial/destination-earth-initiative

On y trouvera entre autres un article sur l'open data : la totalité du catalogue temps réel (IFS, IFS ENS, IFS ENS EXT, SEAS5, toutes résolutions) sera placée en open data (CC-BY 4.0) d'ici à 2026. Une partie sera sans frais de mise à disposition (= totalement gratuite), l'autre sera uniquement soumise à des frais de mise à disposition mais ces derniers ne s'ajouteront plus aux prix actuels des données. De plus, les prix données ont baissé ce 1er juillet (~ -66% pour ce qui m'intéresse).

Enfin, la résolution open data d'IFS et IFS ENS, aujourd'hui à 0.25°, passerait courant second semestre 2025 à 0.125°.

Pour celles et ceux que cela intéressent : les tarifs actuels et les packs disponibles de mise à disposition (basic, bronze, silver et gold) qui resteront en 2026, 500 € / an pour le minimum, 126 500 € pour le maximum selon le volume annuel téléchargé et les services souhaités.

Un autre article sur la future mise à niveau majeure de NEMO (modèle océan glace utilisé par IFS) et un autre sur ORAS6 pour la réanalyse océanographique.