Passage en grib à 0.25°

[pzia]

Les gribs du noaa permettent maintenant de d'améliorer le niveau de précision. L'apport pour le jeu serait :

• rester dans la philosophie : quand on peut être précis, soyons le
• améliorer les conditions en particulier dans le petit temps
• remettre une marche de progrès pour les routeurs

L'impact est sur l'infrastructure : il faut 500 Mo de ram en plus, et vérifier le code (ou bien descendre le nombre de jours disponible, mais ce n'est pas souhaitable.

Idéalement à suivre par @ylafon qui est le mieux placé.

[Phille]

le fichier grib sera 4x plus gros (on a déjà des pb à charger les 33Mb et ça deviendra impossible pour les routeurs version andro et iO) précision oui ... mais pas besoin à mon avis ce ne sont toujours que des prévisions et cela ne va pas nous rapprocher des réels.

[pzia]

Rien n'empêche de générer des fichiers en 0.5 comme aujourd'hui (et donc pas de problème de fichiers 4 fois plus gros)

[Phille]

C'est ce qu'on fait actuellement, non? sbs dis moi si je me trompe ;) On travaille à partir des nouveaux fichiers 0.25 et on charge des 0.5

[pzia]

Aujourd'hui, on récupère les fichiers du noaa, on fabrique des gribs en 0.5 et on les consomme. On pourrait :

• récupérer les gribs du noaa en 0.25
• fabriquer des gribs en 0.25 pour le moteur de vlm
• fabriquer des gribs en 0.5 pour les outils qui préfèrent

Rien d'incompatible ;)

[Phille]

si mes souvenir sont bons on avait déjà discuté le + et le - des grib à 0.25 ... et la position du moment était: on ne change rien pour l'instant. faudrai reprendre le fil ... je vais essayer de retrouver les anciens messages :)

[maitaivw]

Si vlm passe en 0.25 (je suis pour a 200%), la seule chose qu'il faut prevoir en plus cote vlm c'est la possibilite de telecharger une zone et non pas un grib world complet. Un peu a la facon de zygrib ou saildocs.

Le ws qui ressemble a ca aujourd'hui est bcp trop lent et gros, il nous faudrait du vrai fichier grib compresse.

On a un script quasiment pret pour ca deja, si vous (=VLM) ne le faites pas c'est prevu qu'on le fasse de notre cote un jour de toutes facons, a cause de qtvlm-mobile.

PS: qqun peut mettre oxygen en copie de ce post?

Edit: si VLM passe en 0.25 les outils sont forces de travailler en 0.25 aussi... sinon dommage pour le rase-cailloux.

[pzia]

Je viens d'ajouter @oxygen77 dans @v-l-m/devs

Les outils ne sont pas "forcé", en raz kyu ils ont déjà à dispo le vent instantané en provenance de vlm. On reparle du reste après la bascule.

[maitaivw]

Hey on ne navigue plus comme ca (d'autant que ca serait faux vu que le vent donne par vlm n'est PAS le vent a la prochaine vac). On trace une route et on va se coucher, nous :)

[pzia]

Une remarque : je ne suis pas d'accord, vlm peut fournir le vent qui sera le sien au moment de la prochaine vac, il suffit de lui demander. Une deuxième : le besoin de predictabilité absolue est bizarre selon moi, et la plupart des routages ne verraient pas la différence. C'est la même chose que la rengaine sur le temps à la première vac. La différence est en dessous du delta de temps entre 2 serveurs ( on parle de 2 secondes...). Et je ne parle pas du fond.

Cela étant dit, je ne ferai pas de forcing, car je n'ai pas l'intention de me réinvestir dans v-l-m tout de suite à par filer un coup de main ponctuel à sbs.

On ne peut pas prévoir une extraction grib sur une zone définie par chaque utilisateur, ce serait trop coûteux. On peut envisager de donner encore plus de boulot au comité en lui donnant une interface permettant de définir des zones (réutilisables) suivant les courses. Il faut un ticket pour ça ;-)

[maitaivw]

Loin de moi l'idee de polemiquer :)

1) le vent recu par un outil par un /ws/boatinfo est le vent au moment de la requete, c'est ce que je voulais dire (cad il peut etre n'importe qd pendant la vac), il suffit de faire "sync" plusieurs fois dans une vac pour s'en rendre compte. C'est donc inutlisable pour calculer ou on sera a la prochaine vac. Il existe p-tet un autre ws pour ca, je ne sais pas. Il y a a ma connaissance seulement 2 autres ws: ws/windinfo/windgrid.php qui est pour une zone, et ws/windinfo.php dont il est a ma connaissance interdit de se servir.

2) Le pb n'est pas tellement le routage isochronique, c'est l'estime ou la route qui doit pouvoir passer a qques metres des cotes sans se planter, et ce pendant toute la validite du grib (6h). Ca ne concerne pas la prochaine vac seulement. En clair l'interpolation du grib faite en local sur qtvlm doit etre exactement la meme que celle faite par le moteur de vllm, et donc le pas du grib aussi.

