Optimal TWR with Stock vs. FAR Aerodynamics

[GoSlash27]

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.

This, right here, is the crux of the matter. You would think it would, but it doesn't.

Approaching Mach 1 makes your Cd increase, while accelerating beyond Mach 1 makes your Cd decrease. Concurrently, your displayed terminal velocity will diverge from your *actual* terminal velocity will seem lower than it really is as you approach Mach 1, while it will seem higher the more you exceed it.

Therefore it is actually possible to exceed your free-fall terminal velocity without ever having seen the display flip. This is what's happening to you.

Case in point; during your video at, say, 10Km, your velocity is 660M/sec. Were it revised to reflect your Cd *at* the actual terminal velocity, it would show you're actually twice your terminal velocity, but the display suggests that your Vt is 1,270. It says you should be going faster, but you should actually be going slower.

Try calculating it out. What would your ship's 1G terminal velocity be at 10km? ÃÂ=0.165 kPa.

[wasmic]

TWR is dimensionless. A TWR of 1.4 will behave the same for a large rocket or a small rocket... (assuming drag is negligible). Your explanation does not make sense.

A taller rocket will take longer time to move its own height, so to a human it seems like a taller rocket lifts off slower than a smaller rocket with the same TWR.

So that makes sense. I, however, have disabled aerodynamic disassebly in FAR so i dont have to worry about falling apart

How exactly does it make rocket harder to fly though?

If you're moving faster, a smaller deviation from prograde is necessary to make your rocket tumble.

[arkie87]

Case in point; during your video at, say, 10Km, your velocity is 660M/sec.

Ok. This approximately Mach 2. Drag coefficient according to FAR readout is 0.187.

Were it revised to reflect your Cd *at* the actual terminal velocity, it would show you're actually twice your terminal velocity, but the display suggests that your Vt is 1,270. It says you should be going faster, but you should actually be going slower.

Terminal velocity readout is 1270 m/s, which is about Mach 4. Drag coefficient at Mach 4 will be less than 0.187 (how much less I cannot say since i do not have the relationship between drag coefficient and Mach that FAR uses), since drag coefficient decreases with Mach after Mach 1.

Terminal velocity and drag coefficient are inversely proportional, that is, if drag coefficient decreases, terminal velocity increases and vice versa. Thus, in this case, drag coefficient at terminal velocity will be smaller than drag coefficient at current velocity, thus terminal velocity is actually higher than predicted, not lower.

Below Mach 1, terminal velocity prediction is an overestimate since drag coefficient is increasing. Even so, terminal velocity prediction, even in this case, is still larger than current velocity, so acceleration should still help.

Try calculating it out. What would your ship's 1G terminal velocity be at 10km? ÃÂ=0.165 kPa.

I have done so here. I cannot calculate terminal velocity at any other velocity other than the one FAR reports, since i do not have the relationship between drag coefficient and Mach that FAR uses.

[GoSlash27]

"I have done so here. I cannot calculate terminal velocity at any other velocity other than the one FAR reports, since i do not have the relationship between drag coefficient and Mach that FAR uses."

Actually, you haven't calculated it. You need to calculate it the hard way. I believe somebody had posted a chart of the relationship early in this thread.

If we can't hash it out this way, we can try a thought experiment...

How rapidly would you have to accelerate in order to get that display to flip? 10G? 300G? 3,000?

Edited December 15, 2014 by GoSlash27

[Ziff]

I'm out of popcorn. I'll come back later to see how this ends.

[ferram4]

@GoSlash27: Well, then since you clearly understand this problem far better than the rest of us, I look forward to your pull request addressing all of them. In particular, since this must result in more computational overhead, I expect to see it included with documentation of the percent improvement in the estimate, data on the cases where Cd varies with 1/V^n, where n > 2 (as must occur for your assumptions of its inaccuracy to occur), and the use cases for your improvements. All of that should justify why the improvement you're asking for is necessary, and it shouldn't be that difficult; I (and I expect, everyone else) shall take failure to make a pull request within two weeks to be conceding the point.

Enough talk, you know what you're doing; implement it now. Have fun, and I look forward to your contributions.

