Optimal TWR with Stock vs. FAR Aerodynamics

[arkie87]

No, I think you're confusing yourself, and it's way past my bedtime, so last try for this evening.

In your video, you state (and the video shows) that terminal velocity *decreases* with altitude for the first 5KM or so.

Is this true for a free- falling body?

No, of course not. that's absurd.

So your readout of "terminal velocity" isn't talking about an object in free- fall at your atmosphere, but rather your ship under acceleration.

The only reason terminal velocity matters is because it maps the pressure gradient of the atmosphere vs. gravity, which defines your balance between drag losses and pressure losses for an optimal ascent.

That display has nothing to do with it unless you're arguing that objects fall slower when higher above the ground.

That's it for me. I need sleep.

Best,

-Slashy

I agree. It's passed my bedtime. I'm glad you are interested in this enough to keep discussing past yours.

I think i see the problem: terminal velocity doesnt actually decrease with altitude for the first 5 km; this is merely coincidence since i am flying vertically and accelerating. If I were flying horizontally and accelerating, the same trend would be observed.

What is happening in the background is due to the way FAR calculates terminal velocity (i.e. a numerical problem related to the solver): FAR always uses *current* velocity to calculate drag coefficient which it then uses to calculate terminal velocity from:

1/2 rho V_t^2 A Cd = m*g

OR

V_t= sqrt(2 m*g/(rho A Cd))

However, Cd, drag coefficient, varies with velocity/Mach number as shown here:http://upload.wikimedia.org/wikipedia/commons/0/0e/Qualitive_variation_of_cd_with_mach_number.png

However, the drag coefficient is calculated using the current velocity, and not the terminal velocity. To get accurate results for terminal velocity, terminal velocity should be used when calculating drag coefficient or current velocity and terminal velocity must be close; otherwise, drag coefficient used to calculate terminal velocity will be wrong, and might be higher or lower depending on which side of the Cd vs Mach number curve you are on.

I have confirmed that his is how it works, by flying a spaceplane at relatively constant/level flight and observing terminal velocity change as drag coefficient is updated as expected. I have recorded this and will upload video to youtube tomorrow as i am too tired now.

I think this is actually an interesting observation. Props Slashy, and Good night.

Edit: reviewed NathanKell's post regarding FAR, and tried reading the code to see if drag coefficient is calculated based on current velocity or predicted terminal velocity; it seems like my suspicion is confirmed. Perhaps NathanKell can elaborate?

Edited December 15, 2014 by arkie87

[Bryce Ring]

Just reviewed the video, and I think I've got it... sorta.

What would really be helpful would be to drop that same rocket from space, straight down and record the speed in free-fall vs. altitude.

Does anybody have the scale height and surface pressure for the FAR atmosphere?

The numbers for stock are 101.3 kPa at the surface and scale height of 5kM

Best,

-Slashy

Using a fresh install via CKAN

Did a simple climb, turn, fall, splat video.

Hope it has all the readouts to help that hunch. PS I like the analogy "lumberwagon" aerodynamics, by comparison, FAR is like "Butter Lube'd" aerodynamics. I still have two pages to catch up on.

Sorry about the no Surface speed on the way up. did flip between IAS and Surface on the free fall back down. get ready on the pause button here and there.

[GoSlash27]

I agree. It's passed my bedtime. I'm glad you are interested in this enough to keep discussing past yours.

I think i see the problem: terminal velocity doesnt actually decrease with altitude for the first 5 km; this is merely coincidence since i am flying vertically and accelerating. If I were flying horizontally and accelerating, the same trend would be observed.

What is happening in the background is due to the way FAR calculates terminal velocity (i.e. a numerical problem related to the solver): FAR always uses *current* velocity to calculate drag coefficient which it then uses to calculate terminal velocity from:

1/2 rho V_t^2 A Cd = m*g

OR

V_t= sqrt(2 m*g/(rho A Cd))

However, Cd, drag coefficient, varies with velocity/Mach number as shown here:http://upload.wikimedia.org/wikipedia/commons/0/0e/Qualitive_variation_of_cd_with_mach_number.png

However, the drag coefficient is calculated using the current velocity, and not the terminal velocity. To get accurate results for terminal velocity, terminal velocity should be used when calculating drag coefficient or current velocity and terminal velocity must be close; otherwise, drag coefficient used to calculate terminal velocity will be wrong, and might be higher or lower depending on which side of the Cd vs Mach number curve you are on.

