Atmospheric drag

[Kosmo-not]

@ Iskierka

To address your concerns about sources of error in my experiment:

Altimeter: I\'m sure you\'re referring to the one on top of the screen. I knew it would be problematic to read if it were between number. Thus, I used my altitude from the map view instead.

Time: I used a video editor to keep track of time. The video editor records milliseconds.

The data should be a very good approximation, at least below 40km. Above that, the graph gets noisy because the change in velocity was no that great.

[closette]

Glad you found this thread, Kosmo, because the credit for data-taking and inspiration for this is all due to you. I think a scale height of 4850+/-150m is an acceptable result we can all agree on?

You could get better drag data above 30 km by dropping the command module from way above the atmosphere - that way you\'ll be slamming into the upper layers much faster, which will increase the drag force and its effect on acceleration. But above 30 km no-one really cares, since most people have made their gravity turn by then and the terminal speed becomes comparable to the orbital speed up there. (In fact that is why one should be orienting the nose to build up orbital velocity and not so much to push through the atmosphere by then. We all knew it, but your data proves it!).

I\'d like to see (and I\'m not asking you, although it would be a huge favor) similar data for something with larger mass total maximum_drag factor, e.g. a command pod + empty LFE. I\'m just not convinced that the maximum_drag factors are simply additive in the model as claimed elsewhere. If they were, then one would expect a greater difference in the falling speeds of big vs. small objects - with terminal speed proportional to sqrt(total drag factor) - which I am just not seeing in practice.

Since objects fall faster than their terminal speeds in an exponential atmosphere the only way to measure the actual drag on them is by calculating their accelerations, as you did.

[Hypocee]

Er. You are aware that there\'s an erroneous extra mass term in the game\'s drag math right now, which makes objects ignore mass - empty tanks and full ones fall the same etc.

[closette]

@Hypocee,

Yes I am, thanks to your posts and clarifications on earlier threads. What I should have said is that we need drop tests with more parts attached to compare big vs. small, not more mass, although it often amounts to the same thing. I edited my previous post. Thanks again!

[Iskierka]

First things first: yeah, Kerbin IS a pretty impossible planet. Figuring out why it\'s impossible is fun, though.

That being said... you are making a calculation with a perfect gas model: it\'s completely unusable for space reentry conditions, on Earth at least

There is a very good Wikipedia page on this topic, at http://en.wikipedia.org/wiki/Reentry#Perfect_gas_model

I was aware of this, and used the perfect gas model due to it being quicker and still demonstrating the disparity we have, which will still be at least present in the real gas model. Regardless, SF₆ is relatively inert, and that same article states that the limit for perfect gas is 2,000K; just where the perfect gas estimate lies, with a fast reentry. It also doesn\'t take long to find quotes saying the gas against the shuttle in reentry is at least 7,800 K, which is clearly quite a difference.

http://kerbalspaceprogram.com/forum/index.php?topic=5623.msg72319#msg72319

written by someone you might know, and it implies that the maximum_drag parameter includes the conventional factor of 1/2 in front of c_dA.

As I stated, I used an extra factor of 1/2 in my calculations, which I thought would fairly clearly at least imply that I had forgotten that factor in the original equation. As the [tt]maximum_drag[/tt] parameter is meant to be a property of the part, and the / 2 is part of q, it seems fairly reasonable to assume that the /2 shouldn\'t be included in the part parameter. A factor of 10 difference from the ISA seems reasonable also, given everything else about Kerbin is a factor of 10 scale, with the one exception of its moon.

Oh, and as you are aware we don\'t really know gamma for the atmosphere, it could very well have a bunch of Xenon if you don\'t like SF₆. Would that help any? IMHO less re-entry heating than Earth\'s makes for a more playable KSP, and is in line with the gentler aspects of gravity and atmosphere that make early success in the game easier. (That\'s one reason I haven\'t tried Orbiter in a long time!).

Re-entry heating isn\'t as excessive a problem such that a factor of 10 base difference is required for correction. Assuming, quite reasonably, that anything which needs more than 'stick a heatshield on' (which is basically just spaceplanes) will have the option of marking in features such as thermal tiles or actively cooled parts without the months of design work required, only the mass, cost and energy penalties, as is reasonable for gameplay, it would be perfectly feasible for reentry heating to be as extreme as on Earth without being excessive.