Edit: Additionally, it should also point to the theoretical / empirical basis for the improvement; handwaving is not allowed.

Edited December 15, 2014 by ferram4

[arkie87]

Actually, you haven't calculated it. You need to calculate it the hard way. I believe somebody had posted a chart of the relationship early in this thread.

I said i cannot calculate it since I dont have the information.

I did not see that relationship. Please show this relationship to me. unless you are referring to this: http://upload.wikimedia.org/wikipedia/commons/0/0e/Qualitive_variation_of_cd_with_mach_number.png

as it was i that posted that. That relationship is qualitative only. Each part has its own relationship, which are, essentially, its aerodynamic properties.

How rapidly would you have to accelerate in order to get that display to flip? 10G? 300G? 3,000?

What do you mean by "display to flip?"

Acceleration does not effect terminal velocity, as Ferram explicitly stated.

[arkie87]

@GoSlash27: Well, then since you clearly understand this problem far better than the rest of us, I look forward to your pull request addressing all of them. In particular, since this must result in more computational overhead, I expect to see it included with documentation of the percent improvement in the estimate, data on the cases where Cd varies with 1/V^n, where n > 2 (as must occur for your assumptions of its inaccuracy to occur), and the use cases for your improvements. All of that should justify why the improvement you're asking for is necessary, and it shouldn't be that difficult; I (and I expect, everyone else) shall take failure to make a pull request within two weeks to be conceding the point.

Enough talk, you know what you're doing; implement it now. Have fun, and I look forward to your contributions.

Even if Cd varies with 1/V^n where n > 2, this still would not matter since decreasing drag coefficient results in increased terminal velocity, not decreased, as GoSlash is suggesting.

- - - Updated - - -

I'm out of popcorn. I'll come back later to see how this ends.

Nice Avatar. Mind if i copy it?

[arkie87]

@GoSlash27: Well, then since you clearly understand this problem far better than the rest of us, I look forward to your pull request addressing all of them. In particular, since this must result in more computational overhead, I expect to see it included with documentation of the percent improvement in the estimate, data on the cases where Cd varies with 1/V^n, where n > 2 (as must occur for your assumptions of its inaccuracy to occur), and the use cases for your improvements. All of that should justify why the improvement you're asking for is necessary, and it shouldn't be that difficult; I (and I expect, everyone else) shall take failure to make a pull request within two weeks to be conceding the point.

Enough talk, you know what you're doing; implement it now. Have fun, and I look forward to your contributions.

Ferram, what is the general form of the correlation between drag coefficient with Mach number? Is it piece-wise defined? If you give me this relationship, I can write a matlab code in 5 seconds to disprove GoSlash....

Also, does Mach number in FAR factor in temperature from

c = sqrt(gamma*R*T)?

I suppose I can ignore than dependence for the purposes of this debate though and assume V_sound = 343 m/s independent of altitude.

[Ziff]

Nice Avatar. Mind if i copy it?

Not at all! Glad to see another fellow Spaceman Spiff fan.

[Bryce Ring]

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

MechJeb 2 Version 2.4.0 was used. the mods installed are in the picture. you may need to save or view it more zoomed to see them all. Did not touch the KIDS modifier.

terminal velocity has no dependence whatsoever on forces other than drag and gravity.

Spot on.

Hello Mr Ferram4, Great mod, I say that from a totally lower position than you, So my opinion is of no real merit or indication of how well you did. but the fact you can do such things shows that you have vastly more Neural connections than I.

I am curious though. While I was making that video for Slashy, I spotted that the IAS was exceeding actual air speeds. I can understand that some parts of a surface can experience an increase in velocity of wind relative to free flow enviroment. but the amount of IAS shown seems to be way greater than such phenomenon. and if such phenomenon is in play. is there anyway to make it so that it reflects IAS in free stream.

PS, most of this debate could be solved with a simple read out that shows the current Drag force in G #'s or m/s/s or some thing easy to translate to gravity force. I am not trying to get you to copy MechJeb, but the Drag force readout that it has, that shows opposing force due to drag, is really helpful. I like to watch it climb to just above 10.??m/s/s before it does its job of limiting throttle.

