https://wiki.flightgear.org/w/api.php?action=feedcontributions&feedformat=atom&user=LisbellawFlightGear wiki - User contributions [en]2026-04-08T02:57:57ZUser contributionsMediaWiki 1.39.6https://wiki.flightgear.org/w/index.php?title=Creating_new_Nasal_scripts&diff=97217Creating new Nasal scripts2016-04-18T08:43:02Z<p>Lisbellaw: /* User specific Nasal scripts */</p>
<hr />
<div>{{Template:Nasal Navigation}}<br />
<br />
<br />
== Editing code files ==<br />
<br />
Note that there is currently no way to tell FlightGear to reload Nasal scripts from the global Nasal directory at runtime, so in order to see changes take effect, you will have to exit and restart FlightGear for the time being. Note that there are some workarounds available, see: [[Nasal_scripting_language#Loading.2Freloading_Nasal_code_without_re-starting_FlightGear|reloading Nasal code without re-starting FlightGear]].<br />
<br />
Also, note that as of 05/2009, Nasal in FlightGear does not yet support any form of dependency resolution. In other words, there's no "import", "require" or "include" directive - this is also why most code in FlightGear is wrapped inside a _setlistener() call instead, which in turn waits for a FlightGear signal before executing the code (see below for details).<br />
<br />
<br />
== Creating new Scripts ==<br />
<br />
Nasal scripts need to be plain text files, saved with a *.nas extension.<br />
They can be created and written using a conventional plain text editor like notepad, gedit, kate etc.<br />
But you can also use a programming text editor with syntax lighting support, see [[Howto:Syntax highlighting for Nasal]].<br />
<br />
We are also currently planning to add some very basic syntax highlighting support to the built-in [[Nasal Console]] using the new [[Canvas]] system.<br />
<br />
=== Aircraft specific Nasal code ===<br />
<br />
Generally, aircraft specific Nasal scripts reside in the corresponding aircraft's folder (or a corresponding /Nasal subfolder) where they are usually included by adding a corresponding <nasal> tag to the [[aircraft-set.xml]] file (see [[Writing simple scripts in %22nasal%22|Writing simple scripts in "nasal"]]). Also see the section on [[Nasal scripting language#Namespaces|namespaces]] which contains more specific examples.<br />
<br />
=== Instrument specific Nasal code ===<br />
<br />
While instrument specific scripts are saved within the instrument's folder (as previously mentioned, Nasal scripts can also be embedded in various other XML files), Nasal scripts driving shared instruments are generally stored in <tt>[[$FG ROOT]]/Aircraft/Generic/</tt>.<br />
<br />
=== Nasal code as bindings in XML files ===<br />
Nasal scripts can also be used as "binding" objects, and can therefore appear anywhere in a configuration file (keyboard, mouse and joystick bindings, etc...) that accepts a <binding> tag. The relevant command type is "nasal", and you place your Nasal code inside of the <script> tag: <br />
<br />
<syntaxhighlight lang="xml"><br />
<binding><br />
<command>nasal</command><br />
<script><br />
print("Binding Invoked!");<br />
</script><br />
</binding><br />
</syntaxhighlight><br />
<br />
The code above invokes the print() function. This is a simple extension function that simply prints out its arguments, in order, to the FlightGear console as a single-line log entry. It is useful for debugging, but little else.<br />
<br />
=== System-wide Nasal code ===<br />
<br />
Nasal scripts that are not specific to certain aircraft, instruments or other uses, generally reside in the system-wide <tt>[[$FG ROOT]]/Nasal</tt> directory. Scripts that are placed inside this directory (with a *.nas extension) are automatically loaded and run during FlightGear startup. <br />
<br />
=== Nasal sub modules ===<br />
<br />
As of 06/2011, FlightGear also supports so called Nasal "sub modules" which may reside in their own sub folder under [[$FG_ROOT]]/Nasal/ and which provide support for on-demand loading at runtime by toggling properties.<br />
<br />
Some advantages are:<br />
<br />
* Nasal files can be grouped neatly instead of all scripts being mixed up in a single fgdata/Nasal directory. Grouping makes a lot of sense for modules consisting of several scripts - local weather is the best example.<br />
* Guaranteed loading sequence. Submodules are loaded _after_ the main fgdata/Nasal scripts, so they can rely on all fgdata/Nasal content to be already present. No more need for awkward listener callbacks, just to make sure that basic "props" or "gui" modules are available.<br />
* Finally, users have the option to disable loading modules. Unfortunately, just loading scripts (code/data) into memory already causes certain _run-time_ performance effects - even if the Nasal code was never executed (so even when all listeners/timers were disabled).<br />
<br />
Please note that there is a difference between the _individual_ Nasal files in fgdata/Nasal and files belonging to a common Nasal _module in general (no matter whether loaded at run-time or loaded at start-up using a "<nasal>" tag).<br />
<br />
The individual Nasal files in fgdata/Nasal have an own namespace _each_. The namespace get's the name of the Nasal file itself. So if you have a "gui.nas" in the directory, then you can reference a symbol "foo" using "gui.foo".<br />
<br />
Nasal modules also have a single namespace. But all files belonging to the module share this _single_ namespace. The name of their namespace is made from its directory (for the run-time loadable modules), or from the specific tag given below the <nasal> XML element, which are often used for a/c specific modules (e.g. <nasal><ufo>...</ufo></nasal> creates the ufo Nasal namespace in ufo-set.xml).<br />
<br />
'''So each Nasal file in a new Nasal "module" folder now shares the same namespace.'''<br />
<br />
Another important thing to keep in mind is that Nasal sub modules should preferably register a listener to handle initialization, because they are not necessarily loaded by default but rather "on demand". The signal property to listen to will be in /nasal/MODULE_NAME/loaded - for example:<br />
<br />
<syntaxhighlight lang="nasal"><br />
var init = func {<br />
# this is where you put all your startup code<br />
# to ensure that it will only be called<br />
# AFTER all sub modules have been processed<br />
}<br />
_setlistener("/nasal/my_module/loaded", init);<br />
</syntaxhighlight><br />
<br />
This is why you need to wrap everything in a function and register a listener, so that the code is only invoked AFTER ALL sub module files have been LOADED - otherwise, you'll have unresolved references.<br />
<br />
As you can see in <tt>[[$FG_ROOT]]/Nasal/local_weather/compat_layer.nas</tt> there's a sub module listener registered that will be fired once ALL source files in the sub module folder have been processed - this is basically the signal to fire off the callback, so that the code can actually start running. The local weather system doesn't use a separate function, but rather an anonymous func: {{fgdata url|path=Nasal/local_weather/compat_layer.nas|line=76}}<br />
<br />
The whole point of this technique is being able to tell when all files have been parsed by Nasal - so that you know that you can actually start running the code, and rely on all symbols being available in the module's namespace. <br />
<br />
All sub modules are automatically loaded AFTER [[$FG_ROOT]]/Nasal has been processed - so your sub modules only need to register their own "loaded" listener to make sure that the sub module code is only actually run once all files have been processed. Nasal core modules (such as gui.nas io.nas etc) are automatically available to every sub module.<br />
<br />
<br />
For more information on Nasal sub modules, please see:<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg31761.html<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32657.html<br />
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg33458.html<br />
<br />
=== User specific Nasal scripts ===<br />
<br />
It's also possible to put Nasal files into [[$FG_HOME]]/Nasal/, that is: ~/.fgfs/Nasal/ on Unix, and %APPDATA%\flightgear.org\Nasal\ on MS Windows. This has the following advantages:<br />
<br />
* one doesn't have to mix local extensions with standard files<br />
* one is less likely to lose such local additions when upgrading<br />
* one doesn't need write permission to [[$FG_ROOT]]/Nasal/ or<br />
* one doesn't have to become "root" to edit such files<br />
<br />
The files are guaranteed to be read after all the files in [[$FG_ROOT]]/Nasal/, so one can safely use elements of files like props.nas (props.Node), or globals.nas (setlistener() without leading underscore).<br />
<br />
The files are guaranteed to be read in alphabetic order. So, if there are two files where one depends on the other, just name them appropriately.<br />
<br />
The contents of each file are added to a namespace derived from the filename. So, all functions and variables of a file ~/.fgfs/Nasal/local.nas will be added to nasal namespace "local", and a function test() is globally accessible as local.test().<br />
<br />
It's possible to extend a standard module like "math" with definitions in ~/.fgfs/Nasal/math.nas, though this should, of course, not be exploited by code that is to be submitted to cvs.<br />
<br />
[[Category:Nasal]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=97216Turbulence2016-04-18T08:40:59Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. This is possible via the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced weather]] with its so called gust settings, the [[Soaring#Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism#Ridgelift|FGRidgeLiftGlider]]), the [[Soaring#Wave lift|FGWaveLift]] and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these systems are not independent because you can use for example the convective cloud system with a realistic distribution of thermals only in the Advanced Weather mode (see [[Soaring#Setting the weather|Soaring]]) but that shall not be a subject of this article. Instead, the following sections will clarify how these different approaches can generate a realistic contribution to the turbulent wind field. In addition, you need to be aware of the fact, that this subsystems mentioned above only produce low frequency wind fluctuations. That means they just modify the mean values of the wind. The exception to this are the clouds which can really influence the high frequency turbulence simulated by the FDM's.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<br />
=== Mailing lists ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34618077/ Turbulence and JSBSim soaring]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/31346370/ Cloud turbulence]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/27782087/ Turbulence in YASim vs. JSBSim]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=97215Turbulence2016-04-18T08:39:56Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. This is possible via the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced weather]] with its so called gust settings, the [[Soaring#Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism#Ridgelift|FGRidgeLiftGlider]]), the [[Soaring#Wave lift|FGWaveLift]] and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these systems are not independent because you can use for example the convective cloud system with a realistic distribution of thermals only in the Advanced Weather mode (see [[Soaring#Setting the weather|Soaring]]) but that shall not be a subject of this article. Instead, the following sections will clarify how these different approaches can generate a realistic contribution to the turbulent wind field. In addition, you need to be aware of the fact, that this subsystems mentioned above only produce low frequency wind fluctuations. That means they just modify the mean values of the wind. The exception to this are the clouds which really influence the high frequency turbulence simulated by the FDM's.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<br />
=== Mailing lists ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34618077/ Turbulence and JSBSim soaring]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/31346370/ Cloud turbulence]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/27782087/ Turbulence in YASim vs. JSBSim]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=97214Turbulence2016-04-18T08:29:59Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. This is possible via the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced weather]] with its so called gust settings, the [[Soaring#Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism#Ridgelift|FGRidgeLiftGlider]]), the [[Soaring#Wave lift|FGWaveLift]] and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these systems are not independent because you can use for example the convective cloud system with a realistic distribution of thermals only in the Advanced Weather mode (see [[Soaring#Setting the weather|Soaring]]) but that shall not be a subject of this article. Instead, the following sections will clarify how these different approaches can generate a realistic contribution to the turbulent wind field.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<br />
=== Mailing lists ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34618077/ Turbulence and JSBSim soaring]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/31346370/ Cloud turbulence]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/27782087/ Turbulence in YASim vs. JSBSim]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=97213Turbulence2016-04-18T08:22:58Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. This is possible via the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced weather]] with its so called gust settings, the [[Soaring#Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism#Ridgelift|FGRidgeLiftGlider]]) and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these systems are not independent because you can use for example the convective cloud system with a realistic distribution of thermals only in the Advanced Weather mode (see [[Soaring#Setting the weather|Soaring]]) but that shall not be a subject of this article. Instead, the following sections will clarify how these different approaches can generate a realistic contribution to the turbulent wind field.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<br />
=== Mailing lists ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34618077/ Turbulence and JSBSim soaring]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/31346370/ Cloud turbulence]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/27782087/ Turbulence in YASim vs. JSBSim]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=96756Weather2016-04-07T12:17:01Z<p>Lisbellaw: /* Weather pattern scales */</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 5000ft, wind 300° at 10 kt<br />
* Aloft layer, 10000ft, wind 310° at 20 kt<br />
* Aloft layer, 18000ft, wind 320° at 30 kt<br />
* Aloft layer, 24000ft, wind 330° at 50 kt<br />
* Aloft layer, 30000ft, wind 340° at 70 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to start FlightGear with the default weather settings mentioned above you have to take care about disabling METAR Data (look into the <tt>environment.xml</tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind'' in a height convenient to the atmospheric boundary layer thickness. If ''terrain presampling'' is disabled, the boundary layer thickness is 600 feet above ground level. The definition of the ''wind direction'' and ''speed'' has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the height above ground level of 1.2 times "lowest aloft wind speed"/ 10.0 times boundary layer altitude, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects.<br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses, that are typical for the predefined weather tiles. The airmass slider regulates the property /local-weather/config/large-scale-persistence. The values you can set through the silder vary between 0.5 (''small'') and 2.0 (''large''). It determines how long you are flying in a specific weather tile and if the weather tile will change while entering the tile border. A low value reduces the probability for staying in the same weather tile whereas a high value makes it very probably that the current weather tile does not change (see weather_tile_management.nas). <br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
* [[Turbulence]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=96755Weather2016-04-07T12:16:18Z<p>Lisbellaw: /* Weather pattern scales */correction airmass slider</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 5000ft, wind 300° at 10 kt<br />
* Aloft layer, 10000ft, wind 310° at 20 kt<br />
* Aloft layer, 18000ft, wind 320° at 30 kt<br />
* Aloft layer, 24000ft, wind 330° at 50 kt<br />
* Aloft layer, 30000ft, wind 340° at 70 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to start FlightGear with the default weather settings mentioned above you have to take care about disabling METAR Data (look into the <tt>environment.xml</tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind'' in a height convenient to the atmospheric boundary layer thickness. If ''terrain presampling'' is disabled, the boundary layer thickness is 600 feet above ground level. The definition of the ''wind direction'' and ''speed'' has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the height above ground level of 1.2 times "lowest aloft wind speed"/ 10.0 times boundary layer altitude, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects.<br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses, that are typical for the predefined weather tiles. The airmass slider regulates the property /local-weather/config/large-scale-persistence. The values you can set through the silder vary between 0.5 (small) and 2.0 (large). It determines how long you are flying in a specific weather tile and if the weather tile will change while entering the tile border. A low value reduces the probability for staying in the same weather tile whereas a high value makes it very probably that the current weather tile does not change (see weather_tile_management.nas). <br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
* [[Turbulence]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=96149Weather2016-03-22T15:24:22Z<p>Lisbellaw: /* Wind settings */</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 5000ft, wind 300° at 10 kt<br />
* Aloft layer, 10000ft, wind 310° at 20 kt<br />
* Aloft layer, 18000ft, wind 320° at 30 kt<br />
* Aloft layer, 24000ft, wind 330° at 50 kt<br />
* Aloft layer, 30000ft, wind 340° at 70 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to start FlightGear with the default weather settings mentioned above you have to take care about disabling METAR Data (look into the <tt>environment.xml</tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind'' in a height convenient to the atmospheric boundary layer thickness. If ''terrain presampling'' is disabled, the boundary layer thickness is 600 feet above ground level. The definition of the ''wind direction'' and ''speed'' has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the height above ground level of 1.2 times "lowest aloft wind speed"/ 10.0 times boundary layer altitude, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects.<br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
* [[Turbulence]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=96148Weather2016-03-22T15:23:17Z<p>Lisbellaw: /* Wind settings */</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 5000ft, wind 300° at 10 kt<br />
* Aloft layer, 10000ft, wind 310° at 20 kt<br />
* Aloft layer, 18000ft, wind 320° at 30 kt<br />
* Aloft layer, 24000ft, wind 330° at 50 kt<br />
* Aloft layer, 30000ft, wind 340° at 70 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to start FlightGear with the default weather settings mentioned above you have to take care about disabling METAR Data (look into the <tt>environment.xml</tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind'' in a height convenient to the atmospheric boundary layer thickness. If "terrain presampling" is disabled, the boundary layer thickness is 600 feet above ground level. The definition of the ''wind direction'' and ''speed'' has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the height above ground level of 1.2 times "lowest aloft wind speed"/ 10.0 times boundary layer altitude, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects.<br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
* [[Turbulence]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=96147Weather2016-03-22T15:21:31Z<p>Lisbellaw: /* Wind settings */added content</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 5000ft, wind 300° at 10 kt<br />
* Aloft layer, 10000ft, wind 310° at 20 kt<br />
* Aloft layer, 18000ft, wind 320° at 30 kt<br />
* Aloft layer, 24000ft, wind 330° at 50 kt<br />
* Aloft layer, 30000ft, wind 340° at 70 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to start FlightGear with the default weather settings mentioned above you have to take care about disabling METAR Data (look into the <tt>environment.xml</tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind'' in a height convenient to the atmospheric boundary layer thickness. If "terrain presampling" is disabled, the boundary layer thickness is 600 feet above ground level. The definition of the "wind direction" and "speed" has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the height above ground level of 1.2 times "lowest aloft wind speed"/ 10.0 times boundary layer altitude, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects.<br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
* [[Turbulence]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=96146Weather2016-03-22T14:47:35Z<p>Lisbellaw: /* Wind settings */</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 5000ft, wind 300° at 10 kt<br />
* Aloft layer, 10000ft, wind 310° at 20 kt<br />
* Aloft layer, 18000ft, wind 320° at 30 kt<br />
* Aloft layer, 24000ft, wind 330° at 50 kt<br />
* Aloft layer, 30000ft, wind 340° at 70 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to start FlightGear with the default weather settings mentioned above you have to take care about disabling METAR Data (look into the <tt>environment.xml</tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind'' in a height convenient to the atmospheric boundary layer thickness. If "terrain presampling" is disabled, the boundary layer thickness is 600 feet above ground level. The definition of the "wind direction" and "speed" has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the boundary layer, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects.<br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
* [[Turbulence]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=96145Weather2016-03-22T14:46:45Z<p>Lisbellaw: /* Wind settings */added content</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 5000ft, wind 300° at 10 kt<br />
* Aloft layer, 10000ft, wind 310° at 20 kt<br />
* Aloft layer, 18000ft, wind 320° at 30 kt<br />
* Aloft layer, 24000ft, wind 330° at 50 kt<br />
* Aloft layer, 30000ft, wind 340° at 70 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to start FlightGear with the default weather settings mentioned above you have to take care about disabling METAR Data (look into the <tt>environment.xml</tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind'' in a height convenient to the atmospheric boundary layer thickness. If "terrain presampling" is disabled, the boundary layer thickness is 600 feet. The definition of the "wind direction" and "speed" has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the boundary layer, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects.<br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
* [[Turbulence]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=95526Turbulence2016-03-10T21:27:38Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. In the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced weather]] with its so called gust settings, the [[Soaring#Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism#Ridgelift|FGRidgeLiftGlider]]) and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these systems are not independent because you can use for example the convective cloud system with a realistic distribution of thermals only in the Advanced Weather mode (see [[Soaring#Setting the weather|Soaring]]) but that shall not be a subject of this article. Instead, the following sections will clarify how these different approaches can generate a realistic contribution to the turbulent wind field.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<br />
=== Mailing lists ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34618077/ Turbulence and JSBSim soaring]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/31346370/ Cloud turbulence]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/27782087/ Turbulence in YASim vs. JSBSim]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=95525Turbulence2016-03-10T21:26:05Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. In the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced weather]] with its so called gust settings, the [[Soaring#Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism#Ridgelift|FGRidgeLiftGlider]]) and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these Systems are not independent because you can use for example the convective cloud system with a realistic distribution of thermals only in the Advanced Weather mode (see [[Soaring#Setting the weather|Soaring]]) but that shall not be a subject of this article. Instead, the following sections will clarify how these approaches can generate a realistic contribution to the turbulent wind field.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<br />
=== Mailing lists ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34618077/ Turbulence and JSBSim soaring]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/31346370/ Cloud turbulence]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/27782087/ Turbulence in YASim vs. JSBSim]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=95524Turbulence2016-03-10T21:17:27Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. In the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced weather]] with its so called gust settings, the [[Soaring#Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism#Ridgelift|FGRidgeLiftGlider]]) and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these Systems are not independent because you can use for example FGRidgeLift only in the Advanced Weather mode but that shall not be a subject of this article. Instead, the following sections will clarify how these approaches can generate a realistic contribution to the turbulent wind field.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<br />
=== Mailing lists ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34618077/ Turbulence and JSBSim soaring]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/31346370/ Cloud turbulence]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/27782087/ Turbulence in YASim vs. JSBSim]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=95522Turbulence2016-03-10T20:36:13Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. In the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced weather]] with its so called gust settings, the [[Soaring#Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism#Ridgelift|FGRidgeLiftGlider]]) and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these Systems are not independent because you can use for example FGRidgeLift only in the Advanced Weather mode but that shall not be a subject of this article. Instead, the following sections will clarify how these approaches can generate a realistic contribution to the turbulent wind field.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<br />
=== Mailing lists ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34618077/ Turbulence and JSBSim soaring]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/31346370/ Cloud turbulence]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/27782087/ Turbulence in YASim vs. JSBSim]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=95521Turbulence2016-03-10T20:35:09Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. In the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced weather]] with its so called gust settings, the [[Soaring# Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism#Ridgelift|FGRidgeLiftGlider]]) and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these Systems are not independent because you can use for example FGRidgeLift only in the Advanced Weather mode but that shall not be a subject of this article. Instead, the following sections will clarify how these approaches can generate a realistic contribution to the turbulent wind field.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<br />
=== Mailing lists ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34618077/ Turbulence and JSBSim soaring]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/31346370/ Cloud turbulence]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/27782087/ Turbulence in YASim vs. JSBSim]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=95520Turbulence2016-03-10T20:33:31Z<p>Lisbellaw: /* Related content */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. In the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced Weather]] with its so called gust settings, the [[Soaring# Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism# Ridgelift|FGRidgeLiftGlider]]) and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these Systems are not independent because you can use for example FGRidgeLift only in the Advanced Weather mode but that shall not be a subject of this article. Instead, the following sections will clarify how these approaches can generate a realistic contribution to the turbulent wind field. <br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<br />
=== Mailing lists ===<br />
* [https://sourceforge.net/p/flightgear/mailman/message/34618077/ Turbulence and JSBSim soaring]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/31346370/ Cloud turbulence]<br />
* [https://sourceforge.net/p/flightgear/mailman/message/27782087/ Turbulence in YASim vs. JSBSim]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=95519Turbulence2016-03-10T20:23:47Z<p>Lisbellaw: More Background</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. In the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
Apart from the Basic weather systems there are some more subsystems which can also generate wind fluctuations, especially vertical ones. In this context, the [[Advanced Weather]] with its so called gust settings, the [[Soaring# Ridge lift|FGRidgeLiftSoaring]] (see also [[Improving Glider Realism# Ridgelift|FGRidgeLiftGlider]]) and the [[Howto:Modelling clouds|Clouds/Thermals]] approach shall be mentioned. Of course these Systems are not independent because you can use for example FGRidgeLift only in the Advanced Weather mode but that shall not be a subject of this article. Instead, the following sections will clarify how these approaches can generate a realistic contribution to the turbulent wind field. <br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== Basic Weather ===<br />
It is possible to specify the turbulence level during running FlightGear in the Basic Weather System where you have the choice between none, light, moderate, severe (see [[#Background|Background]]). Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" has a magnitude equal to the square of these values.<br />
<br />
=== Advanced Weather ===<br />
=== FGRidgeLift ===<br />
=== Clouds ===<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=95512Turbulence2016-03-10T19:45:13Z<p>Lisbellaw: /* FDMs */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. In the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx).<br />
<br />
When you want to specify the turbulence level during running FlightGear in the Basic Weather System you have the choice between none, light, moderate, severe (see [[#Background|Background]]) . Through choosing one of these levels the above mentioned property "/environment/turbulence/raw-magnitude-norm" is set to a value that follows the subsequent procedure:<br />
<br />
*none = 0<br />
*light = 1/3<br />
*moderate = 2/3<br />
*severe=1<br />
<br />
Accordingly, "/environment/turbulence/magnitude-norm" is the square of these values. The following lines should explain the further transfer of this quantity with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=95460Turbulence2016-03-10T16:44:39Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear when your are using the Basic Weather system. In the menubar ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). In the appearing window you can set the turbulence to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=95455Turbulence2016-03-10T16:35:28Z<p>Lisbellaw: /* Forum topics */ Some more posts</p>
<hr />
<div>{{Stub}}<br />
<br />
This article will try explain how '''turbulence''' works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear in ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). You can set the turbulence there to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer with respect to the used FDM.<br />
<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[JSBSim]]<br />
* [[Weather]]<br />
* [[YASim]]<br />
<br />
=== Forum topics ===<br />
* [http://forum.flightgear.org/viewtopic.php?f=25&t=24659 Turning off turbulence]<br />
* [http://forum.flightgear.org/viewtopic.php?f=69&t=28335 Turbulence numbers]<br />
* [http://forum.flightgear.org/viewtopic.php?f=17&t=28807 Processing the option --turbulence=n.n]<br />
<!--<br />
=== Source code ===<br />
*<br />
--><br />
<br />
[[Category:Weather]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=94647Weather2016-03-03T18:35:47Z<p>Lisbellaw: /* Basic Weather */ Modifying default values</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 5000ft, wind 300° at 10 kt<br />
* Aloft layer, 10000ft, wind 310° at 20 kt<br />
* Aloft layer, 18000ft, wind 320° at 30 kt<br />
* Aloft layer, 24000ft, wind 330° at 50 kt<br />
* Aloft layer, 30000ft, wind 340° at 70 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to start FlightGear with the default weather settings mentioned above you have to take care about disabling METAR Data (look into the <tt>environment.xml</tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind''. It has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the boundary layer, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects. <br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=94646Weather2016-03-03T18:15:52Z<p>Lisbellaw: /* Basic Weather */</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 3000ft, wind 300° at 10 kt<br />
* Aloft layer, 6000ft, wind 310° at 20 kt<br />
* Aloft layer, 9000ft, wind 320° at 30 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to start FlightGear with the default weather settings mentioned above you have to take care about disabling METAR Data (look into the <tt>environment.xml</tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind''. It has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the boundary layer, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects. <br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=94645Weather2016-03-03T18:12:40Z<p>Lisbellaw: /* Basic Weather */</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 3000ft, wind 300° at 10 kt<br />
* Aloft layer, 6000ft, wind 310° at 20 kt<br />
* Aloft layer, 9000ft, wind 320° at 30 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to have this default settings after starting FlightGear you have to take care about disabling METAR Data (look into the <tt>environment.xml</tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind''. It has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the boundary layer, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects. <br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=94644Weather2016-03-03T18:12:12Z<p>Lisbellaw: /* Basic Weather */</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 3000ft, wind 300° at 10 kt<br />
* Aloft layer, 6000ft, wind 310° at 20 kt<br />
* Aloft layer, 9000ft, wind 320° at 30 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to have this default settings after starting FlightGear you have to take care about disabling METAR Data (look into the <tt>environment.xml<\tt> file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind''. It has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the boundary layer, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects. <br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=94643Weather2016-03-03T18:10:28Z<p>Lisbellaw: /* Basic Weather */</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 16093.4m, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 3000ft, wind 300° at 10 kt<br />
* Aloft layer, 6000ft, wind 310° at 20 kt<br />
* Aloft layer, 9000ft, wind 320° at 30 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button. When you want to have this default settings after starting FlightGear you have to take care about disabling METAR Data (look into the environment.xml file under metar-updates-... and set them to false).<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind''. It has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the boundary layer, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects. <br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=94642Turbulence2016-03-03T17:38:14Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
Written by: {{Usr|Lisbellaw}} (3/2016)<br />
<br />
== Objective ==<br />
Explain how turbulence works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear in ''Environment > Weather Conditions'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). You can set the turbulence there to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer with respect to the used FDM. <br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
<br />
<br />
<br />
<br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
== Related ==</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Weather&diff=94628Weather2016-03-03T17:02:35Z<p>Lisbellaw: /* Basic Weather */ other path to default settings</p>
<hr />
<div>FlightGear simulates '''weather''' through one of two weather engines, that provide real weather fetch, predefined weather scenarios, [[3D clouds]] and much more. Weather simulation is not easy, and setting up these systems for the most general needs will be explained below, as well as the features they provide.<br />
[[File:Local_weather_0.85_01.jpg|thumb|450px|right|Advanced Weather clouds over the mountains]]<br />
<br />
== Fundamentals ==<br />
[[File:Weather scenario selection.png|thumb|250px|Weather scenario selection in the main Weather dialog. You can also see where the METAR is shown, and can be edited in ''Manual input'' mode]]<br />
[[File:Windboundaries.png|thumb|250px|A drawing giving an idea of what's the boundary/aloft layer separation (drawn in red)]]<br />
[[File:ASW-20 landing configuration.png|thumb|350px|Advanced Weather can simulate the conditions for [[soaring]]]]<br />
Weather is the state of the atmosphere, especially the {{wikipedia|troposphere}}, at a given time for a given place. Calculating the complete atmosphere or even a small part of it is extremely demanding in computing power. Hence, FlightGear calculates the state of the atmosphere only for a vertical line beginning at earth's center straight through your aircraft up to an appropriate altitude. For every point along this line, the following fundamental parameters are calculated:<br />
* '''temperature''': usually in °C.<br />
* '''{{wikipedia|dew point}}''': indicating at what temperature the air in that point would become a "cloud". It gives an indication of the {{wikipedia|relative humidity}}.<br />
* '''pressure''': in inches of mercury (inHg) or hectopascals (hPa)<br />
* '''density''': this affects the behaviour of the aircraft.<br />
* '''wind''': usually in knots (kt), includes the vertical component and any turbulence.<br />
* '''visibility''': usually in meters or statute miles (''not'' nautical! 1 SM is ~1600 m), tries to define how far an object can be seen, horizontally.<br />
<br />
=== Atmosphere layers ===<br />
Like the real atmosphere, the simulated one is divided in layers. For what concerns flight, a first distinction is made with the ''boundary layer'' and the ''aloft layer''. The {{wikipedia|Planetary boundary layer|boundary layer}} is the thin one close to ground, where the atmosphere, mainly the wind, is affected by the earth's surface. Its thickness may vary depending on how rough the ground is (e.g. sea as opposed to Alps), but in general it's less than 600 ft AGL. The aloft layer is immediately above the boundary one, and is by definition not affected by ground, i.e. there is free to flow air.<br />
<br />
Within these layers, there are other sub-layers that can be defined, because the atmosphere still changes a lot, especially in the aloft layer. These sub-layers in FlightGear define the state of the fundamental parameters above, and can specifically define the presence of clouds. For the points in between, the values are calculated by interpolation, e.g. if you're halfway between two, the values will be set to the average.<br />
<br />
=== Clouds ===<br />
Real life clouds are humidity that become visible when dew point and temperature match, that is when air is saturated. Computing this for the whole atmosphere would be very realistic, and would need, again, some supercomputers, some patience and a huge amount of real data.<br />
<br />
Clouds are therefore simulated by specifying at what altitudes they should be, their kind (fluffy, flat, cotton balls...) and other cloud-related phenomenons (precipitations, thermals...) To make things realistic one must either know very well what to do (Basic Weather) or rely on some advanced algorithms (Advanced weather.) Or use a preset scenario.<br />
<br />
=== Scenarios and METAR ===<br />
Defining weather can be a tedious task, as setting all the parameters for each layer is not everybody's fun. For this reason, in the in-sim dialog ''Environment > Weather Conditions'' you can choose what is called a ''weather scenario''. Scenarios are presets of weather conditions.<br />
<br />
Besides scenarios, FlightGear has a built in [[METAR]] interpreter. This can read the coded weather information from a METAR and apply a more or less reasonable weather, that matches the conditions described in the METAR. Since a METAR ''only describes the weather at a station on the ground'', many parameters, esp. for the higher atmosphere are ''just plain guesses'' which just try to be reasonable.<br />
<br />
You can either pass a METAR string with the [[command line options]] (<tt>--metar=</tt>) or choose ''Live data'' or ''Manual input'' from the ''Weather Conditions'' drop-down menu, where you can enable live weather data or enter your own METAR. The ''Live data'' option enables a task that calculates your nearest airport and fetches the current METAR for that station from NOAA weather service.<br />
<br />
== The two weather systems ==<br />
The two systems are generally referred to as:<br />
* '''Basic weather''' (BW), the historical and default weather system (sometimes called ''Global weather''), and<br />
* '''Advanced weather''' (AW), formerly known as ''Local weather'' and called ''Detailed weather'' in-sim (this is probably a leftover of previous dialog designs.)<br />
<br />
Although they model the same thing, they don't have much in common. Here's a non-exhaustive comparison:<br />
{| class="wikitable" width="60%"<br />
! Basic Weather<br />
! Advanced Weather<br />
|-<br />
| Very simple and straightforward to setup and customize, but can lead to non-realistic conditions and doesn't integrate some advanced features.<br />
| Can be puzzling, but it treats all the variables as a whole keeping things close to reality.<br />
|-<br />
| Knows nothing about the effect of terrain on weather.<br />
| Can make clouds and wind climb up a slope and flow around a mountain peak, and generate thermals consistent with the ground and the clouds (and much more.)<br />
|-<br />
| Applies the same weather conditions for your position and for every other part of the world.<br />
| Can be set up to simulate realistic weather distribution.<br />
|-<br />
| Lets you specify visibility.<br />
| Forces visibility to be consistent with the weather.<br />
|-<br />
| Is part of the FlightGear C++ code.<br />
| Runs in [[Nasal]] space.<br />
|}<br />
<br />
To make it short, each of them has their pros and cons, but in general:<br />
* if you plan to tweak the weather setup, be ready to read some documentation, at least this article and especially for AW;<br />
* if you plan to simply use the weather scenarios, you should probably try AW, because out of the box it gives more realistic results.<br />
<br />
== Basic Weather ==<br />
[[File:Basic weather selected.png|thumb|350px|Basic Weather selected in the main Weather dialog]]<br />
In Basic Weather most calculations are based on the {{wikipedia|International Standard Atmosphere}}. The default weather definition is:<br />
* Boundary layer, 0ft, wind 270° at 3 kt, visib. 10SM, 29.92inHG (1013hPa), temp. 15°C, dewpoint 5°C<br />
* Boundary layer, 500ft, wind 280° at 6 kt<br />
* Aloft layer, 3000ft, wind 300° at 10 kt<br />
* Aloft layer, 6000ft, wind 310° at 20 kt<br />
* Aloft layer, 9000ft, wind 320° at 30 kt<br />
All other values are derived from these parameters. The atmospheric parameters described here are defined in <tt>[[$FG_ROOT]]/Environment/environment.xml</tt>, but they can be changed in-sim by selecting ''Environment > Weather Conditions'' from the menu, enabling ''Manually Configure Weather'' and clicking the ''Manual Configuration...'' button.<br />
<br />
Of course, that's not the only way to configure BW. In fact, it supports the weather scenarios and can read METAR data, be it manually inserted or fetched on-the-fly.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
''Remember that any weather you set up, it will be applied to the whole world.''<br />
<br />
=== Manual configuration ===<br />
[[File:Basic weather dialog.png|thumb|350px|Manual configuration dialog for Basic Weather]]<br />
The Basic Weather manual configuration dialog is mainly split in four: cloud layers, precipitations and pressure, aloft layers and boundary layers.<br />
<br />
==== Clouds ====<br />
Clouds are stacked in layers and for each layer the defining parameters for clouds are:<br />
* coverage (clear, few, scattered, broken, overcast)<br />
* the altitude of cloud base (Above Mean Sea Level)<br />
* the thickness (distance from cloud base to cloud top)<br />
Once again, the definition of the default cloud set is in preferences.xml.<br />
<br />
==== Precipitations and pressure ====<br />
Precipitation should be pretty clear, just notice that only one of snow or rain can be active at one time, and that the change is smoothed, so you have to wait some time to see the full effect of the precipitation. QNH is where to set the pressure at sea level. <br />
<br />
==== Aloft and boundary layers ====<br />
The layers tables can be filled with information on altitude (elevation AGL for the boundary layer), wind direction and speed, visibility, temperature and dew point, turbulence. These values will be interpolated for the heights in between.<br />
<br />
== Advanced Weather ==<br />
[[File:Advanced weather selected.png|thumb|350px|Advanced Weather selected in the main Weather dialog]]<br />
[[File:AW Weather patterns.jpg|thumb|Weather pattern in the Advanced Weather scenarios. You can see the various airmasses.]]<br />
[[File:Clouds-nimbostratus.jpg|thumb|400px|It can't rain all the tile]]<br />
[[File:Advanced weather tile selection mode.png|thumb|Tile selection mode from Advanced Weather settings]]<br />
''If you're in a hurry, please read at least the [[#Quirks|Quirks]] section, for your own good''.<br />
<br />
Advanced Weather not only tries to be more realistic than the Basic Weather, but also adds some effects and tries to keep them all bound together like they are in real life. This means, to give some examples, that clouds move with the wind, and the thermals that generated them in a sunny day will move with them and keep evolving with them, varying their own activity during the day, since when they start where it's more probable (depending on ground type) to when they die over the water or because the ground heat vanishes with the sunset.<br />
<br />
Such convective system, and other details like the ridge lift, allow not just for a nice distribution of clouds, but even for [[soaring|simulating soaring with gliders]]. And these are just some small scale effects. <br />
<br />
=== Advanced Weather scenarios ===<br />
Advanced Weather can also take into account the larger scale phenomenon of the interaction of high and low pressure areas. However, this can work only with some specific "offline" scenarios and another particular setting (see [[#General settings|tile modes]] below), because they allow making assumptions that the METAR (live or manual) with its limited information doesn't permit (even if live METAR can compensate this to some degree.) These scenarios are:<br />
* Core high pressure region<br />
* High pressure region<br />
* Border of a high pressure region<br />
* Border of a low pressure region<br />
* Low pressure region<br />
* Core low pressure region<br />
* Warm sector<br />
<br />
These correspond to some ''{{wikipedia|Air mass|airmasses}}'' which are well defined areas of a map (see the picture) that simulate a classic patterns of {{wikipedia|Extratropical cyclone|cyclones}} and {{wikipedia|Anticyclone|anticyclones}}, as we often see them in the weather forecast maps of mid-latitude areas. So, for example, if you start flying in a low pressure region and keep flying towards E-N-E, you will eventually see how the weather changes while you move to higher pressure regions. Being a large scale phenomenon, this of course requires mid or long range flights.<br />
<br />
Tropical areas currently have a ''weather tile'' definition but it's not used by any scenario. Also, at the moment there's no definition for polar areas.<br />
<br />
In any case, you have to click ''Apply'' or ''OK'' to make the choice effective.<br />
<br />
==== Weather tiles ====<br />
This will be just a quick peek under the hood of Advanced Weather. This weather simulation engine approaches the problem of the local weather definition by using ''weather tiles'' 40x40 km² wide. There are predefined weather tiles corresponding to certain conditions, and the way AW places them is configurable, to some extent (see [[#Tile selection mode|below]].)<br />
<br />
With some knowledge of [[Nasal]], it is also possible to [[Advanced weather#Creating custom Weather Tiles|define custom tiles]] which can reproduce particular, very ''local'' weather conditions or phenomena (e.g. wind shear).<br />
<br />
In normal conditions, though, you don't have to worry about weather tiles.<br />
<br />
=== Advanced configuration ===<br />
[[File:Advanced weather dialog.png|thumb|270px|Settings dialog for Advanced Weather]]<br />
Although the ''Advanced Weather Configuration'' dialog doesn't look that complex, some of the options need a good understanding of what they do. Actually, most of them affect or are affected by other options, and this requires a special care, because you might try to combine incompatible settings or spend hours in tuning one that is disabled.<br />
<br />
==== General settings ====<br />
Here you can set the ''Tile selection mode'' and terrain presampling options.<br />
<br />
When ''Terrain presampling'' is enabled, AW analyzes the terrain height to consider it in its calculations of the distribution of clouds.<br />
<br />
Once this is activated, the ''Terrain effects'' option becomes available. When checked, the ''type'' of terrain (city, crops...) is also taken into account for the distribution of clouds, and their thermals if enabled; also, the shape of terrain determines ridge lift. This option is especially recommended to glider pilots, while the faster and higher pilots won't notice it, most of the time.<br />
<br />
However, if ''Terrain presampling'' is disabled to save some CPU time, AW will not know about ground and will put cloud layers as if at sea level. This is not bad if you ''are'' at sea level, but if you're on the Himalaya you might have clouds underground. So, you might have to set the ''Altitude offset'' conveniently.<br />
<br />
The ''Temperature offset'' is used with scenarios. Since they come with their own pre-defined temperature, that's the only way to simulate winter using them, so if you select a high pressure tile but specify a -45 deg temperature offset, you'll end up somewhere around -10 deg and get a decent arctic airmass for the effort. It has nothing to do with terrain effects.<br />
<br />
The ''Tile selection mode'' specifies how tiles are automatically generated once the aircraft reaches the border of the original tile. It is a good idea to leave this setting as you find it, because it's automatically set when a scenario or METAR is selected. For those who dare, here's an explanation of the options:<br />
* ''single tile'' just won't generate any further tiles. If you go outside of that beware of dragons.<br />
* ''repeat tile'' creates new tiles of the same type as the originally selected tile, randomized to some degree. It only works with AW scenarios (to which actually corresponds a tile definition) and is automatically selected with ''Thunderstorm''.<br />
* ''realistic weather'' works only with the AW scenarios, and is automatically selected with them. It simulates the realistic distribution of airmasses.<br />
* ''METAR'' is automatically selected with ''Live data'' and ''Manual input'' and non-AW scenarios. Basically, it tries to give the best interpretation of the METAR string.<br />
<br />
The first two are good ones if you're testing a custom tile to simulate a particular weather condition, and can't be made to work with all the scenarios. Most of the time, however, the other two options are the right choice, and they're also automatically selected, so you probably shouldn't care about this option.<br />
<br />
==== Wind settings ====<br />
[[File:Advanced weather winds dialog.png|thumb|350px|Wind configuration from Advanced Weather settings. This works in ''Aloft interpolation'' and ''Aloft waypoint'' mode.]]<br />
[[File:Advanced weather wind models.png|thumb|A representation of Advanced Weather wind models]]<br />
This is the trickiest part. We'll describe each setting singularly, and in what cases they can be used/will have effect.<br />
<br />
''Wind direction'' and ''speed'' define ''the lowest aloft wind''. It has no effect in METAR tile mode (because AW deduces it from the METAR itself, which reports the ''ground'' wind) and/or when the wind model is ''aloft interpolated'' or ''aloft waypoint'' (because that wind is used instead - see below). Otherwise you can use it.<br />
<br />
''Gust settings'' are the happiest ones: they always work, immediately, no click needed, but if a new live METAR comes in (because you moved to a new area) they'll be overwritten. Their meaning should be self-explanatory. Note that gusts are only effective in the boundary layer, i.e. when close enough to the ground.<br />
<br />
''Wind model'' defines how the wind should change in space:<br />
* ''constant'' sets the same wind everywhere, as specified in the dialog or derived from the METAR. This wind is the lowest aloft wind, and the boundary layer behaves consistently.<br />
* ''constant in tile'' is like the above, but adds a wee bit of realism by introducing little changes in the wind direction and speed when crossing tiles.<br />
* ''aloft interpolated'' allows to specify through the ''Wind Configuration'' dialog how aloft winds change with altitude, similarly to Basic Weather. Does not work in METAR mode.<br />
* ''aloft waypoints'' is like the above, but lets you specify many positions (called here "waypoints") and AW will interpolate them in the 3D space. In METAR mode it works automatically and, instead of using the user data, it guesses the vertical distribution of winds on its own based on the reported ground wind, especially using as waypoints the live METAR stations.<br />
<br />
Finally, the ''Wind Configuration'' dialog, reachable with the button at the bottom, is the one used by the ''aloft'' wind models. It should be self explaining, but remember to set at least one waypoint if you want to use ''aloft waypoints'' in non-METAR mode. Also, the value for level ''zero'' is not meant to be ground level, but the lowest aloft layer, i.e. the one just above the boundary layer. This dialog is especially uncomfortable with waypoints, because that mode is intended for use with [[Howto: Fetch live aloft data|live aloft wind data]], that someday might become available (again.)<br />
<br />
Note that the boundary layer is always calculated, but is less realistic without terrain effects. <br />
<br />
==== Thermic and visibility settings ====<br />
''Generate thermals'' should be clear. It depends on having ''Terrain effects'' enabled, and the size and intensity of these thermals can be set with the ''Convective conditions'' slider: ''rough'' makes them very localized and entering them will give you a good shake, while ''low'' makes them larger, with less lift and little to no turbulence while entering them.<br />
<br />
''Ground haze'', ''Air pollution'' and ''Fog properties'' work as you move them, so we'll let you find out what they do. However, they work only when not in [[Project Rembrandt|Rembrandt mode]] and with [[Atmospheric light scattering]] enabled.<br />
<br />
''Max visibility'' is there to prevent that AW sets a too high visibility that could kill your framerate. Preventing a dangerously high visibility is also why you need to check ''Realistic visibility'' to get a few more kilometers, but it's still on the conservative side. More on visibility [[#Visibility, cloud distance and performance|below]].<br />
<br />
==== Weather pattern scales ====<br />
These options are active only when in ''realistic weather'' mode, and are most useful if you're a medium or long haul flyer.<br />
<br />
''Airmass'' controls the transition between different airmasses. In the default setting, the typical distance to encounter a different airmass when one flies in a 'High-pressure-core' tile is 200 km. The airmass slider allows to vary this distance between 200 and 800 km.<br />
<br />
''Cloud patterns'' is in a way bound to the previous setting. For each tile type there are some basic cloud layer definitions (patterns) that are chosen randomly. The ''cloud patterns'' slider defines how "often" spatially these patterns change. With a ''large'' scale the theme of clouds will remain similar within each airmass, a ''small'' scale allows for more variation.<br />
<br />
=== Quirks & caveats ===<br />
[[File:3D clouds.jpg|thumb|350px|Clouds as they were in 2008]]<br />
Advanced Weather and its interface are known to have some idiosyncrasies and non intuitive behavior. In general, a good way of thinking of the AW engine is that it needs to be started and that, once running, can't be widely adjusted without a restart, i.e. clicking OK again. Here are some hints:<br />
* If you clicked OK and can't see any cloud at all, you probably set up things in a way that AW doesn't like. Incompatible settings are described above.<br />
* If you made some changes, but you can't ''see'' any even after clicking OK, and the above case is not applicable, you probably didn't follow the working pattern that AW requires:<br />
*# select the scenario (or METAR) (this will likely overwrite some of the advanced settings)<br />
*# open the advanced settings and make a (compatible) setting, then click OK<br />
*# if needed, set the sim time<br />
*# click Apply or OK in the main weather dialog.<br />
* If you change scenario (or METAR) while the advanced settings dialog is open, it might not be consistently updated. Better to close it before changing scenario, to avoid misunderstandings.<br />
Again, these problems are known, and are tough enough to tackle that managed to survive through various interface redesigns.<br />
<br />
=== Autostarting Advanced Weather ===<br />
Currently, the choice of Advanced Weather is not saved through sessions. To enable this, use <tt>--prop:/local-weather/autostart=1</tt> and then check the property in the Nasal init code using <tt>getprop("/local-weather/autostart")</tt>, if it's true, invoke the same routines as the dialog's ok/apply buttons (see the corresponding bindings), and you'll end up with a fully optional autostart-feature. To retain the setting, set the <tt>userarchive</tt> attribute to true. Yes, it's not straightforward.<br />
<br />
=== More on Advanced Weather ===<br />
If you're interested in knowing all that the Advanced Weather engine does and can do, and its inner workings, in FlightGear's base package documentation there is <tt>[[$FG_ROOT]]/Docs/README.local_weather.html</tt>. Although outdated with respect to the user interface, the mechanisms and principles are still valid.<br />
<br />
The original project was presented in [[Advanced weather]].<br />
<br />
== Visibility, cloud distance and performance ==<br />
[[File:X-15-iceland03.jpg|thumb|400px|Now, that's what I call a decent visibility (caution: this screenshot was taken on high end hardware)]]<br />
Basic Weather keeps visibility and weather relatively untied: by using the {{key press|z}} and {{key press|shift|z}} keys you can set the visibility you like.<br />
<br />
Advanced Weather does the opposite, setting visibility to what the atmosphere condition suggests. However, this could set a too high visibility that could lead to bad performance. For this reason, using {{key press|z}} and {{key press|shift|z}} doesn't work as with Basic Weather, but sets the ''Max visibility'' we've already seen.<br />
<br />
Moreover, using live METAR data will often not give the same good visibility you have out of the window. This is because the METAR string is often reported with visibility in meters, in which case the maximum is 9999 m even if it's way more. That is because METAR is intended for airport operations, not for full weather reports. AW knows that, but does what it can.<br />
<br />
For both these reasons you might be unsatisfied with the visibility you're presented with in AW. If ''realistic visibility'' is not enough for you, you can "artificially" increase it by using ''Manual input'' and specifying it in statute miles. This way you can bypass the limit of the 9999 meters, and the atmosphere condition is adjusted accordingly and stays coherent.<br />
<br />
The same partially applies also to how far clouds are drawn. The system is designed to draw them as far as 80 km (at least in AW), but that would easily kill the framerate of most machines. So, the slider in the ''Rendering options'' dialog is limited to 45 km. You can set it to higher values (max 80 km) by opening the property browser and editing <tt>/sim/rendering/cloud-visibility-range</tt>. In FG 3.2, though, new rendering techniques ("impostors") will allow for larger limits.<br />
<br />
== Related content ==<br />
* [[Howto: Fetch live aloft data]]<br />
* [[Weather reports]]<br />
<br />
[[Category:Weather| ]]<br />
<br />
[[es:Clima]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=94404Turbulence2016-02-29T20:54:11Z<p>Lisbellaw: /* JSBSim */</p>
<hr />
<div>{{Stub}}<br />
<br />
Written by: {{Usr|Lisbellaw}} (3/2016)<br />
<br />
== Objective ==<br />
Explain how turbulence works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear in ''Environment > Weather'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). You can set the turbulence there to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer with respect to the used FDM. <br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. Note that for the ttTustin case no distinction have to be made at this point although you can recognize other turbulence. This have something to do with the exact calculation in FGWind.cpp which is not trival. But you can also see in this file that the probability_of_exceedence_index you have set indirectly via <code>--turbulence=value</code> influences only the shared code for both cases. Therefore you can handle ttMilspec and ttTustin the same, at least for the issue disscused here.<br />
<br />
If you have chosen ttCulp then ... <br />
<br />
<br />
<br />
<br />
<br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
== Related ==</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=94399Turbulence2016-02-29T20:29:06Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
Written by: {{Usr|Lisbellaw}} (3/2016)<br />
<br />
== Objective ==<br />
Explain how turbulence works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear in ''Environment > Weather'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]). You can set the turbulence there to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer with respect to the used FDM. <br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. <br />
<br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
== Related ==</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=94398Turbulence2016-02-29T20:25:36Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
Written by: {{Usr|Lisbellaw}} (3/2016)<br />
<br />
== Objective ==<br />
Explain how turbulence works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specifies the turbulence from 0.0 (calm) to 1.0 (severe). <br />
<br />
The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. <br />
<br />
For example, you can switch between some turbulence models when you choose JSBSim as your flight dynamic model (FDM). Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
Furthermore you can specify the turbulence level during running FlightGear in ''Environment > Weather'' when you enable Manual Configuration and click on the button at the right which is also called Manual Configuration (see [[Weather]]. You can set the turbulence there to four values: none, light, moderate and severe. This article will also discuss the internal processing of these settings and what they actually mean in the different turbulence calculations.<br />
<br />
== Properties ==<br />
{{See also|Fixing Presets}}<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [[$FG_ROOT]]/Environment/interpolator.xml):<br />
<br />
<br />
<syntaxhighlight lang="xml"><br />
<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
<input><br />
<expression><br />
<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
</syntaxhighlight><br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [[$FG_ROOT]]/Environment/environment.xml file at the following place:<br />
<br />
<br />
<syntaxhighlight lang="xml"><br />
<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
</syntaxhighlight><br />
<br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer with respect to the used FDM. <br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [[JSBSim_Atmosphere]]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
<syntaxhighlight lang="cpp"><br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
</syntaxhighlight><br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [[$FG_SRC]]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [[$FG_SRC]]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
<syntaxhighlight lang="cpp"><br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
</syntaxhighlight><br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [[$FG_SRC]]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. <br />
<br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
== Related ==</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=De/HB_Radio-NAV&diff=94187De/HB Radio-NAV2016-02-28T16:57:14Z<p>Lisbellaw: /* Der Autopilot (AP) */</p>
<hr />
<div><small>''Dies ist ein Teil des deutschen "Flightgear Handbuches", aufbauend auf der originalen "getstart.pdf". Besuche auch die anderen Teile durch Maus-Klick auf:''</small> <br />
<br />
{{HBmenu}}<br />
<br />
----<br />
=='''Ãœbersicht'''==<br />
Radios und Navigationsgeräte gibt es in den unterschiedlichsten Bauformen und Funktions-Einheiten. In modernen Flugzeugen sind die Geräte selbst meist hinter Verkleidungen installiert – und auch die Anzeigen und Bedienelement sind oft in andere Baugruppen integriert.<br />
Lass uns im Folgenden die Funktion und Bedienung der verschiedenen Radio-Funktionen an den übersichtlichen Bauformen der äußerst großzügig ausgestatteten C172p studieren:<br />
{|<br />
||[[File:c172p-Radio-Tower-De.png|650px|thumb|left|Die Radio-Einheiten der c172p]]<br />
|}<br />
Im Folgenden beschreiben wir die einzelnen Einheiten von oben nach unten (siehe auch die Beschriftungen rechts):<br />
<br /><br /><br />
----<br />
=='''Die Audio-Kontrolleinheit'''==<br />
Jede Radio-Einheit produziert Audio-Ausgaben, die recht störend wirken können wenn sie alle gleichzeitig los-plärren, und damit ein unverständliches Gemisch von mehreren Sprach-Ausgaben, Morse-Codes, Peiltönen, etc. produzieren. Mit der Audio-Kontrolleinheit wird gesteuert, welche Audio-Ausgänge jeweils auf Lautsprecher und/oder Kopfhörer geschaltet werden, und welche derzeit stumm bleiben. Die Bedienung ist selbsterklärend. '''''Allerdings: '''''Diese Einheit ist in unsere C172p (zur Zeit dieses Schreibens) nicht funktionell: Es lassen sich zwar alle Schalter bewegen – aber ohne Funktion! Allerdings benötigen wir diese Funktion auch nicht unbedingt, denn an jedem Einzel-Gerät lässt sich der Audio-Ausgang individuell ein/aus-schalten.<br />
{| style="width:100%"<br />
|-<br />
||[[File:C172-Audio-Control-Unit.png |210px|thumb|left|C172-Radios-ADF-NDB]]Mit dem linken Drehschalter schaltest Du Dein Mikrofon auf einen der beiden Sender (COM1 oder COM2).<br />
Darunter befinden sich 3 Licht-Anzeigen, die während des End-Anfluges bedeutungsvoll sind:<br />
*'''''Outer-Marker: '''''Das '''''blau'''''e Licht, zusammen mit einem '''''400 Hz''''' Ton wird 4-7 mi vor dem Aufsetzpunkt aktiv.<br />
*'''''Middle-Marker: '''''Das '''''gelb'''''e Licht, zusammen mit einem '''''1300 Hz''''' Ton wird 0.5 - 0.8 mi vor dem Aufsetzpunkt aktiv.<br />
*'''''Inner Marker: '''''das '''''weiße''''' Licht, zusammen mit einem '''''3000 Hz''''' Ton wird direkt über dem Aufsetzpunkt aktiv.<br />
|}<br />
<br /><br />
----<br />
=='''Das {{HBabbr|ADF}} / {{HBabbr|NDB}}'''==<br />
{| style="width:100%"<br />
|-<br />
||[[File:C172-Radios-ADF-NDB.png|600px|thumb|left]] <br />
|}<br />
Mit dem „'''A'''utomatic '''D'''irection '''F'''inder“ (''Radiokompass, Empfänger)'' können wir ein '''"N'''on-'''D'''irectional '''B'''eacon" ''(ungerichtetes Funkfeuer)'' anpeilen und mittels des Richtungsanzeigers ''<small>(der gelbe Pfeil in obiger, mittleren Abbildung</small>)'' in dessen Richtung fliegen. Im Beispiel oben müssten wir also unseren derzeitigen Kurs um 20° nach rechts ändern, um zum {{HBabbr|NDB}} zu gelangen! Mit anderen Worten: Du fliegst so, dass die gelbe Nadel senkrecht nach oben zeigt - und kümmerst Dich absolut nicht darum was Dein Kompass anzeigt!<br />
<br />
Du findest die {{HBabbr|NDB}}s in den Luftkarten als rötliche Punkte mit einem runden Wolken-ähnlichen Gebilde um sich herum. {{HBabbr|NDB}}s haben wie {{HBabbr|VOR}}'s einen vollen Namen (z.B. „REIGA“), eine Kennung („LV“) die auch als Morse-Code über das Radio übertragen wird, und natürlich eine Frequenz („374“). ''(Die Darstellung oben rechts ist die Darstellung in der [[De/HB_Features#MPmap|MPmap]])''.<br />
<br />
Zur Benutzung eines {{HBabbr|NDB}} stellst Du dessen Frequenz ein und verifizierst als allererstes dessen Morsecode im Lautsprecher.<br />
<br /><small>''Zum Zeitpunkt des Schreibens funktionierte das Abhören des "Morse-Codes" nicht, somit verifiziere mit anderen Mitteln, dass Du tatsächlich auf das richtige {{HBabbr|NDB}} zufliegst - z.B. mittels der [[De/HB_Features#MAP|Map.]])''</small><br />
<br />Wenn der Morse-Code stimmt folge der Nadel im Instrument, d.h.: Halte diese immer senkrecht nach oben. Du fliegst dann also nicht nach Kompass – sondern in die Richtung der Nadel, vergiss hierbei die Kompass-Rose im Instrument! <br />
<br />
<br />
'''''Der Schwachpunkt dieser Navigation mittels {{HBabbr|ADF}}/{{HBabbr|NDB}}''''' ''(gegenüber der z.B. mittels eines {{HBabbr|VOR}})'' ist, dass nur die Richtung (heading = Nase hin) zum {{HBabbr|NDB}} angezeigt wird - aber die für das Einhalten des "'''''Wanted Course'''''" benötigte Richtung unbekannt ist. Siehe z.B.:<br />
{| style="width:100%"<br />
|-<br />
||[[File:NDB wind deviation.jpg |left]]<br />
*Wenn Du einfach dem Zeiger zum {{HBabbr|NDB}} folgst, wird Dich ein Seiten-Wind versetzen, so dass Du tatsächlich dem hier gezeigten "'''''Actual Course'''''" folgst!<br />
:'''''Dieses gleiche Abdriften passiert auch, wenn Du einen Autopiloten benutzt um auf einen {{HBabbr|NDB}} zuzufliegen!'''''<br />
<br />
*Du bist der Einzige der von Anfang an die "Heading" (Nase) etwas in den Wind drehen kann um den gewünschten "'''''Wanted Course'''''" (Kurs über Boden!) zu verfolgen. (Siehe hierzu eine Anwendung im Kapitel "{{HBabbr|IFR}} Cross-Country", [[De/HB_IFR-Flug#4.29_Der_.E2.80.9EProcedure_Turn.E2.80.9C_.28Umkehr-Prozedur.29|die Umkehr-Prozedur]]).<br />
<br />
'''''Übrigens: '''''Ein echter Pilot muss nachweisen, dass er berechnen kann welche "Richtung" er einhalten muss, um den "Wanted Course" bei der oder der Windstärke aus der oder der Richtung zu halten! Das funktioniert auch relativ gut -- dumm ist nur, dass der Wind sich selten daran hält - er ändert ständig Richtung und Stärke - Du mußt also ständig das aktuelle Wetter wissen und den Kurs neu berechnen!<br />
|}<br />
Dies ist zugegebener Maßen etwas anstrengend und wird auch nicht vom Autopiloten unterstützt -- aber wenn nix anderes <small>(z.B. kein {{HBabbr|VOR}})</small> da ist, ist man eventuell dankbar für diesen Trick! <br />
<br />
'''''Zur Bedienung: '''''<small>(weitere Infos auf http://monterey.militaryflyingclubs.com/Other%20Docs/KR87.ADF.pdf)</small><br />
<br />
*'''''OFF/VOL: '''''Siehe den Drehknopf für die Lautstärke zum Abhören des Morsezeichens. Ganz nach links gedreht schaltet er den Empfänger aus. Verstelle die Lautstärke mittels des Mausrades wenn der Mauszeiger über dem Drehknopf ist (oder durch Mausklicks recht/links davon).<br />
<br />
*'''''ADF/ANT: '''''Achte darauf, dass links in der Anzeige „{{HBabbr|ADF}}“ steht (d.h.: die ADF-Taste ist eingerückt). Basierend auf unterschiedlichen Antennen-Konfigurationen für {{HBabbr|ADF}} und ANT, ist in der Wirklichkeit die Betriebsart „ADF“ besser geeignet für den Richtungsempfang – dem gegenüber ist „ANT“ (wenn die Taste ausgerückt ist) besser für den Empfang des Morsecode geeignet.<br />
:'''''Versichere Dich immer davon, dass im Anzeigefenster "ADF" angezeigt wird - ansonsten gehst Du in die Irre!'''''<br />
<br />
*'''''BFO: '''''Kann zusätzlich aktiviert werden um den Morse-Code auch auf „Nicht-Modulierten“ Sendern zu empfangen. Für uns nicht wirklich wichtig!<br />
<br />
*'''''FRQ: '''''Drücke FRQ mehrmals und beobachte dabei wie die beiden angezeigten Frequenzen zwischen den zwei Anzeigen wechseln. Die Frequenz in der linken Anzeige ist „aktiv“, d.h. sie wird im Radiokompass angezeigt. Die andere ist auf „Standby“ (Bereitstellung) und kann mit dem Einstellknopf ganz rechts verändert werden. Somit kannst Du der eingestellten Peilung weiter folgen und schon mal vorausplanend die als nächstes benötigte Frequenz einstellen.<br />
:*'''''Die Frequenzeinstellung '''''erfolgt mit dem Stellrad ganz rechts: Du kannst nur die rechts angezeigte, standby ''(in Bereitschaft)'' Frequenz verstellen<br />
::Drehe das Rad<br />
::*mittels des Mausrades (oder Mausklick links/rechts) um Einer-Positionen<br />
::*mittels Klick mit der mittleren Maustaste rechts/links um Hunderter-Positionen<br />
::*oder setze die "Nummer" direkt in den [[#Die_.22einfache.22_Radio_Einstellungen:|Radio-Settings]]<br />
:*Achte darauf, dass die Nadel nicht einfach nach rechts zeigt wenn Du die Frequenz änderst - das ist die Ruheposition, '''''die bedeutet dass keine Sender gefunden/eingestellt wurde!'''''<br />
<br />
*'''''FLT/ET: '''''Ersetzt im rechten Teil der Anzeige die Standby-Frequenz mit der Zeitanzeige und wechselt dann zwischen der Anzeige von FLT und ET:<br />
:*FLT = Flight Time (die vergangene Zeit seit Du den FlightGear gestartet hast)<br />
:*ET = Elapsed Time (Stopp Uhr)<br />
:*Um zur Anzeige der Standby-Frequenz zurückzukehren drücke FRQ<br />
*'''''SET/RST: '''''Stellt die Stoppuhr auf 0 und startet sie direkt wieder. Vorsicht: Die Uhr wird dabei immer zurückgestellt, auch wenn sie nicht angezeigt wird!!<br />
<br />
*'''''HD '''''''(Heading Direction - Richtungsanzeige)'': Siehe die Inschrift auf dem kleinen Drehknopf links unterhalb des Instrumentes in der Mitte:<br />
<br /><br /><br />
----<br />
=='''Die COM/NAV-Radios'''==<br />
{|<br />
||[[File:C172-Radio-Com-Nav.png|left]]<br />
|}<br />
Die C172p ist luxuriöses mit 2 COM/NAV-Radios ausgestattet! Beide Radios sind gleich und beide beinhalten sowohl ein COM-Radio (zur Kommunikation, linker Teil) wie auch ein NAV-Radio (zur Navigation, rechter Teil). Beide Radios besitzen die gleichen Bedienelemte und Anzeigen sowohl für den COM-Teil wie auch für den NAV-Teil! Zum NAV-Teil gehört noch eine zusätzliches Anzeige-Instrument: Das sogenannte "{{HBabbr|OBS}}".<br />
<br />
'''''Die Bedienung:'''''<br />
<br />
*'''''Lautstärke: '''''Regele diese je COM und NAV mit dem jeweils linken, kleineren Drehknopf am unteren Rand. Dabei schaltet der ganz linke Drehknopf in der „OFF“-Stellung zusätzlich das komplette Gerät aus.<br />
<br />
*'''''Anzeige: '''''Um immer die nächste benötigte Frequenz einstellen zu können, ohne die bestehende Verbindung zu stören, hat jedes Gerät zwei Anzeigen (siehe im Bild 119.80/125.20 und 114.10/110.50). Aktiv ist immer die Frequenz links in der jeweiligen Anzeige – rechts ist die zusätzlich bereitgestellte Frequenz. Somit ist klar, dass jeweils nur diese „rechte“ verstellt werden kann! Mit der weißen Taste direkt unterhalb der Anzeige schaltest Du zwischen den beiden hin und her - mit anderen Worten definierst Du damit welche Frequenz aktive ist (nämlich nur die links stehende!). In unserem Beispiel also 119.8 für die Kommunikation und 114.10 für die Navigation ({{HBabbr|VOR}} oder {{HBabbr|ILS}}).<br />
<br />
*'''''Frequenz: '''''Regele die Frequenz für COM @ NAV jeweils mit den größeren Drehknöpfen rechts<br />
:*Klicken mit der linken Maustaste links/rechts des Reglers verstellt die Frequenz einstellig<br />
:*Klicken mit der mittleren Maustaste links/rechts des Reglers verstellt die Frequenz um hunderter Stellen<br />
:*Am einfachsten geht es<br />
::*mittels Drehen des Mausrades über dem Regler<br />
::*oder durch Eingabe der Frequenzen via „'''''Menü → Equipment → Radio Settings'''''“, siehe das nachfolgende Kapitel "Die einfache Radio-Einstellung"<br />
<br />
Wenn Du in den NAV-Radios eine neue Frequenz eingestellt hast, solltest Du unbedingt die Lautstärke hoch-drehen und an Hand des zu hörenden Morsezeichens die Station verifizieren. Das gültige Zeichen (inklusive des Punkt/Strich-Codes) findest Du in den Flugkarten. Insbesondere in größeren Höhen kommt es vor, dass ein anderer Sender auf gleicher Frequenz näher ist oder Du Dich bei der Einstellung vertan hast. Im Simulator kann man darüber lachen – aber wir sind doch echte Piloten und wissen was passieren kann, wenn wir komplett vom Kurs abkommen!!<br />
<br /><br />
===Die "einfache" Radio Einstellungen:===<br />
Du hast mehrere Möglichkeiten die benötigten Frequenzen etc. einzustellen - z.B. auch indem du sie direkt an den Geräten einstellst. Aber die einfachste (und genaueste) Art der Einstellung geschieht über:<br />
::„'''''Menü → Equipment → Radio Settings'''''“ :<br />
{|<br />
||[[File:Radio-Settings.png|left]]<br />
|}<br />
Die vorstehenden Einstellungen sind diejenigen, die sowohl für das Kapitel [[De/HB_VFR_Flug|{{HBabbr|VFR}} Cross Country]] wie auch [[De/HB_IFR-Flug|{{HBabbr|IFR}} Cross Country]] benutzt werden. Die eingetragenen Werte entsprechen folgenden Funktionen:<br />
{| cellpadding="2" cellspacing="2" border="1"<br />
! <br />
!Selected / Aktiv<br />
!Standby / Vorwahl<br />
!Bemerkungen:<br />
|-<br />
!scope="row"|COM1<br />
|align="center"|KRHV-TWR<br />
|align="center"|KRHV-{{HBabbr|ATIS}}<br />
|-<br />
!scope="row"|COM2<br />
|align="center"|KLVK-TWR<br />
|align="center"|KLVK-{{HBabbr|ATIS}}<br />
|-<br />
!scope="row"|NAV1<br />
|align="center"|{{HBabbr|VOR}} SJC (R=009)<br />
|align="center"|KLVK {{HBabbr|ILS}} 25R<br />
||Wenn Du mit Autopilot fliegst kannst Du NUR den NAV1 zum Kurshalten benutze!<br />
|-<br />
!scope="row"|NAV2<br />
|align="center"|{{HBabbr|VOR}}-OAK (R=114)<br />
|align="center"|{{HBabbr|VOR}}-ECA (R=229)<br />
||benutze NAV2 insbesondere zur Standortbestimmung oder sonstiger Referenzen<br />
|-<br />
!scope="row"|{{HBabbr|ADF}}<br />
|align="center"|KLVK – Anflug REIGA<br />
|align="center"|Referenz TRACY<br />
||siehe das Kapitel {{HBabbr|ADF}}/{{HBabbr|NDB}}<br />
|-<br />
!scope="row"|<{{HBabbr|DME}}<br />
|colspan="3"|Für den selten vorkommend Fall eines allein stehenden {{HBabbr|DME}}, siehe z.B. EDDF<br />
|-<br />
!scope="row"|{{HBabbr|TACAN}}<br />
|colspan="3"|Hier z.B. der Wert für den Flugzeugträger Eisenhauer bei Marseille (France)<br />
|-<br />
!scope="row"|TRANSPONDER<br />
|colspan="3"|In den neuesten Versionen gibt es ein zusätzliches Feature, insbesondere zur Benutzung mit VATSIM: Den "Transponder"! Setze diesen (falls vorhanden) auf 7000 für {{HBabbr|VFR}} - ansonsten wie von {{HBabbr|ATC}} angewiesen!<br />
|}<br />
<br /><br />
Mittels Maus-Klick auf die Schaltfläche "'''''ATC services in range'''''" ({{HBabbr|ATC}} Services in der Nähe) findest Du Frequenzen für Airports:<br />
<br /><span style="color:brown">''(die folgenden {{HBabbr|GUI}}'s waren früher unter „Menü → ATC/AI → Frequencies“ aufgehängt)''</span><br />
{|<br />
||[[File:Search-Airport-Freq.png |left]]<br />
|}<br />
*Wähle den gewünschten Flugplatz im größeren der beiden {{HBabbr|GUI}}'s<br />
:* durch Maus-Klicke auf einen der gelisteten Flugplätze im Nahbereich (z.B. KRHV)<br />
:* oder tippe den gewünschten <abbr title="International Civil Aviation Organisation == Flughafen ID's">ICAO</abbr>-Kod in das gelbe Feld<br />
*Das öffnet das kleiner {{HBabbr|GUI}} mit den verfügbaren Frequenzen<br />
::übertrage diese in die COM-Radios. z.B. für KRHV:<br />
::*125.20 → in COM1 links als "Selected" (Aktiv) für den {{HBabbr|ATIS}}, den wir zuerst abhören wollen<br />
::*119.80 → in COM1 rechts Standby (Bereitstellung), für den "Tower", den wir erst danach brauchen.<br />
::(Bemerkung: Auf KRHV gibt es keinen extra "Ground", somit ist der Tower der erste Ansprechpartner!)<br />
<br />
Du solltest dann nach ein paar Sekunden Ladezeit die {{HBabbr|ATIS}}-Angaben hören. Wenn Du diese nicht hörst überprüfe ob das Radio eingeschaltet und die Lautstärke aufgedreht ist (siehe oben). Evtl. solltest Du auch unter „'''''Menü → File → Sound Configuration'''''“ überprüfen ob der Ton evtl. ausgeschaltet ist!<br />
<br />
'''''Für FGCOM Benutzer: '''''Die im kleineren {{HBabbr|GUI}} aufgelisteten Frequenzen sind die Standard-Frequenzen aus den FlightGear Daten. Diese können, müssen aber nicht, mit den im [[De/HB_Features#FGCOM|FGCOM]] verfügbaren Frequenzen übereinstimmen! Wenn Du ohne [[De/HB_Features#FGCOM|FGCOM]] fliegst ist das egal – für [[De/HB_Features#FGCOM|FGCOM]] kannst Du aber nur die speziellen FGCOM-Frequenzen verwenden! (siehe die Datei „'''''phonebook.txt'''''“ in Deinem [[De/HB_Features#FGCOM|FGCOM]]-Verzeichnis! ''Dieses Verzeichnis befindet sich unter Windows meistens im [[De/HB_Installation#.24FG_ROOT|'''''$FG_ROOT''''']], für Linux ist es oft unter [[De/HB_Installation#.24FG_HOME$|'''''FG_HOME''''']] installiert!)''<br />
<br /><br /><br />
<br />
===Der NAV-Teil = VOR & ILS===<br />
Der NAV-Teil beider Radios dient der Radio-Navigation mittels {{HBabbr|VOR}} und der Anflugkontrolle mittels {{HBabbr|ILS}}. Dies besagt schon, dass {{HBabbr|VOR}} und {{HBabbr|ILS}} technisch sehr ähnliche Systeme sind. Und grundsätzlich haben sie die gleiche Aufgabe, nämlich dem Piloten (und/oder Autopiloten) den Weg zur Sendestation zu zeigen. Beide geben dabei nicht nur eine generelle Richtung an (wie das {{HBabbr|ADF}}) sondern produzieren einen "Radial" (Leitstrahl), auf den der Pilot einscheren kann um dann den Sender genau auf diesem Leitstrahl auf kürzestem Wege unter genau dem angegebenen Kurs anzufliegen - ein unbeabsichtigtes Abdriften durch den Wind ist dabei nicht möglich!<br />
<br />
Aber was sind die Unterschiede zwischen {{HBabbr|VOR}} und {{HBabbr|ILS}} ??<br />
<br />
*'''''{{HBabbr|VOR}}-Sender''''' können irgendwo im Gelände stehen. Sie senden weitreichende Radials (Richtungssignale) in alle Himmelsrichtungen. Die Reichweite beträgt je nach Flughöhe mehr als 100 mi - sie können aber evtl. auch in geringerer Entfernung nicht wahrnehmbar sein, wenn zwischen Dir und dem Sender ein Berg oder ähnliches ist! Auf Flugkarten erkennst Du {{HBabbr|VOR}}'s daran, dass um sie herum eine Kompassrose ist, mittels derer Du bei der Flugplanung direkt einen gewünschten magnetischen Kurs ablesen bzw. definieren kannst<br />
<br />
*'''''{{HBabbr|ILS}}-Sender''''' stehen an einer Landebahn und strahlen immer in Kursrichtung der Landebahn - Du kannst also keinen anderen Kurs eingeben. Dieser "Landbahnkurs" wird "Localizer" genannt - er hat <small>''(je nach Aufrüstung/Klassifikation)''</small> eine Reichweite von 18 bis zu 100 mi.<br />
:*Zusätzlich zum {{HBabbr|ILS}} gibt es oft einen sogenannten "Glideslope" - wie der Localizer gibt Dir auch dieser eine fest eingestellte Richtung an -- aber vertikal. Diese GS reicht meist aber nur 10 mi weit!<br />
:*Beide zusammen zeigen Dir also, ob Du Dich auf der Ideallinie zum Aufsetzpunkt befindest, sowohl horizontal als auch vertikal!<br />
<br />
Siehe für den Umgang mit einem {{HBabbr|VOR}} die nachstehende Abb. für das Gebiet bei "San Jose". Danach sind ein paar Beispiele für den Umgang mit {{HBabbr|VOR}}'s aufgeführt.<br />
<br />
Aber siehe erst ein paar grundsätzliche Kenndaten an Hand einer "Sectional", z.B. http://skyvector.com :<br />
{| cellpadding="10" cellspacing="2" border="0"<br />
|- valign="top"<br />
||[[File:VOR-Navigation.png|300px|thumb|left|{{HBabbr|VOR}}-Navigation]]<br />
In dieser Grafik siehst Du 2 {{HBabbr|VOR}}s: "OAK" und "SJC". Lass uns am Beispiel des "'''''{{HBabbr|VOR}} SJC'''''" ansehen, welche Informationen uns eine normale Flugkarte dazu gibt (siehe das rot umrandete Feld unten rechts) :<br />
<br />
*'''''VOR-DME: '''''zeigt an, dass dies ein rein ziviles „{{HBabbr|VOR}}“ ist mit einem integrierten „{{HBabbr|DME}}“. Es gibt auch zivil/militärische Kombinationen, so genannte {{HBabbr|VORTAC}}s (siehe z.B. das {{HBabbr|VOR}} in Oakland oben links, das deswegen auch noch zusätzliche Informationen zeigt).<br />
<br /><br />
*'''''SAN JOSE: '''''ist der volle Name<br />
<br /><br />
:*'''''114.1''''' : ist die im NAV einzustellende Frequenz<br />
:*'''''Ch 88''''' : ist die entsprechende Frequenz für einen anderen Radio-Typ<br />
<br /><br />
:*'''''SJC''''' : ist die Kennung des {{HBabbr|VOR}} (diesen würdest Du z.B. in einem Routenplaner eingeben!)<br />
:*"'''''... .--- -.-.'''''" ist der dazugehörige Morsecode ''(„SJC“)'', mit dem sich das {{HBabbr|VOR}} über Funk zu erkennen gibt! Die Punkte und Striche hörst Du als kürzere bzw. längere Töne, zwischen jedem Buchstaben gibt es eine deutliche Pause.<br />
<br /><br />
In der Darstellung sind 2 '''''Radials''''' hervorgehoben:<br />
#"114° FROM", ausgehend vom {{HBabbr|VOR}} OAK<br />
#"002° FROM", ausgehend vom {{HBabbr|VOR}} SJC<br />
Interessant ist, dass sich diese beiden Radials kreuzen und damit einen sehr interessanten Punkt definieren, der sogar einen Namen bekommen hat: "'''''MISON'''''". Dies wurde ein sehr wichtiger "'''''FIX"-Punkt''''' für die Navigation in der Bay-Area! Einen solchen "FIX" kannst Du unter strikten {{HBabbr|VFR}}-Regeln nicht erkennen, da es sich tatsächlich nur um den Schnittpunkt zweier Radio-Signale handelt - versuche also nicht diesen wie eine Sehenswürdigkeit mit den Augen zu erkennen. Aber solche FIX-Punkte helfen den Flugverkehr genauer zu leiten. Zudem kannst Du solche FIX-Punkte als "Waypoints" (Weg-Markierungen) in Flugplänen angeben, oder sie werden als '''''Reporting-Points''''' (Punkte an denen die Piloten der Flugüberwachung Bericht erstatten) definiert, etc.<br />
|}<br />
===OBI: Das {{HBabbr|VOR}}/{{HBabbr|ILS}}-Instrument:===<br />
Wie bereits vorstehend erläutert, gibt es zu dem NAV-Radio noch eine Anzeigeeinheit - die wir uns anschauen sollten. Das Instrument enthält die folgenden Funktionen:<br />
<br />
{| cellpadding="5" cellspacing="2" border="0"<br />
||[[File:C172-VOR-Instrument.png‎|192px|thumb|left]]<br />
'''''{{HBabbr|OBS}}: Dies ist die Einstellschraube in der unteren linken Ecke. Mit dieser verdrehst Du die Windrosen-Skala des Instrumentes, bis der gewünschte Radial ganz oben steht - in diesem Beispiel also "002" (= praktisch 000° direkt Norden, passend zu unserem [[De/HB_VFR_Flug|{{HBabbr|VFR}}-Flug]] und obiger Karte).<br />
<br />
'''''CDI = '''''"Course Deviation Indication" (Kurs-Abweichungs-Anzeige): Die vertikale Nadel zeigt normalerweise<br />
*nach links wenn Du den Kurs nach links ändern solltest um (wieder) auf das Radial zu gelangen<br />
*nach rechts wenn Du den Kurs nach rechts ändern solltest um (wieder) auf das Radial zu gelangen<br />
*senkrecht wenn Du genau auf dem Radial bist<br />
In der jetzigen Anzeige müsstest Du also etwas nach links <small>''(etwa auf Richtung 350° auf dem "Heading Indicator" (Gyro-Kompass))''</small> drehen um auf den genauen Kurs zu kommen - erst wenn die Nadel dann zentriert ist gehst Du genau auf die gewünschte Richtung 002°!<br />
<br />
'''''GS = '''''"Glide-Slope" (Gleitpfad): Diese horizontale Nadel funktioniert genauso wie das <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr> - allerdings in vertikaler Richtung. Dies hat also nur im Zusammenhang mit dem {{HBabbr|ILS}} beim End-Anflug auf eine Landbahn eine Funktion! Beachte, dass dieses GS-Signal (Reichweite ~10 mi) immer erst sehr viel später aktive wird, als das vom gleichen Sender ausgehende <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr>-Signal (Reichweite bis zu 50 mi und mehr)!<br />
<br />
'''''TO/FROM '''''(hin-zu / weg-von): Siehst Du das kleine Fenster rechts von der Mitte, das derzeit "FR" <small>''(für "from")''</small> anzeigt? Hier wird "TO" angezeigt, wenn das eingestellte "Radial" zum {{HBabbr|VOR}} hinweist, "FROM" <small>''(bzw. "FR")''</small> wird angezeigt wenn das Radial vom {{HBabbr|VOR}}> weg weist. Wenn Nichts angezeigt wird, befindest Du Dich nicht im Wirkungsbereich eines {{HBabbr|VOR}} mit der eingestellten Frequenz! '''''Diese Feinheit ist ganz wichtig: '''''Das "TO/FROM" ist unabhängig davon ob Du tatsächlich zum {{HBabbr|VOR}} hinfliegst oder Dich entfernst - es zeigt nur an, dass der eingestellte Radial zum Sender hin- ("TO") oder wegführt ("FROM"). Als Pilot steht es Dir frei diesen Radial auch entgegengesetzt zu benutzen - Du musst nur aufpassen: Die CDI-Anzeigen sind dann entgegengesetzt! Siehe die folgende Skizze:<br />
|}<br />
:{|<br />
||[[File:RNAV VOR-To-From.png|left]]<br />
|}<br />
Beachte also:<br />
:{| cellpadding="10" cellspacing="2" border="1"<br />
!Radial<br />
!Deine Position<br />
!Kompass<br />
!{{HBabbr|OBS}}<br />
!<abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr>-Anzeige bei einem Flug nach Osten:<br />
|- style="color: green"<br />
!scope="row"|TO 090°<br />
|align="center"|westlich des {{HBabbr|VOR}}'s<br />
|align="center"|090°<br />
|align="center"|090°<br />
||Normal: Zeigt nach links wenn du nach links korrigieren solltest<br />
|- style="color: red"<br />
!scope="row"|FROM 270°<br />
|align="center"|westlich des {{HBabbr|VOR}}'s<br />
|align="center"|090°<br />
|align="center" style="color:red|270°<br />
||'''''Entgegengesetzt: '''''Zeigt nach links wenn du nach rechts korrigieren solltest<br />
|- style="color:green<br />
!scope="row"|FROM 090°<br />
|align="center"|östlich des {{HBabbr|VOR}}'S<br />
|align="center"|090°<br />
|align="center"|090°<br />
||Normal: Zeigt nach links wenn du nach links korrigieren solltest<br />
|- style="color: red"<br />
!scope="row"|TO 270°<br />
|align="center"|östlich des {{HBabbr|VOR}}'S<br />
|align="center"|090°<br />
|align="center" style="color:red|270°<br />
||'''''Entgegengesetzt: '''''Zeigt nach links wenn du nach rechts korrigieren solltest<br />
|}<br />
:Lass uns als Beispiel die obige Darstellung des Instrumentes analysieren: Dort wollen wir auf dem Radial „TO 002°“ zum {{HBabbr|VOR}} hin-fliegen – also ziemlich genau zum magnetischen Nordpol:<br />
<br />
:*Dazu haben wir die Kompass-Rose des {{HBabbr|OBI}} mittels des {{HBabbr|OBS}} auf "002°" gestellt. (Das kann man aber bei einem solchen Instrumenten kaum genau einstelle - wenn es darauf ankommt empfehle ich Dir die [[#Die_.22einfache.22_Radio_Einstellungen:|Radio-Setting]] zur Eingabe des digitalen Wertes zu benutzen!)<br />
<br />
:*In dem Beispiel weist uns die nach links geneigte, vertikale Nadel des Instruments darauf hin, dass der eingestellte Radial etwas links von uns ist – wir müssen also unseren Kurs nach dort hin korrigieren:<br />
::*Ändere also die Richtung entsprechend dem Gyro-Kompass anfangs um ~10° nach links (also etwa auf 350°) und beobachte die senkrechte Nadel:<br />
:::*bewegt sich die Nadel weiter nach außen oder bleibt sie wo sie ist: Dann steuere noch einmal 10° mehr nach links (also etwa 340°)<br />
::::*eventuell nimm noch 10° mehr - aber mehr als 30° Korrektur sollten nicht nötig sein! Sei geduldig: Je nachdem wie weit Du vom {{HBabbr|VOR}} entfernt bist, kann es recht lange dauern bis Du eine signifikante Änderung bemerkst! Versuche nicht überzureagieren (das führt nur zu Schlangenlinien und damit zu unnötigem Sprit- und Nervenverbrauch!)<br />
::::* bewegt sich die Nadel hin zum Zentrum, warte bis die Nadel fast senkrecht steht und gehe dann wieder auf Kurs<br />
::*Wenn Du dieses Spielchen ständig machen musst (z.B. weil starker Seitenwind herrscht) ändere Deine Flugrichtung auf dem Gyro-Kompass so, dass die <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr>-Nadel zentriert bleibt. Z.B. könntest Du dann bei Seitenwind von links entsprechend dem Gyro einen Kurs von 355° (7° gegen den Wind) halten, während Du tatsächlich genau auf dem Radial „002°“ entlang fliegst!<br />
<br /><br />
===HSI: Das Horizontal Situation Instrument===<br />
{| style="width: 100%"<br />
||[[File:VOR-HSI DE.png|300px|thumb|left]]<br />
Das HSI kombiniert sowohl das {{HBabbr|OBI}} wie auch den Directional_Gyro in ein einziges Instrument.<br />
<br /><br /><br />
Das macht das Ganze deutlich teurerer als die zwei einzelnen Instrumente, und somit ist es nicht in user c172p!<br />
<br /><br /><br />
Falls Du mehr über das HSI wissen willst, siehe:<br />
:http://de.wikipedia.org/wiki/Horizontal_Situation_Indicator<br />
|}<br />
<br />
'''''Zum guten Schluss dieser Einweisung das Wichtigste in Kürze:'''''<br />
::{| cellpadding="10" cellspacing="2" border="1"<br />
|align="center"|Der Kompass und/oder {{HBabbr|ADF}} zeigen an in welche Richtung Deine Nase zeigt<br />
<br />
Das {{HBabbr|OBI}} zeigt den Kurs!!!<br />
-- und hilft Dir den Kurs zu halten -- sogar OHNE Autopilot !'''''<br />
|}<br />
Siehe hierfür die Anwendung im [[De/HB_IFR-Flug#2.29_Entlang_der_V334_zum_FIXpunkt_SUNOL.2C_via_MISON|"IFR X-Country", "Entlang der V334 zum FIXpunkt SUNOL, via MISON"]].<br />
<br />Für weiterführende Details siehe z.B.: http://de.wikipedia.org/wiki/Drehfunkfeuer.<br />
<br /><br /><br />
===Das COM/NAV-Radio 2===<br />
Das zweite Radio ist genau gleich dem Radio 1, siehe oben. Allerdings kann bei den meisten Flugzeugen das NAV2 nicht zur Steuerung des Autopiloten verwendet werden!!<br />
<br /><br /><br />
----<br />
<br />
== '''Der Autopilot (AP)''' ==<br />
(ref: http://www.g1000.info/Download-Dateien/KAP140.pdf)<br />
{|<br />
||[[File:c172-AP-total.png|left]]<br />
|}<br />
Der Autopilot entlastet Dich insbesondere auf Langstreckenflügen, indem er den vorher eingestellten Daten entsprechend die Steuerung übernimmt. Dies funktioniert meistens besser als es jeder Pilot kann – aber es basiert auf einer sehr engen Auslegung der vorhandenen Daten, die ohne jegliche Intelligenz interpretiert werden. Als Beispiel: Wenn Du auf 10.000 ft steigen willst, führt der Autopilot dies ganz prima aus – aber bei ca. 7.000 ft stürzt Du ab, da das Gemisch so fett wurde, dass der Motor stehen bleibt! Es gibt tausende solcher Beispiele!<br />
:{| cellpadding="10" cellspacing="2" border="1"<br />
||<big>'''''Vergiss also nie: Du bist und bleibst der verantwortliche Pilot – nicht der Autopilot !!''''' </big><br />
|}<br />
*'''''Schalte das Gerät vor Start und Landung unbedingt aus'''''! Ansonsten können absolut unvorhersehbare Dinge geschehen! Sogar wenn Du eine AP-{{HBabbr|ILS}}-Landung machst: Schalte den AP vor dem Aufsetzen auf der Landebahn komplett aus!<br />
**Ja doch: Es gibt Modelle die könne sehr viel mehr und besser – aber nicht die C172 – und viele andere auch nicht! Also Vorsicht!<br />
**'''''Wenn Du ausschaltest''''', schalte nicht nur einzelne Funktionen aus – denn es ist schwierig zu merken welche Funktionen dann noch aktiv bleiben (z.B. bleibt auf jeden Fall das „Rollen“ immer aktiv!)<br />
**Nach dem Ausschalten, schaltet der AP nicht sofort aus sondern blinkt erst ein Weilchen um Dich zu warnen - warte also nicht bis zur letzten Sekunde!<br />
<br />
Lass uns nun von rechts nach links anschauen was Du mit dem AP machen kannst:<br />
<br />
*'''''AP''''' (Autopilot) schaltet das Gerät ein/aus. Nur beim ersten Einschalten wird der derzeitige Flugzustand übernommen.<br />
**In dem Fall würde in der oberen Zeile angezeigt:<br />
***„'''''ROL'''''“: mittels der Ailerons wird ein „Rollen“ (Querlage) verhindert – die Tragflächen werden waagerecht gehalten - und somit wird erstmal schon die derzeitige Richtung beibehalten! Ist doch nett vom AP - oder? '''''Vorsicht: '''''Die Richtung der Nase wird beibehalten - bei Wind ist das meist nicht der "Kurs"! Das mag oft nicht wichtig sein - aber sei Dir dessen bewusst!<br />
***„'''''VS'''''“: Die vertikale Steuerung wird mit dem derzeitigen Wert übernommen – das derzeitige Steigen bzw. Sinken also fortgesetzt!<br />
***„'''''00000'''''“ die gewählte Höhe wird auf 0 gesetzt. Du solltest also möglichst bald mittels „'''''ARM'''''“ Deine gewünschte Höhe eingeben! Oder zumindest sicherstellen, dass Du derzeit nicht sinkst!<br />
**Während des "Cruise" werden wir die AP-Einstellungen ändern, die dann etwa wie im Bild oben aussehen:<br />
***'''''HDG: '''''Der AP folgt dem "roten Marker" auf der Windrose des Gyro-Compasses<br />
***'''''ALT: '''''Der AP übernimmt die Kontrolle über die Höhe<br />
***'''''05000: '''''Das ist die eingestellte Höhe, die der AP halten wird (wenn die Motorleistung es erlaubt! Ein Standard-AP wird die Motorleistung NICHT anpassen!)<br />
**AP-Fehler-Anzeigen: Über dem AP-Druckknopf können zwei rote Buchstaben erscheinen:<br />
***'''''<span style="color:red">P</span>: '''''Der AP kann den Pitch (Höhenruder/Trimm) nicht einstellen - wenn die Situation längere Zeit bestehen bleibt schaltet der AP automatisch ab<br />
***'''''<span style="color:red">R</span>: '''''Der AP kann den ROL (Querruder) nicht einstellen - wenn die Situation längere Zeit bestehen bleibt schaltet der AP automatisch ab<br />
<br />
*'''''HDG '''''(Heading, Richtung) schaltet hin/her zwischen „ROL“ und „HDG“.<br />
**"'''''ROL'''''" versucht die Maschine möglichst gerade zu halten, zumindest die Tragflächen<br />
**Unter „'''''HDG'''''“ folgt der AP dem roten Marker im Gyro-Kompass. Sei vorsichtig wenn Du den Marker verstellst: Der AP dreht immer auf dem kürzesten Weg auf den Kurs des Markers – wenn Du also z.B. den Marker schnell nach links verdrehst und über ein Delta von 180° kommst, wird die Maschine plötzlich nach rechts drehen (sobald dies der kleinere Winkel zum neuen Kurs ist!!). Falls Du als z.B. aus einer Richtung von 360° LINKS herum nach Osten drehen willst (z.B. weil rechts ein Berg ist oder {{HBabbr|ATC}} es so wollte, oder...), musst Du die Einstellung stufenweise vornehmen: z.B. erst auf 190° und erst wenn diese Richtung fast erreicht ist weiter auf 090°!<br />
<br />
*'''''NAV '''''(Radio-Navigation) schaltet um auf den Kurs des „NAV1“, die Maschine wird dann versuchen auf den voreingestellten Radial einzuschwenken. Dieser lässt sich im Menüpunkt Funkfrequenzen ändern. Du solltest vor dem Umschalten bereits auf einem Kurs zum Einscheren in den Radial sein (<60° zum Radial) – ansonsten kannst Du nicht sicher sein ob Du auf „To“ oder „From“ fliegen wirst! Überprüfe auf jeden Fall nach dem Einscheren den Kurs!<br />
<br />
*'''''APR '''''(Approach (Anflug)) schaltet auf den {{HBabbr|ILS}}-Approach (Anflug) – also wird zusätzlich zum Kurs auch der Sinkflug aktiviert (falls der {{HBabbr|VOR}} auch über einen Glideslope (GS) verfügt!).<br />
**Mit der neuesten Version der c172p (besser als FlightGear 2.0) kannst du während des Anfluges direkt auf APR schalten, auch wenn Du noch weit unterhalb des GL bist (früher verursachte das eine direkten Satz nach oben, zum GS!)<br />
**Ich empfehle jedenfalls den GL erst zu aktivieren, wenn er auf unserer Höhe ist - damit man sich bei anderen Modellen erst gar nicht vertut!<br />
<br />
*'''''REV '''''(Reverse) schaltet auf NAV-Gegenkurs. Wenn Du auf „APR“ bist folgt der AP dem Radial entgegengesetzt vom Aufsatzpunkt weg und schaltet den Glideslope aus.<br />
<br />
*'''''ALT '''''(Altitude (Höhe)) schaltet die Höhensteuerung ein. Achte auf die Angabe in der Mitte der Anzeige:<br />
**„'''''VS'''''“ bedeutet: Es wird die Höhe verändert entsprechend der mit den „UP“/“DN“ Tasten eingestellten „<abbr title="Feet per Minute == Steig- oder Sinkgeschwindigkeit">FPM</abbr>“. Hast Du das Problem erkannt? Wenn Du nicht auf Höhe der eingestellten "ALT" bist ist das "UP"/"DN" maßgebend! Der AP wird nicht die eingestellte Höhe anfliegen, sondern entsprechend dem "UP/DN" steigen oder sinken! Wenn also eine Höhe von 4000 ft eingestellt ist, Du aber darunter bist und "UP/DN" auf z.B. "-500" (beachte das Minus!) einstellst, dann wirst Du sinken bis Du auf dem Boden aufschlägst - denn Du erreichst niemals die angestrebte Höhe von 4000, wo der AP automatisch aus-tarieren würde! Siehe unbedingt den nächsten Punkt "UP/DN"!<br />
**"'''''ALT'''''" zeigt an, dass die derzeitige Höhe gehalten wird<br />
:VS und ALT gleichzeitig zeigen an, dass wir uns im Übergang auf eine neue Höhe befinden.<br />
:Mit "ALT" schaltest Du dann zwischen „VS“ und „ALT“ Modus hin und her.<br />
<br />
*'''''PT-Anzeige:'''''<br />
::Zwischen der Anzeige "ALT" und der Höhenangabe "5000" (vergleiche in obigem Bild) kann ein blinkendes "'''''<PT>'''''" (Pitch-Trimm) in vertikaler Schrift erscheinen. Dies ist eine Aufforderung an Dich die Maschine in die angegebene Richtung zu trimmen (erinnere Dich an das große Rad auf der Mittel-Konsole, trimme mit "7/1" oder "Maus-Rad über dem Trimm-Rad", etc.). Es macht keinen großen Unterschied, ob Du der Aufforderung folgst oder nicht -- außer wenn Du den AP ausschaltest - dann übernimmst Du plötzlich ein völlig falsch getrimmtes Flugzeug - das könnte Dich gewaltig überraschen!<br />
<br />
*'''''UP/DN '''''(up/down = rauf/runter) damit stellst Du die <abbr title="Feet per Minute == Steig- oder Sinkgeschwindigkeit">FPM</abbr> ein, mit der Du steigen bzw. sinken willst. Achte auf das Minuszeichen – das wird oft übersehen!<br />
::Diese UP/DN Einstellung hat Priorität gegenüber der Höheneinstellung - und kann damit interessante Phänomene verursachen:<br />
::{| cellpadding="10" cellspacing="2" border="1"<br />
!derzeitige<br />
Flughöhe<br />
!gewünschte<br />
Flughöhe<br />
!up/Dn<br />
<abbr title="Feet per Minute == Steig-Â oder Sinkgeschwindigkeit">FPM</abbr><br />
!Ergebnis<br />
|-<br />
|align="center"|3000<br />
|align="center"|4000<br />
|align="center"|(+) 500<br />
||wir steigen mit 500 <abbr title="Feet per Minute == Steig-Â oder Sinkgeschwindigkeit">FPM</abbr> auf 4000 ft<br />
|-<br />
|align="center"|3000<br />
|align="center"|4000<br />
|align="center"|-500<br />
||wir sinken mit 500 <abbr title="Feet per Minute == Steig-Â oder Sinkgeschwindigkeit">FPM</abbr> zu Boden bis zum <span style="color:red">'''Crash'''</span><br />
|-<br />
|align="center"|3000<br />
|align="center"|2000<br />
|align="center"|(+) 500<br />
||wir steigen mit 500 <abbr title="Feet per Minute == Steig-Â oder Sinkgeschwindigkeit">FPM</abbr> in den Himmel bis zum <span style="color:red">'''Crash''' ''</span><small>(oder der ersten Mondlandung einer Cessna!)</small>''<br />
|-<br />
|align="center"|3000<br />
|align="center"|2000<br />
|align="center"|-500<br />
||wir sinken mit 500 <abbr title="Feet per Minute == Steig-Â oder Sinkgeschwindigkeit">FPM</abbr> auf 2000 ft<br />
|-<br />
|align="center"|3000<br />
|align="center"|3000<br />
|align="center"|erst 500,<br />
dann -500<br />
||<span style="color:green">'''wir "springen" über ein Hindernis und kehren dann direkt zurück auf unser Höhe'''</span><br />
|}<br />
::==> Es könnte sich also lohnen immer erst die <abbr title="Feet per Minute == Steig- oder Sinkgeschwindigkeit">FPM</abbr> (UP/DN) einzustellen, bevor man die Höhe ändert!<br />
<br />
*'''''ARM '''''(=scharf machen) aktiviert die Voreinstellung der Höhe mittels des Drehreglers rechts darunter. Mit dem Mausrad oder einfachem Mausklick rechts/links um 10er-Stellen – mit der mittleren Maustaste um Hunderter.<br />
<br />
*'''''BARO '''''(Barometer) aktiviert den Drehregler darunter zur Eingabe des barometrischen Druckes<br />
::'''''Achtung: '''''Dieser ist unabhängig vom eingestellten Druck im Höhenmesser! Du musst diesen zusätzlich einstellen, wenn Du mit dem AP fliegst! Zumindest bei Modellen wie der C172!<br />
<br />
'''''Bemerkung:''''' Insbesondere wenn Du z.B. von HDG auf NAV umstellst, wird dies nicht sofort aktiviert. Es wird erst einmal die bisherige Einstellung (z.B. HDG) warnend blinken und erst später die neue Einstellung (z.B. NAV) auftauchen. Lass dem Gerät also Zeit für die Umstellung – '''''das Blinken ist KEINE Fehlermeldung''''', sondern nur ein: „ACHTUNG - es wird geändert!“<br />
<br />
Du findest Beispiele für die Benutzung des AP in<br />
*[[De/HB_VFR_Flug|"{{HBabbr|VFR}} Cross-Country"]] wärend des "Cruise" <small>(Reiseflug)</small> und "Approach" <small>(Anflug)</small><br />
*[[De/HB_IFR-Flug|"{{HBabbr|IFR}} Cross-Country"]] beim "Steigen nach dem Start" und "Procedure Turn" <small>(Umkehr-Kurve)</small><br />
<br /><br /><br />
----<br />
<br />
=='''Das DME'''==<br />
{|<br />
||[[File:C172-DMA.png|left]]<br />
|}<br />
Es gibt für das {{HBabbr|DME}} nur eine Anzeige für alle Radios – somit kannst Du immer nur die Werte eines der Radios beobachten. Du kannst aber jederzeit schnell hin- und her-schalten.<br />
<br />
*Mit dem Schalter in der Mitte schaltest Du das Gerät ein/aus ''(on/off)''.<br />
<br />
*Mit dem Wahlschalter links wählst Du von welchem der NAV-Radios ('''''N1''''' oder '''''N2''''') die Werte angezeigt werden sollen (beachte, dass nicht alle {{HBabbr|VOR}}s ein {{HBabbr|DME}}-Signal ausstrahlen!)<br />
:In der mittleren Position "'''''HLD'''''" (hold = halten) wird die {{HBabbr|DME}}-Frequenz beibehalten die zuletzt eingestellt war! Dazu solltest Du wissen, dass die {{HBabbr|VOR}}- und die {{HBabbr|DME}}-Sendefrequenzen unterschiedlich sind. Somit behält diese Stellung die {{HBabbr|DME}}-Frequenz vom zuletzt eingestellten Sender bei - egal was Du mit den 2 NAV-Geräten einstellst! Das ist praktisch: Somit kannst Du Dir das setzen und dann mit den beiden NAV-Geräten tun was Du willst - der eingestellte Entfernungsmesser bleibt bestehen (bis Du wieder auf N1 oder N2 schaltest!). <br />
<br />
*In der Anzeige oberhalb „'''''Miles'''''“ wird die Entfernung zum Sender angezeigt<br />
<br />
*Mit dem weißen Knopf rechts neben „Miles“ wählst Du ob Du dazu rechts die Geschwindigkeit (KTS) oder die Zeit bis zum Ziel (MIN) sehen möchtest.<br />
**Mit '''''KTS''''' wird die Geschwindigkeit über Boden angezeigt (nicht wie im Geschwindigkeitsmesser die <abbr title="Indicated AirSpeed == angezeigte Geschwindigkeit gegenüber der Luft">IAS</abbr>)!<br />
**Die '''''Minuten''''' sind die Zeit bis zur Ankunft am {{HBabbr|DME}}-Sender, wenn die Geschwindigkeit und Richtung konstant bleiben!<br />
<br />
''Du findest ein Beispiel für die Anwendung im [[De/HB_IFR-Flug#4.29_Der_.E2.80.9EProcedure_Turn.E2.80.9C_.28Umkehr-Prozedur.29|"{{HBabbr|IFR}} Cross-Country", Kapitel "Der Prozedure Turn'']]<br />
<br /><br /><br />
----<br />
<br />
=='''Standard VOR-Prozeduren'''==<br />
===Piktogramme===<br />
Auf Flugkarten findest Du verschiedene {{HBabbr|VOR}}-Typen mit unterschiedlichen Piktogrammen:<br />
{| cellpadding="10" cellspacing="2" border="0"<br />
|align="center"|[[File:ILS-VOR.png]]<br />
||Das ganz normale '''''{{HBabbr|VOR}}''''' <span style="color:red">ohne {{HBabbr|DME}}</span>. <br />
<small>''VHF Omnidirectional Radio Range == Drehfunkfeuer''. Mehr auf: http://de.wikipedia.org/wiki/Drehfunkfeuer</small><br />
|-<br />
|align="center"|[[File:DME.png]]<br />
||Ein eigenständiges '''''{{HBabbr|DME}}''''' <span style="color:red">ohne {{HBabbr|VOR}}</span><br />
<small>. Mehr auf: http://de.wikipedia.org/wiki/Distance_Measuring_Equipment )</small><br />
|-<br />
|align="center"|[[File:VOR-DME.png]]<br />
||'''''VOR-DME''''' = ein {{HBabbr|VOR}} gekoppelt mit einem {{HBabbr|DME}}, für beide Funktionen muss nur die {{HBabbr|VOR}}-Frequenz eingestellt werden<br />
|-<br />
|align="center"|[[File:TACAN.png]]<br />
||'''''TACAN''''' = ein militärisches {{HBabbr|VOR}}, dass nicht zivil genutzt werden kann.<br />
<small>''Tactical Air Navigation System == militärische Flugnavigationsverfahren''</small><br />
|-<br />
|align="center"|[[File:VORTAC.png]]<br />
||'''''{{HBabbr|VORTAC}}''''' = (die "eierlegendeWollmilchsau") beinhaltet sowohl ein {{HBabbr|VOR}}-{{HBabbr|DME}} wie auch ein {{HBabbr|TACAN}}! Wobei für {{HBabbr|VOR}} und {{HBabbr|TACAN}} unterschiedliche Frequenzen eingegeben und benutzt werden - aber beide stellen den {{HBabbr|DME}}-Teil automatisch ein.<br />
<small>Mehr auf: http://en.wikipedia.org/wiki/File:VORTAC_TGO_Aichtal_Germany_01.JPG</small><br />
|-<br />
|align="center"|[[File:Pictogram NDB.png|47px]]<br />
||'''''{{HBabbr|NDB}}''''' = Ungerichtetes Funkfeuer: Zeigt dem Piloten mittels {{HBabbr|ADF}} an in welcher Richtung sich das {{HBabbr|NDB}} befindet. Im Gegensatz zum {{HBabbr|VOR}} kannst Du dieses aber nicht anfliegen indem Du einem Radial folgst - somit wirst du bei Seitenwind immer etwas abgetrieben - und somit einen Bogen fliegen! <small>(Siehe oben [[#Das_ADF_.2F_NDB|Das {{HBabbr|ADF}}/NDB]])</small><br />
<small>''Non-Directional Beacon == Ungerichtetes Funkfeuer''. Mehr auf: http://de.wikipedia.org/wiki/Tactical_Air_Navigation</small><br />
|}<br />
===Direkt zu einem VOR Âfliegen===<br />
Das heißt wir sind irgendwo in der Luft und wollen zu einem bestimmten {{HBabbr|VOR}} fliegen (den wir in der MPmap, der Map, in ATLAS, einer Luftfahrtkarte, etc. gefunden haben, oder der uns von {{HBabbr|ATC}} zugewiesen wurde):<br />
*Stelle die {{HBabbr|VOR}}-Frequenz ein und wechsele diese dann von der „Standby“ in die „Aktive“ Position (in die linke Anzeige).<br />
*Überprüfe ob der Morse-Code stimmt!! (Es gibt viele {{HBabbr|VOR}}'s mit der gleichen Frequenz!!!)<br />
*Drehe den Knopf am {{HBabbr|OBS}}-Instrument bis sich die vertikale Nadel zentriert '''''UND das kleine Fenster „TO“''''' anzeigt!!<br />
**Die Nadel zentriert sich 2 mal: Einmal als „FROM“ (dann zeigt sie vom {{HBabbr|VOR}} weg) und einmal als „TO“ (dann zeigt sie zum {{HBabbr|VOR}} hin!).<br />
**Wenn das <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr> eine Abweichung anzeigt und Du dieser folgst - die Abweichung aber größer anstatt kleiner wird, dann drehe um 180°! Du hast offensichtlich "TO/FROM" verwechselt! <br />
**Wenn überhaupt nichts angezeigt wird<br />
***überprüfe ob die Frequenz für das {{HBabbr|VOR}} in dem benutzten NAV-Radio stimmt (und in der linken Anzeige steht!)<br />
***ist das {{HBabbr|VOR}} in Reichweite? (bis etwa 100 mi, wenn keine Berge dazwischen sind<br />
***ist das NAV eingeschaltet?<br />
*Folge der Nadel wie oben beschrieben!<br />
*Wenn die Nadel plötzlich stark ausschlägt und dann "TO" nach "FROM" wechselt - dann hast Du gerade den {{HBabbr|VOR}} überflogen<br />
**im Normalfall kannst Du dann erst einmal den Kurs beibehalten<br />
**oder {{HBabbr|ATC}} die Ankunft über dem {{HBabbr|VOR}} mitteilen (und evtl. in eine "Warteschleife" gehen)<br />
**oder den Kurs wie geplant ändern<br />
<br /><br />
===Ãœber dem VOR auf neuen Kurs drehen===<br />
Wir wollen nun also nicht nur auf einem "TO-radial" zum {{HBabbr|VOR}} hinfliegen (siehe vorstehend), sondern beim Überqueren direkt auf einen neuen Kurs gehen! Dazu könntest Du natürlich warten bis Du über dem {{HBabbr|VOR}} bist und dann das {{HBabbr|OBS}} neu einstellen - aber oft hast Du über dem {{HBabbr|VOR}} noch mehr zu tun und außerdem sieht es bescheuert aus, denn Du würdest erst weit hinter dem {{HBabbr|VOR}} auf den neuen Kurs kommen. Geschickter, in Bezug auf Kosten, Zeit, und Aussehen, ist das Folgendes:<br />
<br />
*Lasse George <small>(den Autopiloten, '''''wir müssen also das NAV1 benutzen'''''!)</small> die <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr>-Nadel zentriert halten während wir auf den {{HBabbr|VOR}} zufliegen - wie im vorstehenden Kapitel beschrieben<br />
*Noch auf dem Wege hin zum {{HBabbr|VOR}} stelle den "'''''roten Marker'''''" im "Heading Indicator" auf den Kurs den Du '''''vom {{HBabbr|VOR}}''''' wegfliegen willst <small>(aber noch NICHT "HDG" drücken!)</small><br />
*Warte bis "TO/FROM" anfängt sich zu bewegen - dann drücke "'''''HDG'''''" (am AP) und die Maschine wird direkt auf den neuen Kurs einschwenken ''(auch wenn Du noch nicht ganz über dem {{HBabbr|VOR}} bist!)''<br />
*Nun hast Du Zeit ganz in Ruhe<br />
**Dein {{HBabbr|OBS}} auf die neue Richtung einzustellen, achte darauf dass "FROM" im Fenster angezeigt wird<br />
**oder sogar den zukünftigen {{HBabbr|VOR}} mit Frequenz und {{HBabbr|OBS}} einzustellen, achte dann darauf dass "TO" angezeigt wird!<br />
*Und dann schaltest Du wieder auf "'''''NAV'''''" und George wird die <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr>-Nadel zentrieren und zentriert halten!<br />
<br /><br />
<br />
===Auf Kurs gehen mittels VOR:===<br />
Gerade auf größeren Flughäfen, oder in deren Nähe, findest Du oft auch einen {{HBabbr|VOR}}-Sender. Du kannst dann einem der Radiale folgen um einen bestimmten Kurs zu fliegen und dabei einem genau vordefinierten Weg über der Landschaft folgen. Du wirst also definitive genau über dem Ziel ankommen, auch bei Seitenwind, Kursabweichungen, Ungenauigkeiten im Ablesen des Kompass, etc. etc..<br />
<br />
Siehe ein Beispiel auf der [[De/HB_Features#MPmap|MPmap]] bei Frankfurt: Wir werden in EDDF starten und auf dem Radial "270° FROM" weg-fliegen:<br />
{|<br />
||[[File:VOR-Departure at EDDF.png|600px|thumb|left|In EDDF starten und auf den Radial "FROM 270°" des {{HBabbr|VOR}} "FFM" einschwenken]]<br />
|}<br />
*Stelle schon vor dem Start den Kurs „weg vom {{HBabbr|VOR}}“ ein, also die Frequenz (114.20) im NAV-Teil des Radios und den Radial (FROM 270) im {{HBabbr|OBS}}-Instrument. ''(Nebenbei bemerkt: Fällt Dir auf, dass das {{HBabbr|VOR}}-FFM als "{{HBabbr|VORTAC}}" bezeichnet wird? Das stammt aus der Zeit als EDDF zusätzlich eine große Militärbasis war! Deshalb auch noch immer 2 Frequenzen: eine zivile 114.20 und ein militärisches {{HBabbr|TACAN}} "089X"!)''<br />
<br />
*Nach dem Start (und der Freigabe durch {{HBabbr|ATC}}) gehe auf einen Kurs auf dem Du den Radial kreuzt. Am Besten kreuzt („intersect“) Du den Radial nicht im rechten Winkel, sondern möglichst auf einem Kurs 30-60° schräg zum Radial. Also in unserm Falle etwa auf Kurs:<br />
**240° (=270-30) wenn wir nach dem Start nördlich des Kurses sind<br />
**300° (=270+30) wenn wir nach dem Start südlich des Kurses sind<br />
:Der 30° Winkel erleichtert es uns beim Einscheren nicht (zu weit) über den Radial hinaus getragen zu werden. Ab einem Winkel von 60° ist es kaum möglich halbwegs gesittet auf unseren Reisekurs einzuschwenken - wir würden erst eine ganze Weile hin- und her-zappeln, bevor wir uns auf den {{HBabbr|VOR}}-Radial eingependelt haben!<br />
<br />
*Vergewissere Dich, dass im Instrument „'''''FR'''''“ <small>("FROM" = weg von)</small> angezeigt wird! (Du willst ja nicht aus Versehen in Moskau anstatt in Paris aufzuwachen!<br />
<br />
*Beobachte Dein Instrument: Sobald die vertikale Nadel anfängt sich zum Zentrum hin zu bewegen, drehst Du auf den Radial-Kurs ein und hältst diesen indem Du die Anzeige der Nadel zentriert hältst: Weicht sie nach rechts ab – ändere Deinen Kurs nach rechts – und umgekehrt. Versuche die Kurskorrekturen klein zu halten (ca. 10°) - und beobachte die Nadel ob sie langsam zurück-wandert – wenn nicht: Vergrößere die Korrektur. Aber sei geduldig: Je weiter weg Du vom {{HBabbr|VOR}} bist um so größer wird die Strecke (siehe die rot/weiße "1") die Du zurücklegen musst, bis sich die Korrektur auf dem Instrument bemerkbar macht – das heißt: Bis sich der Winkel zwischen Abweichung und Radial messbar verringert hat.<br />
<br /><br />
===Positionsbestimmungen mittels VOR/DME}===<br />
*Tune eines Deiner NAVs auf die Frequenz eines {{HBabbr|VOR}} in Deiner Nähe (je nach Höhe bis zu 100 mi Umkreis!) und stelle den {{HBabbr|DME}}>-Selektor (siehe weiter unten) entsprechend auf NAV1 oder NAV2.<br />
*Du solltest nun bereits die Entfernung zu dem {{HBabbr|VOR}} sehen (wenn nicht - bist Du vielleicht zu weit weg, oder ein Berg liegt dazwischen, oder der {{HBabbr|VOR}} hat kein {{HBabbr|DME}})<br />
*Drehe nun die kleine Stellschraube links unterhalb des {{HBabbr|OBS}} bis die senkrechte Nadel des Instruments genau senkrecht steht – lese den Radial ab (ganz oben auf der Kompass-Rose des {{HBabbr|VOR}}) - notiere ob es "TO" oder "FROM" ist - das benötigst Du später um die Richtung in der Karte einzutragen!<br />
*Wenn Du eine genaue Positionsbestimmung benötigst, solltest Du die Werte auf einer "Luftfahrtkarte" eintragen (wegen der unterschiedlichen magnetischen/kartographischen Richtungsanzeigen)<br />
**wenn es nicht soooo genau sein muss, kannst Du auch eine Straßenkarte nehmen (und evtl. die Differenz hinzurechnen, vergleiche [[De/HB_VFR_Flug#Kurs|"Der Kurs"]] in unserem Cross-Country Flug).<br />
*Trage/zeichne diesen Radial in die Karte ein: Also eine Gerade durch den Mittelpunkt des {{HBabbr|VOR}} mit der gefunden Richtung.<br />
*Und messe auf dieser Geraden den Abstand vom Mittelpunkt des Radials. Siehe dazu die Maßstabsangabe der Karte.<br />
Du solltest danach noch einmal Dein Tun verifizieren, indem Du während des Fluges das {{HBabbr|DME}} beobachtest: Die angezeigt Entfernung sollte größer bzw. kleiner werden, je nachdem ob Du auf das {{HBabbr|VOR}} zufliegst oder Dich davon entfernst!<br />
<br /><br /><br />
===Positionsbestimmung mit 2 VOR ({{HBabbr|NDB}}):===<br />
Wenn uns kein {{HBabbr|VOR}} mit {{HBabbr|DME}} zur Verfügung steht, können wir zwei {{HBabbr|VOR}}s in Reichweite anpeilen, indem wir deren Frequenzen in die NAV-Geräte eingeben und dann die Kompass-Rosen so lange verdrehen, bis beide Nadeln senkrecht stehen. Auf den Navigationskarten sind die {{HBabbr|VOR}}s mit ihren (magnetischen) Kompass-Rosen dargestellt – wir müssen dann also nur mit dem Lineal vom Mittelpunkt des jeweiligen {{HBabbr|VOR}} ausgehend über die Radial-Einteilung jeweils eine Linie ziehen und erhalten so als Kreuzungspunkt den derzeitigen Standort. (Ja, ich gebe zu: In einem Jet mit Überschall-Geschwindigkeit könnte das etwas ungenau werden! - Aber wir sind ja in einer C172p! Da macht es doch Spaß zu lernen - und außerdem musst Du das zur Erlangung einer Pilotenlizenz vorführen können!).<br />
<br />
*'''''Tip: '''''Ich selbst benutze diese "uralt"-Methode" selten wie gerade beschrieben! Aber ich benutze dies gerne umgekehrt: Wenn ich im Gebirge niedrig durch die Täler fliegen möchte, trage ich mir vorher gerne ein paar wichtige Wegpunkte in die (Straßen-) Karte ein, um beobachten zu können, ob ich wirklich in dem Tal bin in dem ich sein möchte! In den meisten Tälern möchte man dann nämlich lieber nicht sein: Das Steigvermögen einer Cessna (und auch anderer Spaß-Modelle) ist nämlich sehr limitiert - und das Ende eines Tales ist meist zu eng um umzukehren! (Ja sicher: <abbr title="Global Positioning System == Satellitennavigations-System">GPS</abbr> (und dazu möglichst auch noch Autopilot) ist einfacher -- aber macht es auch so viel Spass?). Am besten ist es dann einen {{HBabbr|VOR}} mit einem Radial zu finden der längs des kritischen Tales verläuft, und einen anderen möglichst rechtwinkelig dazu. Mit den beiden Radials definierst Du "Entscheidungspunkte" (Abbiegen, Drehen nach, Umkehren/Steigen, etc.) - und dann beobachtest Du die Nadeln um zu sehen<br />
:ob Du bereits angekommen bist,<br />
:oder evtl. schon zu weit bist,<br />
:ob du noch richtig bist,<br />
:''etc.''<br />
<br />
*'''''Beachte: '''''Die Positionsbestimmung wird hierbei um so genauer, um so mehr die beiden gemessenen Radials ±90° von einander abweichen. Also z.B: Auf den einen {{HBabbr|VOR}} zu/weg-fliegen - und den anderen möglichst 90° auf einer Seite haben!<br />
<br />
Natürlich könntest Du dies auch mittels "1 {{HBabbr|VOR}} & 1 {{HBabbr|NDB}}" oder sogar "2 {{HBabbr|NDB}}s" machen -- allerdings wird das deutlich ungenauer als mit 2 {{HBabbr|VOR}}'s - und die Reichweite der {{HBabbr|NDB}}s ist sehr limitiert.<br />
<br /><br /><br />
===Anfliegen eines Navigationspunktes===<br />
In diesem Beispiel suchen wir den Wegpunkt „'''''MISON'''''“, der genau auf dem Kreuzungspunkt zweier Radiale liegt. ''(Vergleiche [[#Der_NAV-Teil_.3D_VOR_.26_ILS|die Sectional weiter oben]] und/oder [[De/HB_IFR-Flug#2.29_Entlang_der_V334_zum_FIXpunkt_SUNOL.2C_via_MISON|die Anwendung im Kapitel {{HBabbr|IFR}} CrossCountry)]]''.<br />
<br />
*Setze also Dein NAV1 und NAV2 wie in der Grafik [[#Die_.22einfache.22_Radio_Einstellungen:|„Radio Frequencies“]] gezeigt (NAV1=114,1/002 und NAV2=116,8/114).<br />
<br />
*Wir scheren also als erstes auf den Kurs „NAV1: 002° FROM“ ein und stellen sicher dass die <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr>-Nadel zentriert ist und bleibt (d.h. diesen Teil könnte man auch dem Autopiloten anvertrauen!)<br />
<br />
*Dann warten wir ab, bis sich die <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr>-Nadel des NAV-2 bewegt<br />
**Evtl. solltest Du jetzt sicherstellen ob Du noch vor dem Kreuzungspunkt bist - oder schon dahinter!<br />
***Allerdings ist (mir) die Interpretation dessen, was die NAV2-Nadel uns sagen will manchmal schwierig! Ich helfe mir dabei, in dem ich mir vorstelle<br />
****ich schaue vom {{HBabbr|VOR}}-2 aus entlang des Radials (114°) und weiß, dass mein Flug den Radial von rechts nach links kreuzen soll<br />
****und ich weiß, das die Nadel die Richtung der Abweichung angibt:<br />
*****die NAV2-Nadel nach '''''links''''' bedeutet: Wir müssten nach links korrigieren - wir sind also '''''tatsächlich noch rechts''''' vom Radial: '''''Also noch vor dem Kreuzungspunkt!'''''<br />
*****die NAV2-Nadel nach '''''rechts''''' bedeutet: Wir müssten nach rechts korrigieren - sind also '''''tatsächlich schon links''''' vom Radial: '''''Also schon hinter dem Kreuzungspunkt!'''''<br />
***Also ich hab immer wieder Schwierigkeiten mit der Vorstellung - aber Ãœbung hilft!<br />
**Wenn beide Nadeln genau senkrecht stehen, befinden wir uns genau über dem in der Navigationskarte eingezeichnetem Punkt „MISON“. Aber bevor Du Dir vergeblich die Augen ausschaust: Dies ist keine landschaftliche Sehenswürdigkeit – es ist ein rein elektronischer (<abbr title="Global Positioning System == Satellitennavigations-System">GPS</abbr>) Navigationspunkt -- ein sogenannter "FIX"-Punkt, definiert durch 2 Radiosignale - sonst nix!<br />
<br /><br />
----<br />
==''' Das ILS (Instrument LandeSystem)'''==<br />
{{HBabbr|ILS}}-Sender stehen direkt an Landebahnen und leiten anfliegende Flugzeuge zum Aufsetzpunkt der Landebahn. Sie funktionieren genau wie die {{HBabbr|VOR}}'s, indem sie uns zu einem bestimmten Ort auf einem bestimmten Radial führen. Im Unterschied zum {{HBabbr|VOR}}<br />
<br />
*ist der Radial aber nicht frei wählbar! Er wird vom Sender fest vorgegeben und ist immer die genaue Richtung der Landebahn – wunderbar: Um die Einstellung des Radial brauchst Du Dich also nicht zu kümmern!<br />
**'''''Aber Vorsicht: '''''Bei den Anzeige-Instrumenten der "modernen" c172p macht dies keinen Unterschied. Doch es gibt viele Modelle bei denen das <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr> nicht automatisch synchronisiert wird! Wenn Du bei denen den Radial nicht einstellst, dann sind die <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr>-Anzeigen wertlos! Also besser doch das Radial einstellen!<br />
**Und wenn Du Dir irgendwann einen '''''[[#HSI:_Das_Horizontal_Situation_Instrument|HSI]]''''' leisten kannst, musst Du unbedingt die Richtung der Landebahn möglichst genau eingeben, damit die Kursabweichung korrekt angezeigt wird.<br />
:'''''==> Also ist es besser, die genau Richtung der Landebahn immer einzugeben - anstatt es dann zu vergessen wenn man es braucht!!'''''<br />
<br />
*oft sendet das {{HBabbr|ILS}} zusätzlich zu dem üblichen (horizontalen) Signal auch noch ein "vertikales", den sogenannten "GS" (GlideSlope, Gleitflug, Höhe) aus. Das funktioniert sinngemäß wie beim <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr>:<br />
**wenn die Nadel nach '''''oben zeigt: Erhöhe die RPM''''' um die Sinkgeschwindigkeit zu reduzieren<br />
**wenn die Nadel nach '''''unten zeigt: Reduziere die RPM''''' um das Sinken zu beschleunigen<br />
<br />
:Berücksichtige, dass die GS-Anzeige erst sehr viel später aktiv wird als die Richtungsanzeige! Verlasse Dich auf die Höhenangaben erst ab ungefähr 10 Meilen vor der Landebahn-Schwelle! ''(Das <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr> kann schon 100 mi vorher aktiv sein!)''<br />
<br />
*die Genauigkeit bzw. Sensibilität des Localizer's ist etwa 4 mal höher als die eines {{HBabbr|VOR}}! d.h. '''''Du solltest Deine Korrekturen dementsprechend "feiner" dosieren als bei einem üblichen {{HBabbr|VOR}}!'''''<br />
<br />
<br />
'''''Hast Du bemerkt: '''''Wir haben hier mit keinem Wort das {{HBabbr|DME}} erwähnt -- weil es beim {{HBabbr|ILS}} technisch gesehen kein {{HBabbr|DME}} gibt! Wenn Du die Entfernung zum Flugplatz wissen willst, musst Du einen {{HBabbr|VOR}}-{{HBabbr|DME}} (zusätzlich im NAV2) benutzen (oder <abbr title="Global Positioning System == Satellitennavigations-System">GPS</abbr>). Bei den meisten Groß-Flughäfen ist ein {{HBabbr|VOR}} in der Nähe oder sogar im Zentrum <small>(siehe nachfolgend KSFO)</small> - oder es gibt einen {{HBabbr|VOR}} und ein eigenständiges {{HBabbr|DME}} dazu<small>(siehe nachfolgend EDDF)</small>! Beispiele für diese Möglichkeiten sind:<br />
<br />
{| cellpadding="10" cellspacing="2" border="1"<br />
|-<br />
||[[File:ILS-KSFO.png|300px|thumb|left]]<br />
<br />
In KSFO siehst Du den idealen Aufbau: Genau in der Mitte aller Landebahnen steht ein {{HBabbr|VOR}}-{{HBabbr|DME}}. Somit kannst Du den {{HBabbr|VOR}} schon von weit ausserhalb dazu benutzen um Dich auszurichten, und kannst gleichzeitig bis zur Landung (ziemlich) genau verfolgen wie weit Du noch außerhalb bist!<br />
<br />
Somit kannst Du:<br />
<br />
*NAV1 für das {{HBabbr|ILS}} benutzen <small>(Öffne mit Klick auf das "+" rechts vom RW-Namen "28R" den Localizer</small> '''→ 111.70'''<small>, ILS-catIII)</small><br />
*NAV2 für das {{HBabbr|VOR}} benutzen, inklusive des {{HBabbr|DME}} <small>(siehe im Zentrum der Landebahnen, </small>'''→ 115.80''')<br />
|-<br />
||[[File:ILS-EDDF.png|300px|thumb|left]]<br />
In EDDF kannst Du ähnliches erreichen, indem Du den {{HBabbr|VORTAC}} (inclusive {{HBabbr|DME}}) benutzt - aber die Entfernungsangaben (bei Nebel!) sind dann doch sehr ungenau! Du solltest also ein bisschen mehr arbeiten und den {{HBabbr|DME}} auf dem Flugplatz mit einbeziehen. Seit neuestem hat dieser sogar eine eigene zivile Frequenz: '''''<span style="color:rgb(204, 51,204)">115.9 MHz</span>''''' (siehe http://www.ourairports.com/navaids/FRD/Frankfurt_DME_DE/).<br />
<br />
Somit musst Du hier (der Genauigkeit wegen) 3 Frequenzen einstellen:<br />
<ol><li><br />
Setze den {{HBabbr|VORTAC}} 114.2 in das NAV2<br />
</li><li><br />
Setze das {{HBabbr|DME}} 115.9 in das NAV1<br />
<br />dann schalte den {{HBabbr|DME}}-Selector zuerst auf "1", das setzt die {{HBabbr|DME}}-Anzeige auf das {{HBabbr|DME}}<br />
<br />und dann auf "HOLD", dann wird diese {{HBabbr|DME}}-Einstellung gehalten (bis Du von "HOLD" wegschaltest!)<br />
</li><li><br />
Setze die {{HBabbr|ILS}}-Frequenz in das NAV1<br />
</li></ol><br />
Damit hast Du also 3 Frequenzen:<br />
#114.2: Der {{HBabbr|VORTAC}} auf NAV2 für die weitreichende Navigation (die dabei vorhandene {{HBabbr|DME}}-Anzeige benutzen wir nicht!)<br />
#109.5: Der {{HBabbr|ILS}} Localizer und Glideslope auf NAV1<br />
#115.9: Das eigenständige {{HBabbr|DME}} auf "HOLD"<br />
|}<br />
<br />
'''''Somit erfolgt ein {{HBabbr|ILS}}-Anflug wie folgt:'''''<br />
<br />
#Stelle die {{HBabbr|ILS}}-Frequenz in eins der NAV-Geräte - '''''wenn Du damit auch den Autopilot steuern willst, muss es das NAV1 Gerät sein!'''''<br />
#Wie vorher gesagt ist es besser, auch den Localizer/Radial ({{HBabbr|OBS}}) auf die Landebahn-Richtung einzustellen<br />
#Ab einer Entfernung von 16 bis 50 Meilen zur Landebahn sollte das NAV-Gerät aktiv anzeigen (falls kein Berg oder ähnliches dazwischen liegt). Das heißt das <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr> zeigt an, die "TO" Flag wird sichtbar, etc. Aber beachte:<br />
#*Wenn Du aus der entgegengesetzten Richtung anfliegst, zeigt das <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr> genau verkehrt herum an (z.B. auf dem Downwind)<br />
#*Das Gleiche passiert wenn Du einen GoAroud (Abbrechen und neue Anfliegen) machst und somit entgegen der Richtung des Localizer's fliegst<br />
#*Falls das NAV + <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr> + TO/FROM bei 16 mi außerhalb noch Nichts anzeigen, wird es Zeit die eingestellte Frequenz zu überprüfen, oder nach-zuschauen ob Berge auf Deinem Anflug sind, oder .. oder ..<br />
#In einer Entfernungen zwischen etwa 5 bis 20 Meilen vor der Landebahn schwenkst Du entsprechend des <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr> (wie {{HBabbr|VOR}}-üblich) auf den waagerechten Leitstrahl (dem sogenannten '''''Localizer''''') ein und folgst ihm hin zur Landebahn<br />
#*Falls Deine Flugplatz-Informationen nichts anderes definieren, solltest Du an dieser Stelle etwas höher sein als die Platzrunde (ca 800 bis 1000 ft oberhalb des Flugplatz Niveaus).<br />
#Folge dem <abbr title="Course Deviation Indicator == VOR-Kurs Anzeige">CDI</abbr> während Du die Höhe beibehältst, bis:<br />
#*etwa 10 Meilen vor dem Aufsetzpunkt die waagerechte Nadel (der sogenannte Glideslope = '''''GS''''') aktiv wird<br />
#*An dieser Stelle solltest Du UNTERHALB des GS sein!! d.h. die Nadel zeigt nach oben! Ansonsten wärst Du zu hoch angeflogen!<br />
#**Die meisten Anfänger werden dann gleich nervös und versuche wie gewohnt der Nadel zu folge (oder noch schlimmer: Sofort den GS am AutoPiloten einzuschalten!) -- das wäre hier absolut falsch, fliege waagerecht weiter bis die Nadel sich senkt und genau horizontal anzeigt - im Vergleich zu dem üblichen {{HBabbr|VOR}} heißt das: Du bist auf den Glideslope eingeschwenkt (hast ihn "intercepted").<br />
#*Wenn Du schon anfangs deutlich oberhalb des GS anfliegst, solltest Du sofort einen Neuen Anflug starten (Go Arround). Wenn Du versuchst mit extremen Mitteln auf den GS zu kommen, wirst Du alle Deine wunderbar ein-geübten Prozeduren verfehlen - und Du wirst Dich nach der Landung voraussichtlich schämen müssen! Das ist es nicht wert!<br />
#Bleibe also auf Deiner Anflughöhe (unterhalb des Leitstrahls), bis der waagerechte Zeiger von oben her die Mitte erreicht, '''''erst dann''''' folgst Du auch dem horizontalen Zeiger.<br />
#Entlang des Leitstrahls gibt es 3 Signal-Sender die im Cockpit audio/visuelle Signale auslösen:<br />
##'''''Outer Marker: Blaues''''' Licht + '''''400 Hz''''' Ton, Position 4-7nm vor der Landebahnschwelle<br />
##'''''Middle Marker: Amber''''' Licht + '''''1300 Hz''''' Ton, Position 0.5-0.8 nm vor der Landebahnschwelle<br />
##'''''Inner Marker: Weißes''''' Licht + '''''3000 Hz''''' Ton: direkt über der Landebahnschwelle<br />
<br />
Als einer, der auch viel {{HBabbr|ATC}}-Services macht höre ich immer wieder "das {{HBabbr|ILS}} arbeitet nicht!" oder ähnliches. Glaube mir: Niemand glaubt Dir das! Weder der {{HBabbr|ATC}}, noch Dein Fluglehrer, noch die <abbr title="Federal Aviation Agency == (US-) Luftfahrt-Bundesamt">FAA</abbr>, noch...! Technische Probleme mit dem {{HBabbr|ILS}} sind äußerst selten - Pilotenfehler allerdings recht häufig! Außerdem bist Du verpflichtet sofort manuell zu übernehmen wenn die Automatik versagt! Ich hoffe Du hast gelernt auch ohne Autopilot zu landen!<br />
<br />
'''''Eine Warnung: '''''Die meisten Modell schaffen mit dem Autopiloten keine Landung bis zum Aufsetzen - wenn also Dein Modell es nicht schafft, schalte in Zukunft den Autopiloten so früh ab, das Du noch Zeit zum manuellen eingewöhnen hast - ich würde vorschlagen etwa 100ft über dem Boden!<br />
<br />
Tatsächlich macht es viel Spaß zur Übung den {{HBabbr|ILS}}-Nadeln zu folgen - auch ohne den Autopiloten zu aktivieren!<br />
<br />
''(Für weitere {{HBabbr|ILS}}-Details siehe http://de.wikipedia.org/wiki/Instrumentenlandesystem )''<br />
<br /><br /><br />
----<br />
<br />
=='''<abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAP</abbr>: Die "{{HBabbr|IFR}}-Anflug-Prozedur"'''==<br />
Wie Du in den vorangegangenen {{HBabbr|VFR}}-Flügen bereits gemerkt hast, richtest Du Dein Flugzeug nicht irgendwie auf die nächste Landbahn aus und landest da. Schon unter {{HBabbr|VFR}} musst Du erstmal in die Platzrunde! Dies hilft Dir selbst um Dich ordentlich auszurichten - und hilft Allen nicht ständig zusammen-zustoßen - denn die meisten Leute mögen das gar nicht!<br />
<br />
Bei echten {{HBabbr|IFR}}-Flügen ''(bei schlechter Sicht!)'' besteht diese Notwendigkeit sogar noch mehr. Und da die Flughäfen und Landbahnen weltweit sehr unterschiedlich sind, gibt es für jede Landbahn (die für {{HBabbr|IFR}} zugelassen ist) eine besondere Prozedur.<br />
<br />
Du findest diese Anflug-Beschreibungen bei den Flughafen-Beschreibungen, also z.B.:<br />
<br />
*'''''für die USA z.B.:'''''<br />
:*http://de.flightaware.com/resources/airport/KLVK (tippe irgendeinen <abbr title="International Civil Aviation Organisation == Flughafen ID's">ICAO</abbr>-Code am Ende), dort findest Du<br />
:::→ „IFR-Diagramme“ = {{HBabbr|IFR}} Airport Prozeduren (/<abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAP</abbr>)<br />
:::→ „ILS Runway 25R“ (die einzige in KLVK verfügbare) –''''' diese werden ich für unseren Flug benutzen!'''''<br />
<br />
:*oder in http://www.airnav.com/airport/KLVK<br />
:::die Anflug-Karten sind ziemlich weit unten auf der Seite!<br />
<br />
*'''''für Deutschland z.B.:'''''<br />
:*http://www.vacc-sag.org/?PAGE=airport_overview<br />
:::'''''→ siehe z.B. für EDDF die „IAC VOR RWY 25R“''''' etc. ect. - EDDF hat ein paar mehr Prozeduren zu bieten als KLVK<br />
:::'''''→ aber siehe z.B. auch das kleine Sylt (EDXW):''''' Auch dieses hat solche „Approach Charts“, z.B. die „NDB/DME 14“ - schau Dir evtl. erst einmal diese an, um die wesentlichen Punkte zu erkennen – bevor Du dann in die sehr komplexen Charts der großen Flughäfen einsteigst!<br />
<br />
*'''''ansonsten weltweit z.B.:'''''<br />
:*http://www.vatsim.net/charts/<br />
<br />
Siehe z.B.: '''''KLVK ILS RWY 25R'''''<br />
Während unsres (nachfolgenden) "{{HBabbr|IFR}} Cross-Country" planen wir in Livermore auf der Landbahn 25R unter {{HBabbr|IFR}}-Bedingungen zu landen. Das nehmen wir hier als Beispiel:<br />
<br />
Livermore hat nur 2 <abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAP</abbr>s - während große Airports davon sehr viele haben können. Siehe z.B. das naheliegende KSFO, oder das europäische EHAM, die haben davon jede Menge! Dort gibt es extra Prozeduren für {{HBabbr|ILS}}, <abbr title="Global Positioning System == Satellitennavigations-System">GPS</abbr>, LDA, {{HBabbr|VOR}}, etc.... Es würde mich nicht überraschen wenn es irgendwo auch noch ein Prozedur für das Landen mit Sextanten und Sanduhr gäbe. Und um {{HBabbr|IFR}} zu lernen, musst Du alle diese Typen beherrschen! (Nun ja, die Eieruhr mit dem Sextanten kannst Du heutzutage vergessen - aber es gibt noch Kapitäne, die das während Trans-Atlantic-Flügen (in DC8, Super-Conny, u.ä.) benötigt haben!)<br />
<br />
Für Livermore gibt es (Gott sei Dank) nur 2 <abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAP</abbr>s. Siehe z.B. http://skyvector.com/airport/LVK/Livermore-Municipal-Airport dort findest Du ganz unten auf der Seite zwei <abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAP</abbr>s:<br />
#eine für {{HBabbr|ILS}}: "ILS RWY 25R"<br />
#und eine für <abbr title="Global Positioning System == Satellitennavigations-System">GPS</abbr>: "RNAV (GPS) RWY 25R"<br />
Da wir in unserm "{{HBabbr|IFR}} Cross-Country" unsere {{HBabbr|ILS}}-Ausrüstung testen wollen (und auch nix anderes haben!) entscheiden wir uns also für die "ILS RWY 25R":<br />
{|<br />
||[[File:IFR IAP-KLVK-25R.png|left]]<br />
|}<br />
Diese Anflug-Karten sind weltweit nicht überall genau gleich – aber sie beinhalten immer mindestens drei Teile (die aber nicht so schön farbig markiert sind wie hier!):<br />
#Im '''''weißen''''' oberen Teil stehen grundsätzliche Informationen wie Name, Frequenzen, etc.<br />
#Im '''''rosa''''' Teil ist der Anflug-Plan von oben gesehen, für die Richtungs-Angaben<br />
#Im '''''gelben''''' Teil ist der Anflug-Plan von der Seite gesehen, für die Höhen-Angaben<br />
<br />
2+3 zusammen ergeben also eine 3D (räumliche) Darstellung des Anfluges. Falls Du kein Architekt oder Maschinenbauer bist, ist das anfangs etwas verwirrend – ich werde versuchen es im Nachfolgenden zu erläutern!<br />
<br />
Weitere Angaben sind oft an sehr unterschiedlichen Stellen eingetragen, aber immer vorhanden. Dies sind z.B. Angaben über:<br />
<br />
*'''''Minimum-Werte '''''die für einen Anflug vorgeschrieben sind, z.B. minimale Sichtweiten, erforderliche Radioausstattungen, etc. (hier in der grünen Box)<br />
<br />
*'''''Missed Approach Prozeduren '''''für ein Durchstarten (GoArround) mit Richtungen und Höhen etc. (hier in der weißen Box oben rechts)<br />
<br />
*'''''Minimale Anflughöhen '''''per Richtung, dargestellt in einem Kreis, aufgeteilt in Anflug-Sektoren (hier in der rosa Box rechts unten)<br />
<br />
*den '''''Flugplatz-Lageplan '''''(hier in der weißen Box links unten)<br />
<br />
*''etc.''<br />
<br />
'''''Das Auslesen der <abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAP</abbr>:'''''<br />
Wir müssen als erstes den Anfang der Prozedur finden, den sogenannten <abbr title="Initial Approach Fix == Der Anfangspunkt einer IAP (Initial Approach Procedure)">IAF</abbr>:<br />
<br />
Siehe oben im rosa Bereich → für KLVK gibt es zwei IAF's:<br />
<ol><li><br />
In der Mitte ist der '''''LOM/IAF REIGA''''' (ein {{HBabbr|NDB}} auf der Frequenz 374), dieser hat 2 Funktionen:<br />
*Als <abbr title="Locator Outer Marker == Anfangspunkt für Endanflug">LOM</abbr> definiert er einen standardisierten Anflug-Punkt vor der Landebahn-Schwelle (6.1 nm vor der Landbahn-Schwelle, auf einer Höhe von 1039 ft). Hast Du diese Werte gefunden? "'''''6.1 NM'''''" findest Du im gelben Bereich am unteren Rand, die "'''''1039'''''" stehen direkt am {{HBabbr|NDB}}-Symbol mittig im rosa Bereich!<br />
*Als <abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAF</abbr> ist er der Start der <abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAP</abbr>. Mittels des dort vorhanden {{HBabbr|NDB}} ist er einfach zu finden: Einfach die Frequenz 374 im {{HBabbr|ADF}} einstellen und der Nadel folgen! Die Höhe zu finden ist ein bisschen umständlicher: Es ist 2409(im gelben) + (über :) 1039(im rosa) = 3448!<br />
</li><li><br />
Ziemlich mittig am rechten Rand ist ein zweiter '''''<abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAF</abbr>''''' mit Namen '''''TRACY'''''. Diesem ist zusätzlich eine Warteschleife zugeordnet. Damit könnte es (in der Wirklichkeit) sein, dass uns {{HBabbr|ATC}} als erstes dahin verweist, wenn es gerade viele Anflüge gibt! Aber es könnte auch sein, dass wir den Punkt für einen "'''''Missed Approch'''''" ''(Fehlanflug)'' benötigen (siehe im weißen Feld ganz oben rechts.)! Aber das kennen wir ja aus dem Kapitel "Anflug mittels zweier {{HBabbr|VOR}}s" im Teil "Radio NAV". Wir finden diesen FIX also als Schnittpunkt der Radials:<br />
:157° FROM {{HBabbr|VOR}} "SAC" (SACRAMENTO) on 115.20<br />
:229° FROM {{HBabbr|VOR}} "ECA" (MANTECA) on 116.0<br />
</li></ol><br />
<br />
Vom <abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAF</abbr> aus (s.o.) tasten wir uns also vorwärts:<br />
<br />
*Da wir sowieso von Süden kommen werden, werden wir also mit dem „<abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAF</abbr> REIGA“ anfangen.<br />
<br />
*Von dort aus erscheint Alles recht einfach: Nach links abbiegen und schon sind wir auf dem Leitstrahl ({{HBabbr|ILS}}-LOCALIZER, siehe im <abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAP</abbr> links: Freq. 110.5) --- aber das ist für Profis wie uns viel zu einfach: '''''Wir fliegen erst einmal vom Flugplatz weg!'''''<br />
::Siehst Du rechts vom REIGA die dicke, abknickende Linie mit einer halben Pfeilspitze und der Beschriftung „030°“ und „210°“? Das bedeutet einen „'''''Procedur Turn'''''“ - also zur Anflug-Prozedur gehört auch eine Prozedur der Kehrtwende. Aber die Leute machen es uns einfach: Sie sagen uns direkt im Bild wie das geht:<br />
::*erst einmal nach rechts auf Gegenkurs (255-360=) 75° (siehe auch ganz rechts am Ende des großen Pfeils!)<br />
::*nach '''''2 Minuten''''' drehen wir nach links auf Kurs '''''030°''''', dabei sinken wir langsam auf '''''3300 ft''''' (siehe im gelben: Am Ende der Prozedur sollten wir auf 3300 ft sein!)<br />
::*nach weiteren '''''2 Minuten''''' machen wir einen „U-Turn“, drehen also um 180° nach ... wohin? Richtig: Nach rechts, denn der neue Kurs '''''210°''''' steht auf der Karte rechts vom 030°!<br />
<br />
*Damit sind wir nun auf eine normale {{HBabbr|ILS}}-Landung vorbereitet:<br />
**wir bleiben auf dem Kurs '''''210°''''' bis wir auf den '''''LOCALIZER''''' (Freq. 110.5) einschwenken (Richtung hier 255°)<br />
**während wir dann auf den Flugplatz zufliegen sinken wir auf '''''2800 ft''''' <br />
**und bleiben auf dieser Höhe bis wir wir in den vertikalen Glide-Slope einschwenken, d.h. diesem nach unten folgen!.<br />
<br />
*Und so kommen wir zurück zu nserem alten Freund "'''''NDB REIGA'''''", diesmal auf einer Höhe von 1039 ft.<br />
**wobei RIEGA nun kein <abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAF</abbr> mehr ist, sondern jetzt der "'''''Outer Marker'''''" ist – dort werden wir also mit einem 400 Hz Ton und einem blinkenden blauen Licht begrüßt → damit wissen wir dann, dass wir (einigermaßen gut) auf dem {{HBabbr|ILS}} Leitstrahl sind und es noch 6.1 nm bis zur Landebahnschwelle sind!<br />
**übrigens ist für den "Outer Marker" immer auch die Höhe angegeben: Dies ist für "sorgfältige" Piloten noch einmal eine Check ob sie auf richtiger Höhe sind, ob der "Glideslope" funktioniert, etc. etc.<br />
<br />
*"'''''Missed Approach'''''": Es wird nun höchste Zeit noch einmal zu überdenken, was passiert wenn wir den Anflug abbrechen müssen! Natürlich gibt es auch dafür eine Prozedur: Siehe in der weißen Box oben rechts mit dem Titel "MISSED APPROACH" und die Angaben im grünen Bereich unten:<br />
:*Letztere besagen, dass wir für die "S-ILS 25R" die Landung abbrechen '''''müssen''''', wenn wir auf einer Höhe von '''''597 ft''''' (also 200 ft über Boden) die Landbahn noch nicht in Sicht haben!<br />
<br />
Lass uns alle weit verstreuten Angaben zu dieser Prozedur noch einmal anschauen:<br />
{| cellpadding="10" cellspacing="10"<br />
|-<br />
||[[File:IFR_IAP-GoAround.png|left]]<br />
» wie schon gesagt gibt es die wörtliche Kurzfassung in dem weißen Block oben rechts<br />
<br />» im rosa Teil siehst Du am Ende der Landebahn eine gestrichelte Linie die die Abfluglinie vorgibt<br />
<br />» hin zu einer Warteschleife am rechten Bildschirmrand<br />
<br />» und im gelben Bereich siehst Du das Ganze noch einmal in 5 Symbolen. Von links nach rechts<br />
<br />
#Steige geradeaus (=Landebahnrichtung!) auf 1100 ft<br />
#Auf 1100 ft steige weiter auf 3000 während Du nach rechts drehst<br />
#Fliege zum {{HBabbr|NDB}} "LV" ("LV" ist die Kennung für REIGA)<br />
#Nach "LV" gehe auf Kurs 062°<br />
#Und gehe über dem FIX "TRACY" in die Warteschleife<br />
<br />
und dort beruhigen wir uns erst einmal wieder innerlich und warten darauf, dass uns der {{HBabbr|ATC}} zum erneuten Landversuch auffordert. Du siehst wir sind ziemlich da wo wir auch vorher den {{HBabbr|ILS}}-Anflug gestartet haben - also kein Problem für uns das dann noch einmal zu versuchen!<br />
<br />
<small>Siehe hierzu auch das Kapitel [[De/HB_Wissen#Procedure-Turns_.3D_Warteschleifen|"Warteschleife" im Teil "Wissen"]].</small><br />
|}<br />
<br /><br /><br />
----<br />
<br />
=='''Die Map'''==<br />
Mit der FlightGear-Version 2.4. wurde das im Versuchs-Stadium befindliche "Map" formell integriert (siehe "''Menü-Leiste --> Equipment --> Map''").<br />
Diese "Map" hilft insbesondere bei Flügen mittels Radio-Navigation. Siehe dazu weitere Informationen unter:<br />
:» für eine Beschreibung des Projektes selbst siehe im FlightGear-WIKI http://wiki.flightgear.org/Map<br />
:» die folgenden Beispiele basieren auf dem "{{HBabbr|IFR}} Cross-Country"-Flug, den wir im nächsten Kapitel durchführen werden.<br />
{|<br />
||[[File:HB-IFR-Map1.png|left]]<br />
|}<br />
Du <small>(das gelbe Flugzeugsymbol unten rechts)</small> bist gerade in '''''KRHV''''' gestartet und fliegst nun Richtung 310° zur "Luftstrasse 334". Diese Luftstraße folgt hier dem Radial "'''''SJC 009'''''", den wir im NAV-1 eingestellt haben und auf den wir einscheren werden.<br />
<br />
Der nächste Wegpunkt ist die Kreuzung des Radials "'''''SJC 009'''''" mit "'''''OAK 114'''''" (dieser wurde im NAV-2 eingestellt) - diese Kreuzung definiert den "'''''FIX SUNOL'''''". Der Name "SUNOL" erscheint nicht auf der MAP, da "FIXes" (oben links) nicht aktiviert ist.<br />
<br />
Aber da "Navaids" aktiviert ist, siehst DU:<br />
:» die {{HBabbr|VOR}}s "'''''SJC'''''" und "'''''OAK'''''" in türkis, denn beide sind in unseren NAV1/2 eingestellt<br />
:» dagegen ist der {{HBabbr|VOR}} "'''''OSI'''''" (im unteren linken Quadranten) nicht türkis und ohne Radial, da wir ihn z.Z. nicht benutzen!<br />
<br />
"'''''LV'''''" (ganz oben/rechts) ist der Code-Name (und Morse-Code) für den '''''{{HBabbr|NDB}}"REIGA"''''', welcher unser '''''<abbr title="Initial Approach Fix == Der Anfangspunkt einer IAP (Initial Approach Procedure)">IAF</abbr>''''' für unseren geplanten Anflug auf '''''KLVK''''' ist!<br />
<br />
Da "Traffic" aktiviert ist, sehen wir auch die <abbr title="Veranstaltungen mit mehreren Teilnehmern">Multiplayer</abbr> die sich in unserer Gegend bewegen, z.B. "alex" etwas links von uns und "Godwin" auf dem {{HBabbr|ILS}} nach KSFO. Beachte auch die Richtungsanzeige:<br />
:» "'''''alex'''''" fliegt in Richtung SW relativ schnell<br />
:» verglichen mit "'''''Godwin'''''", der im Anflug auf KSFO dem {{HBabbr|ILS}} langsamer folgt<br />
<br /><br /><br />
{|<br />
||[[File:HB-IFR-Map2.png|left]]<br />
|}<br />
Im vorstehenden Bild haben wir bereits unseren NAV-2 vom Radial "'''''OAK 114" auf "ECA 229" geändert''''', und sind jetzt auf dem Wege vom FIX "'''''SUNOL" zum {{HBabbr|NDB}} "REIGA".'''''<br />
Wie hier schön zu sehen ist, wird der FIX "'''''SUNOL'''''" durch die beiden Radials "'''''SJC 009'''''" und "'''''OAK 114'''''" definiert - und der Name ist nun sichtbar, da "Fixes" aktiviert ist.<br />
<br />
Außerdem haben wir jetzt "Data" aktiviert und sehen somit auch einige Informationen zu den Navigations-Punkten. z.B.:<br />
:» '''''KLVK''''' mit seinen Landebahnen "07L/25R" und der Länge 5236 ft, in den Kompass-Richtungen 91°/271°<br />
:» '''''REIGA''''' mit der Kennung/Morse-Code "'''''LV'''''" und der Frequenz 374 Khz<br />
<br />
Beachte auch den Fix "'''''FOOTO'''''". Nach dem Abbiegen auf 075° über REIGA werden wir an diesem FIX unsere Umkehr mit einer Drehung nach links auf 030° beginnen!<br />
<br />
Beachte zusätzlich, dass dieser Abschnitt dann genau entgegengesetzt dem anfliegenden Verkehr auf dem {{HBabbr|ILS}} nach KLVK ist! Wir sollten also aufpassen und unser Höhe halten!<br />
<br /><br /><br /><br />
Im vorstehenden Bild waren wir auf dem Weg von SUNOL nach REIGA. Inzwischen<br />
{|<br />
||[[File:HB-IFR-Map3.png|left]]<br />
|}<br />
:» sind wir über '''''REIGA auf Kurs 075° nach FOOTO''''' geflogen<br />
:: » wobei FOOTO durch das Kreuzen des Radial "ECA 229" mit unserm "{{HBabbr|NDB}}-Kurs 075°" definiert ist<br />
:» über FOOTO haben wir nach links auf Richtung 030° gedreht<br />
:» und haben dann nach 2 Minuten um 180° nach rechts auf 210° gedreht<br />
<br />
Auf diesem Kurs 210° werden wir nun bald auf den Localizer des "'''''KLVK ILS 25R'''''" einschwenken. Hast Du bemerkt dass das {{HBabbr|ILS}} seine Farbe von dukelblau in türkis geändert hat? Und der Radial '''''"SJC 009" ist verschwunden'''''! --> Wir benötigen den Radial "SJC 009" nicht mehr und benutzen unser NAV-1 nun für das {{HBabbr|ILS}} - welches deshalb nun in türkis angezeigt wird!<br />
<br />
Du solltest auch "'''''TRACY'''''" wiedererkennen (gerade links von uns) - der andere "<abbr title="Initial Approach Fix == Der Anfangspunkt einer IAP (Initial Approach Procedure)">IAF</abbr>", und zugleich auch der FIX-Punkt für eine evtl. benötigte Warteschleife, z.B. nach einem "MISSED APPROACH". Damit wissen wir, dass wir hart am Rande des uns erlaubten 10 Meilen Radius der Kontroll-Zone sind (siehe die [[#IAP:_Die_.22IFR-Anflug-Prozedur.22|<abbr title="Initial Approach Procedure == Verfahren für den IFR Endanflug">IAP</abbr>]])! Also solltest Du aufpassen nicht viel weiter hinaus-zufliegen!<br />
<br />
Falls Du diesen Flug vorher noch nicht gemacht hast, ist diese Beschreibung vielleicht schwer zu verstehen. Siehe dann den folgenden [[De/HB_IFR-Flug|"{{HBabbr|IFR}} Cross-Country"]], und dazu insbesondere die Planung der dazugehörenden "[[De/HB_IFR-Flug#Die_IFR-Anflug-Prozedur_.3D_IAP|IFR-Anflug-Prozedur]]"</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=93661Turbulence2016-02-25T14:32:52Z<p>Lisbellaw: /* FDMs */</p>
<hr />
<div>{{Stub}}<br />
<br />
== Objective ==<br />
Explain how turbulence works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specify the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example you can switch between some turbulence models when you choose JSBSim as you flight dynamic model. Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
== Properties ==<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [http://wiki.flightgear.org/$FG_ROOT /$FG_ROOT]/Environment/interpolator.xml):<br />
<br />
<br />
-<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
-<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
-<input><br />
-<expression><br />
-<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
<br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying a different magnitude than 2 in the [http://wiki.flightgear.org/$FG_ROOT /$FG_ROOT]/Environment/environment.xml file at the following place:<br />
<br />
<br />
-<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
<br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further transfer with respect to the used FDM. <br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [http://wiki.flightgear.org/JSBSim_Atmosphere JSBSim Atmosphere]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in [http://wiki.flightgear.org/$FG_SRC /$FG_SRC]/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in [http://wiki.flightgear.org/$FG_SRC /$FG_SRC]/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in [http://wiki.flightgear.org/$FG_SRC /$FG_SRC]/FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt() that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file [http://wiki.flightgear.org/$FG_SRC /$FG_SRC]/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. <br />
<br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
== Related ==</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=93660Turbulence2016-02-25T14:24:07Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Stub}}<br />
<br />
== Objective ==<br />
Explain how turbulence works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specify the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example you can switch between some turbulence models when you choose JSBSim as you flight dynamic model. Therefore, this article will mainly discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence.<br />
<br />
== Properties ==<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [http://wiki.flightgear.org/$FG_ROOT /$FG_ROOT]/Environment/interpolator.xml):<br />
<br />
<br />
-<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
-<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
-<input><br />
-<expression><br />
-<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
<br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying an other magnitude than 2 in the [http://wiki.flightgear.org/$FG_ROOT /$FG_ROOT]/Environment/environment.xml file at the following place:<br />
<br />
<br />
-<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
<br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further tranfser with respect to the used FDM. <br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [http://wiki.flightgear.org/JSBSim_Atmosphere JSBSim Atmosphere]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in /src/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in /src/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in /FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file /src/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. <br />
<br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
== Related ==</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Fixing_presets&diff=93629Fixing presets2016-02-25T09:43:04Z<p>Lisbellaw: /* Background */</p>
<hr />
<div>{{Portability Navbar}}<br />
<br />
== The Problem ==<br />
{{FGCquote<br />
|One important use of FlightGear is as a pilot training aid, and one huge thing that instructors like to do is setup in-air starts so you can practice a lot of approaches in a short amount of time (that's one of the key benefits of a simulator over a real airplane.)<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/26527536/<br />
|title=<nowiki>[Flightgear-devel] Fwd: in air starts and all preset control/trim<br />
settings broke</nowiki><br />
|author=<nowiki>Curtis Olson</nowiki><br />
|date=<nowiki>2010-11-01</nowiki><br />
}}<br />
}}<br />
<br />
The addition of Presets has caused a plethora of problems and many regressions, including breaking support for [[Reset & re-init]], but also for saving/loading flights.<br />
<br />
{{cquote|<br />
The original reset was a simple kludge that worked fine for a simple program; now that FlightGear is a lot more sophisticated, we need to refactor a bit<br />
rather than just holding things together with scotch tape and bubble gum.<br />
<br />
The problem is that right now we have two different approaches - a lot of stuff is handled cleanly in individual modules' update() methods, but a lot of stuff is still handled by hundreds of lines of BASIC-like, hard-to-read spaghetti code in main.cxx and fg_init.cxx (forget OO, it's not even functional programming).<br />
<br />
That was the right idea to get started - I'm not a fan of wasting time on an initial OO design that you won't end up using -- but now we need to finish cleaning it up. We need to make this a high priority.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg06781.html|title= Crash on "Reset" function.|author=David Megginson |date=Thu, 06 Jun 2002 05:03:39 -0700}}</ref>|David Megginson}}<br />
<br />
{{cquote|<br />
The position init code is a little complex, to allow for starting on a carrier and some other cases, and ideally we would do it from script, but unfortunately there's some technical limitations on doing that. (Not insurmountable, but not quick either). Adding more cases to the position-init code is certainly doable - one suggestion I made some time ago, is when MP is active, to default to starting at a free parking position instead of on a runway. (When no startup position is provided at all). This would avoid people accidentally starting on the runway in MP events, which would be a big usability win.<br />
<br />
When no parking positions are defined, AI traffic defaults to the 'airport centre' location. Selection a taxiway parallel to the active runway is possible, but for complex airport layouts I can imagine many ways this logic could fail. Personally I think it would be more robust to stick to picking parking positions, and otherwise using the airport centre, because it would encourage people to add the parking position data :)<br />
<br />
I anyone wants to work on this, it would be a self-contained function in position-init code, just ask here for any questions. All the pieces certainly exist - the taxiways, parking locations and runways for the airport are all accessible.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/attachment/F69E014E-F15A-4EAB-B512-36B87CA3B2C5%40mac.com/1/|title= Aircraft positioning on the runway|author=James Turner |date=2013-11-12 10:32:27}}</ref>|James Turner}}<br />
<br />
== Status (03/2015) ==<br />
{{FGCquote<br />
|reset and reposition now use the same codepath (something I've been working towards for many months). They do a full control reset, but after that, a full initial state restore. (it would be possible to support a 'nearby' re-position that doesn't touch the tile-manager, AI manager, or so on, and just re-inits the FDM - but that's something for the future, if people want it)<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/26536759/<br />
|title=<nowiki>Re: [Flightgear-devel] Fwd: in air starts and all preset<br />
control/trim settings broke</nowiki><br />
|author=<nowiki>James Turner</nowiki><br />
|date=<nowiki>2010-11-03</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|we already saved all the initial state at the end of the main init - but Nasal scripts run before that state is saved - so running presets-commit then confuses things mightily. What I do now, is special case position changes (presets-commit) that happen during startup, and skip the reset path entirely, since it's unnecessary. This gives us:<br />
* Nasal can merrily re-init during startup if it chooses<br />
* control values specified on the command line, -set files or config survive the init process<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/26536759/<br />
|title=<nowiki>Re: [Flightgear-devel] Fwd: in air starts and all preset<br />
control/trim settings broke</nowiki><br />
|author=<nowiki>James Turner</nowiki><br />
|date=<nowiki>2010-11-03</nowiki><br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|Reposition and reset from the GUI both work, and will give you the state as specified in the -set & config files, and command line. Since reposition from the GUI *is a* reset (now), some properties may change that previously did not, but I can't imagine a situation where the old behaviour was better - since we already wiped the FDM and control state regardless.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/26536759/<br />
|title=<nowiki>Re: [Flightgear-devel] Fwd: in air starts and all preset<br />
control/trim settings broke</nowiki><br />
|author=<nowiki>James Turner</nowiki><br />
|date=<nowiki>2010-11-03</nowiki><br />
}}<br />
}}{{FGCquote<br />
|Reposition and reset from the GUI both work, and will give you the state as specified in the -set & config files, and command line. Since reposition from the GUI *is a* reset (now), some properties may change that previously did not, but I can't imagine a situation where the old behaviour was better - since we already wiped the FDM and control state regardless.<br />
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/26536759/<br />
|title=<nowiki>Re: [Flightgear-devel] Fwd: in air starts and all preset<br />
control/trim settings broke</nowiki><br />
|author=<nowiki>James Turner</nowiki><br />
|date=<nowiki>2010-11-03</nowiki><br />
}}<br />
}}<br />
== Background ==<br />
At one point we decided that it would be useful to reset the aircraft position to someplace else while running FlightGear. JSBSim was modified so if it sensed that any of the position properties where changed it would retrim to those values. This was a start, but the problem was that we were using the same set of properties to report fdm position/orientation as we were using to request a change. This turned out to be a little hard to work with, especially if you wanted to change several parameters ... you got reset 1 time for each parameter you changed.<br />
<br />
So somewhere along the line we came up with a /presets property tree. The idea is that you can fill the tree with all the preset pameters you want to set. Then call for either an on-ground reset or an in-air reset.<br />
<br />
I think the approach itself is very sound, however, it's the implimentation spread across a couple different FDM's and a lot of various code changes that has become a bit complicated.<br />
<br />
There's a /sim/presets area in the property manager which is where all the FDM initial conditions can be batched up. Things like:<br />
<br />
* airport-id (i.e. KSFO)<br />
* runway (i.e. 1R)<br />
* offset-distance (i.e. 7 miles out)<br />
* altitude (i.e. 2000')<br />
* glideslope (i.e. on a 3 degree glide slope)<br />
* airspeed (i.e. 90 kts)<br />
<br />
We setup a facility to define initial conditions in the /sim/presets property tree. This way we can setup our position *request* without needed to change the actual current position. This currently isn't setup to accept an initial pitch, but as far as I know the individual FDM's aren't either.<br />
<br />
You can set altitude, heading, speed (see --vc=kts option) as well as various offsets to runways and navaids.<br />
<br />
You can set any or all of these and when you are satisfied, choose the Presets->Commit menu option (or its corresponding fgcommand).<br />
<br />
<br />
Please note that there is a lot of complexity in this task and a lot of interdependencies with other pieces of the program. We might be able to hide or move or rearrange the complexity, but it's always going to be a little tricky.<br />
<br />
The way this was intended to work is that if you want to start on the ground, you should set the altitude to -9999.<br />
Exposing the raw /sim/presets properties to the end user leaves a lot of room for them to make mistakes.<br />
<br />
== Issues ==<br />
{{cquote|<br />
Here's my current hypothesis: when FlightGear is reset, some modules are replaced with new ones (the old ones may or may not be deleted, but are never unbound). We end up with all kinds of dangling references, especially (but not exclusively) for bound properties, and eventually things grind to a halt.<br />
<br />
If I'm right, the property module makes the crash happen sooner, but the crash *will* happen one way or another, and there are probably some nasty memory leaks in there as well. Remember that reset has always caused occasional unexplained, hard-to-reproduce crashes.<br />
<br />
The long-term fix is to finish the cleanup of main.cxx and fg_init.cxx so that all initialization code is moved out to the subsystems, and<br />
the subsystems themselves are kept in a single, ordered list so that they can be managed easily and transparently. It should not be<br />
necessary to delete and replace any subsystems on a reset, with the exception of the FDM, since all can adjust their state as required.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg06742.html |title= Crash on "Reset" function.|author=David Megginson |date=Wed, 05 Jun 2002 08:00:36 -0700}}</ref>|David Megginson}}<br />
<br />
{{cquote|<br />
I believe the problems started when developers that didn't 'use the reset function often' started making changes to the 'basic' program flow.<br />
<br />
ie this roughly corresponds to the introduction of the BFI<br />
<br />
Hopefully once we get 'reset' working again developers will test 'reset' before submitting their changes in the future so we don't repeat this<br />
quagmire<br />
<br />
IMHO it became a kludge because and ONLY because it was 'ignored' by some in their development efforts and I kept trying to retrofit it back<br />
in on top of a program that was being changed rapidly by some who apparently didn't care about the requirements of the 'reset' functionality.<br />
<br />
IMHO being able to pause, restart with initial conditions, restart with arbritray conditions is a good < should I say basic > test of a well designed<br />
simulation. ie one that is controlable As such IMHO and I realize that this may not be your opinion, getting 'restart' working again AND KEEPING it working is a necessary thing todo.<br />
<br />
It shouldn't be that difficult in that it only requires that you return the individual parts of the simulation to their initial conditions. It is a GOOD exercise in that it illustrates the interdependencies of the program by rewarding you with a 'hard crash' if you do not understand them.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg06769.html |title= Crash on reset|author=Norman Vine|date=Wed, 05 Jun 2002 15:48:34 -0700}}</ref>|Norman Vine}}<br />
<br />
{{cquote|<br />
There's also more to the problem. If we're restoring a saved flight then everything's fine, since all of the FDM state is already valid. If, on the other hand, we're starting in the air, then we need a general trimming routine like the one Tony wrote for JSBSim and LaRCsim to avoid violent oscillations at startup.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg09856.html |title= Presets menu|author=David Megginson |date=Mon, 18 Nov 2002 14:44:41 -0800}}</ref>|David Megginson}}<br />
<br />
{{cquote|<br />
I've actually added a general reinit facility for FlightGear subsystems, but most subsystems haven't been modified to support it yet. In time, we should be able to reinitialize anything - 3D models, keyboard bindings, radio frequencies, or even scenery - without stopping the program. <ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg11597.html |title= GUI|author=David Megginson |date=Fri, 24 Jan 2003 04:41:29 -0800}}</ref>|David Megginson}}<br />
<br />
<br />
{{cquote|<br />
Unfortunately, while the presets hierarchy brought some benefits, it<br />
also broke saving and restoring flights. I think that it's time to<br />
consider doing away with the presets hierarchy, and trying something<br />
like this:<br />
<br />
1. Make an in-memory copy of the property tree that we can revert to when the user wants to reset; we could even keep a stack of reset points, if that was useful to anyone.<br />
<br />
2. Add a few /sim/startup properties to indicate what information should be used for position, orientation, etc. For example,<br />
* /sim/startup/init/position-type : (latlon,airport,navaid,runway)<br />
* /sim/startup/init/altitude-type : (msl,agl,glidepath)<br />
* /sim/startup/init/orientation-type : (rph,runway)<br />
* /sim/startup/init/time-type : (utc,local,sunpos)<br />
<br />
I'm sure that people can think of a better classification. From this point on, then, our initialization code can simply look at these to decide whether to initialize based on the airport, etc.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg17214.html |title= Beyond presets|author=David Megginson |date=Fri, 19 Sep 2003 13:07:52 -0700}}</ref>|David Megginson}}<br />
<br />
<br />
{{cquote|<br />
Write the initial conditions directly into the main property tree. We would need to hold onto a few properties to say which setting to use (say, for location), but this system in general should work much better, since cannot predict what properties any given vehicle might need to preserve on a reset. Essentially, a reset is nothing more than an in-memory save/restore.<ref><br />
{{cite web |<br />
url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18879.html |<br />
title= Re: Helicopters: wow!|<br />
author=David Megginson |<br />
date=Mon, 24 Nov 2003 08:50:37 -0800}}</ref>|David Megginson}}<br />
<br />
{{cquote|<br />
I think that we can do that more cleanly by allowing operation on a second property tree. Here's what I'm suggesting:<br />
<br />
1. Set up the initial property tree (from preferences, the command line, etc.) before running any cycles.<br />
2. Make a deep copy of that tree that can be restored.<br />
With a reset: you should end up with exactly what you started with.<br />
We can provide fgcommands for partial copies from the backup tree -- in that case, it is simply a matter of a few bytes of XML glue (menu, keyboard, etc.) for each kind of reset.<ref><br />
{{cite web |<br />
url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18887.html |<br />
title= Re: Helicopters: wow!|<br />
author=David Megginson |<br />
date=Mon, 24 Nov 2003 08:50:37 -0800}}</ref>|David Megginson}}<br />
<br />
{{cquote|<br />
Yes, reset and save/restore are a bit broken in FlightGear right now. I'll try to fix them when I have a chance, but it will require a bit of refactoring (removing Curt's initial-state stuff, for example).<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@flightgear.org/msg18869.html |title= Re: Helicopters: wow!|author=David Megginson |date=Mon, 24 Nov 2003 07:22:13 -0800}}</ref>|David Megginson}}<br />
<br />
{{cquote|I suspect the sensible thing to do would be to define<br />
* a reset function, and<br />
* a locate (or relocate) function, separate from reset.<br />
<br />
That way the reset function could make a structured reference to<br />
the locate function if it wants to ... while other folks could<br />
call the locate function without getting mixed up with all the<br />
other reset-related functionality.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg08143.html |title=location-in-air|author=John Denker |date=Sun, 07 Jan 2007 09:20:14 -0800}}</ref>|John Denker}}<br />
<br />
<br />
{{cquote|Physics says it ought to work: I start out (on the ground or<br />
in the air) with a reasonable power setting and reasonable<br />
trim settings, I can give myself a new altitude, a new XY<br />
position, a new heading, and/or a new airspeed ... and it<br />
just works. Try it sometime.<br />
<br />
The garbage-in-garbage-out principle applies: If you relocate<br />
yourself into the air before starting the engines, you'll have<br />
a few moments of excitement dealing with the consequences.<br />
Similarly, if you dictate a new airspeed that is inconsistent<br />
with your elevator trim setting, you'll get some additional<br />
excitement.<br />
<br />
It should be particularly obvious that air-to-air relocation<br />
should just work. Air "here" looks a lot like air "there".<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg08168.html |title=location-in-air|author=John Denker |date=Sun, 07 Jan 2007 10:54:48 -0800}}</ref>|John Denker}}<br />
<br />
<references/><br />
<br />
[[Category:RFC]]<br />
[[Category:Core development projects]]</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=93542Turbulence2016-02-24T13:38:38Z<p>Lisbellaw: /* FDMs */</p>
<hr />
<div>{{Stub}}<br />
<br />
== Objective ==<br />
Explain how turbulence works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specify the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example you can switch between some turbulence models when you choose JSBSim as you flight dynamic model. Therefore, this article will discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence. <br />
<br />
== Properties ==<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Now, assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [http://wiki.flightgear.org/$FG_ROOT /$FG_ROOT]/Environment/interpolator.xml):<br />
<br />
<br />
-<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
-<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
-<input><br />
-<expression><br />
-<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
<br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying an other magnitude than 2 in the [http://wiki.flightgear.org/$FG_ROOT /$FG_ROOT]/Environment/environment.xml file at the following place:<br />
<br />
<br />
-<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
<br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further tranfser with respect to the used FDM. <br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [http://wiki.flightgear.org/JSBSim_Atmosphere JSBSim Atmosphere]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to the example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
<br />
Thus, the specified value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in /src/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in /src/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in /FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file /src/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. <br />
<br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
== Related ==</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=93541Turbulence2016-02-24T13:35:11Z<p>Lisbellaw: /* JSBSim */</p>
<hr />
<div>{{Stub}}<br />
<br />
== Objective ==<br />
Explain how turbulence works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specify the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example you can switch between some turbulence models when you choose JSBSim as you flight dynamic model. Therefore, this article will discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence. <br />
<br />
== Properties ==<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Let's assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [http://wiki.flightgear.org/$FG_ROOT /$FG_ROOT]/Environment/interpolator.xml):<br />
<br />
<br />
-<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
-<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
-<input><br />
-<expression><br />
-<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
<br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying an other magnitude than 2 in the [http://wiki.flightgear.org/$FG_ROOT /$FG_ROOT]/Environment/environment.xml file at the following place:<br />
<br />
<br />
-<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
<br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further tranfser with respect to the used FDM. <br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [http://wiki.flightgear.org/JSBSim_Atmosphere JSBSim Atmosphere]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to our example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
<br />
Thus, our value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in /src/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in /src/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in /FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file /src/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. <br />
<br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
== Related ==</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=93529Turbulence2016-02-24T11:48:47Z<p>Lisbellaw: Processing the option --turbulence=n.n to the JSBSim ttMilspec model and further general informations</p>
<hr />
<div>{{Stub}}<br />
<br />
== Objective ==<br />
Explain how turbulence works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
In FlightGear it is possible to set the option <code>--turbulence=0.0 to 1.0</code> which specify the turbulence from 0.0 (calm) to 1.0 (severe). The difficulty is to translate this value to all the different variants that allow a calculation for the turbulent wind fluctuations. For example you can switch between some turbulence models when you choose JSBSim as you flight dynamic model. Therefore, this article will discuss how the turbulence is influenced by the value of <code>--turbulence=0.0 to 1.0</code> with respect to the different computational methods that are possible for determining the turbulence. <br />
<br />
== Properties ==<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
All flight dynamic models who are able to calculate turbulent fluctuations of the windfield (it seems that only YASim and JSBSim can do this) need to know the value one can set in the console via <code>--turbulence=value</code>. Therefore one single magnitude between zero and one have to translate into several quantities which are considered in the different turbulence calculations. Let's assume you have specify <code>--turbulence=0.5</code> and do not change this during running flightgear. Then generally, the property "/environment/config/presets/turbulence-magnitude-norm" is the first one who obtains this value. Afterwards, another property called "/environment/turbulence/raw-magnitude-norm" get this value too and the most important property "/environment/turbulence/magnitude-norm" is calculated through (see [http://wiki.flightgear.org/$FG_ROOT /$FG_ROOT]/Environment/interpolator.xml):<br />
<br />
<br />
-<filter><br />
<name>EnvironmentInterpolator:turbulence-magnitude</name><br />
-<enable><br />
<property>/environment/config/enabled</property><br />
</enable><br />
-<input><br />
-<expression><br />
-<pow> <br />
<property>/environment/turbulence/raw-magnitude-norm</property><br />
<property>/environment/turbulence/sensitivity</property><br />
</pow><br />
</expression><br />
</input><br />
<output>/environment/turbulence/magnitude-norm</output><br />
<type>gain</type><br />
<gain>1</gain><br />
</filter><br />
<br />
<br />
In other words this means "/environment/turbulence/raw-magnitude-norm" to the power of "/environment/turbulence/sensitivity", hence 0.5 <sup>2</sup>. It is possible to change this procedure by specifying an other magnitude than 2 in the [http://wiki.flightgear.org/$FG_ROOT /$FG_ROOT]/Environment/environment.xml file at the following place:<br />
<br />
<br />
-<turbulence><br />
<!-- the turbulence/magnitude-norm interpolator applies this value as an exponent to the magnitude --><br />
<sensitivity type="double">2</sensitivity><br />
</turbulence> <br />
<br />
<br />
In the code itself, the value of 0.5 is saved in a variable called magnitude_norm (see /src/Environment/presets.cxx). The following lines should explain the further tranfser with respect to the used FDM. <br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation (see [http://wiki.flightgear.org/JSBSim_Atmosphere/ JSBSim Atmosphere]). This results in the question how the value of <code>--turbulence=value</code> you have set is processed in this model. The first and crucial steps happen in /src/FDM/JSBSim/JSBSim.cxx. A variable called turbulence_gain is initialized via <code>turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)</code>. Thus, according to our example, turbulence_gain has a value of 0.25. The next step depands on what turbulence type do you use. We will discuss it here for the default variant, the ttMilspec turbulence model. In this case (also when you choice ttTustin) the connection between the value you have told flightgear (0.5, respectively 0.25) and JSBSim is realized through:<br />
<br />
double tmp = turbulence_gain->getDoubleValue();<br />
Winds->SetProbabilityOfExceedence(<br />
SGMiscd::roundToInt(TurbulenceSeverityTable.GetValue( tmp ) )<br />
);<br />
<br />
Thus, our value of 0.25 (now corresponds tmp) determines how the value of the variable probability_of_exceedence_index is set. The function ProbabilityOfExceedence() itself is defined in /src/FDM/JSBSim/models/FGWinds.h. The procedure for getting the probability_of_exceedence_index is realized as follows: The object TurbulenceSeverityTable which belongs to the class FGTurbulenceSeverityTable (also described in /src/FDM/JSBSim/JSBSim.cxx) calls the function GetValue which is defined in /FDM/JSBSim/math/FGTable.cpp. This combination ensures that the returned value is calculated on the basis of the FGTurbulenceSeverityTable<br />
<br />
class FGTurbulenceSeverityTable : public FGTable {<br />
public:<br />
FGTurbulenceSeverityTable() : FGTable(4) {<br />
*this << (0.0/9.0) << 0.0;<br />
*this << (1.0/9.0) << 3.0;<br />
*this << (4.0/9.0) << 4.0;<br />
*this << (9.0/9.0) << 7.0;<br />
}<br />
};<br />
<br />
Usally, tmp is different from 0, 1.0/9.0, 4.0/9.0 or 1. Therefore the function GetValue(double key) do a linear interpolation in each interval. For our case this means that we get a probability_of_exceedence_index of 3 because 0.25 is between 1.0/9.0 and 4.0/9.0 and a linear interpolation results in a value of roughly 3.42 (don't forget to notice the function roundToInt that rounds the double value to an integer). Once we have the probability_of_exceedence_index it is used in the file /src/FDM/JSBSim/models/FGWinds.cpp to get a value from the POE_table. As you can see in the turbulence computation in FGwinds.cpp this is only important for heights greater than 2000ft. Thereby, the option <code>--turbulence=value</code> does not influence the turbulence near the ground, at least for the JSBSim ttMilspec variant. <br />
<br />
<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
== Related ==</div>Lisbellawhttps://wiki.flightgear.org/w/index.php?title=Turbulence&diff=93486Turbulence2016-02-24T09:10:42Z<p>Lisbellaw: </p>
<hr />
<div>{{Stub}}<br />
<br />
== Objective ==<br />
Explain how turbulence works in FlightGear and its FDMs.<br />
<br />
== Background ==<br />
<code>--turbulence=0.0 to 1.0</code> Specify turbulence from 0.0 (calm) to 1.0 (severe)<br />
<br />
== Properties ==<br />
{{FGCquote<br />
|1= In /src/Environment/presets.cxx you find the nodes<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm-override") and<br />
<br />
("/environment/config/presets/turbulence-magnitude-norm").<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= In /src/Environment/environment.cxx you can find another property called<br />
<br />
"turbulence/magnitude-norm"<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Code ==<br />
{{FGCquote<br />
|1= The file /src/main/options.cpp deals with all the options you can set in the console, maybe also the turbulence value betweenero and one; see:<br />
<syntaxhighlight lang="cpp"><br />
static int fgOptTurbulence( const char *arg )<br />
{<br />
Environment::Presets::TurbulenceSingleton::instance()-&gt;preset( atof(arg) );<br />
return FG_OPTIONS_OK;<br />
}<br />
</syntaxhighlight><br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Subsystems ==<br />
=== FGRidgeLift ===<br />
<br />
== FDMs ==<br />
=== JSBSim ===<br />
The JSBSim flight dynamic model has the most opportunities to create a turbulent wind situation [see http://wiki.flightgear.org/JSBSim_Atmosphere].<br />
{{FGCquote<br />
|1= In /src/FDM/JSBSim/JSBSim.cxx handels again with some more turbulence properties like<br />
<br />
turbulence_gain = fgGetNode("/environment/turbulence/magnitude-norm",true)<br />
<br />
and a lot more.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276520#p276520<br />
| title = <nowiki>Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
{{FGCquote<br />
|1= The option --turbulence=n.n seems to scale with the probability_of_exceedence_index JSBSim uses. This index is saved via the property /fdm/jsbsim/atmosphere/turbulence/milspec/severity.<br />
|2= {{cite web<br />
| url = http://forum.flightgear.org/viewtopic.php?p=276529#p276529<br />
| title = <nowiki>Re: Processing the option --turbulence=n.n</nowiki><br />
| author = <nowiki>gierschi@flightgear</nowiki><br />
| date = Feb 18th, 2016<br />
| added = Feb 18th, 2016<br />
| script_version = 0.25<br />
}}<br />
}}<br />
<br />
== Issues ==<br />
{{FGCquote<br />
|1= setting turbulence magnitude norm to a given value creates very different strength of turbulence in YaSim and JSBSim. I probably could introduce a hack in the weather system that some FDM dependent scaling factor is used, but I really think the weather system should *not* have to know about the FDM - this violates any modulariation idea, so I think this is an FDM-side issue. Besides, the same issue must exist in Basic Weather<br />
|2= {{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/30113514/<br />
| title = <nowiki>Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki><br />
| author = <nowiki>Renk Thorsten</nowiki><br />
| date = Nov 18th, 2012<br />
| added = Nov 18th, 2012<br />
| script_version = 0.25<br />
}}<br />
}}<br />
== Related ==</div>Lisbellaw