Sylvain

Les données sont bonnes a priori. Ce ne sont plus les données master depuis janvier parce que le serveur nomad ets en rade mais les données 0.5° classiques. En fait je vois plusieurs possibles raisons pour le problème évoqué : Déjà la limite est 1000hPa, on ne voit pas ce qu'il se passe après 1000hPa. Si la pression de la surface est supérieure à 1000hPa il en manque un bout Sinon il faut prendre en compte également l'altitude nominale de GFS 0.5° pour ce point, et si cette altitude correspond par example à 970hPa, ce qui est après 970hPa est faux puisque pour le modèle c'est en dessous du sol. Autre raison peut être : les températures 2m ne sont pas tirées directement des températures données pour chaque pression, mais il y a peut être un traitement particulier pour la radiation en ciel clair par exemple qui ferait baisser la température. Les températures par pression sont dites "free-air". Apparement y'a des gens qui ont fait des études la dessus http://www.agu.org/pubs/crossref/2005/2005JD006150.shtml Il faudrait peut être indiquer l'altitude nominale de GFS pour le point sur les sondages ?

En faisant un sondage sur Paris juste à la fin de la perturbation de vendredi, on voit qu'il y a quand même l'iso 0° vers 680m , ce qui n'est pas rien... Même avec des precipitations intenses et une forte isothermie, ça va pas être facile. http://www.meteociel.fr/modeles/sondagegfs...92_286_63_1.png

Oui je ne comprends pas trop pourquoi GFS ne met pas de la neige dans ces cas là. On dirait que le champ "CSNOW" est devenu plus strict depuis le changemenet du 26 septembre... Ptet que les coupes/sondages donnent un passage > 0°C ?

Plein d'infos sur le nouveau système ATD utilisé : ftp://www.wmo.int/Documents/SESSIONS/CBS....d06-1(2)_fr.pdf "Les messages SFLOC, utilisés jusqu'à maintenant pour diffuser la position des éclairs en code SFERIC sur le SMT, ne conviennent plus du fait qu'ils sont bien trop rudimentaires pour la haute précision des positions indiquées actuellement et qu'il est impossible de signaler le nombre de positions qu'indique le nouveau système. C'est pourquoi le Royaume-Uni souhaite faire passer les utilisateurs actuels des messages SFLOC à de nouveaux messages qui tiendront compte de la précision des positions désignées." ou alors http://www.wmo.ch/pages/prog/www/IMOP/publ...(7)_Nash_UK.pdf Bon alors c'est quoi ces nouveaux messages?

Si (si c'est bien de la température dont tu parles) : Dans le Top 3: 1) Cannes 20.3 °C 2) Bastia 19.1 °C 3) Cap Sagro 17.8 °C

Finalement j'ai trouvé dans le code du post process : SUBROUTINE CALGUST(LPBL,ZPBL,GUST)C$$$ SUBPROGRAM DOCUMENTATION BLOCKC . . . C SUBPROGRAM: CALGUST COMPUTE MAX WIND LEVEL C PRGRMMR: MANIKIN ORG: W/NP2 DATE: 97-03-04 C C ABSTRACT: C THIS ROUTINE COMPUTES SURFACE WIND GUST BY MIXINGC DOWN MOMENTUM FROM THE LEVEL AT THE HEIGHT OF THE PBLC [...] DO 20 J=JSTA_M,JEND_M DO 20 I=2,IM-1 L=LPBL(I,J) IE=I+MOD(J+1,2) IW=I+MOD(J+1,2)-1 USFC=D25*(U10(I,J-1)+U10(IW,J)+ U10(IE,J)+U10(I,J+1)) VSFC=D25*(V10(I,J-1)+V10(IW,J)+ V10(IE,J)+V10(I,J+1)) SFCWIND=SQRT(USFC**2 + VSFC**2) U0 = D25*(U(I,J-1,L)+U(IW,J,L)+ U(IE,J,L)+U(I,J+1,L)) V0 = D25*(V(I,J-1,L)+V(IW,J,L)+ V(IE,J,L)+V(I,J+1,L)) WIND=SQRT(U0**2 + V0**2) DELWIND=WIND - SFCWIND DELWIND=DELWIND*(1.0-AMIN1(0.5,ZPBL(I,J)/2000.)) GUST(I,J)=SFCWIND+DELWIND Comprenne qui pourra On voit déjà que la valeur max de rafale est composée du vent de surface (SFCWIND) + un vent additionnel (DELWIND), qui est calculé en fonction du geopotentiel du PBL (Planetary Boundary Layer : limite de basse couche) et de la différence du vent de surface et du vent à la PBL.

J'ai pas réussi à trouver dans le code Ni sur les docs. Désolé /emoticons/biggrin@2x.png 2x" width="20" height="20">

J'avais posté un peu d'info sur ça dans un autre forum : Apparement c'est fini parce que le MetOffice a changé leur système et après avoir demandé à plein de monde (tu parles! seulement aux institutions et aux sites commerciaux surement...) ils ont décidé que c'était inutile de recréer qqch pour continuer à donner ces infos, donc voilà, surement que les infos existent maintenant en format BUFR, mais ça doit être envoyé par des canaux dont on n'a pas l'accès... On peut écrire au metoffice pour savoir peut être ? Petits détails ici : http://groups.google.fr/group/uk.sci.weath...163f285460130f9 Sur ECOMET on voit que c'est payant on dirait, et ils ne parlent plus de SFUK : http://www.ecomet.eu/members/UK.htm Lightning Detection The Met Office system which produces the lightning location data is known as Arrival Time Difference (ATD). The ATD system is an automatic thunderstorm location network comprising seven autonomous outstations - Keflavik (Iceland), Lerwick (UK), Camborne (UK), Norderney (Germany), Korppoo (Finland) , Akrotiri (Cyprus) and Gibraltar - sensing lightning flashes over a wide and variable geographical area. The system locates lightning by timing the arrival of radio waves generated by individual lightning strokes at the above outstations. The differences in the arrival times of these strokes at the outstations are used to calculate the location of the lightning. The system is vertically polarised to detect mainly cloud to ground lightning. Bulletins are in ASCII format giving latitude and longitude of detected flashes plus an estimate of the accuracy of the fix. Fees, including delivery by ftp, are fixed at: Near global - 40,000 EUR European service area - 14,500 EUR North Atlantic service area - 14,500 EUR Customised areas can be provided but the minimum fee is 5,000 EUR. Sinon on a toujours blitzortung avec les données brutes qui donne ça sur une carte : http://meteociel.fr/cartes_obs/foudreb.php Mais ça m'a l'air être plein de parasites même si ils disent que c'est triangulé et tout ça... Il y a strikestar aussi : http://195.214.200.121/index.aspx?id=40 Le mieux ça serait de faire notre propre système avec des bolteks sur la France, l'Angleterre et les autres pays frontaliers, mais j'ai l'impression de la couverture ne va pas être parfaite Ca va faire mal en été tout ça. C'est la fin des "croix violettes" !

On essaye de modérer comme on peut... Mais bon le Metar de Chateauroux ne doit pas mentir lui ! Neige à 21h30

Désolé pour la non disponibilité des coupes GFS sur Météociel, c'est le serveur américain Nomad3 qui a planté, et ils mettent du temps à reparer les disques durs. C'est le seul endroit où l'on peut trouver les "Master" GFS 0.5° avec le plus de données ( le plus de couches disponibles ). Donc on attend http://nomad5.ncep.noaa.gov/DOC/announce.txt Je vais essayer de faire un système de "backup" quand le serveur Nomad n'est pas disponible, et il prendrait les données 0.5° normales. C'est plus long et plus compliqué malheureusment

C'est juste dommage que les données GRIB pour NOGAPS ne sont pas dispo jusqu'à 180h, pour pouvoir les afficher sur Meteociel ou Wetterzentrale. J'ai envoyé un mail pour demander et je n'ai jamais eu de réponse /emoticons/happy@2x.png 2x" width="20" height="20">

Là entre autres : http://meteociel.fr/modeles/ukmo2.php?ech=0&carte=2000

J'ai supprimé l'obs, parce que "neige forte" et "gros flocons" c'est impossible.

Nope, je ne sais pas pourquoi exactement ça fait ça... C'est pas un bug de génération de carte en tout cas. Ca a l'air d'être dans le modèle. Ce paramètre n'est pas directement calculé dans le calcul du modèle, il est calculé en post process (le tourbillon absolu, le CAPE, CIN également). La formule doit être assez compliquée et il est possible que pour quelques points de la maille, il y ait un problème de précision, une division par un nombre proche de zéro ou qqch du genre. Après, il faut savoir que le modèle tourne sur une grille Gaussienne 0.3°, et donc l'interpolation à une grille "Lat/Lon" 0.5° ou 1.0° cause peut-être ce genre d'inconvénients parfois ! Par exemple, lors du changement des gfs masters de 0.5° en Gaussienne 0.3° en septembre dernier, j'ai été embêté parce que les valeurs du PVU à la longitude 0° étaient complétement fausses à cause de cette nouvelle interpolation... Du coup maintenant je ne prends jamais en compte les valeurs 1.5PVU ou Tourbilon abs sur la longitude 0° qui passe malheureusment en plein milieu de la France, et je fais la moyenne des 2 valeurs voisines qui sont correctes C'est peut être un problème du même genre ici...

Heu, en fait je viens de voir le problème : les coordonnées pour Paris (sur la page diagrammes) sont fausses et beaucoup trop au Nord. Du coup ça pointe sur un point de la mer du Nord avec des températures forcément plus douces /emoticons/biggrin@2x.png 2x" width="20" height="20"> En cliquant directement sur la carte, on trouve le bon diagramme par contre ! Et puis c'est un peu moins précis que les cartes GFS 0.5° aussi parce que les ensembles sont en 1.0°, mais ça on peut rien y faire /emoticons/biggrin@2x.png 2x" width="20" height="20">. Voici le lien corrigé : http://91.121.94.83/modeles/gens/graphe_en...amp;ville=Paris

Bon j'ai reussi à remettre une autre source pour le GFS 12z /emoticons/sad@2x.png 2x" width="20" height="20"> il arrive now. Et la NOAA a reglé le problème, le GEFS 12z arrive également. Sinon, le début d'ECMWF n'est pas mal non plus on dirait ! Après c'est un peu moins bien mais bon... http://www.meteociel.com/modeles/ecmwf.php...ode=1&map=0

A quelle heure sort le CEP ? Il va commencer maintenant jusqu'à 20H20 environ. A part sur méteociel quelqu'un pourrait-il me dire ou l'on trouve les scénarios GEFS ??? Je ne sais pas s'ils sont sur wetterzentrale... Sachant que les données brutes sont absentes totalement du serveur de la NOAA, je ne sais pas si on les aura sur un site pour l'instant /emoticons/biggrin@2x.png 2x" width="20" height="20"> A moins qu'il existe une autre source, mais je ne pense pas.

A propos du run d'ECMWF de ce soir. Il est totalement plus chaud que les scénarios des scénarios de l'ensemble après Jeudi ! A vous de juger pour De Bilt : http://www.knmi.nl/exp/pluim/Data/PLUIM_06260_NWT.png

Ouaip ça va être utile les cartes de l'ARL pour voir. A première vue pas de différences notables ! Par contre je pense qu'ils utilisent les données "simples" 1.0° avec des niveaux de pression de 25hPa en 25hPa au début puis de 50hPa en 50hPa. Moi, pour les coupes et sondages GFS, j'utilise les données "gfsmaster" 0.5°, avec niveaux de pression de 25hPa partout (d'où la différence pour le point de rosée à 175hPa je pense). Par la suite je pourrais éventuellement faire la même chose avec NMM, mais ça risque d'être plus compliqué encore... Pour la carte rafales de NMM, je ne sais pas du tout d'où ça vient, c'est juste un champ "GUST" dans les données GRIB /emoticons/biggrin@2x.png 2x" width="20" height="20"> Donc je prends la direction du vent 10m et la vitesse GUST. Faudra voir ce que ça vaut ! Je vais essayer de regarder dans les sources de wrfpost ce soir pour voir comment c'est calculé, mais c'est en fortran avec des noms de variables peu explicites...