Oxygen connait mieux que moi le script (similaire a celui de zygrib) qui fabrique un extrait de grib au format grib a partir d'un grib mondial. C'est lui l'expert mais IMO c'est pas gourmand du tout, a ma connaissance c'est juste une extraction de record sans interpolation ni rien. Il faudrait bien sur qd meme un systeme de file de requetes pour eviter l'embouteillage.

A noter que j'ai tente d'utiliser windgrid, mais c'est bcp plus lent de demander ca sur une zone comme par exemple l'atlantique nord que de telecharger le grib world complet de 33mb, j'ai donc renonce. Ce ws est un danger pour vlm a mon avis, mais c'est une autre histoire.

Des zone predefinies c'est pas ideal a mon avis. Sur un tour du monde y'aura tjrs un moment ou on aura besoin de 2 zones a la fois, je pense.

[pzia]

Sur le 1 et 2 : une zone pour le routage sur la durée du grib (6h) c'est 3 appel à wingrid (en comptant que les gribs ont un pas de 3h) Ca ne me semble pas lourd, wingrib renvoie au plus 1000 points c'est à dire de quoi faire 30x30, c'est àdire 7,5°x7,5° c'est pas mal, non pour du razkyou ?

Cf. le ticket #781 pour les gribs partiels. Cf. le ticket #780, @maitaivw et @oxygen77 ... je vous laisse développer pour les dangers de wingrid...

On garde ce ticket pour l'implémentation technique du changement de step.

[maitaivw]

Oui, ca serait utilisable pour du rase-cailloux a court terme, sur une petite zone pdt 6h. Mais de toutes facons il nous faut aussi le reste pour le routage (entre autre).

Pour saildocs on a dans le meme grib a 0.5/0.5-3h pdt 96 heures et ensuite 2.5/2.5-12h, et ca fonctionne tres bien.

On pourrait tres bien avoir un fonctionnement similaire dans VLM, cad 0.25/0.25-3h pendant 9h et ensuite un autre pas moins gourmand. Du moment qu'on a la meme chose dans VLM et dans les outils jusqu'a la prochaine maj meteo pas de soucis.

[ylafon]

Au passage... on a des gribs UV en 0.25 quelque part pour tester ?

[maitaivw]

Suffit d'envoyer un mail a query@saildocs.com avec n'importe quoi comme sujet (mais non vide) et par exemple le texte:

GFS:51.50N,31.00N,35.50W>4.00W|0.25,0.25|0,3,6..384|WIND

[sbsrouteur]

y a un flag pour choisir si on est en 0.5 ou 0.25 ? ou c'est de la préparation à 0.5 en attendant de passer à 0.25? il faudra faire un branche pour coder et tester tout ça, à terme.

[ylafon]

Il y a un flag en effet, il faut changer la version de vlm-c dans le Makefile, ce qui n'a pas encore été fait. Il sera très facile de modifier le script de recuperation des gribs, on fera ça après la prochaine release. Mais un premier test montre que ça semble marcher comme il faut. (À verifier sur une carte météo, on verra sur testing).

[sbsrouteur]

Ok. J'ai fait un milestone Wind0.25 pour gérer tous les tickets liés à cette modification pour la prise en compte. Comme ça on pourra savoir ou on en est car c'est quand même un gros morceau. Et aussi un bon sujet pour faire un branche pour aller à coté de unstable.testing.v-l-m.org. Comme ça on pourra faire vivre les deux cote à cote et voir ce que ça donne.

[ylafon]

Petite question... testing utilises ses propres gribs ? (ie: est-ce que je peux forcer la recuperation des gribs en 0.25 dessus pour tester).

[pzia]

En principe oui. Je ne pense pas qu'on l'aies mis en slave de v-l-m.

Le 9 avril 2015 21:05, Yves Lafon notifications@github.com a écrit :

Petite question... testing utilises ses propres gribs ? (ie: est-ce que je peux forcer la recuperation des gribs en 0.25 dessus pour tester).

— Reply to this email directly or view it on GitHub https://github.com/v-l-m/vlm/issues/777#issuecomment-91329556.

[sbsrouteur]

oui testing utilise ses propres gribs qu'il télécharge de la noaa avec le même script que celui de neptune. Donc il faut patcher le script (avec un flag idéalement) pour aller chercher les données à 0.25 au lieu de 0.5 et roulaize.

[maitaivw]

A savoir (je me repete mais bon) que qtvlm ne prendra pas facilement un grib mondial de 0.25 sur 5 jours, c'est trop.

D'ou le ticket sur le grib partiel, imo faut faire avant de basculer en 0.25

[pzia]

J'ai pas oublié, c'est le #781.

[ylafon]

Ce n'est pas le but initial de VLM d'exporter via un WS 5 jours de vent, il vaut mieux prendre le grib côté client et qu'il fasse ce qu'il faut lui même, non ?

[pzia]

