Drag Calculations

[arthur106]

I've been combing through the forums trying to find out exactly how KSP calculates drag and have come across some helpful posts.  It seems that the method has changed substantially with new versions of the game, so I'd like to summarize my understand of the current system (please correct me where I'm wrong) and ask a few questions as well.

Because I'm stating a lot of my assumptions (which may or may not be true) and asking questions, I'll place the questions in bold font for readability.
I understand the basic formula is the 1/2*rho*v^2*Cd*S where rho is atmospheric density, Cd is coefficient of drag, and S is exposed surface area.  I also understand that the game has some some mechanic to determine Cd based on drag cubes and the part construction.  Furthermore, there is a Cd multiplier for leading faces, side faces, and trailing faces; this multiplier is dependent on mach number (is it dependent on anything else?).  I saw some plots of this a few days ago, but at the time of writing this, I can't find it.  Can anyone point me to the game file where this information is stored?

The whole "drag cube" concept seems somewhat odd to me.  How do you model the side faces of a cylindrical part with a cube?  Imagine you have a perfectly cylindrical fuel tank flying through the air and it is travelling in a direction parallel to it's axis of symmetry.  Now, lets examine two cases in which its attitude is perturbed by a small number of degrees "theta"; first in a direction towards the center of one of the side drag cube faces (such that one side face is exposed), then in a direction towards one of the corners (such that two sides faces are exposed).  The actual fuel tank would care which direction it had been perturbed, as it is axially symmetric.  The drag cubes, however, are not.  The latter case would result in more exposed surface area than the former.  Is this how the actual calculations work?

Going back to the mach-based multipliers for the Cd.  Does anyone know how the values given in the game file are interpolated?  (linearly, quadratically..)

How are these multipliers applied?  If I'm in a rocket, ascending straight upwards, it's obvious that the leading multiplier is applied to the leading face, side multiplier to the side faces, and so on.  But what if I have a non-zero AoA?  Now there are two components of velocity, "mainstream", and sidestream, causing "drag", and "sideforce", respectively.  Does the game do multiple drag calculations (treating the side of the rocket as a side face when resolving drag and as a leading face when resolving side force?)

I read somewhere that they swapped surface area with mass???  That doesn't seem very intuitive.  Does this still exist?

Any light that can be shed on this would be extremely helpful and much appreciated.  Thank you in advance.

My goal is to understand the methods the good people at Squad used so I can use this information to write accurate scripts for KOS.  The first one would launch a rocket and perform a series of simple maneuvers, varying altitude, airspeed, and attitude to either A. determine an "equivalent drag cube" for any given spacecraft or B. use a simple neural net to accurately predict drag based on inputs (pitch, yaw, roll, speed, temp, pressure).  I'll then use the ability to very accurately predict drag to create ascent profiles and then scripts to follow them.

Edited April 8, 2020 by arthur106

[Xyphos]

in old versions of the game, if you put a part on your vessel, it had drag effect no matter what, even if it was in a stack attachment, it behaved like it wasn't
later, drag cubes where added and calculations were put in place to determine if the drag should be applied/multiplied, etc but this proved to be suboptimal and caused lag.
fast forward to present, the last I heard, the drag cubes aren't used anymore, or at least don't behave as they used to.

I haven't tested it, but I theorize that the drag is the surface area of the part like you said, and the drag cubes simply add a "tweaking" mechanic to the drag model.

if you do some experimenting with the surface area formula and compare your results to other test cases, I'm sure you'll find some sort of pattern and/or formula.

Edited April 9, 2020 by Xyphos

[CBase]

Okay this might get a longer post, so first I like to give overall structure:

1. Prograde Drag
2. Drag Cubes and Angle of Attack
3. Special cases I am aware of

Before I start, let me point out that all of my knowledge I got from reading posts, working on Trajectories addon for my personal need and finally some reverse engineering when documentation was sparse or outdated: Only KSP holds the truth for stock aerodynamics ;-)

Prograde Drag

Drag is created by motion and always opposite of the surface velocity. Therefore air sees your object from a single side: Opposite of velocity. For simplicity first lets assume you are flying perfect prograde.

Real Drag is gets very comlicated once air get turbolent. As long as it is laminar, the newton equation you found is a very good approximation:

On 4/9/2020 at 12:50 AM, arthur106 said:

1/2*rho*v^2*Cd*S where rho is atmospheric density, Cd is coefficient of drag, and S is exposed surface area

KSP does basically this for every single part and then adds up all the drag from the parts with respect of the point, so asymmectrical drag will turn the object.

Let us take a moment and think how S and Cd are derived:

The exposed surface area is the surface projection of the part in the plane normal to direction of drag. So going to your cylinder example: from sideways the surface area is a rectangle with surface area of length * diameter of your cylinder. For constructs KSP subtracts the opposing surface area of parts attached via nodes. In Stock KSP nothing else.