As for drags of parts being additive - remember that the drag of a part only acts on that one part. That part will attempt to behave regardless; ie, a pod will fall as though it has a drag of 0.2. The parachute on top, as though it has 0.3, which means a slower fall. Once these start behaving differently, the physics system comes in and resolves the forces holding them together, which is the only effect that will be seen. Where has it been claimed the parameters are additive?

As an extra on atmosphere scale height, I just tested another property which I recall HarvesteR stating on IRC, but is currently locked in a log on an unaccessible harddrive partition. But this factor was that the atmosphere ends when its density is precisely one millionth that of surface level. Given how straightforward that number is, it would be silly to assume he didn\'t pick this number exactly, also. This is further reinforced by the result of this test.

With a scale height of 5 km, this would mean the atmosphere ends at 69,077.55m. To test just how much error I could expect, I went in reverse and found out the scale height that would be implied if it were 69 km exact, which was just 6 metres less than 5 km. So, quite clearly, barring a very awkward and nonsensical cutoff, this test would give a very accurate measure of the scale height. For completeness, I\'ll also state that the next round order of magnitude with decreasing scale height isn\'t reached until 4.3 km, so I didn\'t forget a zero.

To test, I then set up my most precise orbit ever. Apoapsis 70,414m, periapsis 69055m. If this entered the atmosphere, it would say the height is at least 4.995 km. Even better if it occurred at the precise altitude. So, I entered time warp, 5x to minimise excess speed, then waited until I was booted from warp. The moment I was, I hit escape to pause and read altitude. The altimeter reads 69077m. Very quick unpause and re-pause to check the map. Precise readout is still on the higher value of 69078 m. If this can\'t settle what the scale height is, I\'m not sure what other than HarvesteR\'s direct intervention can.

[closette]

Thanks Iskierka, lots to digest:

1. It sounds like 5.00 km is a scale height consistent with Kosmo-not\'s free-fall data AND your well-designed orbital experiment - also a contender for the 'most circular orbit' challenge! The 'insider information' is interesting, but the experiment is far more convincing. Coincidentally, it was Sir Robert Boyle, of Boyle\'s Law of gases, that gave the Royal Society its motto 'Nothing by authority'.

Having said that, here is a post from Harv about the pressure scale height (although I think he writes the equation incorrectly):

http://kerbalspaceprogram.com/forum/index.php?topic=2322.msg22234#msg22234. The scale height for that is, you guessed it, 5 km, the same as for density, so that implies an isothermal atmosphere.

2. Thanks for explaining about your forgotten vs. implied factor of 1/2 in front of the drag force equation. I\'ll update my calculations to include it so that we\'re all comparing like with like, although I\'d like to see the code fragment as to how maximum_drag is implemented.

3. Speaking of which:

As for drags of parts being additive - remember that the drag of a part only acts on that one part. That part will attempt to behave regardless; ie, a pod will fall as though it has a drag of 0.2. The parachute on top, as though it has 0.3, which means a slower fall. Once these start behaving differently, the physics system comes in and resolves the forces holding them together, which is the only effect that will be seen. Where has it been claimed the parameters are additive?

WHA...? I saw a post 'somewhere' about the drag factors being additive but suspected that was wrong. I am troubled (yes troubled!) by the statement that 'the physics system comes in and resolves the forces holding them together'.

How? What does that mean? That attached objects duke it out and the one with the largest maximum_drag wins? Newton\'s 3rd law doesn\'t apply between them? Or that accelerations are calculated separately and a weighted or unweighted average of them is taken? (Minus points on a physics test for anyone who does that).

If objects 1 and 2 are attached and the drag force on each computes to b₁v² and b₂v² respectively, doesn\'t that make the combined drag force just (b₁ +b₂) v²?

If you can offer any insights as to how to calculate the drag factor for an assembly of objects I\'d appreciate it - it would save some tedious experimenting.

And it may be time for Harv to weigh in (get it?) on how drag is actually calculated.

[Hypocee]

