Optimal TWR with Stock vs. FAR Aerodynamics

[ferram4]

Would you mind referencing which equation you're using for terminal velocity that includes current acceleration as a term? I'm not seeing where it is in any of my aerodynamics textbooks, all of them indicate that terminal velocity, which is defined as the velocity at which drag and gravity are perfectly balanced, has no dependence whatsoever on external accelerations.

Do you have a method behind your words that you intend to implement and contribute, with math and results, or are you just talk?

[GoSlash27]

Would you mind referencing which equation you're using for terminal velocity that includes current acceleration as a term? I'm not seeing where it is in any of my aerodynamics textbooks, all of them indicate that terminal velocity, which is defined as the velocity at which drag and gravity are perfectly balanced, has no dependence whatsoever on external accelerations.

Do you have a method behind your words that you intend to implement and contribute, with math and results, or are you just talk?

Ferram,

I'm not referencing *any* equations for this beyond what has already been provided here.

Current acceleration is *not* a factor in computing free-fall terminal velocity. Likewise, current velocity is not a factor in computing terminal free-fall velocity.

Or at least it's not *supposed* to be, and that's the problem.

Any attempt to estimate it based on current velocity and Cd in FAR *does* make it a factor because it assumes that the current Cd is valid in that scenario, and it's just plain not. Thus, it gives you an incorrect answer. When you're supersonic that error will always be positive.

Edited December 15, 2014 by GoSlash27

[ferram4]

And then based on the estimated value, you calculate a new Cd, which then based on that, you get a new terminal velocity, which you then continue to iterate... as arkie is doing. So I'm not sure where your criticism is on his methods at all.

Do you have any mathematical proof of your conjectures that the terminal velocity is in the wrong direction at M > 1? Have you run the math? Do you have any data on the extra overhead to fix the error? Do you know the magnitude of the errors? Do you have a use case for the accuracy that you're requesting far from terminal velocity? If the answer to any of those questions is no, then you're woefully unprepared to argue here, and you should rectify that.

Also, still expecting you to make a pull request fixing the issues, with all the docs I requested. You wouldn't be considering not doing that, since you've spent so much time on this issue, now would you? After all, it might convince people that you actually don't have a point...

[GoSlash27]

ferram,

Gettin' a bit rude here. I know the feeling, so please bear with me.

in FAR, Cd is a decreasing function with Mach when you're supersonic. That's by your own submitted formula.

The faster you go, the lower your Cd.

That's all well and good, but what happens when your velocity is higher than the ballistic terminal velocity?

Say you had an object at 10Km altitude that had been accelerated at one G until the drag had equalized with the thrust and equillibrium had been achieved. That is your ballistic terminal velocity for that object at that pressure/ temperature.

Say (for the sake of argument) this value was 600 M/sec. What happens when you attempt to calculate this velocity from an object that is travelling 800 m/sec?

That object has a lower Cd due to it's higher Mach number. If we calculate the Vt of an object with that lower Cd, it will return an even *higher* value. If we attempt to iterate it, it gets worse, not better.

You can't calculate Vt assuming the Cd of an object that's already going faster than it. You just can't. That's my point.

Best,

-Slashy

Edited December 16, 2014 by GoSlash27

[arkie87]

Ferram,

I'm not referencing *any* equations for this beyond what has already been provided here.

Current acceleration is *not* a factor in computing free-fall terminal velocity. Likewise, current velocity is not a factor in computing terminal free-fall velocity.

Or at least it's not *supposed* to be, and that's the problem.

Any attempt to estimate it based on current velocity and Cd in FAR *does* make it a factor because it assumes that the current Cd is valid in that scenario, and it's just plain not. Thus, it gives you an incorrect answer. When you're supersonic that error will always be positive.

So i thought about what he said on my ride home, thinking that he had a point: what he was saying is that the iterative method isn't stable when mach number is greater than 1 and when your initial guess (i.e. craft velocity) is greater than terminal velocity (assuming we know what terminal velocity is somehow) because it causes V_t to go in the wrong direction due to he logical argument i'll present below. Thus, the method FAR uses-- one iteration in this iterative method--is actually predicting a completely unrealistic value, since if FAR let it iterate indefinitely, it will not converge to the solution, but rather, diverge to infinity.

