> Quoting Fabian Grodek
> Now, regarding the 737 sample case, it should be checked
> which flaps-slats combinations are normally possible; it may
> be the case where let's say flaps 20 cannot come with
> retracted slats (if there is a problem with the slats
> deployment you are allowed to use only flaps 0).
Well, they sometimes use simulators to play "What if" scenarios after a
crash. Sure, there is logic built into the flap controller to not allow
flaps 20 with retracted slats, as in your example, but what if that logic is
flawed, or a sensor or linkage is broken, and it is achieved even though it
shouldn't be. Asymetric flap deflection shouldn't be allowed, but if the
sensor is on the jackscrew and the control horn on the flap for the
jackscrew breaks, the jackscrew might go to the 40 degree position, but the
flap retracts. I want DATCOM+ to be able to crank out all of this data,
because Datcom will allow us to.
> Regarding the tables with infinite numbers of dimensions; I
> do not understand why this should be needed. The buildup
> concept used in JSBSim lets you specify delta of each
> coefficient for every aerodynamic surface (flaps, elevator,
> stabilizer, etc.) independently; JSBSim adds all that
> together. For the downwash, DATCOM could be executed first
> for the clean configuration, obtain Epsilon vs. alpha, then
> for certain airfoil representing one slat-flap combination,
> obtain the new Epsilon vs. alpha, and finally we can build a
> 2D table for deltaEpsilon vs. alpha vs. flaps. If the slat is
> another input, then 3D tables (with tableData breakpoints)
> are already applicable in JSBSim. We can then have one 2D
> table for slats 0, then another for slats 20, etc. The
> elevator sweeps could be done with flaps up, and then, this
> elevator effects included as another contribution in the aero buildup.
> One important issue in generating the independent
> contribution of each aero surface is that sometimes there are
> interferences between them; this can be significant for
> example between flaps and airbrakes.
I understand what you are trying to say here, but there are several issues
that you point out. Let me see if I can straighten out a couple of these
issues:
1. Unfortunately for us, Datcom doesn't provide downwash angles with
defelcted surfaces (flaps, etc.). It provides it for a wing only. That is
why I thought that I might have to figure out the airfoil section with the
flap deflected, and input that. Of course, I was going to let DATCOM spit
out the airfoil section with the flap deflected for me, and feed that back
into Datcom to obtain the downwash angles at the tail. The data should be
there, I just have to figure out how to get it out of there and feed it back
into itself (kinda like a self-eating watermelon)
2. I think what you are saying is:
epsilon = f( alpha, flap, slat )
I don't think that you were advocating using two 2-D table
epsilon(slat=0) = f ( alpha, flap )
epsilon(slat=20) = f ( alpha, flap )
If you were, there would have to be an interpolation done between these two
tables in order to get the effects during transitions. Yes, that is
important, because the dynamics of the aircraft during a surface change like
that is examined by the FAA during qualification. I'm just guessing that we
could cobble something together in the existing JSBSim structure to do an
interpolation between these two tables.
Now, if you add in thrust effects, you end up with:
epsilon = f( alpha, flap, slat, thrust )
We are now at a 4-D table. I guess my use of the term 'inifinate dimensions'
might have been a poor choice, but as soon as the code for 4-D tables is
finished, we'll find that we need 5 or 6 dimensions. As Jon pointed out, the
code isn't the important part, but the specification of poly-dimensional
tables in the XML file is.
Datcom cranks out data in 1-D and 2-D tables for a particular case. I am
trying to pack multiple cases together in one file, maybe varying several
parameters to get the overall picture. Those parameters include TE and LE
flaps, thrust coefficients, even height abouve ground for ground efects
(although I was able to factor this one out). Each new parameter adds
another dimension to our tables.
> One important issue in generating the independent
> contribution of each aero surface is that sometimes there are
> interferences between them; this can be significant for
> example between flaps and airbrakes.
Again, unfortunately, Datcom doesn't provide interference effects between
various components. You are allowed to deflect one surface at a time only.
This is where building up the airfoil section based on flap deflection plays
in.
One other issue that I have to attack, which shouldn't really cause anyone
headache (famous last words) is that Datcom only allows one thrust
coefficient to be defined. I was going to change the PREDAT code to allow an
array of thrust coefficients instead of the present version which only
allows one thrust coefficient, to allow us to build up a series of thrust
coefficients in the input file. PREDAT would basically cycle through the
array of thrust coefficients, building up the aircraft for each thrust
coefficient, outputting each as a separate case. On the back-end, DATCOM+
has to collect these various cases for varying thrust coefficients and
present the data as required. I just can't throw this together without
thinking of the overall picture with regard to flaps,e tc.
Bill
p.s. You really have to stop paying me by the word ;-}
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
