PDA

View Full Version : Turbofan Thrust Calculations



JohnC
June 12th, 2010, 08:24
While we're on the topic of calculating thrust, I thought it would be nice to touch turbofans/turbojets. I've been using an empirical method via interpolation to nail down exact numbers in simulation, but it would be really nice to do it all by crunching numbers.

Here's what I have:

Assuming all input values are between data points in tables 1502-1507. Going from Throttle input => CN2 => CN1 => Thrust Factor/Ram Drag Factor appears to be a simple matter of linear interpolation. From there I've used these equations (found at avsim for major, and aerodynamics textbook for minor), but the numbers produced aren't quite matching up in simulation.

Net Thrust = Engine Thrust - Ram Drag

---------------------------------------------------------------------

Engine Thrust = (Static_Thrust*Thrust_Factor*Delta_2)*Thrust Scalar

Delta_2 = Ptotal / Psl = Standard Pressure Ratio/Total Pressure Ratio

SPR = Pamb / Psl

TPR = Pamb / Ptotal = (1+((G-1)/2)*M^2)^(-G/(G-1)) where G (gamma) is assumed constant at 1.4 for air

=> TPR = (1+0.2*M^2)^-3.5


*I have no idea how table 1524 fits into this equation. The scalar is direct at M0.0 || SL, but does not appear to correlate linearly at higher speeds/altitudes

---------------------------------------------------------------------

Ram Drag = (Inlet_Area*Ram_Drag_Factor/SQRT(Theta_2))*(TAS(ft/s)/g0(ft/s^2))

g0 = 32.174

Theta_2 = Ttotal / Tsl = Standard Temperature Ratio/ Total Temperature Ratio

STR = Tamb / Tsl

TTR = Tamb / Ttotal = (1+((G-1)/2)*M^2)^-1

=> TTR = (1+0.2*M^2)^-1

---------------------------------------------------------------------

N1 = CN1*SQRT(Theta_2)

N2 = CN2*SQRT(Theta_2)

--------------------------------------------------------------------

Results:

For two test points at M0.80 || FL250 / FL350:

Starting with Throttle percentage, CN1 was calculated with 0% error for both data points

Thrust errors were 6.7% and 0.8% respectively.

As a check, I also empirically calculated Theta_2 using the defined equations for CN1 => N1

For the same two test points, errors in Theta_2 were 3.8% and 1.3%. However, substituting the empirically determined Theta values increased the thrust error.

---------------------------------------------------------------------

From here, I'm not sure where to go....but if any of you see an error in the equations or have a deeper insight into the inner workings of FSX, I would be hugely grateful.

