.

[Cers]

@Smercz @Damien49 sur la carte storm motion de Keraunos, la vitesse (couleur + norme du vecteur) et la direction (sens du vecteur) de déplacement des cellules sont représentées.

 

Je cite Keraunos dans l'une de ses notes techniques, que j'avais téléchargé :

 

"Ce champ présente la vitesse et la direction de déplacement des cellules orageuses (Storm
Motion), sous forme de vecteurs et de plages de couleurs libellées en km/h. Ces éléments sont
calculés sur la base des profils verticaux simulés par le modèle."

 

Valeurs Signification générale :

< 40 km/h Déplacement lent
40 à 70 km/h Déplacement standard
70 à 100 km/h Déplacement rapide
> 100 km/h Déplacement très rapide

Modifié 22 juillet 2020 par Cers

[_sb]

À moins que cela ait changé (j'en étais resté à la 3.x), l'output standard (WPS+WRF) ne calcule pas directement ces paramètres, c'est du post-processing.

Ce n'est pas le « pack WRF » qui génère les cartes, j'ignore comment meteociel s'y prend (ncl ? probable puisque le langage est bien intégré à l'environnement WRF)

http://www.ncl.ucar.edu/Document/Functions/wrf.shtml

Il me semble moins hasardeux de personnaliser un script de génération de carte en y introduisant involontairement une erreur.

En revanche, je ne vois pas d'erreur chez Keraunos. On peut estimer que la carte est incomplète ou peu pertinente mais ce n'est pas une erreur.

Je ne sais pas si c'est plus clair...

 

EDIT : Ma mémoire me joue peut-être des tours, il me semblait qu'on pouvait modifier les inputs entre modules de calculs mais je ne vois rien de tel sur la doc. Ton incompréhension vient peut-être de  là.

De mon côté, la plupart des erreurs sur les cartes que j'ai pu générer ont une origine dans le script de génération, un - ou un + « oublié », c'est malheureusement fréquent. Je m'en aperçois lors des tests avant de mettre en production mais ça arrive de passer au travers.

En revanche, je ne comprends pas le problème que vous voyez avec les cartes de Keraunos ?

Modifié 22 juillet 2020 par _sb

[Pan]

.

Modifié 26 août 2023 par Pansa

[_sb]

il y a 4 minutes, Smercz a dit :

Le problème peut venir de cette interface qui calcule les champs, mais ces scripts sont éprouvés et testés. Je pense donc à de l’erreur humaine, lors de la manipulation de ces scripts.

 

Finalement, nous arrivons à la même conclusion.

 

Ce ne serait pas la première fois que des bugs sur une carte ou sur la page se révèlent : lors d'IFS testing de juin et de GFS 16 //, je suis allé voir sur meteociel comment ils les présentaient et de nombreuses petites erreurs étaient présentes au démarrage qui ont été corrigées quelques jours après (IFS présentées comme la version en test alors que c'était l'opérationnel sur les "archives", présence de GFS 14 legacy dans le chapeau, etc). J'ignore comment ils testent avant de mettre en prod. Là, ce serait une erreur plus gênante.

[Pan]

.

Modifié 26 août 2023 par Pansa

[Cers]

il y a 3 minutes, Smercz a dit :

On ne sait pas ce qui est vraiment représenté ni par quelle méthode ça a été dérivé, de plus une terminologie non standard (juste “helicité” par exemple) est utilisée...

 

Savent ils eux mêmes ce qu'ils ont représenté ? 😀

 

Ok je sors

[Sylvain]

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.

 

Modifié 23 juillet 2020 par Sylvain

[_sb]

Merci de cet éclairage.

Ne serait-il pas opportun d'enlever cette page le temps de pouvoir introspecter le code ? Ou du moins d'y ajouter un avertissement ?

[Pan]

.

Modifié 26 août 2023 par Pansa

[Pan]

.

Modifié 26 août 2023 par Pansa

[Cotissois 31]

Tu es sûr que sur les versions publiques, on a le choix du post-traitement ?  On a le choix du coeur et/ou des paramétrisations mais je ne me rappelle pas avoir un choix sur le post-traitement.

[Pan]

.

Modifié 26 août 2023 par Pansa

[Cotissois 31]

Ah, j'avais pas compris le post-traitement comme çà. Je pensais à un post-traitement intégré qui sort dans les fichiers de sortie. Là du coup il faut se faire son propre post-traitement avec son logiciel préféré. Il faut bien bien s'y connaître pour utiliser les bonnes routines alors, voire coder soi-même des formules pour être sûr du résultat.

[Pan]

.

Modifié 26 août 2023 par Pansa

[Cotissois 31]

Pour un diagnostic poussé, je comprends bien  

Mais je ne pensais pas que le post-processing standard était d'utiliser des choses comme NCL.

Dans l'esprit de l'utilisateur, NCL paraît extérieur à WRF.

[Pan]

.

Modifié 26 août 2023 par Pansa

[Sylvain]

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 

[Cers]

@Sylvain merci, c'est désormais parfaitement cohérent avec les données sur Kéraunos.

[Pan]

.

Modifié 26 août 2023 par Pansa