Bryce.

Edit1

at 2:40 I start flipping between surface and IAS

Edited December 15, 2014 by Bryce Ring

[GoSlash27]

What do you mean by "display to flip?"

You said that even though the display doesn't display the free-fall terminal velocity, that it would still indicate the relationship between your current velocity and the free fall terminal velocity; that it would read higher than your current velocity if you had not yet reached free-fall terminal, and lower if you had exceeded it.

So exactly how rapidly do you have to accelerate in order to exceed the free-fall terminal velocity and thus have this display read a lower velocity than your current velocity?

[NathanKell]

Bryce Ring, Compressibility effects. As v approaches M=1, and supersonic, IAS gets...wonky.

[arkie87]

You said that even though the display doesn't display the free-fall terminal velocity, that it would still indicate the relationship between your current velocity and the free fall terminal velocity; that it would read higher than your current velocity if you had not yet reached free-fall terminal, and lower if you had exceeded it.

So exactly how rapidly do you have to accelerate in order to exceed the free-fall terminal velocity and thus have this display read a lower velocity than your current velocity?

It DOES display (free-fall) terminal velocity, this value is just inaccurate due to incorrect drag coefficient being used.

To get up to terminal velocity in FAR, I would try >10g acceleration.

vf^2 = vi^2 + 2*a*h; vi=0; a=98.1 m/s/s, vf=1200 m/s

h = 1/2 vf^2/a = 7.34 km altitude

So you will reach about 7.34 km altitude with 10 g (which should be plenty of buffer to counter act drag force) such that you should hit terminal velocity at 10 km.

[GoSlash27]

It DOES display (free-fall) terminal velocity, this value is just inaccurate due to incorrect drag coefficient being used.

To get up to terminal velocity in FAR, I would try >10g acceleration.

vf^2 = vi^2 + 2*a*h; vi=0; a=98.1 m/s/s, vf=1200 m/s

h = 1/2 vf^2/a = 7.34 km altitude

So you will reach about 7.34 km altitude with 10 g (which should be plenty of buffer to counter act drag force) such that you should hit terminal velocity at 10 km.

If it's "inaccurate", then it's not displaying it.

Okay, so 10 Gs acceleration. I don't suppose I could convince you to test that theory out, could I?

Actually accelerate a rocket vertically at 10 Gs and see if the indicated speed actually does exceed the Vt display? I bet it wouldn't.

[ferram4]

The variance of Cd with Mach number, for non-wings, is:

//For straight cylinders,
Cd ~= 0.003;  //based on total wetted area, only increases from here for changes in diameter


if(M < 1)
Cd *= 1 + 0.4 * e^(10 * M - 10);
else
Cd *= 0.15 / M + 1.25;

if(open node away from flow)
{
if(M < 1)
Cd += ((M^2 * 0.2) + 0.1) * areaNode / refArea;
else
Cd += (0.21 / M^2) * areaNode / refArea;
}

There's some extra math for open nodes facing into the flow, but that's not relevant for the standard rocket.

Mach number is based on temperature using the assumptions of a calorically perfect gas, so your equation was correct. Further, it runs on standard Earth temperature and air assumptions.

[arkie87]

This, right here, is the crux of the matter. You would think it would, but it doesn't.

Approaching Mach 1 makes your Cd increase, while accelerating beyond Mach 1 makes your Cd decrease. Concurrently, your displayed terminal velocity will diverge from your *actual* terminal velocity will seem lower than it really is as you approach Mach 1, while it will seem higher the more you exceed it.

Therefore it is actually possible to exceed your free-fall terminal velocity without ever having seen the display flip. This is what's happening to you.

Case in point; during your video at, say, 10Km, your velocity is 660M/sec. Were it revised to reflect your Cd *at* the actual terminal velocity, it would show you're actually twice your terminal velocity, but the display suggests that your Vt is 1,270. It says you should be going faster, but you should actually be going slower.

Try calculating it out. What would your ship's 1G terminal velocity be at 10km? ÃÂ=0.165 kPa.

