Fr/A local weather system

Statut: Août 2010

Le système météo actuel de FlightGear peut être appelé Global quand Flightgear se lance sans connexion internet : tous les paramètres, que ce soit pour le vent, les nuages, la pression atmosphérique, restent identiques et immuables. Il n'est pas possible de voler dans un endroit où le temps est différent, ou voir des changements atmosphériques dans un autre lieu.

Quand nous nous connectons, le système météo offre un lien avec des serveurs METAR, qui déterminent le temps de manière locale : on peut changer de météo en volant en un lieu où le METAR disponible est différent, mais le changement s'opère de manière globale, c'est-à-dire qu'il n'y a pas de transition comme par exemple, traverser des nuages denses, puis avoir du soleil et une bonne visibilité.

Au contraire, un système de météo locale permet des changements continus de la météo d'un endroit à un autre, car les phénomènes météorologiques sont liés à un endroit précis. Inutile de dire qu'il est plus compliqué à simuler. Voici un schéma conceptuel expliquant comment un système météorologique local pour FlightGear pourrait être créé en utilisant la technologie et le code existants.

Echelle des phénomènes météorologiques

La météo réelle est déterminée par des processus se produisant à des echelles de taille très différentes. A la plus petite echelle est le système de régions de haute et basse pression et de fronts entre les masses d'air froid et d'air chaud, qui ont des echelles spatiales de taille : O(1000) km. D'autre part existent des phénomènes très localisés, par exemple une surface goudronnée noire chauffée par le soleil agit comme la source d'un courant ascendant thermique qui aura comme conséquences un cumulus. Ces deux côté sont pertinents dans une simulation et dans Flightgear - un avion sur un vol long-courrier est en mesure d'observer les fronts météorologiques à grande échelle de loin, alors qu'un pilote de planeur a besoin d'une simulation raisonnable des courants ascendants et des vents liés aux caractéristiques du terrain, cela d'une manière crédible pour une expérience de vol réaliste. Un système météo local doit donc :

simuler la météo à différentes echelles
idéalement générer le temps avec ou sans connexion
autoriser une quelconque modification par l'utilisateur
être suffisament rapide pour pouvoir générer en temps réel

Actuellement, les dynamiques atmosphériques sont un problème très complexe, qui même résolu a besoin d'heures de travail de la part d'un CPU, même très puissant. Ainsi, il est clair qu'un système de météo locale ne peux pas être (même approximativement) physiquement une représentation du processus atmosphérique, mais le système doit être une maquette crédible d'une telle simulation, remplacée par des règles heuristiques.

Pour donner un exemple, Il faut considérer un developpement de cumulus. La création de cumulus est reduite lors d'une journée à température élevée, sous un ciel de cirrus brumeux. La raison est que Le ciel composé de cirrus réfléchit une part de la lumière du soleil, qui ne chauffera pas le sol, ce qui provoquera un atténuement de la formation de cumulus. Une simulation précise devrait commencer avec la valeur de l'energie du soleil absorbée par différentes surfaces, puis résoudre les équations gouvernant le flux ascendant de l'air chaud, du sol jusqu'à l'altitude adéquate, suivi par des équations de la dynamiques des fluides pour la création de cumulus dûe à la convection. Une règle heuristique devrait simplement exposer que la rpobalité régissant le placement des cumulus dans l'environnement de Flightgear est réduite de 50% quand une couverture de cirrus est presente (évidemment, la sophistiquation des règles détermine le réalisme de la météo).

Dans la suite, la technologie pour un tel système météo appelé à différentes échelles est décrit- d'abord pour un situation sans connexion, suivi par des idées sur son implémentation dans un vol en ligne, et sa connexion avec le système METAR.

A moindre échelle - effets de volumes et conditions moyennes

Pour simuler une météo locale à pétite échelle, le comportement de volumes (EV) est un concept très utile. les effets de volumes définissent des régions dans laquelles les conditions climatiques normales (vend, turbulences, courants ascendants, visibilité, précipitations...) sont remplacées par les caractéristiques de la région. Par exemple, on pourrait définir l'intérieur d'un nuage comme environnement à visibilité réduite ou la couche de précipitations sous un orage est un volume dans lequel il y a présence de forte pluie, d'une visibilité réduite, d'une température faible ainsi que de turbulences.

