A funny thing happened to the aero parts

[numerobis]

I was trawling through the .cfg files of all the aero parts to update my KSP-scripts, and found a gem in the aero parts.

Let's compare the drag coefficients of a normal rocket part (0.2 at any angle of attack, the blue line), a Mk2 long tank (red +), and an Mk2 short tank (green x):

That's the drag *coefficient*, before you multiply by the mass. So if you want to fly on an Mk2 long tank, you could instead fly on a pair of Mk2 short tanks. You'd get the same lift, the same mass, the same amount of fuel, but less drag -- much less at high angle of attack. At high angle of attack, the long tank is worse than the standard rocket tanks (but we're talking very high, more than 30 degrees).

All the new-to-me (i.e. released in 0.23.5, 0.24, or 0.25) surfaces have this "feature": the smaller the elevon, the lower the drag coefficient, which means that two elevon4 are the same mass and lift as one elevon3, but at half the drag.

I assume it's a misunderstanding by the author of the new parts. The mass and lift have to be reduced by half for a half-sized part. But the drag generally shouldn't be, because it gets multiplied by the mass later.

[Werwolf]

Good catch. Have you posted this in the bugs forum?

[GoSlash27]

I noticed that about some of the new control surfaces; some of them are ridiculously drag-free... at least on paper.

I haven't worked out a test rig yet to verify the behavior in-game.

Best,

-Slashy

[Red Iron Crown]

I wish we had more info on how lift is calculated. The deflection lift "coefficient" is twice as large in the large tank, depending on how lift is calculated it might be appropriate for the Cd to change in such a way. It's also not clear how the Module Lifting Surface calculates drag either.

I'm going to run some tests and see if the smaller tank falls faster than the larger, see what empirical evidence shows.

Edit: Some initial test results:

Test rig hauling tanks up:

Upon separation the smaller tanks accelerate quicker, but I think this is due to the decoupler force being equal for both tanks so it accelerates the smaller tank more:

They quickly settled into a fixed formation, falling at the same terminal velocity:

I'm not sure if this is the expected result or not. The tanks are falling edge on so I don't know what their AoA is, if it's equivalent to nose on they might be using the min AoA value so there's no variation between them. I'll try another rig and see if I can find better results.

Edited November 3, 2014 by Red Iron Crown

[Ival70]

I've done a few casual "tests" and the results seem to confirm this. I might go back now and do some more serious experiments to get some data.

[Red Iron Crown]

A better test rig, with the tanks set to have a 45 degree AoA and eliminating decoupler force from the equation, you're definitely on to something here:

The smaller tanks fall much faster, indicating they have much less drag. Not sure how lift was affected, though I did observe that the pairs of big tanks flipped over so that the multinode part faced down before crashing while the smaller tanks did not.

Edit to add: I tried the same test again but instead doubled up the small tanks so that the masses would be equal. Same result, the smaller tanks fall faster.

Edited November 4, 2014 by Red Iron Crown

[numerobis]

I wish we had more info on how lift is calculated

This is how it's calculated. For lifting surfaces and "winglet" parts (which is most of the wings), there's a function of angle of attack that grows until about 35 degrees and then falls off to zero. For control surfaces, that function is the sin of AoA.

The lift force depends on that function, the air pressure, the deflectionLiftCoeff value, and the speed. It doesn't depend on the mass, so if you want to denote that your lifting surface is twice as big, you have to double the lift coefficient.

The drag is computed by taking the sin(AoA), interpolating according to that between dragAtMinAoA and dragAtMaxAoA (or between zero and dragCoeff). That gives you the drag coefficient. That plugs into the drag formula: 0.008 * air density * v^2 * dragCoefficient * mass. That depends on the mass, so if your part is twice as big, you'll double the mass, and drag will follow suit. If you also double the dragCoefficient, you've overcorrected.

[numerobis]

The smaller tanks fall much faster, indicating they have much less drag. Not sure how lift was affected, though I did observe that the pairs of big tanks flipped over so that the multinode part faced down before crashing while the smaller tanks did not.

Oh cool. Flipping is consistent with my calculation. The docking node has drag 0.2; the big tanks at 45 degrees AoA have drag 0.24, so they'd want to be on top. The small tanks have drag 0.13, so they remain on the bottom.

[Red Iron Crown]

This is how it's calculated. For lifting surfaces and "winglet" parts (which is most of the wings), there's a function of angle of attack that grows until about 35 degrees and then falls off to zero. For control surfaces, that function is the sin of AoA.

The lift force depends on that function, the air pressure, the deflectionLiftCoeff value, and the speed. It doesn't depend on the mass, so if you want to denote that your lifting surface is twice as big, you have to double the lift coefficient.

How did you arrive at the lift formula? Is it derived empirically or through some other method?

[numerobis]

Through code inspection, verified by my planes taking off almost exactly as the speed predicts.

[Red Iron Crown]

Fascinating. I was about to suggest you let mhoram know for his Physics of KSP reference, but I see you've already posted in that thread.

Back to this topic: I would consider this a bug, have you reported it as such? I really don't think the devs intended for the simulation to reward breaking craft up into many smaller parts, which is what this would seem to do.

[numerobis]

No, I just noticed it yesterday and worked this out today in detail. How does bug reporting work these days?

[Red Iron Crown]

The bugtracker is probably best. If for whatever reason you'd rather stick to the forums, there are provisions for reporting bugs in the Support forum.

This is something that really should be fixed, I wish I knew how to write ModuleManager cfgs as I'm pretty sure it can be fixed with that.

[GoSlash27]

Something that's so self-evident that I'd never really thought much about it:

Lift/drag is equal to the inverse of t/w in cruising flight. This is because in level flight where you're not accelerating, lift equals weight and drag equals thrust.

It should be a fairly straightforward task to fly in various regimes and empirically determine the lift- to- drag for various components and see if the math lines up.

Best,

-Slashy

[bsalis]

So are we finding faults with the areo model in the game? It's going to be a looong thread.

[Cirocco]

So are we finding faults with the areo model in the game? It's going to be a looong thread.

not really. We're finding inconcistencies and exploitables.

Might still be a long thread, but a helpful one.

[Red Iron Crown]

So are we finding faults with the areo model in the game? It's going to be a looong thread.

Not exactly. Numerobis has discovered an interesting inconsistency in the .cfg files for some aerodynamic parts, fixing it doesn't require any changes to the aero model but instead some minor edits to the cfgs.

[ratchet freak]

Not exactly. Numerobis has discovered an interesting inconsistency in the .cfg files for some aerodynamic parts, fixing it doesn't require any changes to the aero model but instead some minor edits to the cfgs.

what happens if you put the V upside down (or right side up as it were), do the small tanks flip over so the multinode is pointing up?

[Ted]

Interesting find there, nicely done!

Could you place this on the bug tracker when you get a moment?

Thanks

[Red Iron Crown]

what happens if you put the V upside down (or right side up as it were), do the small tanks flip over so the multinode is pointing up?

I would expect it to, but I'm not at my KSP computer at the moment to try it.

[numerobis]

Come to think of it, the test rig would be better without the multinodes, or at least with doubling the short tanks so that the mass is the same.

[Red Iron Crown]

Come to think of it, the test rig would be better without the multinodes, or at least with doubling the short tanks so that the mass is the same.

The same thing occurred to me about doubling the tanks, I edited the post after to say that I tried with the short tanks doubled and got the same results.

My initial test rig had no multinodes, but this was problematic as the tanks would want to rotate to zero AoA and equal drag. The pictured rig was able to keep them at the appropriate AoA, but I'm certain there's room for a better test rig design.

[Laie]

I'm certain there's room for a better test rig design.

A) Put them on top of a booster, or boosters. the higher TWR the better, so as to maximise drag. launch straight up. Note altitude of flameout.

A1) Autostage boosters through mechjeb. Note peak altitude in F3.

Attach a few winglets so that the tanks become self-stabilising gliders. Put them in a 10km "orbit" using hyperedit (or as high as necessary so they won't come apart). Note time-to-impact.

Edit, just tried a quick variant of B: attached small reaction wheel, mechjeb for command, a few ox-stats for power. Used the hyperedit lander to lift it to 5000m, then let it drop.

Time-to-impact was 51 seconds for the large tank, 45 seconds for two short tanks.

Edited November 4, 2014 by Laie