@ylafon : on peut le faire comme une mise à disposition de grib partiel, pas comme un ws json. Mais je suis d'accord, on devrait le gérer comme un projet à part car ça dépasse le scope initial de VLM et ça pourrait être utile qu'il y ait des serveurs alternatifs qui se montent avec le même service.

[RisAMer]

Situation du 20150307-12z: De gauche à droite et de haut en bas: Vents (m/s): grib 0p25, grib 0p50 replacé sur la grille à 0.25 Ecarts sur la magnitude (m/s) et la direction (radians)

Zoom sur un zone plus étroite:

Bof Bof... A peu près autant envie de voir ça sur VLM que du 4K sur un dumbphone.

[maitaivw]

C'est moi le dumbphomme.... :)

Un peu d'explication de texte sur ces images et le probleme qu'elles montrent stp?

[sbsrouteur]

Je pense qu'elle montrent qu'il y a très peu de différence, vu que le seul endroit ou cela fera vraiment un différence c'est là ou il y a de fort gradient en force et ou direction.

On pourrait pas avoir un xor de deux images l'une sur l'autre, afin que les différences sautent plus aux yeux?

On Fri, Apr 10, 2015 at 7:51 PM, maitaivw notifications@github.com wrote:

C'est moi le dumbphomme.... :)

Un peu d'explication de texte sur ces images et le probleme qu'elles montrent stp?

— Reply to this email directly or view it on GitHub https://github.com/v-l-m/vlm/issues/777#issuecomment-91635601.

[pzia]

quand on voit les discussions sur le caractère serré du routage... je pense que les petites différences restent importantes, non ;) ?

[RisAMer]

Je pense qu'elle montrent qu'il y a très peu de différence, vu que le seul endroit ou cela fera vraiment un différence c'est là ou il y a de fort gradient en force et ou direction.

Yep, plutôt d'accord avec ça.

On pourrait pas avoir un xor de deux images l'une sur l'autre, afin que les différences sautent plus aux yeux?

Pas littéralement un XOR, mais c'est ce que font les deux figures du bas (Delta en norme et direction), non?

[pzia]

Il faudrait faire la même chose avec des gribs 0.5 et 1.0 interpolés à 0.5 Pas sur qu'on verrai plus de différence...

Sur le fond, même si aujourd'hui on ne bénéficie pas beaucoup du modèle fin, c'est un investissement. En plus ça laisserai quand même plus d'incertitudes dans le jeu ce qui est un bien.

[RisAMer]

Sur le fond, même si aujourd'hui on ne bénéficie pas beaucoup du modèle fin, c'est un investissement.

AMHA, le 0.25 sur les courses longues, ça va vite devenir très pénible, voire douloureux. Mais sur les permanentes ultra-courtes, ou à la rigueur sur les WE, ça peut être jouable (petite surface et pas long, donc pas beaucoup de records dans le grib). Suis assez d'accord avec vous deux, la seule obligation pour VLM, c'est d'annoncer sans ambiguité le grib qu'utilise le moteur. Après, aux outils de se débrouiller avec. Ça limite l'investissement.

En plus ça laisserai quand même plus d'incertitudes dans le jeu ce qui est un bien.

Totalement favorable à plus d'incertitude, Oulala, j'achète des deux mains. Plus d'incertitude avec une maille plus fine? Mmmmh, pas si sûr. J'aurais plutôt tendance à penser que 0.25 ou 0.5, c'est pareil, mais que le passage à 0.25 côté NOAA l'a d'ores et déjà minorée, qu'on prenne le 0.25 ou le 0.5. Quant à le démontrer, c'est une autre histoire: pas simple comme question. :cyclone:

[maitaivw]

" la seule obligation pour VLM, c'est d'annoncer sans ambiguité le grib qu'utilise le moteur. Après, aux outils de se débrouiller avec. Ça limite l'investissement."

Toutafait.. VLM est la reference, aux outils de se debrouiller ou pas. VLM ne doit pas se limiter pke potentiellement ca va nuire a tel ou tel outil, y compris la TCV. ;) Je rigole mais ca vaut pour qtvlm, ft, sbsrouteur, et d'autres a venir ou pas. La nature etant bien faite, etc.

Autre point important, l'ihm de vlm. Autant il faut vraiment revoir le website pour l'inscription et la partie "adminstrative" creation de compte et de boats (quoique un petit ws le ferait aussi tres bien), et l’annonce des courses.... autant imo autant virer le cote boat-control et juste donner un lien vers FT etc. Je dis FT pke c un client leger/web, pas juste pour etre mignon.

Combien de gens je connais qui sont allés sur VLM, motives et tt ca, et ont ete perdus/rebutes/degoutes/etc pke rien comprendre a l'interface?

Si on n'a pas les ressources pour refaire l'ihm, autant laisser faire les outils au moins pour l'instant, et que vlm se concentre sur les autres aspects qui sont moins time-consuming et plus pointus. Les outils suivront VLM de toutes facons d'une maniere ou d'une autre.

[pzia]

je me désabonne de ce ticket :) je reviendrai lire quand il y aura une demande claire dans un sens ou dans un autre. Je vais faire d'autres trucs en attendant.