The drag coefficient Cd is holding all information about the shape when looking at the object in the direction of the drag, really look up https://en.wikipedia.org/wiki/Drag_coefficient to understand Cd. This is the answer how a flat surface rectangle can model your round cylinder drag. Especially for flat backsides turbolences are the true reason for their higher Cd value, so by clever calculations of Cd you get more realistic than the original assumption.

Cd and S are usually calculated by Unity from the parts model when loading the game assets. ModuleManager caches these part values in case you want to look them up.

In the theory outlined on wikipedia the Cd value includes drag contributions from all sides of the object: Front, side and backside. Since constructs can modify for instance the backside by a pointy cone, KSP splits real world Cd into contribution by side and via multipling with exposed surface area only relevant contributions are counted.

Now we have an understanding for prograde drag using Newton drag approximation.

Newton drag has its limitations: Once you get close to the speed of sound (mach 1) drag changes a lot and when the laminar assumption fails you need to modify your calculations. KSP does both of this by applying a factor for each to the calculated drag, one is a function on mach number, the other a function on a pseudoreynolds number which is rho * v. The actual functions are parameterized curves, since they are exposed in the API for Addons, I never cared to explore them more.

So still for prograde drag we are at: 1/2*rho*v^2*Cd*S*f(mach)*f_reynolds( rho*v)

Drag Cubes and Angle of Attack

So far the natural orientation of our object and the flat surface defined by the drag vector as normal were perfect aligned. Of course we could calculate Cd for any object orientation (remember that Unity does this on loading), KSP choosed to only do this for all 6 perpendicular sides of an part, which forms the Drag Cube. If you want to create a mental model of this drag cube, do this as rather wireframe with scaled surface cross sections painted on the sides.

Before I mentioned only a f(mach) function which is now split into 3 different functions depending on the orientation of our cube face: f_front(mach), f_back(mach), f_side(mach).

In order to get the resulting drag KSP calculates the normalized dot product of velocity and each cube faces normal, which is basically the cosinus of angle of attack for each cube surface. Depending on the angle it uses this cosinus to linear blend between f_front(mach) and f_side(mach) or f_back(mach) and f_side(mach). Since sideway modifiers are smaller, drag is smaller if the angle of attack for a surface is higher.

Special cases

Most obvious case: If the part is shielded inside a cargo bay or fairing it has no drag.

Some parts like struts or fuel lines have simplified constant drag values instead of Drag Cubes.

Parachutes nowadays have Drag Cubes for each state (packed, semi deployed, deployed), but ommit the area occlusion and chute direction is independent of part.

I did saw some special case code for very low drag situations, but never cared enough to investigate further.

All lifting surfaces (wings, control surfaces) do calculate drag completely different, mostly dependent on a function of cosinus between velocity and wing normal. https://github.com/cbase2/KSPTrajectories/blob/master/src/Plugin/StockAeroUtil.cs has all wing calculations if you are interested, the official repository from neuoy has them more obscured via KSP function codes which has some side effects on using the current orientation.

 

 

[arthur106]

7 hours ago, CBase said:

Drag is created by motion and always opposite of the surface velocity.

 

 

 

Does the game use velocity relative to the velocity of the surface directly below you, or the velocity of the surface projected to your current altitude?  I realize that's a bit confusing, but I thought about it for a few minutes and that's the best explanation I could come up with...  For example:  at the equator, the surface velocity on kerbin is ~175m/s.  If we go up 50km, however, the velocity would be ~190 due to the larger radius.

Forgive me if I missed it in you explanation, but are f_mach and f_reynolds independent of individual parts?  or are there separate f_mach and f_reynolds functions for each part?

[CBase]

10 hours ago, arthur106 said:

Does the game use velocity relative to the velocity of the surface directly below you, or the velocity of the surface projected to your current altitude?

Actually I always assumed that the game uses the correct surface speed for given altitude for drag calculations, the basic methods in CelestialBody are there and these are used in Trajectories addon (simple vector cross product of radius and angular Velocity).

However Trajectories never got Drag 100% right and I never understood why, so I looked into this part of the game and to my surprise something complete different was there: It seems the game splits movement between Unity (only mionor part) and internal handling in Krakensbane Class, which as the name suggests fixes vessels being ripped apart by the Kraken. However the difference is very small from a test, so in respect of your question the answer is: Yes the game uses the correct rotational surface speed for each altitude.

10 hours ago, arthur106 said:

are f_mach and f_reynolds independent of individual parts?

Yes, sorry for not being clear about this. They are all calculated per part, so you can display them in aero part debug output (which is a good reason to do the same), but the function is the same for all parts.

Edited April 11, 2020 by CBase
updated speed part with additional information