Merci à tous pour les encouragements En ce qui concerne le problème (merci JS et Hailstone de vous être penchés sur la question !) : Je ne m'y connais pas assez pour pouvoir diagnostiquer tout ça météorologiquement, je me contenterai donc d'expliquer la partie technique : Pour tracer les courbes je reprends exactement les mêmes données que pour les coupes GFS, c'est juste une autre représentation des données en fait. Pour les tests j'ai comparé la température des coupes et la courbe sur le sondage, ça concorde (à quelques dixièmes de degrés près). Maintenant peut être que le calcul du point de rosée et de la température du thermomètre mouillé n'est pas exact. J'ai utilisé les formules que j'ai trouvé dans les scripts sur cette page : http://www.srh.noaa.gov/elp/wxcalc/rh.shtml Comme ça vient de la NOAA j'ai supposé que c'était correct. Le calcul de la wetbulb est assez compliqué puisqu'il faut faire des itérations pour arriver au résultat. Dans mon code ça donne ça : http://www.meteociel.com/calcultemp.txt (GFS ne donne que la température et l'humidité relative pour chaque niveau de pression) Le truc que je me demande, c'est est-ce-que ces formules sont valables pour tous les niveaux de pression, et pas seulement pour des stations au sol par exemple. J'ai rajouté temporairement la valeur de l'humidité relative de GFS dans les sondages pour pouvoir contrôler. Le problème vient peut-être aussi du fait qu'il y a eu des absences de données aujourd'hui, et toutes les échéances > 30h était du run de mercredi 18Z. Ca peut fausser les résultats car les échéances ne se suivent plus, il faut bien regarder la date écrite en bleu sur l'image générée (qui est du coup totalement en désaccord avec la carte GFS 0.5° où l'on clique). J'ai relancé la récupération des données du 12z d'aujourd'hui jusqu'à 180h (le 18Z n'est pas dispo on dirait...). J'espere que cette récupération de données sera moins chaotique dans les jours qui suivent... (oops et j'ai oublié de mettre la suppression automatique des images de chaque run aussi... je ferai ça demain) Ou comme JS dit, GFS est peut-être nul en fait Sylvain

