On 12/01/2009 12:47 PM, Stuart Buchanan asked:
> You suggest two possible explanations. Not having access to a C-172,
> nor enough flight time to be able to guess which is correct, I'm not
> sure there's much I can sensibly do without making it worse. If you
> can suggest which is wrong, I'll see what I can do. My guess would be
> idle RPM, given your previous comments that the aircraft if
> over-powered.
Those are good questions. I don't yet know for sure
whether there is too much power and/or too little drag.
However, while trying to answer those questions, I came
across another snafu that calls for some attention.
The topic for today is the h_b-mac-ft variable that is
used by JSBSim as part of the interface between the C
code and the xml configuration files for a given aircraft.
There are at least four things we know about this variable:
1) How it is calculated, upstream of the interface
2) How it is used, downstream of the interface
3) Some meaning we can try to read into the name
of the variable; and
4) The explicit documentation found at
http://www.mail-archive.com/flightgear-us...@lists.sourceforge.net/msg02747.html
When we look into it we find:
1) My reading of the code that produces h_b-mac-ft suggests
it is the height of AERORP (the aerodynamic reference point)
above the ground ... divided by wingspan.
2) The variable is used in the xml configuration files
to calculate ground effect. This is entirely consistent
with (1). This is not causing the problem with the C172p.
So far so good.
3) As previous explained in detail, I find it is rarely
a good practice to read meaning into names. Charpentier
was a composer, not a carpenter. Boulanger was another
composer, not a baker.
4) In the only documentation I could find, namely
http://www.mail-archive.com/flightgear-us...@lists.sourceforge.net/msg02747.html
it claimes h_b-mac-ft is the "Altitude of MAC divided by wing span"
which doesn't make any sense. MAC is the conventional
abbreviation for Mean Aerodynamic Chord. Talking about
MAC in this context is like talking about the diameter
of my arm when you want to know the height AGL of my
collarbone.
======================
Suggestions:
A) Having documentation in an archive such as
http://www.mail-archive.com/flightgear-us...@lists.sourceforge.net/msg02747.html
is waaaay better than nothing, but it would be even
better if documentation were incorporated in the code
base, so that
*) people could find it more easily, and
*) people could submit patches against it
B) In general: documenting the interfaces is important.
No matter how well documented (or poorly documented)
the internal workings of the code may be, there needs
to be good documentation for the interface.
C) In this particular case, it would be nice to
document h_b-mac-ft conspicuously, and sooner rather
than later, given that there are misconceptions
floating around.
------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
