Mises à jour des modèles de prévisions

[_sb]

Mise à jour mineure (->5.5.1) du modèle Meso-NH du CNRM / CNRS en juin dernier.

C'est un modèle non hydrostatique que l'on peut installer (à l'instar des WRF, pardon @Kendor, c'est pour signifier sa différence avec ARPEGE, IFS ou UKMO par exemple).

Mise à jour aussi de la doc.

http://mesonh.aero.obs-mip.fr/mesonh55/Welcome

http://mesonh.aero.obs-mip.fr/mesonh/dir_open/dir_MESONH/WHY-BUGFIX-551.pdf

http://mesonh.aero.obs-mip.fr/mesonh55/BooksAndGuides?action=AttachFile&do=get&target=users_guide_m551.pdf

 

[_sb]

Le 01/11/2021 à 11:13, Cers a dit :

Qu'est ce qui motive ECMWF à utiliser la même légende pour les températures à 1000 hPa, 500 hPa et 200 hPa ici ? C'est inadapté, à 500 hPa par exemple on y voit que du bleu.

 

https://apps.ecmwf.int/webapps/opencharts/products/medium-t-z?base_time=202110271200&level=500&projection=opencharts_europe&valid_time=202110271200

 

Cet été, ECMWF travaille (entre autres choses évidemment 😛 ) sur une refonte de la gestion des couleurs dans Magics, leur librairie graphique. La piste explorée est de permettre l'utilisation des metadonnées incluses dans les binaires pour générer l'échelle de couleurs à partir d'un paramétrage (par exemple, 10 couleurs en tout ou une couleur pour 4 unités ou une palette prédéfinie, etc).

[oliver88]

1 hour ago, _sb said:

 

Cet été, ECMWF travaille (entre autres choses évidemment 😛 ) sur une refonte de la gestion des couleurs dans Magics, leur librairie graphique. La piste explorée est de permettre l'utilisation des metadonnées incluses dans les binaires pour générer l'échelle de couleurs à partir d'un paramétrage (par exemple, 10 couleurs en tout ou une couleur pour 4 unités ou une palette prédéfinie, etc).

Comment le savez-vous ?

Mon T500 hpa créé avec Magics, j'utilise les mêmes couleurs que pour le T850. Ma propre échelle de couleurs. 

 

[_sb]

J'avais posé la question de façon informelle puis formelle aux développeurs lorsque @Cers s'était ému du manque de lisibilité des cartes de T aux niveaux supérieurs. J'avais eu une première réponse, admettant la légitimité de la demande. Ça a été ajouté aux travaux estivaux, ce sera très probablement intégré lors d'une maj prochaine.

 

C'est toi qui voit pour les échelles de couleurs. Perso, celle que tu proposes peut être valable en été, mais en hiver, les T500 évoluent généralement sur ce domaine entre -15°C à l'extrême sud et -50°C à l'extrême nord. Donc 1/3 de ton échelle seulement et les valeurs les plus basses ne seront pas différenciées.

De plus, même en été, tu n'auras jamais de +20°C !

 

C'est une question récurrente que tout le monde se pose à un moment. Le choix d'une échelle dynamique pallie ce problème mais les couleurs ne sont pas les mêmes en fonction des configurations. Les échelles absolues comme ECMWF proposent actuellement facilitent la comparaison tout en perdant en lisibilité. Les échelles adaptatives, une pour les T500 de -50°C à 0°C environ; une pour les T850 de -30°C à + 40°C sont une sorte de compromis. Le choix peut être guidé par les objectifs, les enjeux qu'on souhaite faire passer, la science (climato ou météo), etc

[_sb]

ICON a son code source ouvert (non commercial). Le DWD implémente certains modules spécifiques par exemple mais le cœur est accessible, fonctionnel et utilisable.

La version 2.6.5 (la version opérationnelle du DWD est la 2.6.4) est désormais accessible :

 

Citation

Dear all,

We are happy to announce the release of ICON 2.6.5. IT can be downloaded at the usual place.

For your convenience we attache the release notes her.

Best Regards,
Luis Kornblueh for the ICON developers.

