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.

Salut, désolé c'est simplement un bug de téléchargement. Le script qui récupère le GFS 0.5° s'est bloqué et n'a pas réussi à tout télécharger le 00Z d'aujourd'hui, du coup la courbe est celle du GFS 00Z d'hier (d'où le décalage d'un jour). J'ai vu ce qui clochait, cela ne devrait plus se reproduire

Pour info on a bien atteint 46.9°C à Cordoue entre 15h et 16h ( La valeur de 46.8°C est le max des températures 10min )

A propos de l'altitude : Sur les diagrammes GEFS, l'altitude est l'altitude interpolée les points de maille du modèle utilisés, tandis que sur les prévisions GFS, c'est l'altitude de la ville dans la base de données qui est mentionnée. Pour la différence de coordonnées : En effet il y avait une petite différence quand on clique sur "Bordeaux" sur la page GEFS et quand on y accède par les prévisions, j'ai corrigé ça. Par contre " N 44°51' / W 0°34 pour les prévisions détaillées et 44.9N 0.6W pour les ensembles. ", ça représente le même point, le format d'écriture n'est juste pas le même (ce qui n'est pas terrible en effet). Pour les différences de valeurs : Les valeurs de la courbe de GFS sur le diagramme sur Météociel et les valeurs sur les prévisions IC sont les mêmes puisque les 2 utilisent les données GFS 0.5° (il me semble). On garde la résolution 0.5° ici pour garder une cohérence avec les autres scénarios GEFS. Par contre les prévisions par ville Météociel utilisent les données les plus fines dispo via GFS à savoir le GFS HD à 0.2° et les pics de chaleurs locaux y sont mieux représentés. On peut les voir bien sur les cartes de températures GFS HD. Par ailleurs on dit GFS HD mais c'est le même run GFS mais on a la possibilité d'avoir certains paramètres sur la grille native du modèle (plus précis que 0.25°). Je revérifierai les valeurs des prévisions dans les prochains jours pour être sûr qu'il n'y a pas de problèmes.

Bonjour, C'est un problème de résolution de la grille des modèles je pense. Pour GFS : Les prévisions et cartes utilisent les données GFS HD à savoir 0.2° (environ 20km) Pour GEFS : Les différents scénarios utilisnet les données GEFS 0.5° (environ 50km) Sur les diagrammes, pour garder une certaine cohérence, on utilise les données 0.5° pour à la fois les courbes de GFS (noire) et les courbes des différents scénarios GEFS (couelurs), du coup les données GFS peuvent sembler lissées par rapport aux prévisions et cartes GFS HD. C'est pour ça que ça monte moins sur les diagrammes dans ce cas, Bordeaux se situant à la limite du très chaud en interpolant sur les données 0.5° et dans le très chaud en interpolant sur les données HD 0.2°. C'est d'ailleurs un peu moins visible sur le 12Z, on voit les courbes dépasser les 30°C cette fois. Par ailleurs, il ne faut pas oublier le mode 3h sur les diagrammes GEFS, il permet de voir les températures à 15Z qui sont souvent plus proches des Tx que celles de 12Z ou 18Z. Pour bien comparer il faudrait aussi cliquer sur "Diagramme Ens. GFS" en haut à droite du tableau de prévisions et non cliquer sur la ville Bordeaux sur la page GEFS, il est possible qu'il y ait une petite différence dans le positionnement, je vais voir pour corriger ça.

Hello, on a maintenant quelques infos : La mise en place du GFS// en tant que GFS opérationnel est prévue pour le 20 juin 2017. Là on est toujours en période de "pré-parallèle" avec quelques données dispo, et la période réglementaire des 30 jours du GFS// sera en Avril. On devrait avoir le modèle final à ce moment. Cette nouvelle version a été déjà été approuvée même si les résultats ne sont pas exceptionnels et on n'observe pas de grosses améliorations dans les performances du modèle. Cette nouvelle version prépare par contre l'avenir, elle tourne sur une nouvelle architecture unifiée (NEMS) et prépare l'assimilation de nouvelles données des satellites.

Bonjour, Pour créer une ligne courbe : - Sélectionner l'outil "Ajouter lignes", cocher "Lisser en courbe" - Cliquer sur la carte pour créer les différents points de la courbe. Pendant la création, il y aura des lignes droites entre les points temporairement. - Cliquer avec le bouton droit de la souris pour finir la courbe. Pour changer a posteriori des lignes droites en courbe - Utiliser l'outil "Sélectionner / bouger" - Sélectionner la ligne (il y aura des petits carrés de sélection une fois que la ligne est selectionnée) - Clic droit sur la ligne, et cocher "Lisser en courbe" dans le menu qui apparaît.

Tout a fait il y a un problème avec la courbe GFS avant 240h. C'est du à un problème de téléchargement du GFS0.5 qui se finit pas avant le téléchargement du GEFS 0.5°. Pour une raison inconnue, un transfert de fichier sur 100 bloque sur les serveurs de la NOAA et ça prend beaucoup de retard. Je suis en train de rajouter des timeouts et de régénérer toutes les données, ça devrait être bon d'ici 30mins. Désolé pour ça, merci d'avoir reporté le problème Voilà c'est réparé, il ne devrait plus y avoir de problèmes maintenant :

En effet, il y a un problème, je vais vérifier. C'est juste la courbe GFS 06 qui n'est pas bonne. Le téléchargement de GFS 0.5° sur les serveurs de la NOAA a pris plus de temps que prévu (blocages intempestifs de 1 minute sur quelques fichiers) du coup ça a tout décalé Je vais tout régénérer, d'ici 1h ça sera bon. Désolé pour ce problème ! EDIT : C'est corrigé !

Heu non, c'était peut-être mal écrit mais tu peux publier les images créées avec le logiciel sans restrictions. C'est pour mettre le logiciel en lui-même sur un site ou autre qu'il faut demander l'autorisation. J'ai changé les phrases. La carte de base est une carte France, mais il est possible de changer facilement avec le bouton "Changer Fond", il faut d'abord récupérer/générer une carte du département auparavant.

Désolé, les cartes T850 de UKMO sont fausses, ce sont celles de janvier. Ne pas en tenir compte. Seules les cartes UKMO Z500/pression 72-144h sont correctes.