There\'s force 1 on part 1, and force 2 on part 2. If those forces differ in magnitude or direction there\'s a resultant force 3 on the joint between the two parts. So yes, the overall force on the ship is simply the sum of the two, but if they have different Cds you get moments, tension/compression, excitation and disintegration; 'the ship' is not necessarily the object of interest.

Right now everything is entirely transparent to drag - from the atmosphere\'s point of view the ship is an open lattice of dimensionless drag points. HarvesteR\'s taken one or two half-attempts at a decent fairing effects model, but it\'s proven to be highly nontrivial and been postponed until time can be dedicated to it rather than improvised between release-oriented tasks. Either the .13 or the .14 thread\'s got about 8 pages of the latest peanut gallery session somewhere inside

[closette]

@Hypocee,

The 'system' of the ship is my object of interest, and should be easiest to analyze. Newton\'s 3rd law guarantees that forces between components (1 on 2 and 2 on 1) cancel out for the ship as a whole, although they can produce big torques as you point out.

But since you are saying (I think!) that the orientation of the spacecraft doesn\'t matter in the current model, can I just find the total aerodynamic force by adding the maximum_drag factors, and multiplying those by 1/2 * atmospheric density * v²? Regardless of torques, as long as the spacecraft is a rigid body, I can use that to find the instantaneous acceleration of the center of mass from Newton\'s 2nd law.

Iskierka above implied that I cannot just add drag factors, and my layperson\'s observation that all my bits and pieces fall together, regardless of size, seems to accord with his take.

Or are there other parameters that come into play from the parts file, such as minimum_drag and angularDrag?

I trust that the developers will come up with more realistic model of drag in the future. But for now, someone please just tell us how to calculate the multipler of v² to get the drag force for some assembly in 0.13.2!

Perhaps an example of command module+stowed parachute+liquid fuel tank+liquid fuel engine would help to illustrate, and would make for a good drop test to compare theory and practice.

[Kosmo-not]

I\'ve calculated the relation that maximum_drag has on terminal velocity at KSC ground level. I haven\'t figured out a way to fit it into the bigger picture to figure out things we don\'t know for certain yet. But, I think every little bit of info helps.

V_t=45.519/sqrt(maximum_drag)

Remember that this is for terminal velocity at the KSC ground level.

[closette]

Hi Kosmo,

Using your data I fitted terminal speed of the pod as a function of altitude to be given by v_T = 97.8 m/s Exp (altitude / 9900 m), which agrees closely with your sea-level value of 101 m/s, but I\'m not sure how this applies to other objects.

Did you get your maximum_drag relation from just the command-module\'s sea-level terminal speed and scaling appropriately from its maximum_drag of 0.2? Or did you actually establish it from measuring the accelerations of other falling objects with different drag factors and verifying that in practice the relation holds true? Because I don\'t think we can assume that at this stage with a suspect drag model.

And the question remains as to how assemblies of objects behave.

[Kosmo-not]

I used a command module with which I modified the maximum_drag factor. I still gotta try doing a 1km orbit around Kerbin. Should be fun. I took different speed readings upon crashing (or landing) with maximum_drag factors of 1000, 500, 100, 50, and 10. I\'ll probably go up again with a factor of 50 and test at different altitudes.

*edit* I should have attached the excel file.

[closette]

OK, interesting experiment! Not sure if editing parts files has the same effect as combining parts though - that\'s a behavior which I bet is deeply buried in the code.

And please be aware that the impact speed may not be the terminal speed if the module is still speeding up or slowing down before impact, although for the very high drag factors you are using I bet that the residual accelerations are small.

[Kosmo-not]

The net acceleration is so small, that it take a while for it to change by 0.1 m/s. So, it\'s effectively measuring terminal velocity.

[closette]

Roger on the terminal speeds, and thanks for the Excel data. Square-root dependence on maximum_drag in the parts file CON-FIRMED!

Could you try crashing your modified pod with another, unmodified part attached such as a fuel tank or SRB? It would be interesting to see if the combination of drag factors of (say) 100 and 1.0 behave the same as a command module with drag factor 101, or 50.5, or some horrendous mass-weighted average perhaps.

[Kosmo-not]