Ok. I have made a model in matlab to calculate this exectly (which is similar to what FAR would have to do to get accurate results for terminal velocity display).

First, i had to make an assumption for the relationship between Cd and Mach (i have assumed speed of sound is 343 m/s). I have defined it as a peicewise function:

If Mach < 0.8 (a placeholder value for critical_mach number): Cd = 0.2 + 1/8*M

If 0.8<Mach < 1: Cd = 0.3 + (M-M_crit)/(1-M_crit)*0.7

If Mach > 1: Cd = 1/M

The graph of this function looks like this , and is realistically looking: http://upload.wikimedia.org/wikipedia/commons/0/0e/Qualitive_variation_of_cd_with_mach_number.png

I have then wrote a matlab code which will use current velocity as a guess value for drag coefficient, which it will then use to calculate terminal velocity. It will then iterate until the terminal velocity used to calculate the drag coefficient returns the same terminal velocity. This takes about twenty iterations:

As you can see, V_t increases from its initial value since it is over estimating the drag force, not underestimating it.

Furthermore, after 20 iterations, the terminal velocity value we have calculated is correct, since if we compute drag coefficient using it, and then use drag coefficient to compute terminal velocity, we arrive at the same number...

Edited December 15, 2014 by arkie87

[arkie87]

The variance of Cd with Mach number, for non-wings, is:

//For straight cylinders,
Cd ~= 0.003;  //based on total wetted area, only increases from here for changes in diameter


if(M < 1)
Cd *= 1 + 0.4 * e^(10 * M - 10);
else
Cd *= 0.15 / M + 1.25;

if(open node away from flow)
{
if(M < 1)
Cd += ((M^2 * 0.2) + 0.1) * areaNode / refArea;
else
Cd += (0.21 / M^2) * areaNode / refArea;
}

There's some extra math for open nodes facing into the flow, but that's not relevant for the standard rocket.

Mach number is based on temperature using the assumptions of a calorically perfect gas, so your equation was correct. Further, it runs on standard Earth temperature and air assumptions.

Thanks, i will update matlab code with these values shortly...

[GoSlash27]

Ok. I have made a model in matlab to calculate this exectly (which is similar to what FAR would have to do to get accurate results for terminal velocity display).

First, i had to make an assumption for the relationship between Cd and Mach (i have assumed speed of sound is 343 m/s). I have defined it as a peicewise function:

If Mach < 0.8 (a placeholder value for critical_mach number): Cd = 0.2 + 1/8*M

If 0.8<Mach < 1: Cd = 0.3 + (M-M_crit)/(1-M_crit)*0.7

If Mach > 1: Cd = 1/M

The graph of this function looks like this http://i.imgur.com/lGVMDfX.jpg, and is realistically looking: http://upload.wikimedia.org/wikipedia/commons/0/0e/Qualitive_variation_of_cd_with_mach_number.png

I have then wrote a matlab code which will use current velocity as a guess value for drag coefficient, which it will then use to calculate terminal velocity. It will then iterate until the terminal velocity used to calculate the drag coefficient returns the same terminal velocity. This takes about twenty iterations: http://i.imgur.com/pfMvlCZ.png

As you can see, V_t increases from its initial value since it is over estimating the drag force, not underestimating it.

Furthermore, after 20 iterations, the terminal velocity value we have calculated is correct, since if we compute drag coefficient using it, and then use drag coefficient to compute terminal velocity, we arrive at the same number...

I'd like to bookmark this and revisit it, as it contains a major flaw, but to avoid getting us off on a tangent, I'd like to continue with the current thought experiment.

You have proposed that the Vt display will show a lower value than your indicated airspeed at 10KM if you accelerate at 10G.

Could I convince you to try it? It'd be really helpful if you did, but if you don't want to, then we don't really have to.

Actually, it would simplify everything *tremendously* if you would humor me and try it. I'm keen to see what the new numbers look like, and I expect it'll be a real eye- opener for you.

Edited December 15, 2014 by GoSlash27

[arkie87]

The variance of Cd with Mach number, for non-wings, is:

//For straight cylinders,
Cd ~= 0.003;  //based on total wetted area, only increases from here for changes in diameter


if(M < 1)
Cd *= 1 + 0.4 * e^(10 * M - 10);
else
Cd *= 0.15 / M + 1.25;

if(open node away from flow)
{
if(M < 1)
Cd += ((M^2 * 0.2) + 0.1) * areaNode / refArea;
else
Cd += (0.21 / M^2) * areaNode / refArea;
}

There's some extra math for open nodes facing into the flow, but that's not relevant for the standard rocket.

Mach number is based on temperature using the assumptions of a calorically perfect gas, so your equation was correct. Further, it runs on standard Earth temperature and air assumptions.

Question about the *= format:

Cd *= 1 + 0.4 * e^(10 * M - 10)

means:

Cd = Cd*(1 + 0.4 * e^(10 * M - 10) )

Correct?

If so, what is initial value of Cd? 0.003?

What is aeraNode/refArea (i assume 1 for this graph)? And is this term active if a rocket is placed on the backside?

If so, below is my graph of Cd vs M that FAR uses for Rockets:

Can you confirm this looks correct?

If areaNode/refArea is 4 since the leading edge of the rocket is small (1.25 diameter) and the trailing edge is large (2.5m), then my graph looks like:

Are either of these correct?

Edited December 15, 2014 by arkie87

[arkie87]

I'd like to bookmark this and revisit it, as it contains a major flaw, but to avoid getting us off on a tangent, I'd like to continue with the current thought experiment.

You have proposed that the Vt display will show a lower value than your indicated airspeed at 10KM if you accelerate at 10G.

Could I convince you to try it? It'd be really helpful if you did, but if you don't want to, then we don't really have to.

Actually, it would simplify everything *tremendously* if you would humor me and try it. I'm keen to see what the new numbers look like, and I expect it'll be a real eye- opener for you.

I will test it when i get home.

Meanwhile, I'm dying to hear what the major flaw is...

[arkie87]

Further, it runs on standard Earth temperature and air assumptions.

T is constant or T has some profile?

gamma = 1.4

T=300 K

R=287?

[ferram4]

Those graphs look wrong, because the function is not discontinuous at M = 1. Both sides of it equal 1.4 at Mach 1, which your graph doesn't show. And yes, for the assumption of no change in diameter across the part, Cd is 0.003. The left side looks right, but the right side doesn't.

And those temp and gas properties are about correct; I'm not sure the details of KSP's temp curve, but it provides decent results, with a = 340 m/s at SL and a = 300 m/s at ~10km.

Also, that ratio is really, really, really high for an areaNode/refArea ratio. That would imply that the node area is equal to the rest of the surface area of the rocket.

Edited December 15, 2014 by ferram4

[Bryce Ring]

Bryce Ring, Compressibility effects. As v approaches M=1, and supersonic, IAS gets...wonky.

Thank you for your reply.

I always feel good when I learn something new or add to or correct a previously incorrect assumption or piece of knowledge I may have had.

I will read up on IAS and EAS etc in my own time. sorry to have taken(wasted) a bit of you time there.

Bryce.

[GoSlash27]

I don't want to derail the experiment by getting us off on a tangent, but you're using the "current velocity" as a seed value when the "current velocity" wasn't achieved from 1G acceleration in the current atmospheric density.

Your iteration will always scale upwards because you're supersonic and thus Cd decreases the faster you go.

If you put in a higher seed value (say, by having climbed at 8 Gs instead of 5) it will iterate to an even *higher* terminal velocity.

If you put in a lower seed value, (say by having climbed at 3 Gs instead of 5) it will iterate out to a lower terminal value, but still well above your current indicated speed.

It is based on the assumption of current velocity, *not* the velocity the ship would have actually been going had it been at the actual 1G free fall terminal velocity.

The error in this approach is exactly the same as it is with the FAR readout. No matter what "current velocity" you feed into it, it will *always* spit out a higher velocity as it's estimation of the free-fall terminal velocity. It is therefore useless as an indicator of when you have truly achieved free-fall terminal velocity.

Edited December 15, 2014 by GoSlash27