Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
I would need: CLtail = f(alpha_tail, delta_elevator) where alpha_tail = alpha_aircraft + horizontal_stab_angle - Epsilon src/jsbsim --aircraft=c172x --catalog The --catalog option will give you a list of all the properties that JSBSim defines and knows about. That is separate from FlightGear-specific properties that are part of the *interface* between FlightGear and JSBSim. JSBSim does have its own elevator deflection property. I don't understand the issue with the 747 model, and (unfortunately) I don't have time to look into it at the moment. Jon I am not talking about the elevator property, but about the horizontal stabilizer (HS)property, which seems to be missing in JSBSim. In most airliners and bussiness jets there is an all-moving HS, together with the elevator (and maybe also a trim-tab). Then I would need to refer to the HS current deflection (which the pilot changes in order to trim the aircraft pitching moment) in order to calculate the tail angle of attack : alpha_ac + HS - Epsilon. Here is the relevant part of the 747.xml as defined in the aircraft subdirectory that ships with JSBSim package. 1. Note that: descriptionLift_due_to_stabilizer_deflection/description 2. But: propertyfcs/speedbrake-pos-rad/property 3. My question is: why it uses speedbrake? function name=aero/coefficient/CLs 1. See here --- descriptionLift_due_to_stabilizer_deflection/description product propertyaero/qbar-psf/property propertymetrics/Sw-sqft/property 2. and here --- propertyfcs/speedbrake-pos-rad/property table independentVarvelocities/mach/independentVar tableData 0.0.8190 0.20000.7850 0.65000.7390 0.90000.8590 /tableData /table /product /function Fabian - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
First, thank you all for the direct answers to my question. 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). 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. Finally, one short question: why there is no dedicated horizontal stabilizer property available in JSBSim, and we need to use for this the speedbrake property? Just curious... Fabian A couple problems that I've been addressing lately is that Datcom doesn't produce downwash angles when you drop flaps. Also, the elevator sweeps are a function of free-stream angle of attack (i.e., AOA at the wing, not the elevator). Another important omission from Datcom is that you can't drop flaps then do elevator sweeps. To me, these are important factors, since most of the crashes happen near the ground, when you have flaps and gear down. The FAA testing is heavy on near-ground performance, because that is where you get into the most trouble, such as losing an engine during take-off or landing. One approach that I've been considering is to calculate what the airfoil looks like when you lower the flaps, and input THAT as the airfoil, then do all of the normal calculations. For something like a 737 where you have leading and trailing edge flaps, you could easily get into 20 cases, with each case generating all of the coefficient tables (Cd, CL, CM, etc.). For a twin-prop aircraft, you just have trailing edge flaps, but you really need to run power effects at each flap setting, and you really should split the aircraft in half, since you could be flying on one engine. Engine thrust should be run at several settings, such as off, idle, cruise, and max, as a minimum. Interpolation between those power settings should be fairly accurate. Let me give you a good example. Twin engine prop aircraft, drop the flaps fully, you lose the right engine, and push the left one to max in order to climb. On the right side, you just have freestream airflow over the right wing, flap, rudder and elevator. On the left side, you have a prop blast hitting the wing, part of the flap, left side of the rudder, and most of the elevator. Ignoring the engine torque issue, you are going to experience different lift (higher on the left side) which creates a rolling moment. You will also experience different elevator control effectiveness right versus left. Rudder dynamic pressure might actually be different left versus right, creating a yawing moment, which is in addition to the thrust different left versus right. Now, is this a little overkill? Maybe, since most trainers that I've seen don't go into such details. It is possible to generate data for these cases, and I think it would yield higher fidelity trainers than anything seen before, simply because that kind of data hasn't been available before. The question I'm wrestling with is whether it is worth all the headaches. After all, we could end up with 60-80 times more data than what we currently deal with now. Any thoughts? Bill - 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 - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Finally, one short question: why there is no dedicated horizontal stabilizer property available in JSBSim, and we need to use for this the speedbrake property? Just curious... Fabian Are you talking about JSBSim, or DATCOM? I'm not sure I understand your question. There is a property available in JSBSim for elevator deflection. Jon - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
On the topic of calculating downwash at the tail, and the effects thereof, rather than make a four dimensional table it might be better to think outside the box and consider alternative ways to do what you need. Modeling ground effect is one example of that. It's a function that is calculated outside any axis. If we can calculate downwash by itself as a *function* (not a table lookup) of thrust, qbar, and lift coefficient (for *example*), then that could be used later in calculating tail forces/moments. Jon - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
On the topic of calculating downwash at the tail, and the effects thereof, rather than make a four dimensional table it might be better to think outside the box and consider alternative ways to do what you need. I agree. That's why I brought it up in the first place, to see if anyone had any great ideas, or at least to spark a healthy discussion. Sometimes when you have to explain something, you understand it better yourself because it makes you organize your thoughts. - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
See my comment after quotation... 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. Indeed, I was talking about two 2-D tables, wrongly guessing that JSBSim would interpolate the data in case, let's say, the current slat position is not any of the specific slat for which the tables are defined. Such an interpolation would be quite accurate, being better the more 2-D tables we define. This would be a very useful feature, and although I am not a programmer, I guess (hopefully right this time...) that it wouldn't be hard to implement (Jon?). You are right with the failure cases of the flaps/slats logics; that complicate things, but maybe interpolations could still help. 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. In this example, the thrust effects on downwash could be evaluated in DATCOM+ for a clean configuration, once with zero thrust, then with an array of thrust coefficients, and finally calculating the difference relative to the zero thrust downwash. A table of delta_epsilon vs. Thrust_coeff could then be built. What is needed is just the thrust effect, without having to worry about flaps or slats. This difference in Epsilon should be added to the overall epsilon. I understand this can be done in JSBSim by using Functions (although I am still not sure I already know how to do it); is that right? Jon, if you are still here...regarding the horizontal stabilizer property I was indeed talking about JSBSim. I know there is a property for elevator deflection, but in many cases also the stabilizer moves to different angles for trimming the aircraft. Well, meanwhile I see there are two new replies in this thread, I hope my long story is still relevant... :) Fabian 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 - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Indeed, I was talking about two 2-D tables, wrongly guessing that JSBSim would interpolate the data in case, let's say, the current slat position is not any of the specific slat for which the tables are defined. Such an interpolation would be quite accurate, being better the more 2-D tables we define. This would be a very useful feature, and although I am not a programmer, I guess (hopefully right this time...) that it wouldn't be hard to implement (Jon?). We could probably use the existing code to do that interpolation between two or more tables. It would just be really ugly. In the case of DATOM+ output, I'd have to generate that ugly code automatically. What is needed is just the thrust effect, without having to worry about flaps or slats. I don't think that we can do that. Think about the twin-prop aircraft, flaps down versus flaps up, idle power versus full power. Prop blast (and epsilon) on the tail is going to be different for those case. Bill - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
We could probably use the existing code to do that interpolation between two or more tables. It would just be really ugly. In the case of DATOM+ output, I'd have to generate that ugly code automatically. Well, it may be ugly and inaccurate, but for some cases the phisics could probably be quite close to a linear interpolation. Other than this, if we are not concerned with the transition between flaps,there is no problem with having many 2-D tables. What is needed is just the thrust effect, without having to worry about flaps or slats. I don't think that we can do that. Think about the twin-prop aircraft, flaps down versus flaps up, idle power versus full power. Prop blast (and epsilon) on the tail is going to be different for those case. Well, I was thinking of a citation type aircraft, where the airflow arriving at the tail may have been affected by the flaps, slats, etc., but how much it is deflected now by the jet at the tail can be taken independently. But even for a twin prop, it may be possible to take a similar approach: to evaluate how much the prop blast deflects the downwash, relative to the no-thrust case. The only issue may be that with full flaps down, the prop blast may be different than with flaps up (due to the flaps obstruction), and then, the thrust effect delta would be a number of 2-D tables: dEps_Thrust (flaps 0) = f (alpha, thrust coeff) dEps_Thrust (flaps 20) = f (alpha, thrust coeff) Fabian p.s.: where do they pay by the word? :) Bill - 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 - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Indeed, I was talking about two 2-D tables, wrongly guessing that JSBSim would interpolate the data in case, let's say, the current slat position is not any of the specific slat for which the tables are defined. Such an interpolation would be quite accurate, being better There certainly is interpolation in the use of tables. If a kinematic FCS component is used to define the position of the slats, then there also is an intermediate position for the slats and that would (could) be used as the lookup into the table. It is normal and expected that aerosurface positions will index into tables allowing continuous output. Jon, if you are still here...regarding the horizontal stabilizer property I was indeed talking about JSBSim. I know there is a property for elevator deflection, but in many cases also the stabilizer moves to different angles for trimming the aircraft. No assumptions are made for the horizontal stabilizer, whether it is all-moving, or is fixed with a movable surface. There is only a deflection associated with the surface, and that is used to index into an aero table. I am not quite sure what you need, or what you are referring to here. Using properties, one could define just about anything they want to. Can you be more descriptive about exactly what you want? Jon - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
No assumptions are made for the horizontal stabilizer, whether it is all-moving, or is fixed with a movable surface. There is only a deflection associated with the surface, and that is used to index into an aero table. I am not quite sure what you need, or what you are referring to here. Using properties, one could define just about anything they want to. Can you be more descriptive about exactly what you want? I would need: CLtail = f(alpha_tail, delta_elevator) where alpha_tail = alpha_aircraft + horizontal_stab_angle - Epsilon Some time ago I've been told that this can be done using the speedbrake property (indeed this is the way it is done in the 747 example) as if it were the stabilizer (only a matter of names); that's OK, but I only wonder whay there is no stabilizer property, or is it? I hope this time I was more descriptive. Thanks. - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
I would need: CLtail = f(alpha_tail, delta_elevator) where alpha_tail = alpha_aircraft + horizontal_stab_angle - Epsilon We should be able to do this. Some time ago I've been told that this can be done using the speedbrake property (indeed this is the way it is done in the 747 example) as if it were the stabilizer (only a matter of names); that's OK, but I only wonder whay there is no stabilizer property, or is it? I hope this time I was more descriptive. Thanks. If you can run JSBSim in standalone mode (compiling and linking with JSBSim.cpp) then you can do this at the command line (I am assuming that the executable is in the src/ directory, as it would be in the JSBSim build tree under Linux or Cygwin): src/jsbsim --aircraft=c172x --catalog The --catalog option will give you a list of all the properties that JSBSim defines and knows about. That is separate from FlightGear-specific properties that are part of the *interface* between FlightGear and JSBSim. JSBSim does have its own elevator deflection property. I don't understand the issue with the 747 model, and (unfortunately) I don't have time to look into it at the moment. Jon - 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
[Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Curerntly, as far as I understand, JSBSim does not support the buildup of the aerodynamic characteristics by taking the wing-body alone and adding the tail contribution. This is essential for example in investigating an aircraft behaviour during ice contaminated tailplane stall, a hot subject nowadays. For example, the total pitching moment would be: CM_wing-body + CLtail * tail_volume. Of course, the aero model should then need to include the downwash (Epsilon) at the tail (as a function of alpha, flaps, etc.) and CLtail vs. alpha_tail. My questions therefore are: 1. Is it possible to introduce Epsilon tables in the aircraft properties file? 2. Is it possible to have an option to evaluate alpha_tail (alpha_aircraft + horizontal_stab – Epsilon + dynamic components) whenever an Epsilon table is present in the properties file? This would be essential to calculate the tail lift and its contribution to the overall pitching moment. Regards, Fabián - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Hi, IIRC you can specify functions (e.g. tables) in JSBSim which are in a first step completely unrelated to lift, drag, sideforce or any of the moments. The files output by DATCOM+ do this for the ground effect by establishing a table of additional coefficients based on the ratio of height AGL and span. These coefficients are then multiplied on the basic lift and drag. Simply place a function outside any of the axis definitions and then use it as a property in your axis functions. An example can be seen in the Seneca-model by Torsten Dreyer: http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/data/Aircraft/SenecaII/SenecaII-jsbsim.xml?content-type=text%2Fplainview=co Search for ground-effect-factor-lift. You could use this to describe the downwash based on the current AoA and whatever is needed in addition. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Fabian wrote: Currently , as far as I understand, JSBSim does not support the buildup of the aerodynamic characteristics by taking the wing-body alone and adding the tail contribution. This is essential for example in investigating an aircraft behaviour during ice contaminated tailplane stall, a hot subject nowadays. For example, the total pitching moment would be: CM_wing-body + CLtail * tail_volume. Actually, JSBSim supports exactly that kind of thing. [You might want to move this part of the discussion to the JSBSim list.] In JSBSim we use the coefficient build-up method to define the forces and moments about each of the axes. There is also the possibility of creating functions that calculate whatever you want, which can then be applied to the coefficients as needed. For example, multipliers into tables or other functions. You could use DATCOM+ to calculate the wing/body effects, then add other effects as needed, unless you already have data. For information on DATCOM+, see www.holycows.net/datcom. Of course, the aero model should then need to include the downwash (Epsilon) at the tail (as a function of alpha, flaps, etc.) and CLtail vs. alpha_tail. My questions therefore are: 1. Is it possible to introduce Epsilon tables in the aircraft properties file? To my knowledge, nobody has tried this, yet. However, it is certainly possible. 2. Is it possible to have an option to evaluate alpha_tail (alpha_aircraft + horizontal_stab - Epsilon + dynamic components) whenever an Epsilon table is present in the properties file? This would be essential to calculate the tail lift and its contribution to the overall pitching moment. Yes. That's one of the reasons that we created the function capability. One of our newsletters (see www.jsbsim.org) has information about defining functions in the aerodynamics section of a JSBSim aircraft config file. Also, there is this (somewhat formal) definition of JSBSim-ML: http://jsbsim.sourceforge.net/JSBSim/JSBSim.xsd.html Some information on the function definition can be found here: http://jsbsim.sourceforge.net/wiki/index.php/User%27s_Manual#Configuration_F iles For more information, as on the JSBSim list! Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
_ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon S. Berndt Sent: Saturday, July 21, 2007 12:48 PM To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Epsilon,alpha_tail and independent tail contributions Fabian wrote: Currently , as far as I understand, JSBSim does not support the buildup of the aerodynamic characteristics by taking the wing-body alone and adding the tail contribution. This is essential for example in investigating an aircraft behaviour during ice contaminated tailplane stall, a hot subject nowadays. For example, the total pitching moment would be: CM_wing-body + CLtail * tail_volume. Actually, JSBSim supports exactly that kind of thing. [You might want to move this part of the discussion to the JSBSim list.] In JSBSim we use the coefficient build-up method to define the forces and moments about each of the axes. There is also the possibility of creating functions that calculate whatever you want, which can then be applied to the coefficients as needed. For example, multipliers into tables or other functions. You could use DATCOM+ to calculate the wing/body effects, then add other effects as needed, unless you already have data. For information on DATCOM+, see http://www.holycows.net/datcom www.holycows.net/datcom. Of course, the aero model should then need to include the downwash (Epsilon) at the tail (as a function of alpha, flaps, etc.) and CLtail vs. alpha_tail. My questions therefore are: 1. Is it possible to introduce Epsilon tables in the aircraft properties file? To my knowledge, nobody has tried this, yet. However, it is certainly possible. 2. Is it possible to have an option to evaluate alpha_tail (alpha_aircraft + horizontal_stab - Epsilon + dynamic components) whenever an Epsilon table is present in the properties file? This would be essential to calculate the tail lift and its contribution to the overall pitching moment. Yes. That's one of the reasons that we created the function capability. One of our newsletters (see http://www.jsbsim.org www.jsbsim.org) has information about defining functions in the aerodynamics section of a JSBSim aircraft config file. Also, there is this (somewhat formal) definition of JSBSim-ML: http://jsbsim.sourceforge.net/JSBSim/JSBSim.xsd.html http://jsbsim.sourceforge.net/JSBSim/JSBSim.xsd.html Some information on the function definition can be found here: http://jsbsim.sourceforge.net/wiki/index.php/User%27s_Manual#Configuration_ Files http://jsbsim.sourceforge.net/wiki/index.php/User%27s_Manual#Configuration_F iles For more information, as on the JSBSim list! Jon A couple problems that I've been addressing lately is that Datcom doesn't produce downwash angles when you drop flaps. Also, the elevator sweeps are a function of free-stream angle of attack (i.e., AOA at the wing, not the elevator). Another important omission from Datcom is that you can't drop flaps then do elevator sweeps. To me, these are important factors, since most of the crashes happen near the ground, when you have flaps and gear down. The FAA testing is heavy on near-ground performance, because that is where you get into the most trouble, such as losing an engine during take-off or landing. One approach that I've been considering is to calculate what the airfoil looks like when you lower the flaps, and input THAT as the airfoil, then do all of the normal calculations. For something like a 737 where you have leading and trailing edge flaps, you could easily get into 20 cases, with each case generating all of the coefficient tables (Cd, CL, CM, etc.). For a twin-prop aircraft, you just have trailing edge flaps, but you really need to run power effects at each flap setting, and you really should split the aircraft in half, since you could be flying on one engine. Engine thrust should be run at several settings, such as off, idle, cruise, and max, as a minimum. Interpolation between those power settings should be fairly accurate. Let me give you a good example. Twin engine prop aircraft, drop the flaps fully, you lose the right engine, and push the left one to max in order to climb. On the right side, you just have freestream airflow over the right wing, flap, rudder and elevator. On the left side, you have a prop blast hitting the wing, part of the flap, left side of the rudder, and most of the elevator. Ignoring the engine torque issue, you are going to experience different lift (higher on the left side) which creates a rolling moment. You will also experience different elevator control effectiveness right versus left. Rudder dynamic pressure might actually be different left versus right, creating a yawing moment, which is in addition to the thrust different left versus right. Now, is this a little overkill? Maybe, since most trainers that I've seen don't go into such details. It is possible to generate
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Bill G. wrote: Now, is this a little overkill? Maybe, since most trainers that I've seen don't go into such details. It is possible to generate data for these cases, and I think it would yield higher fidelity trainers than anything seen before, simply because that kind of data hasn't been available before. The question I'm wrestling with is whether it is worth all the headaches. After all, we could end up with 60-80 times more data than what we currently deal with now. Any thoughts? Jon Replies: I've been thinking about these issues for some time. I've actually considered just guessing. :-) I wonder how much data is too much data? It would be great to have this level of fidelity modeled. Jon - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Jon Replies: I've been thinking about these issues for some time. I've actually considered just guessing. :-) I wonder how much data is too much data? It would be great to have this level of fidelity modeled. Jon Any chance JSBSim could be expanded to do infinity number of dimensions of tables (if it doesn't do it already)? Bill - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Jon Replies: I've been thinking about these issues for some time. I've actually considered just guessing. :-) I wonder how much data is too much data? It would be great to have this level of fidelity modeled. Jon Any chance JSBSim could be expanded to do infinity number of dimensions of tables (if it doesn't do it already)? Bill We could probably expand to do four dimensions, which is pretty close. Jon - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Any chance JSBSim could be expanded to do infinity number of dimensions of tables (if it doesn't do it already)? Bill We might actually be able to effectively do that, since we could have multiple tables defined that create multipliers that could be used later. Jon - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Any chance JSBSim could be expanded to do infinity number of dimensions of tables (if it doesn't do it already)? Bill We might actually be able to effectively do that, since we could have multiple tables defined that create multipliers that could be used later. Jon Well, that was going to be my initial approach, but it's a real pain to remove one dimension like that out of a 4-D table to make it two 3-D tables (if I remember how that works). I haven't looked at your LFI implementation, but one that I did years ago I think used recursion, and therefore it was possible to have 'inifinty' number of dimension.. Or maybe I was just working on that and never going it working. I don't know. I've spelt since then. I'll try to quantify how many dimensions that I need out of DATCOM data. Bill - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
We might actually be able to effectively do that, since we could have multiple tables defined that create multipliers that could be used later. Jon Well, that was going to be my initial approach, but it's a real pain to remove one dimension like that out of a 4-D table to make it two 3-D tables (if I remember how that works). I haven't looked at your LFI implementation, but one that I did years ago I think used recursion, and therefore it was possible to have 'inifinty' number of dimension.. Or maybe I was just working on that and never going it working. I don't know. I've spelt since then. Bill In my mind, the problem is not so much the programmatic/algorithmic aspect, but how do you arrange the data in our XML format in files? I've got a few ideas, but it seems like it could be convoluted. Jon - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon S. Berndt Sent: Saturday, July 21, 2007 2:49 PM To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Epsilon,alpha_tail and independent tail contributions We might actually be able to effectively do that, since we could have multiple tables defined that create multipliers that could be used later. Jon Well, that was going to be my initial approach, but it's a real pain to remove one dimension like that out of a 4-D table to make it two 3-D tables (if I remember how that works). I haven't looked at your LFI implementation, but one that I did years ago I think used recursion, and therefore it was possible to have 'inifinty' number of dimension.. Or maybe I was just working on that and never going it working. I don't know. I've spelt since then. Bill In my mind, the problem is not so much the programmatic/algorithmic aspect, but how do you arrange the data in our XML format in files? I've got a few ideas, but it seems like it could be convoluted. Jon This is how I do 3-D data in my free-format method. Another dimension might just be 2 entries on the 0.0 and 5000.0 lines, and there would have to be another 2 tables, if the 4th dimension only has two values. CP_ALTITUDE_CORRECTION_TABLE_TRAINING NON_DIMENSIONAL_TRUE_AIRSPEED SS_THRUST_COEFFICIENT DENSITY_ALTITUDE 0.0 6.377530E-03 6.799520E-03 7.671665E-03 8.155430E-03 8.714625E-03 0.000 0.0 0.0 0.0 0.0 0.0 0.075 -7.08702E-06 -7.46443E-06 -3.33640E-06 0.0 0.0 0.095 -3.13841E-06 -2.70910E-06 -6.89935E-07 0.0 0.0 0.115 9.80799E-09 2.24440E-06 3.75856E-06 0.0 0.0 0.135 1.64757E-06 5.51617E-06 6.02906E-06 0.0 0.0 0.155 3.16493E-06 8.90633E-06 9.08185E-06 0.0 0.0 0.175 4.73170E-06 1.27943E-05 1.29269E-05 0.0 0.0 0.195 6.08803E-06 1.72407E-05 1.61440E-05 0.0 0.0 0.215 7.20410E-06 1.86653E-05 1.64733E-05 0.0 0.0 0.235 9.13959E-06 2.25281E-05 1.90848E-05 0.0 0.0 0.255 1.11248E-05 2.56991E-05 2.07885E-05 0.0 0.0 0.275 1.48693E-05 3.54481E-05 2.81742E-05 0.0 0.0 0.295 1.96035E-05 4.86056E-05 3.89821E-05 0.0 0.0 0.315 2.43772E-05 5.99209E-05 4.68421E-05 0.0 0.0 0.335 2.60403E-05 5.76844E-05 4.35042E-05 0.0 0.0 0.355 3.45229E-05 6.20062E-05 4.31986E-05 0.0 0.0 5000.0 6.377530E-03 6.799520E-03 7.671665E-03 8.155430E-03 8.714625E-03 0.000 0.0 0.0 0.0 0.0 0.0 0.075 -5.82699E-06 -7.74447E-06 -3.98641E-06 -4.12238E-06 -2.16311E-06 0.095 -2.94845E-06 -4.71913E-06 -2.63005E-06 -3.49648E-06 -2.35165E-06 0.115 -1.14023E-06 -1.42562E-06 2.58558E-07 5.97211E-08 1.97976E-06 0.135 -8.32457E-07 1.66066E-07 1.02905E-06 1.69658E-06 4.06150E-06 0.155 -6.55098E-07 1.42632E-06 1.91189E-06 3.04350E-06 5.77344E-06 0.175 -1.36832E-06 2.06431E-06 2.86690E-06 5.00068E-06 9.04538E-06 0.195 -2.87194E-06 2.66073E-06 2.91396E-06 6.18843E-06 1.22274E-05 0.215 -1.00594E-06 3.82526E-06 3.67334E-06 6.54650E-06 1.32896E-05 0.235 -5.70348E-07 4.86814E-06 4.36482E-06 7.76484E-06 1.46019E-05 0.255 9.14792E-07 5.92906E-06 4.92844E-06 9.11357E-06 1.53244E-05 0.275 -9.10659E-07 8.20810E-06 6.30418E-06 1.05824E-05 1.77469E-05 0.295 -4.84660E-06 9.83535E-06 7.65215E-06 1.42617E-05 2.20197E-05 0.315 -5.64283E-06 1.19309E-05 8.17212E-06 1.69514E-05 2.69024E-05 0.335 1.35030E-06 1.46345E-05 9.07423E-06 1.68110E-05 2.66753E-05 0.355 1.51130E-05 2.15764E-05 1.23685E-05 1.73016E-05 2.39984E-05 - 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
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
Jon Replies: I've been thinking about these issues for some time. I've actually considered just guessing. :-) I wonder how much data is too much data? It would be great to have this level of fidelity modeled. Jon Don't know if anyone noticed, but the flaps are already split left and right. I did this for the asymetric flap deflection issue. I wondered if the 737 that crashed in Pittsburgh in ...hmmm.. 1987(?) could have been caused by a flap jack screw attachment point breaking, thereby allowing the flap to blow up. In the post-crash investigation, it might look like the flap was down because the jack screw was fully extended, but if it's not attached to anything That crash was blamed on a rudder failure, with a subsequent redesign of the rudder servo, but it made me wonder what would happen if I had never seen anything like asymetric flap deflection on a sim before, but didn't see any reason Datcom couldn't do it. It's not like you can collect that data any other way. I never did experiment with a 737 to see what would happen, though Bill - 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