Brett_Henderson
June 12th, 2010, 11:00
Interesting.. But considering that a thrust lever is set up to deliver a "linear" thrust selection (it's not just a throttle-vave-control)... then all we're concerned about is a total, available thrust that's realistic..

Hence, to us simmers.. "gigantic set of formulas" = thrust scalar

How that thrust translates in airspeed becomes an airframe issue.. parasitic/induced drag.

JohnC
June 12th, 2010, 12:12
Interesting.. But considering that a thrust lever is set up to deliver a "linear" thrust selection (it's not just a throttle-vave-control)... then all we're concerned about is a total, available thrust that's realistic..

Hence, to us simmers.. "gigantic set of formulas" = thrust scalar

How that thrust translates in airspeed becomes an airframe issue.. parasitic/induced drag.

Brett, apologies but the question was directed at fellow flight model developers, and/or an engineer (i.e. Jerry) who is familiar with aerodynamic and propulsive theory. Thrust profiles change dramatically over the range of flight for a given aircraft, and adjusting exclusively the thrust scalar in the aircraft.cfg will almost never give you accurate performance between low & slow, and high & fast since its application is non-discrete across the entire flight envelope.

Brett_Henderson
June 12th, 2010, 12:34
but the question was directed at fellow flight model developers

No apology needed :jump: I'm one of the most downloaded, freeware modelers for FSX.. and have done the thrust modeling on many others (Jets included).. (and I'm a real-world engineer, albeit not aerodynamics)

I'm just pointing out that from a cockpit.. a thrust lever is attached to a veritable black box.. so that pilot has linear thrust control.. because a thrust profile does vary (very poorly model in FSX).

The MSFS "engine" isn't a sophisticated enough model to worry about much more than max available thrust, and let the sim pilot do as a real pilot does..ie.. assume the systems give him linear control over the thrust.

Edit: Real-world pilot, too

Brett_Henderson
June 12th, 2010, 13:09
Let's say that you could work within the limitations of the "engine".. and with enough trial/error and a little luck, actually could come up with a realistic thrust profile. You'd have to literally UN-do that work with an interface (XML gauge/module), that returned linear control to the pilot.

When it's all said and done, the realism counts in-flight, as the throttle is manipulated, right ?

The problem lies in that you're trying to squeeze reality out of a model, that it's not capable of delivering.. kinda like aerodynamics for variable geometry wings, or just a simple stall itself. The foundation just isn't there, and the give-n-take as you try (all the paramter-esque, un-intended consequences from changing something) can leave you chasing your tail.

Example..I've done some experimentation for variable wing geometry.. involving a guage that controls a combo of "invisible" flaps and spoilers for different wing settings. You'd have to do something similar.. Like a gauge that constanly reads the game-controler throttle position, then accounts for, altitude/airspeed/etc, and the returns the actual throttle position variable (unseen, and constantly changing regardless of game-control throttle position) , ultimately applying the proper amount of available thrust... which is pretty much what you already have, so long as the total available thrust is accurate.

JohnC
June 12th, 2010, 13:57
Brett,

Good to know you're a real world engineer too. However, I don't think we're seeing eye to eye on this topic. The question of interest to me is whether or not it's possible to accurately predict the in sim thrust at a specific Mach and Altitude from what is contained within the .air file.

Why? At present, my ability to increase the accuracy of the flight models I develop is limited by primarily by my understanding of the simulation engine. Sure there are limitations imposed by the manner in which it has been created, but I'm not yet at the point where all I can see are road blocks. Beyond that, it would also save me a good chunk of development time to be able to calculate thrust directly. So, for me the benefit is two fold.

Brett_Henderson
June 12th, 2010, 14:25
Brett,

Good to know you're a real world engineer too. However, I don't think we're seeing eye to eye on this topic. The question of interest to me is whether or not it's possible to accurately predict the in sim thrust at a specific Mach and Altitude from what is contained within the .air file.

Why? At present, my ability to increase the accuracy of the flight models I develop is limited by primarily by my understanding of the simulation engine. Sure there are limitations imposed by the manner in which it has been created, but I'm not yet at the point where all I can see are road blocks. Beyond that, it would also save me a good chunk of development time to be able to calculate thrust directly. So, for me the benefit is two fold.

My hat is off to you.. Trying to model realistically takes quite a bit of dedication. Lemme see if I can get us both seeing the same thing ('cause I've been down this road).

Let's start with altitude/mach specific thrust. Even if we could go past predicting it, directly to dictating it by air-file manipulation, it's pointless if the in-game experience is innacurate (enter the MSFS model short-comings, re: what it does with thrust across a flight-envelope).

Forest from the trees:

Where the rubber meets the road, is in-game performance. I've got KSAW set up as a test track. It's got 11,000 foot runways, and I open it up with an airport editor to place scenery objects along the runway at key locations; like where a model should reach V3 and have enough lift to start flying.

Sart with the model at MGTW an tweak both thrust and wing-efficiency, until the model indeed can take off AT the proper distance down the runway, and AT the proper airspeed.

Then.. slew up to cruise altitude and see how much "throttle" it takes to maintain realistic cruise speeds. Therein begins the first give-n-take that now involves parasitic/induced drag... and will have you going back to step one, several times.

When you get those two extremes reasonably close, then grit your teeth and start analyzing the cruise/climb performance.. which will of course involve tweaking ALL the listed variables (thrust/wing-efficiency/induced-parasitic drags).. and will have you back-tracking to the takeoff/cruise tests; over and over and over again.

THEN start the WHOLE process over at aprox 1/2 max useful load.

Now, since you haven't messed around too much "inside" of the engine, the engine instrumentation won't be way off. If it is.. this is where cheating comes in; and you just customize the gauges to read realistically.

Last of course, is setting fuel-consumption to yield realistic range. It, itself can be a little tricky, because you have to live with a compromise. Climb consumption reality will have to yield a bit to cruise consumption. But this whole process is a compromise.. *sigh*

My point is.. even if you could get to a realistic, engine, performance setup, AND (big and) get the in-game stuff realistic WITH that setup.. you'd end up with a wildly unrealistic throttle (see "Un-doing it all" in a previous post), and even goofier gauge readings.

I really don't like it either.. but we're almosted forced to go about engine stuff, from the outside in, where airframe parameters are just as important (mostly more important) as engine parameters. Kinda force things to work.. Because what really matters, is what you experience sitting in front of the monitor, with your hand on the throttles.

JohnC
June 12th, 2010, 15:55
I'm going to try and make this as polite as possible, but try to understand that you have completely hijacked this thread away from the purpose of the original post, which had a serious amount of thought and effort behind it. At this point all I will say is that until you have read an engineering textbook dedicated to propulsive analysis and are actively employing computer aided engineering to perform cycle analysis on specific gas turbine engines as a base to generate nearly every table between 1502 and 1507, then you have not been down the same road as I am currently traveling. If you have any doubt over the potential of the current method I am using, I would suggest shooting a pm over to John Miguez (jmig here). He used to pilot an F-5E, the most recent aircraft for which this method has been implemented.

I'm not saying there is anything wrong with the method you use, which I hope you understand is different than my approach. However, I would really appreciate it if you stuck with the original topic, because any progress made to its end would be hugely useful for me. However, if you would like to further discuss the methods you and I use to see if either of us have something to learn or gain, then by all means start up a new thread and I will gladly discuss it with you.

Brett_Henderson
June 12th, 2010, 16:59
Don't worry about politeness.. :jump: I'm immune..

Anyway.. fair enough.. Just trying to point out that it's not roadblocks.. there is no road going where you're trying to get. The software were using doesn't allow for that type of detailed, realistic modeling; ... if it did, it would be in the several thousand dollar range, and a desktop computer couldn't handle it.

Thread's all yours.. sorry 'bout that :wavey: