Advanced weather: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Created page with 'Status: Feb. 2010 The current weather system of Flightgear can be called global when Flightgear runs offline: Any menu weather setting, be it windspeed, visibility, precipitatio…')
 
m (adding links to related discussions (from flightgear forums))
Line 90: Line 90:
as this will make the pressure at position  <i>i</i> equal to  <i>p_i</i> and lead to the average of the individual pressures if the distance to all METAR stations is the same.
as this will make the pressure at position  <i>i</i> equal to  <i>p_i</i> and lead to the average of the individual pressures if the distance to all METAR stations is the same.


 
= Related Discussions =
* [http://flightgear.org/forums/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010)
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010)
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7358 A local weather system] (03/2010)


== Connection with the Multiplayer system ==
== Connection with the Multiplayer system ==


(should be written by someone who knows what the Multiplayer system can and cannot do)
(should be written by someone who knows what the Multiplayer system can and cannot do)

Revision as of 10:11, 16 March 2010

Status: Feb. 2010

The current weather system of Flightgear can be called global when Flightgear runs offline: Any menu weather setting, be it windspeed, visibility, precipitation or cloud coverage, affects the weather everywhere. It is not possible to fly to a region where the cloud cover is different, or see precipitation from an aircraft flying in sunshine, or to observe a change in atmospheric pressure by flying somewhere else.

When online, the weather system offers a link with METAR servers, which makes the weather locally-determined global: One can change the weather by flying to a different location where a different METAR is available, but the change happens instantaneously everywhere, i.e. there is no transition of for example crossing a rain front or leaving dense clouds behind to emerge in sunshine.

A local weather system in contrast is one in which continuous changes from the weather at one location to the weather in a different location are simulated, i.e. weather phenomena are tied to a specific location. Needless to say, a local weather system is significantly more complicated to simulate than the present system. Below is a conceptual outline how a local weather system for Flightgear could be created using mainly existing technology and code.


Scales for weather phenomena

Real weather phenomena are determined by processes occurring at vastly different size scales. At the large end of the scale is the system of low and high pressure regions and fronts between cold and warm air masses, which have spatial size scales of O(1000) km. At the other end of the scale are very localized phenomena, for instance a dark tarmac surface heated by sunlight acting as the source point of a thermal updraft resulting in a Cumulus cloud. Both size scales are relevant for the Flightgear experience - an airliner on a longhaul flight is able to observe large-scale weather fronts from above, whereas a glider pilot needs a reasonable simulation of local updrafts and sinks tied to terrain features in a credible way for a realistic flight experience. A local weather system therefore needs to

  • simulate weather phenomena at different scales
  • ideally work offline as well as online
  • allow modification by the user on various scales
  • 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) 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).

In the following, the technology for such a local weather system needed at the relevant scales is outlined - first for the situation offline, followed by ideas how it could be connected with the METAR system in online use.

Small scale - effect volumes and average conditions

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 - 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).

Outside the EV, many meteorological parameters may vary in a continuous way, for example visibility may decrease from 5000 to 4000 m when flying 20 km north - but inside the cloud (the EV), it will change in a discontinuous way very suddenly to a low value (say 30 m), to jump back to a large value outside the cloud. Thus, the EVs are used to simulate only discontinuous, local changes in conditions, the larger scale changes in the background need to be taken care of by a different system.

EV's should be implemented such that they can be user-specified, i.e. a user should be able to place any particular combination of weather effects and cloud/precipitation model to a specific location.

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) 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.

Thus, there need to be different 'types' of tiles, each representing a typical snapshot of a development inside the larger system. Tile themes would be something like 'leading edge of warmfront', 'trailing edge of warmfront', 'cold front', 'dry high-pressure region', 'developed tropical thunderstorms' and so on. This has the added benefit that the user can specify the weather locally simply by chosing an appropriate tile from a menu (he does not need to micromanage the weather by placing individual EV and cloud models).

The type of tile then determines the rules for populating the tile with EV and models. A 'leading edge of a warmfront' tile could for example have the rules

  • populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft
  • make sure the models are spaced sufficiently far apart
  • make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)
  • populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft

(...)

The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles.

Technically, each tile can be populated by a Nasal script specific for the tile type whenever the tile is needed (probably when it becomes visible).

Large scale - tile placement rules

To create a realistic experience for flights beyond a tile, there need to be matching rules for tiles. Since each tile represents a particular development in a larger weather environment, only certain types of tiles match. For instance, one cannot place a 'high-pressure region' tile next to a 'low pressure region' tile without crossing a front. With a moderately large library of different tile types and a set of placement rules, out of which (in offline mode) a credible set of neighbouring tiles is chosen, a more or less realistic long-distance flight experience can result.

If each tile type contains default values for weather parameters (to be overwritten by METAR info if available), the actual value of any parameter such as atmospheric pressure of visibility can be obtained by interpolation between tile centers, and the parameters will vary even in the absence of METAR info simpy due to the tile placement rules mocking up the presence of real large-scale weather systems.

Tile placement rules can be implemented in a Nasal loop which monitors the local position and initializes a new tile as soon as it is needed.


Connection with the METAR system

Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:

  • selection of tile type
  • placement of EVs and models inside the tile
  • continuously varying weather parameters

Selection of tile type

If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.

Placement of EVs and models inside the tile

At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).

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 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 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)

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

Connection with the Multiplayer system

(should be written by someone who knows what the Multiplayer system can and cannot do)