I have confirmed that his is how it works, by flying a spaceplane at relatively constant/level flight and observing terminal velocity change as drag coefficient is updated as expected. I have recorded this and will upload video to youtube tomorrow as i am too tired now.

I think this is actually an interesting observation. Props Slashy, and Good night.

Edit: reviewed NathanKell's post regarding FAR, and tried reading the code to see if drag coefficient is calculated based on current velocity or predicted terminal velocity; it seems like my suspicion is confirmed. Perhaps NathanKell can elaborate?

Aye...

So now that we have confirmed that

1) the display you had been using is, in fact, the terminal velocity of your ship under power and *not* the free- fall terminal velocity as you had thought, and

2) by your own statement upstream

We are not interested in the "terminal velocity" of a craft under thrust since it has no bearing on optimum launch, and likewise, we are not interested in "terminal velocity" of a gliding craft.

What DOES have a bearing on optimal launch is falling terminal velocity i.e. the accepted definition of terminal velocity.

It can be shown mathematically that the terminal velocity of a falling object (no thrust) happens to be the optimum ascent velocity to minimize fuel consumption. This is the result of a balance between drag force and gravitational losses

It should be apparent that the entire strategy is flawed. You're not saving DV by accelerating at a high rate, you're losing DV by doing that.

Best,

-Slashy

Edited December 15, 2014 by GoSlash27

[GoSlash27]

Bryce Ring,

Thanks!

-Slashy

[ferram4]

@GoSlash27: How could that equation produce terminal velocity under power when it does not include a thrust or acceleration due to thrust term at all? It is terminal velocity, from the definition of terminal velocity, based on the current drag coefficient. Now, it is an estimate, because I'm not going to lag out KSP to get the exact Mach number at that velocity and recalculate drag coefficients, and do that until it converges; the improvement in accuracy isn't much use if you're already far from terminal velocity, and it'll slow things down in proportion with the number of parts that your vehicle has. But it's certainly not "terminal velocity under power" because terminal velocity has no dependence whatsoever on forces other than drag and gravity.

[GoSlash27]

@GoSlash27: How could that equation produce terminal velocity under power when it does not include a thrust or acceleration due to thrust term at all? It is terminal velocity, from the definition of terminal velocity, based on the current drag coefficient. Now, it is an estimate, because I'm not going to lag out KSP to get the exact Mach number at that velocity and recalculate drag coefficients, and do that until it converges; the improvement in accuracy isn't much use if you're already far from terminal velocity, and it'll slow things down in proportion with the number of parts that your vehicle has. But it's certainly not "terminal velocity under power" because terminal velocity has no dependence whatsoever on forces other than drag and gravity.

Ferram, welcome aboard.

It is because the equation assumes the Cd of the vehicle and it's current velocity, and both of those numbers are a result of the vehicle having been accelerated to it's current state.

If your ship is hovering, climbing at mach 1, or or falling at 50 m/sec, this equation will yield varying results.

Those variations are due to the velocity and state of the ship at the moment, not the state of the atmosphere.

In order for the Vt readout to actually reflect what the free- fall velocity would have been had it been dropped, allowed to stabilize at it's terminal velocity, and then measured at that altitude, the user would have to have *actually* done that.

Arkie had thought that this display was literally showing that, inferring that it conveyed the change in atmospheric density with altitude at the moment, and basing his launch profile off of it.

Best,

-Slashy

Edited December 15, 2014 by GoSlash27

[GoSlash27]

Bryce Ring,

What is the mod you're using that allows you to see your cumulative drag and gravity losses? That looks pretty darn handy!

-Slashy

[arkie87]

Ferram, welcome aboard.

It is because the equation assumes the Cd of the vehicle and it's current velocity, and both of those numbers are a result of the vehicle having been accelerated to it's current state.

If your ship is hovering, climbing at mach 1, or or falling at 50 m/sec, this equation will yield varying results.

Those variations are due to the velocity and state of the ship at the moment, not the state of the atmosphere.

In order for the Vt readout to actually reflect what the free- fall velocity would have been had it been dropped, allowed to stabilize at it's terminal velocity, and then measured at that altitude, the user would have to have *actually* done that.

Arkie had thought that this display was literally showing that, inferring that it conveyed the change in atmospheric density with altitude at the moment, and basing his launch profile off of it.

The optimal velocity during ascent is the instantaneous terminal velocity of the craft, were it in free fall at that altitude (which is sorta what you describe). The terminal velocity readout in FAR is the instantaneous terminal velocity of the craft at that altitude (and attitude).