The basic reasoning is that let's say (using my made up Cd vs Mach number relationship since I am still working on yours, Ferram ), we are able to determine that V_terminal = 1961.8 m/s (since my method converged, we know it is the correct answer for terminal velocity). If we happen to be going above that value: say 3000 m/s, FAR will calculate drag coefficient at 3000 m/s, which results in a lower Cd, which should result in a larger terminal velocity; the next iteration, the larger terminal velocity will result in an even smaller drag coefficient, which will then increase terminal velocity yet again until terminal velocity approaches infinity and drag coefficient approaches 0.

However, to my surprise, this isnt what happened; it still converged to the correct solution: 1961.8 m/s. Here is the table of the results on a per iteration basis:

Thus, even though my initial guess was above terminal velocity, it was still able to converge to the correct solution despite he logical argument i just made (and that I think you are making).

I am still working on an explanation...

ferram,

Gettin' a bit rude here. I know the feeling, so please bear with me.

in FAR, Cd is a decreasing function with Mach when you're supersonic. That's by your own submitted formula.

The faster you go, the lower your Cd.

That's all well and good, but what happens when your velocity is higher than the ballistic terminal velocity?

Say you had an object at 10Km altitude that had been accelerated at one G until the drag had equalized with the thrust and equillibrium had been achieved. That is your ballistic terminal velocity for that object at that pressure/ temperature.

Say (for the sake of argument) this value was 600 M/sec. What happens when you attempt to calculate this velocity from an object that is travelling 800 m/sec?

That object has a lower Cd due to it's higher Mach number. If we calculate the Vt of an object with that lower Cd, it will return an even *higher* value. If we attempt to iterate it, it gets worse, not better.

You can't calculate Vt assuming the Cd of an object that's already going faster than it. You just can't. That's my point.

Best,

-Slashy

I agreed with you! Until i tried actually iterating! See above!

Edited December 16, 2014 by arkie87

[ferram4]

Why does the acceleration matter at all? You still haven't justified why it comes into your consideration at all.

So, let's consider your situation:

The vehicle is traveling at a higher Mach number, yes. It will have a slightly lower Cd, yes. However, if you do the math out, you will discover that you will get a terminal velocity between 600 m/s and 800 m/s, not > 800 m/s as you state; this is because drag is dominated by the V^2 term, not Cd. In order for the situation you are describing to occur, Cd must decrease faster than 1/V^2 to overpower the effect of drag, and this is not something that occurs. Therefore, the problem you are describing does not exist, and arkie's method is correct.

All of these analyses assume that drag is dominated by Cd. This is not the case; it is dominated by V^2, and that is the effect that we see.

[GoSlash27]

So i thought about what he said on my ride home, thinking that he had a point: what he was saying is that the iterative method isn't stable when mach number is greater than 1 and when your initial guess (i.e. craft velocity) is greater than terminal velocity (assuming we know what terminal velocity is somehow) because it causes V_t to go in the wrong direction due to he logical argument i'll present below. Thus, the method FAR uses-- one iteration in this iterative method--is actually predicting a completely unrealistic value, since if FAR let it iterate indefinitely, it will not converge to the solution, but rather, diverge to infinity.

The basic reasoning is that let's say (using my made up Cd vs Mach number relationship since I am still working on yours, Ferram ), we are able to determine that V_terminal = 1961.8 m/s (since my method converged, we know it is the correct answer for terminal velocity). If we happen to be going above that value: say 3000 m/s, FAR will calculate drag coefficient at 3000 m/s, which results in a lower Cd, which should result in a larger terminal velocity; the next iteration, the larger terminal velocity will result in an even smaller drag coefficient, which will then increase terminal velocity yet again until terminal velocity approaches infinity and drag coefficient approaches 0.

However, to my surprise, this isnt what happened; it still converged to the correct solution: 1961.8 m/s. Here is the table of the results on a per iteration basis:

http://i.imgur.com/bCF0Awl.png

Thus, even though my initial guess was above terminal velocity, it was still able to converge to the correct solution despite he logical argument i just made (and that I think you are making).

I am still working on an explanation...

I agreed with you! Until i tried it! See above!

Close, but you converged on the *same* solution, which would be expected. Doesn't mean that it's "correct" if your initial assumption is higher than the actual Vt.

I already have the explanation

[arkie87]

Best explanation is this:

While drag coefficient decreases with increasing Mach for M > 1, drag force always increases with Mach (this should be self-evident from the fact that drag force is proportional to Cd V^2 and Cd is proportional to 1/V when M > 1, thus, V^2 trumps 1/V and drag force still increases).

Below is a plot of drag force (blue line) vs. velocity. The green line is weight (40 ton craft). The intersection of these two lines is terminal velocity--- 1961.8 m/s.

- - - Updated - - -

Close, but you converged on the *same* solution, which would be expected. Doesn't mean that it's "correct" if your initial assumption is higher than the actual Vt.

I already have the explanation

False. There is only ONE solution. See graph of Drag force vs Velocity.

False again, because if the iterative method converges, it converges to the correct solution, regardless of the initial guess.

Besides, from your logic, if our initial velocity is larger than V_t, V_t will only increase with subsequent iterations, but when we try iterating, as you suggest, it doesnt...

Maybe you need me to remind you what you just said:

Say (for the sake of argument) this value was 600 M/sec. What happens when you attempt to calculate this velocity from an object that is travelling 800 m/sec?

That object has a lower Cd due to it's higher Mach number. If we calculate the Vt of an object with that lower Cd, it will return an even *higher* value. If we attempt to iterate it, it gets worse, not better.

And i did exactly what you recommend, but the math does not work out the way you describe. It works the way Ferram describes

Edited December 16, 2014 by arkie87

[arkie87]

Why does the acceleration matter at all? You still haven't justified why it comes into your consideration at all.

So, let's consider your situation:

The vehicle is traveling at a higher Mach number, yes. It will have a slightly lower Cd, yes. However, if you do the math out, you will discover that you will get a terminal velocity between 600 m/s and 800 m/s, not > 800 m/s as you state; this is because drag is dominated by the V^2 term, not Cd. In order for the situation you are describing to occur, Cd must decrease faster than 1/V^2 to overpower the effect of drag, and this is not something that occurs. Therefore, the problem you are describing does not exist, and arkie's method is correct.

All of these analyses assume that drag is dominated by Cd. This is not the case; it is dominated by V^2, and that is the effect that we see.

Yes. This is the reason why.

[GoSlash27]

Why does the acceleration matter at all? You still haven't justified why it comes into your consideration at all.

Because the acceleration affects the velocity a vehicle has attained at a given altitude. It could be going 100 m/sec, or 300 m/sec, or even 3Km/per second, depending on the acceleration that got it there. Each of these objects will exhibit a different Cd due to it's velocity.

So, let's consider your situation:

The vehicle is traveling at a higher Mach number, yes. It will have a slightly lower Cd, yes. However, if you do the math out, you will discover that you will get a terminal velocity between 600 m/s and 800 m/s, not > 800 m/s as you state; this is because drag is dominated by the V^2 term, not Cd. In order for the situation you are describing to occur, Cd must decrease faster than 1/V^2 to overpower the effect of drag, and this is not something that occurs. Therefore, the problem you are describing does not exist, and arkie's method is correct.

All of these analyses assume that drag is dominated by Cd. This is not the case; it is dominated by V^2, and that is the effect that we see.

I'm not talking about where the velocity actually trends, which is absolutely correct by your math and as it should be. I'm talking about where the *predicted Vt* trends. It goes above the current velocity, not below.

Your formula says "this is my velocity, so this is my Cd. Using this Cd, the terminal velocity is blah". But the assumed Cd is too low, so the predicted Vt is too high. And the predicted Vt is always higher than the current velocity.

Assuming the Cd of the predicted Vt will always result in a lower prediction of Cd, which will result in an even higher prediction of Vt.

The aerodynamics work fine, it's the prediction that goes haywire.

If you feed in a Cd lower than that of an object actually *traveling* at that velocity (in the supersonic regime), the prediction diverges from the correct answer.

[arkie87]

Because the acceleration affects the velocity a vehicle has attained at a given altitude. It could be going 100 m/sec, or 300 m/sec, or even 3Km/per second, depending on the acceleration that got it there. Each of these objects will exhibit a different Cd due to it's velocity.

What you are talking about is whats know as an "initial guess". Dont say acceleration since it is confusing given your previous arguments. The acceleration of the craft gives it a different initial guess, so just say initial guess.

I'm not talking about where the velocity actually trends, which is absolutely correct by your math and as it should be. I'm talking about where the *predicted Vt* trends. It goes above the current velocity, not below.

Your formula says "this is my velocity, so this is my Cd. Using this Cd, the terminal velocity is blah". But the assumed Cd is too low, so the predicted Vt is too high. And the predicted Vt is always higher than the current velocity.

Assuming the Cd of the predicted Vt will always result in a lower prediction of Cd, which will result in an even higher prediction of Vt.

The aerodynamics work fine, it's the prediction that goes haywire.

If you feed in a Cd lower than that of an object actually *traveling* at that velocity (in the supersonic regime), the prediction diverges from the correct answer.

Predicted Vt trend is correct as well. Look at my table again:

After the first iteration of my algorithm (which is what FAR does for its prediction-- only ONE iteration), Vt prediction goes from 3000 m/s to 2400 m/s, thus, it DOES go in the correct direction even if initial guess is above Mach 1 and above actual terminal velocity.

Edited December 16, 2014 by arkie87

[GoSlash27]

Best explanation is this:

While drag coefficient decreases with increasing Mach for M > 1, drag force always increases with Mach (this should be self-evident from the fact that drag force is proportional to Cd V^2 and Cd is proportional to 1/V when M > 1, thus, V^2 trumps 1/V and drag force still increases).

Below is a plot of drag force (blue line) vs. velocity. The green line is weight (40 ton craft). The intersection of these two lines is terminal velocity--- 1961.8 m/s.

http://i.imgur.com/LyzFGi7.png

- - - Updated - - -

False. There is only ONE solution. See graph of Drag force vs Velocity.

False again, because if the iterative method converges, it converges to the correct solution, regardless of the initial guess.

Besides, from your logic, if our initial velocity is larger than V_t, V_t will only increase with subsequent iterations, but when we try iterating, as you suggest, it doesnt...

Maybe you need me to remind you what you just said:

And i did exactly what you recommend, but the math does not work out the way you describe. It works the way Ferram describes

Actually, your math works out the way I predicted it would. See above.

Now that you're home, I'm looking forward to seeing your attempt to make the Vt readout indicate that you have achieved Vt.

Best,

-Slashy

[GoSlash27]

Apologies, as your response was posted before mine.

I *would* expect the prediction itself to converge though I would not expect the prediction to converge on a value that is below the current velocity.

Your example above shows otherwise.

So now with this new information in hand, would you state that the ballistic Vt for your vehicle at 10Km is 1,962 m/sec? That is, the velocity that it would stabilize at in a homogenous pressure of .165kPa with 1 G of force applied?

Best,

-Slashy

Edited December 16, 2014 by GoSlash27

[arkie87]

Apologies, as your response was posted before mine.

I *would* expect the prediction itself to converge though I would not expect the prediction to converge on a value that is below the current velocity.

Your example above shows otherwise.

Best,

-Slashy

If it converges, it converges to the correct and only solution.

[arkie87]

Now that you're home, I'm looking forward to seeing your attempt to make the Vt readout indicate that you have achieved Vt.

Best,

-Slashy

I never thought i would say this but, DAMMIT! THE NEW VERSION OF KSP CAME OUT AND NOW I HAVE TO UPDATE ALL MY MODS BEFORE I CAN TEST THIS!

But i am excited for the new version of KSP

Video will come. I only need to update FAR to do this test...

[GoSlash27]

Your response was posted to an earlier edit of my post. I will wait for you to confirm that you stand by this before we proceed.

*edit* crap! Gotta update mine too!

Best,

-Slashy

[arkie87]

I never thought i would say this but, DAMMIT! THE NEW VERSION OF KSP CAME OUT AND NOW I HAVE TO UPDATE ALL MY MODS BEFORE I CAN TEST THIS!

But i am excited for the new version of KSP

Video will come. I only need to update FAR to do this test...

So i found an old version (0.24), and luckily, i kept FAR for this version (since FAR hasnt been updated yet, probably because we have been bothering him-- sorry everyone!), so i was able to do your test. Watch the video:

Can we put this to bed yet?

Edited December 16, 2014 by arkie87

[arkie87]

So now with this new information in hand, would you state that the ballistic Vt for your vehicle at 10Km is 1,962 m/sec? That is, the velocity that it would stabilize at in a homogenous pressure of .165kPa with 1 G of force applied?

Best,

-Slashy

No. The Cd vs Mach relationship i used is made up since i did not yet receive the information from Ferram (at that point in time), and the actual one used by FAR is a lot more complicated and i'm not entirely sure how to evaluate it since it must be applied to all parts carefully.

But what it does contain is the same relationship between Cd and M when M>1, that is, a proportional to 1/M relationship.