Et pour info, la carte SST de Meteociel http://www.meteociel.com/accueil/sst.php, utilise les mêmes sources que Medspiration, d'une précision d'environ 2km si je me rappelle bien.

Un lien interessant pour savoir ce que les gens de la NCEP pensent des modèles quotidiennement : http://www.hpc.ncep.noaa.gov/discussions/pmdepd.html. En anglais et ça concerne les Etats Unis, mais ça peut être utile pour nous aussi ...

Sorry, je corrige ça, j'étais en train de tester les cartes Nord Hemisphere d'UKMO, et ça a pris les mauvaises données... D'ici 15 minutes les bonnes cartes seront regénérées et disponibles avec les nouvelles cartes NHem !

A mon avis le problème c'est la résolution différente entre le run déterministe (0.5°) et les scénarii de l'ensemble (1.0°), ce qui fait que l'altitude des points évalués par les modèles n'est pas la même dans les deux cas. Cela doit être très visible dans des zones de montagne.

Si on anime les cartes ECMWF nord Hémisphère : http://www.meteociel.fr/modeles/ecmwf.php?...ode=1&map=1 On voit qu'il y a un mouvement de rotation, qui entraîne les bas géopotentiels du Nord vers le Sud de manière continue... Si ça pouvait rester comme ça tout l'hiver /emoticons/wink@2x.png 2x" width="20" height="20">