Help on KSP stock aerodynamic model

[aerozine-50]

Hello,

I've been planning to write a program to optimize ascent profiles but without running KSP.

My idea is to write a genetic algrorithm, similar to the work of CheersKevin ([YT Link]),  but it should simulate the dynamic equations without running KSP so the optimization can be faster. While KSP provides straightfoward modeling of the propulsion and masses, I can't wrap my head around the aerodynamics. In order to be able to properly simulate the aerodynamic forces, I need to model both drag (C_D) and lift (C_L)

 

From what I've read it uses this "cubedrag" modeling where each component has a drag area (C_dA) for each direction. The full drag area is a weighted sum of all the faces depending on the relative wind. For instance in a 2D plane, if the relative wind is at 2 degrees of incidence you would have something like: C_dA = C_dA_x cos(2°) + C_dA_y sin(2°).
While this makes kinda sense, I am not sure if the game just accounts for the drag areas that are exposed to the air, or all of them (so including the opposite faces). This is important because in Physics.cfg you can find a set of curves used to correct the aerodynamic data, and some involve the drag areas of faces opposite of the flow.

I've tried to reverse-engineer the code in Kerbal Wind Tunnel mod to better understand the stock aerodynamics, but I'm still confused.
It would be very helpful if you could also explain me the lift model. While the drag data is in the parts file, I can't find anything about the lift data.

 

Thank you very much for your help.

[Cavscout74]

I'm hardly an expert but as far as I am aware, exposed faces are calculated (including the opposite face) while ones covered by other parts (of the same size) are not.  That is why have open nodes front or back are so bad when building spaceplanes.

[OHara]

The Physics.cfg has 'LIFTING_SURFACE_CURVES' that give lift for the airfoils that use ModuleLiftingSurface.  The lift as a function of angle-of-attack is given by a table of 'key's and KSP interpolates between them with piece-wise cubic polynomials.   The only relevant parameter for each part is the area of the wing, with the (inappropriate) name 'deflectionLiftCoeff' in each configuration file.

There is an introductory post about the aerodynamics model here

I posted my reverse-engineering about how drag of parts combine, to give KSP's approximation to drag of the whole
craft, here

19 hours ago, aerozine-50 said:

you would have something like: C_dA = C_dA_x cos(2°) + C_dA_y sin(2°).

KSP does this, but why did you expect a sine and not cos²(2°) and sin²(2°) ?  I am wondering where KSP got that formula.  The force on a face goes as the sine of the angle, yes, but there is another factor of the sine of the angle to take the component of that force in the direction that we call 'drag'.  The drag goes as sine-squared of the angle giving a nice smooth curve (in real life, though not in KSP).

[aerozine-50]

11 hours ago, OHara said:

I posted my reverse-engineering about how drag of parts combine, to give KSP's approximation to drag of the whole
craft, here

Thank you very much for your help. I remember reading your post before making this thread. One thing I haven't understood well is if bodies in KSP generate lift too (like cylindrcal bodies of rockets).
 

11 hours ago, OHara said:

KSP does this, but why did you expect a sine and not cos²(2°) and sin²(2°) ?  I am wondering where KSP got that formula.  The force on a face goes as the sine of the angle, yes, but there is another factor of the sine of the angle to take the component of that force in the direction that we call 'drag'.  The drag goes as sine-squared of the angle giving a nice smooth curve (in real life, though not in KSP).

I think there's a bit of confusion here, but you pointed out I, indeed, forgot the squared term.
I derived that formula from the one you wrote in your thread:

Quote

D = ½ ρ ( V_x² A_x C_d,x + V_y² A_y C_d,y + V_z² A_z C_d,z )

In a 2D plane you could rewrite that formula as (by looking at the image, assuming a dragcube with only +x and +y faces)

D = ½ ρ ( V² cos²(α) A_x C_d,x + V² sin²(α) A_y C_d,y ) = ½ ρ V² (cos²(α) A_x C_d,x + sin²(α) A_y C_d,y)

Regarding real life, in my aerodynamics course I never heard about a sine-squared tendency of C_d with respect to angle of attack. For airfoils the behaviour is pseudo-polynomial, similar to x² . For instance for the NACA 0015:

Other arifoils may have a low near-constant drag region (called laminar bucket) followed by a steep increase of drag outside of it.
While induced drag (which afaik is not modeled by stock aerodynamics, but Ferram does) is proportional to the square of the generated lift.

 

[OHara]

KSP simulates body lift.  There are additional lift vectors, in light blue, visible from the body of a rocket when you enable alt-F12->physics->aero->aeroGui.   There is also a section 'name = bodyLift'  in Physics.cfg.   I never experimented to find exactly which parts have body lift applied, nor what surface-area is used.

KSP does estimate the induced drag.  You can see its value as 'L-I-D' (lift-induced drag) in the 'aero-Gui'.   This appears to be proportional to the square of the total lift of the craft, so represents the energy lost to the wake of the whole craft.  The amount of energy lost, and thus drag, depends on the wingspan of the craft, which KSP does not compute for any other reason.  I remember concluding that KSP uses some approximation that is close to the theory for craft with wings with aspect ratio around 5.   Surely Boots has induced drag in his Kerbal-Wind-Tunnel mod, so he must have computed it or found the API function that returns the KSP's computation.

[KerikBalm]

1 hour ago, OHara said:

The amount of energy lost, and thus drag, depends on the wingspan of the craft, which KSP does not compute for any other reason.

Wait, so KSP does computer wingspan, and it does matter for aerodynamic drag or L/D?

Higher wingspan = better in KSP?

[OHara]

No, you would expect the lift-induced drag to depend on wingspan,
    L-I-D  =  Lift² /Q /π /span²
where Q is the dynamic pressure, but KSP does not consider the shapes of wings.

It looks like KSP uses the total area of the wing parts as a quantity that scales as length².  In a single wing area = chord × span,  so if η = span/chord is the aspect ratio of that wing, then span² = η × area, so they could do
      L-I-D  =  Lift² /Q /π /η /area
for some estimated η, and then they can figure this type of drag for each individual wing component.   Experimentally, KSP does make this type of drag depend on Lift² and Q and total wing-area in this way.

Looking at L-I-D in the aero gui, KSP acts as if η is a function of the mach number, going from about 5 at low speed down to about 1 at mach-1.  I can't find any aspect-ratio-versus-mach curves in the configuration files, though. The induced drag is only noticeable at low speed, parasitic drag dominates when you fly faster, so I just say KSP uses an aspect ratio about 5 to estimate L-I-D whenever I might notice it.

[OHara]

On 6/8/2020 at 3:51 PM, aerozine-50 said:

Regarding real life, in my aerodynamics course I never heard about a sine-squared tendency of C_d with respect to angle of attack. For airfoils the behaviour is pseudo-polynomial, similar to x²

My thinking here is that 'x' is proportional to the angle of attack θ for small angles, as is sin θ.   Wings can have a very flat drag bucket in C_d versus θ,  or a parabolic θ² shape like the NACA airfoil you showed.   KSP's physics.cfg has curves that look parabolic for small angles, and KSP uses sin θ as the independent variable here.

I would expect other parts to also have drag that goes roughly as x² or θ² or sin²θ for small deviations from the cardinal directions.  For large angles, a simple sin²θ is reasonable, is written very simply in terms of componenets, and transitions naturally into the drag for the other cardinal directions.

The v-shaped drag curves we see for fuselage parts seems to be a mistake in KSP, which makes mk2 fuselages very draggy unless we fly them strictly prograde.  I suppose you will need to replicate this mistake to write your optimizer -- unless the optimal ascents always have zero angle of attack.