Edited December 16, 2014 by arkie87

[GoSlash27]

Arkie,

After pondering this (haven't seen the video yet), I've concluded that your approach must, indeed, be correct.

The free-fall terminal velocity for a craft would be the point where the total drag equals the weight, so successive approximation like you have shown can find it.

I think the light bulb finally went on. Sorry for all the confusion!

*edit* just watched the video, and yeah, I think we can definitely put this to bed. Thanks!

Best,

-Slashy

Edited December 16, 2014 by GoSlash27

[GoSlash27]

Ferram4,

All of these analyses assume that drag is dominated by Cd. This is not the case; it is dominated by V^2, and that is the effect that we see.

I think this is what was dominating my thought process; I was so focused in on the Cd that I was forgetting the velocity^2, which is the dominant factor.

Sorry for the headache!

-Slashy

[GoSlash27]

Just occurred to me:

So now that you have established that 10G acceleration is sufficient to catch Vt in FAR, what acceleration is sufficient to maintain it? That's gotta be lower than 10 Gs, right? Wouldn't you expect that 2 Gs would be sufficient?

Best,

-Slashy

[arkie87]

Arkie,

After pondering this (haven't seen the video yet), I've concluded that your approach must, indeed, be correct.

The free-fall terminal velocity for a craft would be the point where the total drag equals the weight, so successive approximation like you have shown can find it.

I think the light bulb finally went on. Sorry for all the confusion!

*edit* just watched the video, and yeah, I think we can definitely put this to bed. Thanks!

Best,

-Slashy

I think it's important when debating to pause for a minute and seriously consider the other person's perspective, rather than rushing off to a rebuttal. I readily admit that I can be guilty of that to, but i can say with certainty that in this debate, I seriously considered your side, read and re-read your posts (to make sure i wasnt misunderstanding you, which will just lead to frustration on both sides) and even thought I was wrong a few times through the course of the debate (I even mentioned it once).

That said, I'm glad it's over

[arkie87]

Just occurred to me:

So now that you have established that 10G acceleration is sufficient to catch Vt in FAR, what acceleration is sufficient to maintain it? That's gotta be lower than 10 Gs, right? Wouldn't you expect that 2 Gs would be sufficient?

Best,

-Slashy

First of all, i think i used more than 10G's to get to terminal though less might have sufficed....

I have no idea... i would need to test it...

I can imagine it might be sufficient for a while, until you get high enough that terminal velocity increases too fast to accelerate too. This happens with stock aero too (i sent you a graph of it), however, for both stock and FAR, it probably occurs during gravity turn (in FAR, gravity turn begins right away anyway).

[numerobis]

Terminal velocity (for a given craft, altitude, and atmospheric conditions) is "the" speed at which drag(v) - gravity = 0. A priori there's no reason that this function has only one zero over the positive reals.

However, if drag is a monotone function in v, then there's a single unique solution. Drag is monotone for stock: it's quadratic for most parts, and cubic in some regimes for air intakes. It's also monotone for FAR, even right around the M=1 peak in Cd, despite what eyeballs might believe.

The iterative solve converges linearly; throw in Newton iteration to get quadratic convergence, and you'll get there much faster. But it's not a hugely useful number, so it's not likely worth the effort.

[arkie87]

Terminal velocity (for a given craft, altitude, and atmospheric conditions) is "the" speed at which drag(v) - gravity = 0. A priori there's no reason that this function has only one zero over the positive reals.

However, if drag is a monotone function in v, then there's a single unique solution. Drag is monotone for stock: it's quadratic for most parts, and cubic in some regimes for air intakes. It's also monotone for FAR, even right around the M=1 peak in Cd, despite what eyeballs might believe.

The iterative solve converges linearly; throw in Newton iteration to get quadratic convergence, and you'll get there much faster. But it's not a hugely useful number, so it's not likely worth the effort.

You seem to be more of a mathematician than an engineer i.e. you seem to know more theory than me

I have lots of experience with numerical methods (i've dont a lot of numerical work for my PhD), but not so much of the theory, especially when it comes to stability.

If drag is some arbitrary function, then of course, a priori, we do not know its behavior. But since it is a physical function, it has to make physical sense, and it wouldnt make physical sense for an increased velocity to result in less total drag force (less drag coefficient is fine though). Thus, we should know that it is monotonically increasing with velocity, and so, there is only one root.