I\'m wondering if the devs decided to make area directly proportional to mass. Doubling the mass in this case would double the drag force, provided maximum_drag is constant. We already have the evidence that 2 fuel tanks fall at the same rate regardless of mass. If this is true, we can say the drag equation is:

F_D=.5*density*velocity^2*maximum_drag*mass

[closette]

That\'s the equation I was assuming, and Izkierka and Hypocee confirmed it above and in previous threads. It is a 'bug' or a feature of the Kerbal world that does not exist in reality. It results in a full and empty tank both falling together, as observed. But how it extends to an assembly of parts is the question that I cannot seem to get a straight answer to!

[Kosmo-not]

I just did a test and calculations...

F_D=.5*density*velocity²*(max_drag₁*m₁+max_drag₂*m₂...)

My experiment involved finding the speed at which a capsule with chute deployed will land at KSC. As you know, the chute has a max_drag of 55 when deployed, which is vastly different than the capsule. Plugging everything in, with density being roughly 0.00972 at ground level, you come out to a velocity of 12.5 m/s, which is the speed the capsule hits the ground at.

[closette]

You beat me to it, Kosmo (honest!). Thank you so much!!!

I was doing something similar with cfg-edited pod (your idea) and a set of cfg-edited stack decouplers, both with large but different maximum_drag hacks. Drop a pod (sans parachute, I forgot about that the first time!), then pod +1 decoupler, pod +2 decouplers etc. and measure their terminal speeds.

I\'ll still finish my tests, just not this weekend (busy). But your equation makes sense (in the Kerbal world) and, combined with the atmospheric density profile:

density ~ 0.01 Exp(-height/5000 m) kerbal mass units per meter^3*,

this finally allows users to compute drag force, terminal velocity and optimum ascent speed (which is close to terminal speed) for their ships as a function of altitude. Nirvana!

^* I define the command pod to have mass m=1 kerbal mass unit, as shown in the VAB display. This might be 1 kg or 1000 kg, or something in between. The drag force computed from the equation has the same units as rocket thrust as given in the VAB display.

[Hypocee]

@Hypocee,

...

But since you are saying (I think!) that the orientation of the spacecraft doesn\'t matter in the current model, can I just find the total aerodynamic force by adding the maximum_drag factors, and multiplying those by 1/2 * atmospheric density * v²? Regardless of torques, as long as the spacecraft is a rigid body, I can use that to find the instantaneous acceleration of the center of mass from Newton\'s 2nd law.

Iskierka above implied that I cannot just add drag factors, and my layperson\'s observation that all my bits and pieces fall together, regardless of size, seems to accord with his take.

You can simply add all the forces. I don\'t think that\'s the same as just adding the factors - you may be looking at an arithmetic mean...? Weighted by mass...? Beyond my comprehension.

[closette]

@Hypocee,

From Kosmo-not\'s clever experiments above it looks like the total drag force comes from a mass-weighted sum.

The fact that most of the big parts\' drag factors are similar, ~0.2-0.3, explains why mass pretty much cancels out when finding terminal (or optimum ascent) speeds, which is why a bunch of big and small things released at high altitude will all fall almost together, unlike in reality.

I intend to write this up, with due credit to those who did the work, for the Kerbal Space Wiki, and include a full analysis of optimum Thrust/Weight ratio for ascent in there too, which I know you were looking for. I just have to block out a peaceful afternoon.

Your replies to my questions on this and other threads have been extremely helpful.

[Kosmo-not]

Well, that was fun. Which problem shall we tackle next?

[closette]

Your choice! (But it should be in a new thread I think). Possible suggestions off the top of my head:

- Optimal descent and landing from circular Munar orbit (although that\'s a bit spacecraft-specific, fuel/mass ratios and so on). There\'s already a thread for that which we have both visited.

Or, using our known model for atmospheric drag (can I call it ours?)...

- Flight profile to spot land back near the KSC (or anywhere else, first on the equator, later at any point) from an equatorial circular orbit around Kerbin, say 80km, or 160 km (so that one can warp faster).

I\'m off for a long drive to SpaceUP San Diego for the weekend. I\'ll be talking up all this cool analysis to anyone who will listen or sit next to my laptop for 5 minutes!