Sylvain

Ah merci en effet, mes changements ont cassé la version ARPEGE. C'est réparé ! Ok merci si ça peut arriver en vrai, je vais essayer de détecter quand ça arrive et supprimer les valeurs du niveau problématique. Par ailleurs on va changer de serveur bientôt pour les sondages/coupes AROME/ARPEGE, donc il y aura a priori moins de lag à la création.

J'ai finalement trouvé le temps pour regarder ça. Pour filtrer les sondages HD avec beaucoup de valeurs, j'ai donc essayé d'intégrer https://github.com/tsupinie/SoundingFilter, ça marche relativement bien mais j'ai l'impression que c'est toujours pas assez filtré ? Il garde bien la forme des courbes du sondage néanmoins. C'est disponible dans l'option "Sharppy filtré" dans la fenêtre des radiosondages observés. Pour l'autre problème des sondages AROME, j'ai vu plusieurs fois le problème jusqu'à hier soir, où en effet il y avait le paramètre altitude qui redescendait sur un niveau avant de remonter (mais en fait quelques autres valeurs n'étaient pas correctes non plus) Depuis j'ai ajouté du debug, recompilé et plus moyen d'avoir le problème, sur le 00Z, le 06Z et le 12Z actuel. La progression des pressions et des altitudes sont cohérentes. Je ne sais pas si le problème a bien été corrigé ou si c'est quelque chose qui arrive de temps en temps seulement, ou un problème avec un timing bien précis lors de l'extraction des données, donc je vais continuer à surveiller. Pour le géopotentiel, je passe du géopotentiel à l'altitude géopotentielle en divisant par 9.80665. Il y a ensuite une petite différence entre l'altitude géopotentielle et l'altitude géométrique mais c'est négligeable. Quand il n'y pas le bug, ça a l'air de bien correspondre entre les niveaux "altitudes" et les niveaux "à pression constante" disponibles pour AROME.

Merci pour les remarques. Pour le filtre, je n'ai pas l'air d'avoir un filtrage inclus dans ma version. Est-ce-que c'est celui là en externe : https://github.com/tsupinie/SoundingFilter ? Pour le problème d'altitude qui redescend, à mon avis c'est un bug quand on passe des données d'AROME "altitudes +20m, +100m etc." aux données d'AROME "aux niveaux de pression". Ca pourrait être un problème de différence entre géopotentiel et altitude géométrique. J'utilise une constante pour passer de l'un à l'autre.

Hello, On a déjà eu plusieurs demandes sur ce sujet mais en fait en regardant ce qui se passait : Il existe bien une petite ville appelée Donetsk en Russie, qui se trouve à la frontière historique : https://www.google.fr/maps/place/Donetsk,+Oblast+de+Rostov,+Russie/@48.3287452,39.9180211,13z/data=!3m1!4b1!4m5!3m4!1s0x411e3d1d7c36553f:0x21095bc8f8beb59a!8m2!3d48.3321569!4d39.9653797 https://www.meteociel.fr/previsions/72273/donetsk.htm << en regardant en bas les coordonnées on voit que c'est bien cette ville. En ce qui concerne la ville d'Ukraine dans la base elle est enregistrée avec une apostrophe : https://www.meteociel.fr/previsions/76579/donets_k.htm Dans Wikipedia on retrouve cet apostrophe ici : https://en.wikipedia.org/wiki/Donetsk (version romanisée de l'écriture ukrainienne) On n'a pas mis à jour la base de données des villes mondiales depuis des années, donc c'est comme ça depuis un moment. Vu que ça a l'air de poser des problèmes, il faudrait que ça soit précisé ou peut-être ne pas avoir à mettre l'apostrophe pour trouver la ville ukrainienne.

On utilise bien le nouveau postprocesseur UPP. Le bug de la génération de carte est fixé. C'était un changement de signe sur la composante V qui a sauté à un moment, maintenant les flèches de storm motion devraient être ok. J'ai changé aussi le titre. Merci d'avoir remonté le problème donc

Hello, Sur Météociel, ces champs (storm motion et helicity) ne sont pas calculés à la main mais c'est le post processeur de WRF qui les calcule, on ne fait que les afficher. Donc a priori pas de problème dans les formules. Sur la carte il y a donc la direction du storm motion avec les flèches de flux et la couleur pour l'"hélicité" qui est en fait le "Storm relative helicity" (la traduction avait l'air ok mais peut être pas habituelle en météo ?). Ce n'est peut être pas idéal, dites-moi si une autre présentation serait mieux. Dans le GRIB final on a donc : rec 359:181731828:date 2020072218 HLCY kpds5=190 kpds6=106 kpds7=7680 levels=(30,0) grid=255 3000-0 m above gnd 3hr fcst: HLCY=Storm relative helicity [m^2/s^2] rec 360:182102250:date 2020072218 HLCY kpds5=190 kpds6=106 kpds7=2560 levels=(10,0) grid=255 1000-0 m above gnd 3hr fcst: HLCY=Storm relative helicity [m^2/s^2] rec 361:182472672:date 2020072218 USTM kpds5=196 kpds6=106 kpds7=15360 levels=(60,0) grid=255 6000-0 m above gnd 3hr fcst: USTM=u-component of storm motion [m/s] rec 362:182966538:date 2020072218 VSTM kpds5=197 kpds6=106 kpds7=15360 levels=(60,0) grid=255 6000-0 m above gnd 3hr fcst: VSTM=v-component of storm motion [m/s] (Ce n'est pas dit ici mais dans le post process WRF c'est le SRH pour les cellules à moteur droit qui est calculé) Après on ne peut pas exclure un problème soit dans le postprocesseur WRF, soit dans le code qui affiche les données. Le code de génération des cartes WRF est full custom (juste la lib wgrib pour décoder le grib) et commence à être assez vieux et cette carte n'a pas l'air d'être beaucoup utilisée donc un bug s'est peut-être glissé à un moment lors des mises à jour du modèle ou autre. Voilà j'espère que ce message aura levé des ambiguïtés sur quelques points. J'essaierai de jeter un oeil sur le code prochainement pour voir s'il y a un truc évident.

@nico_37, peu de personnes doivent utiliser cette méthode d'envoi ici , je t'invite à envoyer un message via le formulaire de "Contact" en bas à droite du site de Météociel et on pourra t'aider pour cela.

Non rien de tout ça, tous les paramètres disponibles sont listés là : https://www.metoffice.gov.uk/binaries/content/assets/metofficegovuk/pdf/data/european_model_data_sheet_lores1.pdf

Ce sont les RR brutes, on n'a pas accès à des champs de RR corrigées. Pour les RR corrigées, je n'ai pas trouvé d'algorithme pour corriger les données (même si en effet les RR ont l'air un peu surestimées parfois) Les seules références à une correction des RR d'Euro4 sont chez Kachelmannweather ou ils disent : Qui se traduit en Du coup ça serait ce site qui ferait une correction par eux-mêmes, et non le Met-Office. Mais s'il y a un endroit où un algorithme est décrit par le Met-Office, je suis preneur bien sûr :) Sylvain

La résolution du modèle était déjà de 13km avant le changement vers FV3. Tous les champs sont disponibles à la résolution 0.25° (ou 0.5° ou 1.0°) sur une grille classique 1440x721. Une sélection de champs est disponible sur une grille gaussienne 3072x1536 ce qui donne environ 0.117° (proche des 13km natif du modèle). C'est ce qu'on appelle (peut-être a tort) les champs HD pour la température et les précipitations. Cela n'a pas changé entre la version précédente et actuelle au niveau de la distribution de la NOAA. Donc aucun changement sur les sites.

Oui, il y a en effet un problème sur certains serveurs de la NOAA/NCEP depuis hier soir, ce qui ralentit beaucoup voire stoppe les téléchargements parfois. La courbe noire n'était pas "synchronisée" avec les autres scénarios car le téléchargement du GFS n'était pas fini avant le GEFS, donc ça affichait le run GFS noir de la veille. J'ai switché vers les serveurs qui marchent correctement et j'ai envoyé un mail à la NOAA, ils avaient déjà l'air au courant du problème. Tout devrait être ok ce soir.

En effet, et le problème a été corrigé ce soir. C'était les cartes classiques (statiques) qui étaient légèrement décalées juste pour ce modèle.

Non, juste pour info : ce sont bien les relevés réels sans interpolation , désormais on bénéficie de radiosondages (qu'on a appelé HD) super précis qui donnent les mesures toutes les 1 à 2 secondes d'ascension, donc tous les 10m d'altitude environ, ça donne ce tableau de plus de 3000 valeurs souvent, au lieu de max 50-100 auparavant.

Désolé, il y a un bug sur les TX/TN des cartes classiques d'ARPEGE après 78h (ça doit prendre d'anciennes TX/TN), il faut regarder heure par heure ou aller voir en attendant les cartes zoomées dynamiques où il n'y a pas le bug. Je vais corriger ça d'ici ce soir. En gros ça provient du moment où on avait les échéances de 3h en 3h après 78h jusqu'à la fin (pendant 2 semaines), et ça continue à prendre en compte les tx/tn des échéances qui n'existent plus après 78h.

En effet, il y avait bien un problème, la carte "accumulation des précipitations" de ICON-EU (et de COSMO-DE en fait) donnait la somme des précipitations et de la neige (ce qui faisait qu'on voyait environ le double si toutes les précipitations étaient sous forme de neige). J'ai corrigé le problème et ça s'appliquera dès les prochains runs (15Z). Rien vu de spécial pour une éventuelle exagération des précipitations/précipitations neigeuses par contre.