One does not need to conduct an experiment to drop it from space and somehow, let it come to terminal velocity while simultaneously remaining at constant altitude the whole time. Terminal velocity can be calculated analytically using the equations i provided a few posts ago.

Edited December 15, 2014 by arkie87

[GoSlash27]

The optimal velocity during ascent is the instantaneous terminal velocity of the craft, were it in free fall at the altitude (em mine)(which is sorta what you describe). The terminal velocity readout in FAR is the instantaneous terminal velocity of the craft at that altitude (and attitude).

Exactly; they're not the same thing because the info shown was not collected while it was in free-fall.

Since it's showing the instantaneous terminal velocity of the vehicle and *not* what it's free fall terminal velocity would have been had it been dropped, you cannot use that info to determine an optimal launch profile.

Get it?

-Slashy

[arkie87]

Exactly; they're not the same thing because the info shown was not collected while it was in free-fall.

Since it's showing the instantaneous terminal velocity of the vehicle and *not* what it's free fall terminal velocity would have been had it been dropped, you cannot use that info to determine an optimal launch profile.

Get it?

-Slashy

This is still incorrect. It is showing the instantaneous terminal velocity were it in free fall at that altitude, since this is the definition of terminal velocity....

If you think the velocity profile that would be measured had it been dropped from space is the optimal velocity required for launch, then i ask you this: From what height should it be dropped? 70 km i.e. just outside Kerbin's atmosphere or from the edge of the SoI...

These two drops will have vastly different velocity profiles through the atmosphere...

Regardless, neither is correct. Instantaneous terminal velocity is the "correct" (read: only) one to use to assess ascent profile and efficiency.

Edited December 15, 2014 by arkie87

[OhioBob]

It is showing the instantaneous terminal velocity were it in free fall at that altitude, since this is the definition of terminal velocity....

Did I also read in this thread that the terminal velocity is calculated using the rocket's instantaneous drag coefficient, rather than what it's drag coefficient would be at the terminal velocity?

[arkie87]

Did I also read in this thread that the terminal velocity is calculated using the rocket's instantaneous drag coefficient, rather than what it's drag coefficient would be at the terminal velocity?

Yes, this is an approximation by Ferram so that it doesnt use too much cpu power to get an exact value of terminal velocity. However, if craft velocity is close to terminal velocity, terminal velocity value will be correct. Thus, the indicator should read more as: terminal velocity is faster than current speed or slower....and that is the only information needed to assess launch efficiency.

[Starman4308]

Did I also read in this thread that the terminal velocity is calculated using the rocket's instantaneous drag coefficient, rather than what it's drag coefficient would be at the terminal velocity?

What FAR gives you is, indeed, an approximation, because it's calculated with the current Mach multiplier so as to save time*. Regardless, Slashy is still continuing to misunderstand what terminal velocity is: it is, was, and forever will be the speed at which drag force equals gravitational force (independent of vector), and happens to be the speed at which your object would fall. There is no dependence on thrust: terminal velocity is a function solely of aerodynamics (atmospheric density, object shape, object orientation relative to direction of travel) and gravity (technically also buoyancy in the real world).

It is also an instantaneous number: technically speaking, your object will probably be falling a bit faster than terminal velocity, because it's falling down from thinner atmosphere. In order to converge on instantaneous terminal velocity, you would need to extend out that band of atmosphere and gravity infinitely far. However, generally speaking, by the time you hit lower atmosphere, a falling object is usually pretty close to its terminal velocity.

*Because you generally only need to know if you should speed up or slow down, it's really not worth trying to iteratively pin down exactly what Mach multiplier to use. If you're near terminal velocity, it should be quite accurate anyways.

Edited December 15, 2014 by Starman4308

[GoSlash27]

Did I also read in this thread that the terminal velocity is calculated using the rocket's instantaneous drag coefficient, rather than what it's drag coefficient would be at the terminal velocity?

OhioBob,

I wish I had your ability to clearly and simply state the salient point!

The terminal velocity readout would only be correct (for the purpose of flightpath planning) if the aircraft's current Cd matched what it's Cd would have been at terminal velocity.

[arkie87]

What FAR gives you is, indeed, an approximation, because it's calculated with the current Mach multiplier so as to save time*. Regardless, Slashy is still continuing to misunderstand what terminal velocity is: it is, was, and forever will be the speed at which drag force equals gravitational force (independent of vector), and happens to be the speed at which your object would fall. There is no dependence on thrust: terminal velocity is a function solely of aerodynamics (atmospheric density, object shape, object orientation relative to direction of travel) and gravity (technically also buoyancy in the real world).