Les caractéristiques climatiques d'un volume sont imposées une fois que l'avion rentre dans le volume, et sont détruits de la même manière que l'avion quitte le volume. L'IA de Flightgear a déjà quelques exemples de structures qui, par essence sont des systémes de volumes - thermiques et orages. La première structure contient un EV (effet de volume) où le mouvement vertical de l'air est actif, la deuxième, des turbulences. Ces structures doivent rassemblées dans un système IA, nommé weather dans lequel essentiellement tous paramètres climatiques dans le volume doit être configuré par des tags XML.

Du côté visuel, quelques parties de ces volumes doivent être attachées à des modèles visibles. l'intérieur d'un nuage peut être modélisé par une visibilité réduite, mais l'extérieur doit être un modèle. De même, l'intérieur d'un front de pluie apparait comme une précipitation générée par le système de Flightgear, mais l'extérieur doit être un modèle 3d d'une couche de précipitations. Cela signifie que des modèles 3d individuels pour différents phénomènes visibles de l'atmosphère (nuages, précipitations, ombre, ...) doit être créés (voir modéliser des nuages pour la technique de création de nuages).

A l'extérieur du volume, nombre de paramètres météo peuvent varier d'une manière continue, par exemple la visibilité peut baisser de 5000 à 4000 m Si l'on vole 20 km au nord - mais l'entrée dans le nuage (le volume), va changer d'une manière discontinue et très soudaine ce paramètre (disons 30 m), pour revenir ensuite à une plus grande valeur en dehors du nuage. Ainsi, les EVs sont utilisés pour simuler seulement des changements discontinus de la météo locale, les variations de plus grande échelle ayant besoin d'être dirigées par des systèmes différents.

Les comportements des volumes devraient être créés de telle sorte qu'il puissent être modifiés par l'utilisateur, c'est à dire que l'on puisse être capable de construire n'importe qu'elle combinaison particulière des effets météo et du modèle de nuages et de précipitations pour un lieu spécifique.

Echelle moyenne - temps par "tuiles"

La météo doit être simulée et effective aussi loin que l'on peut voir ou ressentir d'un avion - cela conduit naturellement au concept de "tuiles" météo (analogues aux "scenery tiles") couvrent un région, disons, de 30x30 km environ.

Puisque toute expérience convainct qui que ce soit, placer un ensemble aléatoire de modèles de nuages dans un champ de 30*30 km ne va pas créer un ciel réaliste. En revanche, quelques types de nuages se produisent généralement ensembles, d'autres pas. la raison est la dynamique météorologique à grande échelle déterminant les phénomènes à un endroit donné. Par exemple, les cirrus sont visibles à la limite d'un front chaud - et sont habituellement suivis, par des types de nuages en couches comme l'Altostratus, mais généralement pas par un front orageux.

