As you presumably know, the gui, as embodied in the weather-conditions
popup, weather.xml, assumes a multi-layer model of the atmosphere.
The same assumption can be found in much of the back-end code.
Today I call attention to the code near line 715 in
Environment/environment.cxx
void
interpolate (const FGEnvironment * env1, const FGEnvironment * env2,
double fraction, FGEnvironment * result)
{
...
result->set_temperature_sea_level_degc
(do_interp(env1->get_temperature_sea_level_degc(),
env2->get_temperature_sea_level_degc(),
fraction));
...
}
When this code is used, env1 refers to the level below "here",
env2 refers to the level above "here", and the result refers
to the actual environment "here", i.e. the environment that
affects the aircraft. You can see that the result is an
interpolation between the two tabulated levels.
Can somebody tell me how the _sea level_ temperature below
the aircraft can be inferred from an interpolation up there
between levels N and N+1?
Can somebody explain the intention here? What is the basic
concept? What is the design?
Also, as previously mentioned, the pressure and temperature
relationships contravene the laws of physics. In particular,
it appears that the tables created at the top of environment.cxx
implement an incorrect model of non-standard pressure conditions,
and no model whatsoever of non-standard temperature conditions.
It's not clear whether these issues are internal to environment.cxx
On the one hand, there is a "set-outside-air-temp-degc" command
in Main/fg_commands.cxx that is exported to the network and even
mentioned in the perl examples. On the other hand, I haven't
found any aircraft that actually use this command.
1) Can somebody tell me what effect this command *should* have
in a multi-layer model?
1a) Should it just affect the layer associated with "the" elevation
in "the" environment?
2b) Or should it shift the entire air column by some amount? How
much?
2) Or would it be better just to drop this functionality altogether?
Is there anybody out there who actually has a use for it?
In any case, does setting OAT affect the pressure, in accordance
with the laws of physics? Does this mean we should recalculate
the pressure-factor-versus-altitude table in environment.cxx?
Does it mean we should recalculate all the buckets in the
environment-versus-altitude table in environment_ctrl.cxx?
There is no existing code to do these things.
This leads to huge errors in the pressure altitude property
under non-ISA temperature conditions. This makes it essentially
impossible shoot ILS approaches under non-ISA conditions. If
you are skilled, you will break off the approach; otherwise
you will crash.
These are not the only issues. Some related issues have been
previously discussed, e.g.
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11129.html
Does anybody see a way out of this mess, short of a complete
redesign and rewrite of Environment/*.?xx ?????
I haven't thought about it very much, but my first thought is
that any redesign would start by splitting the "environment"
concept into two concepts, namely
-- the air-column concept, and
-- the ambiance concept.
That is, the air column would exist independent of the number
and location of whatever aircraft, airports, etc. (if any)
are present. Meanwhile, the ambiance of an aircraft or
airport would depend on the location of /that/ entity within
the air column. Just a thought.
Does anybody have any helpful suggestions?
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