It is also an instantaneous number: technically speaking, your object will probably be falling a bit faster than terminal velocity, because it's falling down from thinner atmosphere. In order to converge on instantaneous terminal velocity, you would need to extend out that band of atmosphere and gravity infinitely far. However, generally speaking, by the time you hit lower atmosphere, a falling object is usually pretty close to its terminal velocity.

*Because you generally only need to know if you should speed up or slow down, it's really not worth trying to iteratively pin down exactly what Mach multiplier to use. If you're near terminal velocity, it should be quite accurate anyways.

I have asked ferram in PM if he thinks it is worth using the current *guess* of terminal velocity to approximate the drag coefficient. That way, as time goes on, the prediction will become more accurate (assuming conditions arent changing too fast).

The only downside to this, is that because the multiplier is piece-wise and derivative is discontinuous at mach 1, this method might flip flop back and forth and never converge if subsequent guesses flip flop back and forth on either side of Mach 1. Thus, under-relaxation might be necessary,and is probably not worth it. As you mentioned, all that is needed is to know if your velocity is above or below terminal to know if you should throttle up or throttle down.

- - - Updated - - -

OhioBob,

I wish I had your ability to clearly and simply state the salient point!

The terminal velocity readout would only be correct (for the purpose of flightpath planning) if the aircraft's current Cd matched what it's Cd would have been at terminal velocity.

This is not true. See my and Starman's point above.

[GoSlash27]

The problem with your point above is that it's not gonna work that way. Your assumption is that if you ever approach Vt (Vt in the sense that Starman thinks I don't understand), your display will become correct and would reflect that you've exceeded or met it.

In reality, the instantaneous value is going to run away and hide no matter how rapidly you accelerate, so *it* will still be much faster than your current velocity even if you've already exceeded your free-fall Vt at your altitude.

[Starman4308]

The problem with your point above is that it's not gonna work that way. Your assumption is that if you ever approach Vt (Vt in the sense that Starman thinks I don't understand), your display will become correct and would reflect that you've exceeded or met it.

Because you clearly don't. Terminal velocity is independent of what is going on with your craft. It is dependent solely on atmospheric pressure and craft aerodynamics. Your current drag is meaningless: the only important thing is drag at terminal velocity and gravity.

You can be going at 0.1c and accelerating at 600 gravities, and instantaneous terminal velocity would be the same as if you were in free-fall.

From Wikipedia: Vt = SQRT((2mg)/(pACd)). There is mass, there is gravitational acceleration, there is atmospheric pressure, there is cross-sectional area, and there is the coefficient of drag. None of these variables are in any way dependent on the current velocity or acceleration: they depend solely on aerodynamics, atmosphere, and gravity. Vt comes out of equating Fd with Fg: essentially, "at what velocity will drag equal gravity". Velocity is in there only once (in drag), and can be solved for, getting you the above equation.

EDIT: And to remove any possible remaining confusion: the Mach multiplier (which is an approximation itself) to apply to Cd would be the Mach multiplier you would see at terminal velocity. The only reason FAR prints it out based on current velocity is because it'd be too much of a pain to figure out exactly what terminal velocity is.

EDIT #2: And if you're wondering "then why does Vt change as my rocket flies!", it is primarily because you are changing altitude (and thus local atmospheric density and gravity), and secondarily because of aforementioned wonkiness in how FAR estimates Vt.

Edited December 15, 2014 by Starman4308

[GoSlash27]

"None of these variables are in any way dependent on the current velocity"

And *this* is why you're mistaken. In FAR, Cd *is* dependent on the current velocity.

[Starman4308]

"None of these variables are in any way dependent on the current velocity"

And *this* is why you're mistaken. In FAR, Cd *is* dependent on the current velocity.

Slashy, I pointed this out.

Cd for terminal velocity is dependent on what Cd would be at terminal velocity.

Your current Cd is meaningless. It is what Cd is at terminal velocity: yes, that is a bit recursive, but that's how terminal velocity works.

[GoSlash27]

Slashy, I pointed this out.

Cd for terminal velocity is dependent on what Cd would be at terminal velocity.

Your current Cd is meaningless. It is what Cd is at terminal velocity: yes, that is a bit recursive, but that's how terminal velocity works.

You are very passionately arguing the exact same thing I've been saying for the last I-don't-know-how-many pages now. This should be bolded and stickied.