Ainsi, il doit y avoir différent types de "tiles", chacune représentant une image instantanée d'une dynamique d'un système plus large. les thèmes doivent être du genre 'bord d'attaque d'un front chaud', 'bord de fuite d'un front chaud', 'front froid', 'région sèche à haute pression', 'orages tropicaux' et ainsi de suite, avec le bénéfice que l'utilisateur puisse définir la météo locale, simplement en choisissant un thème dans un menu (Il n'a pas besoin de gérer indépendamment les "EVs" ou les orages).

Le thème détermine ainsi les règles pour la crétions de nuages ou d'orages. Un type " pointe d'un front chaud" peut avoir les règles suivantes:

créer vers le nord du terrain de manière aléatoire dix nuages de type "cirrus" entre 25.000 et 30.000 pieds
s'assurer que les modèles sont suffisamment espacés
s'assurer que les modèles montrent le même type de texture (ne pas mélanger différents types de cirrus)
créer 20 Cirrocumulus vers le sud de la tuiles de terrain entre 20.000 et 25.000 pieds

(...)

les paramètres à l'extérieur des EVs seraient fixés au milieu de la tuiles et interpolés entre tuiles de terrain voisines.

Techniquement, chaque tuile peut être peuplée par un script nasal spécifique pour son type à chaque utilisation (probablement dès qu'elle devient visible). Comme exemple pour l'état actuel du développement (Mars 2010), il ya une image d'un front froid approchant avec une couche de Stratocumulus et une activité faible de Cumulonimbus.

Grande échelle - règle de placement

Pour créer une expérience réaliste pour les vols dépassant une tuile de terrain, il faut des règles de correspondance des tuiles. Etant donné que chaque tuiles représente un développement particulier dans un environnement météo plus large, seulement certains types de tuiles correspondent. Par exemple, on ne peut pas placer une 'région haute pression' près de'une 'région basse pression' sans créer un front. Avec une assez riche librairie de types de terrain, et un ensemble de règles pour leur placement, sur lequel (en mode deconnexion) un ensemble crédible de tuiles est choisi, un expérience de vol plus ou moins réaliste sur une longue distance peut en résulter.

Si chaque type de tuiles contient les valeurs par défaut des paramètres météo, (et être remplacées par des infos METAR si possible), la valeur actuelle de chaque paramètre comme la pression atmosphérique ou la visibilité paut être obtenue par une interpolation entre le centre des tuiles, et les paramètres varieront même en l'absence d'informations METAR, car les règles de placement des tuiles ne suivent pas la présence de paramètres réels de systèmes météo plus larges.

Les règles de placement des tuiles peuvent être implémentées par une boucle en Nasal qui contrôle la position locale et initialise une nouvelle tuile dès que l'on en a besoin.

Connection avec le système METAR

Connecter les concepts décrits plus haut avec les infos METAR réelles n'est pas simple. L'info Meztar devrait influencer conceptuellementtrois différentes choses:

selection du type de tuile
placement de EVs et de modèles dans la tuile
continuellement varier les paramètres météo

Sélection du type de tuile

Si l'info METAR peut déterminer le type de tuile, il faudrait trouver un algorithme qui prend le METAR depuis des stations proches, et essaye d'extraire un modèle météorologique plus global à partir de cette information. Par exemple, les différences de pression et la direction du vent peuvent être utilisées pour localiser des régions de hautes et basses pression, ainsi que la différence de température (corrigée en fonction de l'élévation) peut aider pour trouver des masses d'air froid et chaud, et sur la base de la situation météorologique la plus probable compte tenu de ces éléments d'information, le type initial de tuile ainsi que les tuiles voisines les plus probables correspondantes pourraient être choisies.

Placement des EVs et des modèles dans la tuile

Au moins quelques aspects des EVs et du placement des modèles, comme une base de nuages,la force des précipitations,ou le nombre de nuages peut plus ou moins être modifié directement depuis l'information METAR. Cependant, les règles des tuiles peuvent en général être en conflit avec les détails de l'info METAR, de sorte que le système météo décrit ici ne saurait pas toujours reproduite l'info METAR (par exemple, il pourrait arriver que les rapports METAR indiquent une pluie vers une aérodrome, mais que la génération de tuiles ne place pas un nuage de pluie directement au-dessus de cet endroit).

METAR et variation continuelle des paramètres météo

Si l'info METAR est récupérable, elle devrait être utilisée pour régler certains paramètres météo, comme (plutôt que les paramètres par défaut)la visibilité, la pression, ou la température. Pour éviter certains sauts discontinus, l'information météo devrait être interpolée linéairement dans le temps pour chaque position où un METAR est disponible. Si le METAR est mis à jour toutes les dix minutes,on peut utiliser l'information au début de chaque position des premières dix minutes de vol, puis faire de même au prochain METAR en changeant lentement la valeur ( à chaque position) dans les prochaines dix minutes, et ainsi de suite ( il ya essentiellement un décalage de dix minutes par rapport au temps réel).

Pour interpoler dans l'espace, un simple algorithme avec une pondération des distances peut être utilisé (d'autres solutions plus précises mais plus compliquées existent): Si la pression "p" est connue à la position "n", de telle sorte que la pression à la position "i" est "p_i" et la distance entre l'avion et "i" est "d_i", alors une bonne approximation de la pression locale peut être exprimée comme ceci:

p = (sum p_i (1/d_i)) / (sum 1/d_i)

Cela rendrait la pression à la position "i" egale à "p_i" et conduirait à la moyenne des pressions du système si la distance de toutes les stations METAR est la même.

Discussions relatives

(en)

Weather algorithms (06/2010)
A smart cloud altitude algorithm (05/2010)
Weather dynamics (04/2010)
New thunderstorm AI scenario alpha release (02/2010)
Cirrus sky (download link in first post) (02/2010)
A local weather system (03/2010)

Connection avec le système Multijoueurs

(devrait être écrit par quelqu'un qui connait les fonctions et limites du système multijoueurs)

Développement

Quelques utilisateurs ont affirmé avoir des problèmes en utilisant l'outil recommencer/nouveau lieu; le système de météo locale devrait enregistrer dans /sim/signals/* et se suspendre/remettre à zéro lui-même, de sorte que toutes les opérations soient correctement mises en pause. This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [1]
Dynamiquement examiner les APIs FG/Nasal en faisant marcher le code responsable d'exceptions, peut aussi causer certaines impressions d'erreurs sur la console, cela serait une bonne idée d'exposer les variables à l'arbre de propriétés, de sorte que le système log peut quelques fois être dans de tels cas, c'est à dire en introduisant une priorité "nulle" ou "muette" : [2].
L'approche "feature-checking" utilisée par "compat_layer.nas" devrait probablement être généralisée et être disponible comme un module nasal standard, ainsi que pour une utilisation par d'autres scripts, tant qu'il propose une bonne méthode pour tenir une compatibilité d'arrière-plan.

[3]

On pourrait introduire un autre hash/espace de nom dans le module "compact_layer" pour des solutions de contournement basées en nasal, qui sont directement critiques au niveau des performances, de sorte que l'implémentation C++ soit prioritaire.
Pour certains usages, "threading" peut fournir un réel bénéfice de performances. Cependant, nous avons besoin d'assurer que le "threading" est par défaud OPTIONEL, ainsi les utilisateurs peuvent aisément vérifier si des potentiels problèmes sont reliés au threading ou non. Les "Worker threads" semblent être le meilleur moyen.
Une utilisation excessive de l'arbre de propriétés pour conserver toutes sortes de variables d'état, est une source potentielle de pertes de performances. Il est souvent meilleur de directement utiliser des structures de données en Nasal. De plus, il est plus facile de faire l'usage de "worker threads" quand toutes les données sont disponibles en Nasal, d'autant plus que l'arbre de propriété ( et fondamentalement toutes les fonctions d'extension en Nasal) ne sont pas faites pour être "thread-safe".
Pour être capable d'optimiser plus encore le système, il serait bon d'intégrer quelques formes de références simples, de sorte que les utilisateurs peuvent facilement fournir les résultats [4] (Nous avons parlé de cela le 9/2011, Il y a ainsi des possibilités de fournir cette information automatiquement, mais cela exigerait une modification du coeur de l'interpréteur Nasal, et probablement introduire quelques nouveaux instruments spécifiques (new instrumentation-specific) opcodes, aussi - Cela ne semble pas être une idée très populaire pour le moment.

Les demandes de fonctionnalités du côté C++

Intended as a base for discussions on how to implement particular features in the C++ code. Also see Weather algorithms discussion from 06/2010.

As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be performance, accessibility, a clear structure and backward compatibility. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++.

Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file compat_layer.nas. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are:

Terrain related

(08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [5] [6].

To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon.

Environment related

(08/2012): Provide an option to disable the precipitation "layer" system [7]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [8] [9]

(06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [10].

expose the atmospheric model to the property tree (or Nasal) [11] [12] [13] [14]

Once I cross the mountaintops, some system switches on turbulence (I suspect ridge lift, since I could not find any other property which would create turbulence). That's bad, because wave lift isn't turbulent at all. To disable the ridge lift system, set /environment/ridge-lift/enabled to 0

Cloud placement

08/2012: Cloud placement meanwhile uses a new fgcommand "add-cloud", however that's using the property tree, and it only places a single cloud - it might make sense to provide another version which places multiple clouds at once, so that a single call can add several clouds. This would probably be faster by using a Nasal extension function, instead of an fgcommand.

calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are:

a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules.

clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for.

Performance bottlenecks

For reference, the main performance bottlenecks in v0.81 seem to be:

rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used.

moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed.

generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal

sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed)

placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery

deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree.

frequently used fgcommands

property tree access (i.e. reduce property tree use and use native Nasal data structures where possible)

New Nasal API requests

For things that should be implemented as new Nasal APIs, rather than being hard coded features in C++ The file $FG_ROOT/Nasal/local_weather/compat_layer.nas contains compatibility wrappers for functions that are currently implemented in Nasal space, because the corresponding features are not yet supported by the core fgfs/Nasal APIs. This may be a good starting point for implementing new Nasal APIs.

Current development status

The current version 0.7 supports placement of effect volumes for visibility, rain, snow, turbulence and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, thunderstorms, external models of precipitation and (with a Git patch) also support for gliders, i.e. it creates thermals below convective clouds. Automatic weather tile reloading for long-range flights is implemented, both in a simple 'repeat-tile' function and a set of tile selection rules to simulate the long-range change of real weather. 3d clouds are rendered up to 45 km distance. Terrain presampling algorithms automatically adjust the cloud placement over elevated terrain.

A feature gallery of version 0.85: