4,400
edits
Advanced weather: Difference between revisions
Jump to navigation
Jump to search
m
Robot: Cosmetic changes
m (Robot: Cosmetic changes) |
|||
| Line 17: | Line 17: | ||
* be reasonably fast to run in real-time | * be reasonably fast to run in real-time | ||
The actual dynamics of the atmosphere is a very complex problem which even solved approximately needs hours of CPU time on supercomputing clusters. From this, it is clear that a local weather system cannot be an (even approximately) | The actual dynamics of the atmosphere is a very complex problem which even solved approximately needs hours of CPU time on supercomputing clusters. From this, it is clear that a local weather system cannot be an (even approximately) physically accurate description of processes in the atmosphere, but needs to be a credible mockup of such a description in which heuristic rules replace simulation. | ||
To give an example for what this means, consider the development of Cumulus clouds. Cumulus development is reduced on a hot day under a hazy Cirrus sky. The reason is that the Cirrus sky reflects part of the sunlight, thus the ground is not heated that much by direct sunlight and the convective processes responsible for Cumulus cloud formation are lessened. An accurate simulation would need to start with the energy absorbed from the sunlight on various types of surfaces, then solve the equations governing the heat flux from the ground to the air above, followed by fluid-dynamical equations for the convective currents creating Cumulus clouds. A heuristic rule would simply state that the probability for the placement of a Cumulus cloud into the Flightgear environment is reduced by 50% when a Cirrus cover is present (obviously, the sophistication of the ruleset determines how realistic the weather system will appear). | To give an example for what this means, consider the development of Cumulus clouds. Cumulus development is reduced on a hot day under a hazy Cirrus sky. The reason is that the Cirrus sky reflects part of the sunlight, thus the ground is not heated that much by direct sunlight and the convective processes responsible for Cumulus cloud formation are lessened. An accurate simulation would need to start with the energy absorbed from the sunlight on various types of surfaces, then solve the equations governing the heat flux from the ground to the air above, followed by fluid-dynamical equations for the convective currents creating Cumulus clouds. A heuristic rule would simply state that the probability for the placement of a Cumulus cloud into the Flightgear environment is reduced by 50% when a Cirrus cover is present (obviously, the sophistication of the ruleset determines how realistic the weather system will appear). | ||
| Line 27: | Line 27: | ||
To simulate local weather at small scale, effect volumes (EV) are a useful concept. The effect volumes define regions in which the normal weather conditions (wind, turbulence, updraft, visibility, precipitation...) are replaced by ones characteristic for the region. As an example, one would define the inside of a cloud as an effect volume in which visibility is reduced as compared to outside, or the precipitation layer underneath a thunderstorm as an EV in which heavy rain is on, visibility is reduced, the temperature is reduced and some turbulence may be active. | To simulate local weather at small scale, effect volumes (EV) are a useful concept. The effect volumes define regions in which the normal weather conditions (wind, turbulence, updraft, visibility, precipitation...) are replaced by ones characteristic for the region. As an example, one would define the inside of a cloud as an effect volume in which visibility is reduced as compared to outside, or the precipitation layer underneath a thunderstorm as an EV in which heavy rain is on, visibility is reduced, the temperature is reduced and some turbulence may be active. | ||
The conditions characteristic for the EV are imposed once the aircraft enters the volume, they are restored to the outside values once the aircraft leaves the region again. The Flightgear AI system already has examples of structures which in essence are EVs - | The conditions characteristic for the EV are imposed once the aircraft enters the volume, they are restored to the outside values once the aircraft leaves the region again. The Flightgear AI system already has examples of structures which in essence are EVs - '''thermal''' and '''thunderstorm'''. The first structure contains an EV in which vertical air motion is active, the second one in which turbulence is present. These structures could be generalized to an AI system '''weather''' in which essentially all weather parameters inside the volume could be set by XML tags. | ||
On the visual side, parts of the EV must also be tied to visible models. The inside of a cloud can be modelled by reduced visibility, but the outside of the cloud must be a model. Similarly, the inside of a rain front appears as rain generated by the Flightgear system, but the outside must be a 3-d model of a precipitation layer. This means that individual 3-d models for various visible atmospheric phenomena (clouds, precipitation, fog, ...) need to be created (see [[Howto: Modelling Clouds]] for a collection of techniques for creating cloud and precipitation models). | On the visual side, parts of the EV must also be tied to visible models. The inside of a cloud can be modelled by reduced visibility, but the outside of the cloud must be a model. Similarly, the inside of a rain front appears as rain generated by the Flightgear system, but the outside must be a 3-d model of a precipitation layer. This means that individual 3-d models for various visible atmospheric phenomena (clouds, precipitation, fog, ...) need to be created (see [[Howto: Modelling Clouds]] for a collection of techniques for creating cloud and precipitation models). | ||
| Line 37: | Line 37: | ||
=== Mid scale - weather tiles === | === Mid scale - weather tiles === | ||
Weather needs to be explicitly simulated about as far as one can see from an aircraft - that naturally leads to the concept of weather tiles (analoguous to scenery tiles) | Weather needs to be explicitly simulated about as far as one can see from an aircraft - that naturally leads to the concept of weather tiles (analoguous to scenery tiles) which would cover a region of, say, 30x30 km or something of that size. Inside tiles, weather is simulated explicitly in terms of EVs and 3-d models. | ||
As experiments will quickly convince anyone, placing a random set of cloud models into a tile does not create a realistic sky appearance. Instead, some cloud types usually occur together, others do not. The underlying reason is of course that there is large scale dynamics of the weather which determines what happens in a given location. For instance, Cirrus clouds are found at the leading edge of a warmfront - and they are usually followed by lower, layered cloud types like Altostratus, but typically not by a thunderstorm front. | As experiments will quickly convince anyone, placing a random set of cloud models into a tile does not create a realistic sky appearance. Instead, some cloud types usually occur together, others do not. The underlying reason is of course that there is large scale dynamics of the weather which determines what happens in a given location. For instance, Cirrus clouds are found at the leading edge of a warmfront - and they are usually followed by lower, layered cloud types like Altostratus, but typically not by a thunderstorm front. | ||
| Line 86: | Line 86: | ||
=== METAR and continuously varying weather parameters === | === METAR and continuously varying weather parameters === | ||
If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby | If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather). | ||
To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure | To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure ''p'' is known at ''n'' positions, such that the pressure at position ''i'' is ''p_i'' and the distance between aircraft and ''i'' is ''d_i'', then a good approximation of the local pressure is | ||
p = (sum p_i (1/d_i)) / (sum 1/d_i) | p = (sum p_i (1/d_i)) / (sum 1/d_i) | ||
as this will make the pressure at position | as this will make the pressure at position ''i'' equal to ''p_i'' and lead to the average of the individual pressures if the distance to all METAR stations is the same. | ||
== Related Discussions == | == Related Discussions == | ||
| Line 108: | Line 108: | ||
== Development == | == Development == | ||
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to | * Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94765] | ||
* We need to add an option to completely disable the local weather system, so that it doesn't run at all, or even better so that it doesn't even get loaded (this is possible by explicit rather than implicit loading using the io.nas module, see next item). This should make it much easier to do troubleshooting, and it would be easier for users to tell if their problems are related to the local weather system or not. [http://flightgear.org/forums/viewtopic.php?f=5&p=96439#p96439] | * We need to add an option to completely disable the local weather system, so that it doesn't run at all, or even better so that it doesn't even get loaded (this is possible by explicit rather than implicit loading using the io.nas module, see next item). This should make it much easier to do troubleshooting, and it would be easier for users to tell if their problems are related to the local weather system or not. [http://flightgear.org/forums/viewtopic.php?f=5&p=96439#p96439] | ||
* We should seriously think about moving the local weather system to its own directory, either as a sub directory within $FG_ROOT/Nasal, or possibly even directly in $FG_ROOT/LocalWeather ? The local weather system is becoming one of the most complex systems ever implemented in Nasal, and so it is only good and natural to modularize it even further to keep everything organized (i.e. split code into distinct modules), however the $FG_ROOT/Nasal directory is getting increasingly cluttered due to this ((I am getting the impression that if we had an active Nasal maintainer, that person would rightly complain about this ...because the local weather stuff is not really a part of the "standard library" but instead a completely new system)). It would be better to move everything to a dedicated directory, and only leave a small wrapper script in $FG_ROOT/Nasal that handles loading/unloading of complete systems, | * We should seriously think about moving the local weather system to its own directory, either as a sub directory within $FG_ROOT/Nasal, or possibly even directly in $FG_ROOT/LocalWeather ? The local weather system is becoming one of the most complex systems ever implemented in Nasal, and so it is only good and natural to modularize it even further to keep everything organized (i.e. split code into distinct modules), however the $FG_ROOT/Nasal directory is getting increasingly cluttered due to this ((I am getting the impression that if we had an active Nasal maintainer, that person would rightly complain about this ...because the local weather stuff is not really a part of the "standard library" but instead a completely new system)). It would be better to move everything to a dedicated directory, and only leave a small wrapper script in $FG_ROOT/Nasal that handles loading/unloading of complete systems, loading the corresponding modules explicitly (rather than implicitly due to being located in the $FG_ROOT/Nasal directory) using the helpers available in the io.nas module. The neat thing about using this approach is that it would also be trivially possible to enable/disable the complete local weather system just by setting a property during startup. In addition, it would help keeping things organized. This is especially because the $FG_ROOT/Nasal directory is -by convention- considered to be the "library" directory, but addons like the local weather system (or the bombable addon) are complete systems, which would better live in separate places. | ||
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a "NONE" or "MUTE" logging priority [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370]. | * Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a "NONE" or "MUTE" logging priority [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96370]. | ||
* The feature-checking approach used by "compat_layer.nas" should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96358] | * The feature-checking approach used by "compat_layer.nas" should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&p=96439#p96358] | ||
| Line 122: | Line 122: | ||
Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8365 Weather algorithms discussion] from 06/2010. | Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8365 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 | 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 | 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 === | === Terrain related === | ||