Sylvain

Hehe c'est juste en fait 2 ou 3 fichiers manquants de l'ensemble GEFS (à +60h) qui empéchait le programme de continuer. Il n'y a pas de problème avec le scénario GFS

Le GFS12z ne correspond à aucun des scénarios d'ENS. Il faut le voir comme un run totalement indépendant qui n'est pas représenté sur les courbes/cartes ENS.

Heu, ça c'est seulement pour Wetterzentrale qui affiche toujours le 00z

Le GEM 12Z est encore mieux avec un flux de Nord-Est vers la fin (je rappelle que le 12Z ne sort que jusqu'à 120h) http://www.meteociel.fr/modeles/geme_carte...=108&mode=0 Avec du -10° à 850hPa

Quelques flocons liées à la pluie faible vers les hauteurs du Boulonnais (62). Rien d'important pour le moment. La température est en baisse (2.3°c)

C'est bizarre, il y a eu un coup de vent cette nuit qui n'était pas vraiment prévu. Une rafale à 130km/h relevée à Boulogne sur mer à 4h, et 133km/h au Cap-Gris-Nez. Loin d'être négligeable.

Tiens, je viens de voir ce sujet /emoticons/tongue@2x.png 2x" width="20" height="20"> Oui c'est automatique, et c'est bien écrit en bas de la page. C'est peut être pas terrible comme prévisions (je le reconnais) mais ça donne un aperçu rapide Ce problème vient de la base de données qui était en rade lors des moments de forte affluence. Le programme qui fait les cartes a essayé d'y accéder et n'a pas pu retourner de valeur donc il a rempli les tableaux avec des 0. Donc en effet, comme les températures sur GFS sont données en Kelvins donc par la suite on doit soustraire 273, d'où la valeur /emoticons/wink@2x.png 2x" width="20" height="20"> Je vais empêcher la génération des cartes quand il y a un problème de base de données, ça limitera la casse la semaine prochaine qui risque d'être encore très agitée /emoticons/smile@2x.png 2x" width="20" height="20">

UKMO 12z n'est pas loin d'une deuxieme descente non plus.. Un petit décalage à l'ouest serait cool http://www.meteociel.com/modeles/ukmo2.php...&carte=1021

Heu maintenant c'est celles du 06z. J'ai rajouté un petit élément sur la page pour savoir de quel run les données proviennent, parce que c'est vrai que le "Reactualisé à" peut prêter à confusion. J'ajoute qu'en ce moment, on a certains problèmes de base de données, donc les mises à jour des prévis peuvent être retardées, donc il faut faire attention

Comme le Nogaps 18Z d'hier, le Nogaps 6Z d'aujourd'hui a l'air de montrer une nouvelle descente à 144h : http://www.meteociel.fr/modeles/nogapse_ca...=144&mode=0 Avec des pressions et géopotentiels qui remontent sur le Groenland.

Pour les ensembles de ECMWF, ils ne sont malheureusment pas disponibles gratuitement, mais on a toujours un lien, pour la ville de De Bilt, une ville des Pays-Bas : http://www.knmi.nl/exp/pluim/Data/PLUIM_06260_NWT.png

Juste une précision, le run de GEM de 12z ne va jusqu'à 120h /emoticons/tongue@2x.png 2x" width="20" height="20"> Seul le run de 0z va jusqu'à 240h.

La seule différence entre les 2 cartes est la résolution, la carte Europe est en 1.0° et la carte France en 0.5°. Je vais regénérer les deux cartes et regarder s'il y a un problème. Apparement c'est plutôt le 0.5° qui a raison. Mais de toute façon ce genre de carte à 180h n'est pas fiable du tout.

Surtout que c'est possible avec la version "daily" de CFS, qui va jusqu'à neuf mois. J'ai mis un traitement automatique tous les jours pour générer les cartes jusqu'à une échéance de +6700h. Mais biensûr il faut prendre ça à la rigolade : http://91.121.0.76/modeles/cfs/run/ ( les runs ont 8 jours de retard comme pour le CFS mensuel ) Je n'ose pas le mettre sur le site

Toutes les 6h, le modèle GFS génère 16 runs : - le run déterministe, c'est le run principal de GFS avec la résolution la plus grande (0.5°) - les runs de l'ensemble GFS (GEFS) qui sont avec une résolution un peu moins grande (1.0°): -> Le run de contrôle, qui utilise les mêmes données de départ que le run déterministe. -> 14 runs perturbés, c'est à dire un run dont les données de départ ont été légèrement modifiées pour contrer les erreurs d'observations. Donc le run déterministe et le run de contrôle devrait être les mêmes, mais ils ne sont pas à la même précision. Or dans l'intégration numérique du modèle, cette différence de précision se fait sentir et donc on peut avoir un très grand écart entre le run de contrôle et le run principal/déterministe. Maintenant je ne sais pas s'il utilise exactement la même version du modèle pour le run principal que pour les runs d'ensemble, mais théoriquement il n'y a pas de raison d'en prendre des différentes.

Juste un petit détail, ce que tu montres c'est le run n°7 de l'ensemble GEM, mais c'est un scénario possible également /emoticons/smile@2x.png 2x" width="20" height="20">

Petite clarification : Il y a le run de GFS déterministe et les 11 runs ensemblistes de GFS (1 de controle + 10 pertubés). Ils sont tous différents. Ca fait donc 12 scénarios en tout pour GFS. Le run de contrôle de GEFS, c'est la même chose que GFS (pas de perturbations), mais effectué à une résolution plus basse, donc il y a des différences avec le run opérationnel de GFS et le run de contrôle. Avant, la "courbe bleue" des diagrammes était bien le run de GFS, parce qu'il n'y avait pas de run de contrôle. Et d'ici ce soir ou demain, on va avoir 4 scénarios de plus (perturbations de 11 à 14) "officiellement", ça fera donc 16 scénarios en tout.

En fait, il sort deux fois par jour quand même. Le run de 0z ( dispo vers 6h ) : échéance de 0 à 240h Le run de 12h ( dispo vers 18h ) : échéance de 0 à 120h Mais en effet, seul un run 0-240 par jour. Info ici : http://www.meteo.ec.gc.ca/grib/Low-resolution_GRIB_f.html Par contre, le site de Wetterzentrale a l'air d'afficher seulement le run de 0Z, avec un décalage de 12h (voir le 240h sans données à la fin )

oops En effet il y a un problème pour les précipitations pour les échéances 6,12,... 84 heures, ce sont les précipitations en 6h divisée par 2. Pourquoi ce problème ? Il se trouve que les précipitations sur 3h sont seulement dispo dans les données des échéances de 3, 9, 15 etc... Ca serait bien d'avoir les prec. 3h aussi dans le reste mais pour des raisons de compatibilité descendante, GFS n'a pas ces données... Deux exemples : pour 93h : 594:192792848:d=2006120218:APCP:sfc:90-93hr acc:NAve=0 595:193150322:d=2006120218:ACPCP:sfc:90-93hr acc:NAve=0 pour 96h : 594:193278658:d=2006120218:APCP:sfc:90-96hr acc:NAve=0 595:193636132:d=2006120218:ACPCP:sfc:90-96hr acc:NAve=0 Et donc pour trouver 93h-96h, il faudrait faire APCP(96h)-APCP(93h), ce qui nécéssite d'avoir les deux données en parallèle. C'est ce que doit faire Wetterzentrale. Pour l'instant c'est très ennuyeux à faire dans le système courant, étant donné qu'il y a 2 à 3 ordinateurs qui génèrent les cartes une échéance différente en même temps... Je vais voir ce que je peux faire, ça ne fait en effet pas très sérieux de laisser la situation comme ça. Une idée serait peut être de forcer un ordinateur à faire 2 échéances à la suite, pour avoir la donnée pour soustraire à portée de main... Ceci ne concerne bien sûr que les cartes précipitations et précipitations convectives et accessoirement le "risque de neige" qui est aussi un champ de GFS sur 3h ou 6h. Désolé pour ce petit désagrément /emoticons/biggrin@2x.png 2x" width="20" height="20">

Bien sûr que c'est un bug, ça arrive rarement mais ça arrive.. Désolé pour ce problème La raison est que pour une raison bizarre, le programme n'a pas téléchargé le fichier en entier et il complète avec des nombres farfelus...

Oui c'est un bug ! Pour s'en rendre compte, il faut regarder l'échéance d'avant et d'après et/ou les températures Désolé pour la fausse joie

D'ailleurs, pour information, le modèle GEM vient d'être beaucoup amélioré, avec une meilleure résolution, une meilleure assimilation des données. Cela vaudrait peut-être donc le coup de regarder si cette amélioration se voit dans les runs. http://www.msc-smc.ec.gc.ca/cmc/op_systems/recent_f.html

C'est juste un mini-bug de réception des données Ca va disparaître dans quelques minutes avec le 6z Biensûr quand il y a des données bizarres comme celles-ci , il faut les ignorer, ça arrive parfois.

Voilà pour Evreux c'est reglé, surement une erreur de codage. Il y avait -2.6° au lieu de 12.6° pour la Tn de 18 TU. Merci d'avoir noté ça /emoticons/tongue@2x.png 2x" width="20" height="20"> Et sinon oui il arrive de rater le coche des fois

Oui désolé pour ces observations farfelues, on essaye de les supprimer le plus vite possible, mais il se peut que quelques uns nous échappent Certaines personnes pensent que c'est un jeu de mettre de la neige ou du -10°C sur la carte en été... Si par contre cela vient de stations synop/metar, il se peut qu'ils reportent des valeurs bizarres. En ce moment, c'est souvent en Italie que l'on trouve le plus de problèmes avec des reports de pluie de 10 voire 100mm en une heure. Peut être une spécialité du pays pour les synops italiens Ce printemps on a eu la station de Gourdon qui reportait constamment des valeurs inférieures à -10°c, problème de sonde ou de transmission. Et aussi quelques metars reportent de la pluie le soir alors qu'il n'y a rien du tout, genre à Chambéry ou Deauville (spécialistes en la matière). Il est difficile de mettre en place des techniques de filtrage, en effet on pourrait manquer des reports véritables.. La meilleure façon de se faire une idée est de regarder les observations des alentours, les images sats et le radar pour voir si l'observation est plausible.