# Release notes for icon-2.6.5

It is time for yet another ICON release.

 

After 10 month we managed to provide a new ICON release with new machine configurations, a new buildbot, significantly extended, improved GPU capabilities, first steps into ICON seamless and a cleaned up version of the MPIM AES physics (now available as aes physics and not echam anymore).

 

- CSCS: Introduction of more and optimized OpenACC code parts and introducing work to allow later more modularization for improving and consolidating of the ICON code.

 

- DKRZ: Bugfixes and more bugfixes, cdi-1.8.4 incorporates nom (joint effort of DKRZ and CIMD) cdi-pio, new versions of all tools maintained by DKRZ, a new buildbot (Ralf Müller) and strong support for getting ICON running on levante.

 

- DWD: Introduction of many improvements in the parameterizations, in tuning and adding bugfixes. Setting up on the new ECMWF system and supporting the data assimilation system. First steps for ICON-seamless are done, especially the coupling to ICON ocean is technically available and mot of the time varying external data for climate simulations have been added. However, the code variant has to tuned and extensively tested and some parts are still missing. This activity is a joint effort of DWD and MPIM colleagues.

 

- MCH: Is actively providing more, and more model components of the NWP physics for the use on GPUs. Furthermore they are  supporting all activities related to GPUs and testing of large parts of the ICON code.

 

- MPIM AES: To simplify and streamline further high resolution modelling only, the echam physics has been renamed as aes physics and some former components have been removed as are the SSO gravity drag parameterization, as well the gravity drag parameterization for the middle atmosphere, and most prominent the convection parameterization. As cloud parameterizations the DWD graupel and two-moment scheme are available. A few more, minor, changes have been applied. Newly added is the former large eddy model component the Smagorinsky 'vertical' diffusion scheme.

 

- MPIM OES: Added a new C-grid seaice model (C. Mehlmann) and extensive improvements of OpenMP for hamocc.

 

- MPIM LES: JSBACH got more model components and has been adapted for to all changes above its top-level.

 

- KIT: The aerosoly microphysics and plume components have been added as well as a large number of bugfixes.

 

- MPIM CIMD: just a lot of things in the area of coupling, configuring and building and model infrastructure, new machine setups for lumi (CSC), juwels/booster (JSC) and levante (DKRZ)

 

- All developers: many of the work has been done in cross institutional working groups.

 

A special thanks is going to Sergey Kosukhin (MPIM-CIMD) for his work on the configuration and build system of ICON making life of developers much easier.

The work on the GPU code version, implemented based on OpenACC has been supported by NVIDIA. Thanks a lot, Dmitry Alexeev (and his colleagues).

For detailed information, please, have a look at
https://gitlab.dkrz.de/icon/wiki/-/wikis/Protocol-of-Release-Commits

 

Note : « Levante » est une infrastructure matérielle maintenue et fournie par le DKRZ à tous les développeurs qui souhaitent participer / contribuer à ICON ou utiliser ICON à des projets définis.

Similaire pour Juwels et Lumi.

Il est nécessaire d'être enregistré pour accéder aux dépôts du DKRZ (instance gitlab).

[_sb]

Citation

Subgrid scale Lightning Potential Index for ICON with parameterized convection

 

A subgrid scale lightning potential index (LPI) based on parameterized deep convection as well as a modified version of this index (MLPI) have been developed and implemented in ICON.

It is based on the LPI formula of Lynn and Yair (2010) for models with resolved convection. Following the idea of Lopez (2016), the quantities (e.g. vertical velocity) needed in the LPI formula are derived from the updraft of the Bechtold-Tiedtke parameterization scheme (Bechtold et al., 2008, 2014). In case of MLPI the formula is further improved by taking into account the vertical equivalent potential temperature gradient (i.e. the KO-index). LPI and MLPI are tested in ICON with 20 km resolution (ICON-20).

The MLPI is verified against LINET lightning data (Betz et al., 2009) over central Europe for the months 06/07 2020 and 03/2021-08/2021. The MLPI is also compared to the LPI and the lightning flash density (LFD, Lopez, 2016), all computed in ICON-20. A grid scale verification for the test period shows that the MLPI outperforms the LPI and LFD. However, when the location error is removed, LPI performs best.

 