The display isn't showing a terminal velocity using the terminal Cd, but rather the *current* Cd. It is therefore misleading for the purpose arkie was using it for. The assumption that approaching your terminal velocity would be reflected in that display is erroneous because it's displayed "terminal velocity" will always exceed your current velocity no matter how quickly you accelerate. In fact, the more rapidly you accelerate, the more rapidly it will appear to increase.

Even when you've left your free-fall Vt far behind, it will still read a velocity far ahead.

You just plain can't use that display to determine an optimal launch profile.

Edited December 15, 2014 by GoSlash27

[OhioBob]

EDIT: And to remove any possible remaining confusion: the Mach multiplier (which is an approximation itself) to apply to Cd would be the Mach multiplier you would see at terminal velocity. The only reason FAR prints it out based on current velocity is because it'd be too much of a pain to figure out exactly what terminal velocity is.

I don't know anything about FAR or KSP modding, but it seems to me it would be easy to compute via iteration using a loop.

[arkie87]

I don't know anything about FAR or KSP modding, but it seems to me it would be easy to compute via iteration using a loop.

Yes, Starman, I, and FERRAM himself have already said this. See Ferram's response in page 8:

@GoSlash27: It is terminal velocity, from the definition of terminal velocity, based on the current drag coefficient. Now, it is an estimate, because I'm not going to lag out KSP to get the exact Mach number at that velocity and recalculate drag coefficients, and do that until it converges; the improvement in accuracy isn't much use if you're already far from terminal velocity, and it'll slow things down in proportion with the number of parts that your vehicle has. But it's certainly not "terminal velocity under power" because terminal velocity has no dependence whatsoever on forces other than drag and gravity.

[OhioBob]

Yes, Starman, I, and FERRAM himself have already said this. See Ferram's response in page 8:

Thanks, I missed seeing that reply. FERRAM gave a good explanation of his reasons for doing it that way.

[arkie87]

The display isn't showing a terminal velocity using the terminal Cd, but rather the *current* Cd. It is therefore misleading for the purpose arkie was using it for.

We have already countered this argument.

The terminal velocity display in FAR is not always 100% accurate, since it is not accounting for the effect of velocity on the drag coefficient.

However, since it uses drag coefficient at current velocity, it IS useful for assessing whether we are below or above terminal velocity, since when current craft velocity and the terminal velocity displayed in FAR and are equal, the terminal velocity displayed in FAR is 100% accurate. Thus, while the terminal velocity indicator does not tell us quantitatively how far away from terminal velocity we are, it does always qualitatively tell us if we are above or below it.

And since knowing whether we are above or below is what is needed for establishing optimum ascent speed and thrust, the terminal velocity function is adequate as is.

The assumption that approaching your terminal velocity would be reflected in that display is erroneous because it's displayed "terminal velocity" will always exceed your current velocity no matter how quickly you accelerate.

In fact, the more rapidly you accelerate, the more rapidly it will appear to increase.

Even when you've left your free-fall Vt far behind, it will still read a velocity far ahead.

I dont know where you get this idea from. Ferram himself has countered this argument, and i have posted a video showing that terminal velocity is not a function of spacecraft acceleration already

- - - Updated - - -

Thanks, I missed seeing that reply. FERRAM gave a good explanation of his reasons for doing it that way.

Ferram always does

Edited December 15, 2014 by arkie87

[arkie87]

You are very passionately arguing the exact same thing I've been saying for the last I-don't-know-how-many pages now. This should be bolded and stickied.

The display isn't showing a terminal velocity using the terminal Cd, but rather the *current* Cd. It is therefore misleading for the purpose arkie was using it for. The assumption that approaching your terminal velocity would be reflected in that display is erroneous because it's displayed "terminal velocity" will always exceed your current velocity no matter how quickly you accelerate. In fact, the more rapidly you accelerate, the more rapidly it will appear to increase.

Even when you've left your free-fall Vt far behind, it will still read a velocity far ahead.

You just plain can't use that display to determine an optimal launch profile.

My final attempt is as follows.

Even with stock aerodynamics, terminal velocity is optimum during ascent.

I would like to know how you manage your ascent velocity during the first 7 km climb before the gravity turn (you mentioned somewhere you usually climb straight vertical for 7 km)?

Since you clearly prefer experiments to theory, I would like to propose an experiment: measure deltaV required to get to LKO in stock aerodynamics by climbing however fast you like until 7 km and then performing your gravity turn.

Then follow this profile as close as you can, which specifies craft velocity vs. altitude.

I guarantee following this chart will require less deltaV since you will be flying at terminal velocity in stock.