Keywords: Lightning, Deep convection

Je n'ai pas lu.

https://www.dwd.de/EN/ourservices/reports_on_icon/pdf_einzelbaende/2022_10.pdf?__blob=publicationFile&v=4

[Damien49]

Citation

 

AROME :

* passage à de nouvelles données radars, diffusiomètres à plus haute résolution dont Ascat de Metop-C

* changement du schéma d'advection avec suppression de la diffusion des hydrométéores associée

* nouveaux diagnostics de convection et aéronautiques

* uniformisation des 8 réseaux qui vont tous jusqu'à 51 h

 

 

On est pas mal de chasseurs d'orages à trouver que depuis la dernière mise à jour d'Arome, la prévision convective est devenu très compliqué avec beaucoup plus d'erreurs qu'auparavant. Des décalages très importants dans le calcul de CAPE, des décalages de plus de 6h des dégradations orageuses, des décalages de plus de 200km des noyaux convectifs et un écartement très important par rapport aux autres modèles. Je peux citer pas mal d'exemples sur les 2 mois que l'on vient de vivre et nous en discutions régulièrement entre chasseurs avant de savoir qu'il y avait eu une mise à jour du modèle pile à partir du moment où nous nous sommes rendus compte de ça.

 

Je n'explique pas la raison, mais il semble qu'il y a un lien avec la dernière MAJ du modèle pour qu'on soit si nombreux à avoir un tel ressenti entre chasseurs de différentes régions de la France depuis début juillet. Est-ce que cette Maj est en opendata ? Sinon les données diffusées en opendata sont-elles devenues dégradées ?

[_sb]

Il y a 5 heures, Damien49 a dit :

Est-ce que cette Maj est en opendata ? Sinon les données diffusées en opendata sont-elles devenues dégradées ?

 

Toutes les sorties d'AROME ne sont pas en données ouvertes mais celles qui le sont sont opérationnelles.

 

Le 28/07/2022 à 21:52, _sb a dit :

Le 01/11/2021 à 11:13, Cers a dit :

Qu'est ce qui motive ECMWF à utiliser la même légende pour les températures à 1000 hPa, 500 hPa et 200 hPa ici ? C'est inadapté, à 500 hPa par exemple on y voit que du bleu.

 

https://apps.ecmwf.int/webapps/opencharts/products/medium-t-z?base_time=202110271200&level=500&projection=opencharts_europe&valid_time=202110271200

 

Le 29/07/2022 à 14:57, _sb a dit :

J'avais posé la question de façon informelle puis formelle aux développeurs lorsque @Cers s'était ému du manque de lisibilité des cartes de T aux niveaux supérieurs. J'avais eu une première réponse, admettant la légitimité de la demande. Ça a été ajouté aux travaux estivaux, ce sera très probablement intégré lors d'une maj prochaine.

 

C'est désormais intégré, comme anticipé précédemment.

contour_shade_colour_list_policy permet d'ajuster les bornes en fonctions des valeurs minimales et maximales du champ et dans le domaine considéré. Par défaut, ce n'est pas dynamique. Le nombre d'éléments reste déterminant (contour_level_count). Si dynamique, les valeurs min et max ne sont évidemment plus nécessaires.

contour_shade_colour_reverse_list permet de renverser les couleurs de la palette. Les palettes n'étant définies que dans un fichier json, c'était facile à réaliser. En natif, c'est une étape en moins.

[oliver88]

On 8/25/2022 at 2:54 PM, Damien49 said:

 

On est pas mal de chasseurs d'orages à trouver que depuis la dernière mise à jour d'Arome, la prévision convective est devenu très compliqué avec beaucoup plus d'erreurs qu'auparavant. Des décalages très importants dans le calcul de CAPE, des décalages de plus de 6h des dégradations orageuses, des décalages de plus de 200km des noyaux convectifs et un écartement très important par rapport aux autres modèles. Je peux citer pas mal d'exemples sur les 2 mois que l'on vient de vivre et nous en discutions régulièrement entre chasseurs avant de savoir qu'il y avait eu une mise à jour du modèle pile à partir du moment où nous nous sommes rendus compte de ça.

 

Je n'explique pas la raison, mais il semble qu'il y a un lien avec la dernière MAJ du modèle pour qu'on soit si nombreux à avoir un tel ressenti entre chasseurs de différentes régions de la France depuis début juillet. Est-ce que cette Maj est en opendata ? Sinon les données diffusées en opendata sont-elles devenues dégradées ?

Je n'ai pas d'expérience avec AROME car je suis en dehors du domaine des modèles.  

Mais la nouvelle ARPEGE, d'après mon expérience à court terme ici dans le bassin des Carpates (où je vis), est devenue insensible aux précipitations convectives. Il semble que l'ancien schéma de convection était plus sensible. 

Quelqu'un d'autre a-t-il rencontré ce ?

 

Cependant, le nouveau schéma convectif est devenu plus fiable en termes de diminution des erreurs dans la prévision des précipitations convectives diurnes, mais aussi plus insensible malheureusement.

 

[Idéfix37]

Je place ici un article de Météo-Suisse qui résume bien les avancées des modèles développés ou co-développés par le CEP (ECMWF) ainsi que les prochaines perspectives de développement prévues. L’article original émanant de l’ECMWF est disponible dans l’article sous la forme d’un lien. 
https://www.meteosuisse.admin.ch/home/actualite/meteosuisse-blog.subpage.html/fr/data/blogs/2022/9/ecmwf.html

 

[Nico 14]

Il y a 5 heures, Idéfix37 a dit :

Je place ici un article de Météo-Suisse qui résume bien les avancées des modèles développés ou co-développés par le CEP (ECMWF) ainsi que les prochaines perspectives de développement prévues. L’article original émanant de l’ECMWF est disponible dans l’article sous la forme d’un lien. 
https://www.meteosuisse.admin.ch/home/actualite/meteosuisse-blog.subpage.html/fr/data/blogs/2022/9/ecmwf.html

 

 

Intéressant tout cela en effet. Hâte de voir IFS avec la résolution d'Arome, ce que donneront ces "modèles tempêtes"( @_sb va nous dénicher une bêta en open data ) et ce nouvel ensemble étendu qui pourrait faire progresser la tendance mensuelle. 

[_sb]

 

Le Max-Planck Institut für Meteorologie (le fameux MPI-Met) avec le Karsruher Institut für Technologie (KIT) en association avec le DWD développent aussi un ICON global tout aussi ambitieux. On trouve déjà quelques simulations encourageantes. J'avais mis quelques liens précédemment. Avec ECMWF, le but n'est pas de se concurrencer mais d'explorer des pistes différentes, les échanges sont fréquents entre les équipes.

Le Met'Off officiait aussi dans ce sens, je n'ai pas suivi depuis. Outre-atlantique, cette idée est présente aussi.

Pour de l'open data, va falloir attendre quand même ! Un peu, beaucoup, passionnément ...

[oliver88]

Quel est le problème avec le serveur Meteo France ? Depuis hier, impossible de télécharger les fichiers grib. 

 

 

 

[_sb]

Je ne rencontre pas de problèmes particuliers.

[meteomettra]

Hello,

 

Ma question ne correspond pas exactement au titre de ce topic mais vu qu'on parle de modèles ici je pense qu'il a sa place ici.

 

Récemment, ça parle souvent du modèle "Swiss HD 4x4" sur le forum mais je n'ai pas trouvé grand chose à son sujet. Je suppose que 4x4, c'est la taille de la maille et "Swiss" pourrait signifier qu'il est développé par/en Suisse... Sur ce dernier point, ce n'est clairement pas un modèle opérationnel de MétéoSuisse (https://www.meteosuisse.admin.ch/home/systemes-de-mesure-et-de-prevision/systemes-d-alertes-et-de-previsions/Le-systeme-de-prevision-cosmo.html).

 

Du coup, si quelqu'un a quelques infos sur ce modèle, ça m'intéresse !

[_sb]

C'est un modèle développé par The Kachelmann Group de résolution horizontale 4 par 4 km avec 4 cycles par jour. Pour le reste, je n'ai pas obtenu de réponse à l'adresse de contact.

Il existe Swiss Super HD, un modèle de résolution horizontale plus fine, 1 par 1 km mais non disponible en Europe (pour le moment du moins).

Il existe aussi un Swiss HD 4x4 avec les conditions initiales et aux bordures d'IFS.

 

Effectivement, rien à voir avec les modèles de Meteo Suisse basés sur COSMO (COSMO-1E et COSMO-2E) qui passeraient à terme sur le noyau ICON-LAM (DWD et MPI-Met)

[meteomettra]

dommage de ne pas avoir plus d'info...

[_sb]

Je n'ai eu la moindre info de chez eux et je crains de ne pas en avoir une cette fois.

Peut-être est-ce un WRF ? Toujours ennuyeux de ne rien savoir d'un modèle, ce sont des infos importantes pour calibrer l'analyse.

[Nico 14]

Ça ne nous en dit pas plus sur le modèle en lui-même mais je l ai dit sur le topic qui traite du derecho en Corse en allant chercher quelques infos sur les prévisions et prévisionnistes d'ESTOFEX J'ai remarqué que le directeur de l'ESSI le qualifiait de plutôt bon modèle.C est vrai que pour l avoir utilisé récemment il est plutôt correcte en prévision convective et se complète très bien avec Arome et son frère avec les conditions d'IFS.

 

Modifié 19 septembre 2022 par Nico 14

[meteomettra]

Il y a 10 heures, Nico 14 a dit :

Ça ne nous en dit pas plus sur le modèle en lui-même mais je l ai dit sur le topic qui traite du derecho en Corse en allant chercher quelques infos sur les prévisions et prévisionnistes d'ESTOFEX J'ai remarqué que le directeur de l'ESSI le qualifiait de plutôt bon modèle.C est vrai que pour l avoir utilisé récemment il est plutôt correcte en prévision convective et se complète très bien avec Arome et son frère avec les conditions d'IFS.

 

 

Oui, c'est en partie ton post qui m'a fait réagir. Je n'ai jamais pensé utiliser ce modèle, n'ayant jamais rien trouvé sur ces caractéristiques....

Est-ce que "convection permitting model" signifie nécessaire que le modèle est non-hydrostatique ? à mon avis pas, mais je n'en suis pas certain. Non-hydrostatique, je vois très bien ce que cela veut dire, mais pour "convection permitting model" je ne suis pas certain de savoir comment ce terme est employé...

[Pan]

.

Modifié 27 août 2023 par Pansa

[meteomettra]

Il y a 10 heures, Pansa a dit :

Convection permitting model, c'est un modèle non-hydrostatique et pour lequel le pas de grille est suffisamment petit pour ne pas avoir à utiliser de paramétrisation convective afin de simuler de la convection aux échelles appropriéees, ainsi qu'une partie de la circulation interne (downdrafts). Cependant, le modèle intéragit avec d'autres paramétrisations, radiative, microphysique, etc).

merci. mais du coup on est d'accord, qu'on ne peut pas modélisé les orages monocellulaires avec un "convection permitting model" de résolution 4km x 4km sans paramétrisation.... => simulation sans paramétrisation uniquement pour les système convectifs de plus grande échelle dans ce cas donc !?

[Pan]

.

Modifié 27 août 2023 par Pansa

[_sb]

Qu'apporte cette conception par rapport à celle avec paramétrisation de la convection (type AROME ou ICON-D2) ?

 

J'ai lu que cela demandait moins de ressources de calculs et permettait ainsi à des pays en voie de développement de bénéficier de modélisations pertinentes, notamment sur le (très) court terme et typiquement le nowcasting.

 

Quelle aide supplémentaire pertinente est introduite pour la prévision des risques notamment (nowcasting) ?

Question subsidiaire : l'observation reste-t-elle la voie royale pour ce type de prévision à TCT ? (@Pansa 😉 et d'autres)

[Pan]

.

Modifié 27 août 2023 par Pansa
ajouté la réponse à la dernière question de _sb, ajouté des précisions