the drag of parts

[OHara]

Let's collect the facts we've reverse-engineered from KSP's drag model,
that we sometimes need to know when playing KSP.

By convention, people describe drag, the force opposite the airspeed, as a product
   D = ½ ρ V² A C_d
for an object with frontal area A, in m², moving at speed V (m/s) through air with density ρ (1kg/m³ at sea level). The coarse dependence on speed, etc, is factored out leaving the more subtle dependence on speed in a coefficient C_d.  C_d is dimensionless, independent of the units of measure, and is near 1.0 for a brick, near 0.1 for a needle pointed into the airflow. For the frontal area A of a part, KSP uses its silhouette that you would see if it were heading directly toward you.

C_d depends on the orientation of a part in the airstream. Interesting shapes like wings have Cd depend in a complicated way on orientation, but the simplest dependence is
   D = ½ ρ ( V_x² A_x C_d,x + V_y² A_y C_d,y + V_z² A_z C_d,z )
with V_x, etc., being vector components of V.

Starting with the overhauls for 1.0, KSP stores silhouette areas and drag coefficients for x, y, and z directions, and also distinguishes +x and −x, etc., because it treats leading- and trailing- sides differently.  Nearly all the parts have default orientation with y along the direction of usual motion. These are in the lists of numbers after the DRAG_CUBE entries (example in spoiler) in PartDatabase.cfg.

Spoiler

// Example drag cube from the Mk2 pointy cockpit
//         (m²)        (m)  units
//  state, Area, Cd0, depth;
cube = A, 4.56, 0.55, 1.34, // XP pilot's right
          4.56, 0.55, 1.34, // XN pilot's left
          2.53, 0.20, 4.60, // YP forward
          2.53, 0.96, 0.61, // YN rear
          7.61, 0.87, 0.87, // ZP top (hatch side)
          7.61, 0.86, 1.09, // ZN bottom
// The model fits in some box.
// In the x,y,z coordinates of the model, here are
          0.00, 1.02,-0.01, // x,y,z of center of bounding box
          2.50, 4.53, 1.53  // dx,dy,dz dimensions of bounding box
//         (m)   (m)   (m)  units of measure
// For purposes of shielding reentry heat, the 'depth' entries say
// how far the widest feature of the part, from each point of view,
// lies behind the wall of the bounding box.

 

KSP figures the leading-face drag a little differently than I would have thought:
   D = ½ ρ V ( V_x A_x C_dx + V_y A_y C_dy + V_z A_z C_dz )           (plot versus AoA at right is from Boots' Kerbal Wind Tunnel mod)
An Mk2 cockpit has very low C_dy along its normal direction of motion, but its large flat bottom has large A_z and large C_dz.
If I'm flying with 6° AoA, nose at a slope of 1:10 to the relative wind, V_z = 10% V, then KSP gives me 10% of the drag I would feel at 90° AoA.  This feels too much; maybe the total force is about 10% the maximum, but some would be lift not all drag. I would expect the drag  on the bottom '−z' face to get a factor (V_Z/V)², just 1%.   (So for Mk2 spaceplanes in KSP, rotate your wings to some angle of incidence so you can fly with the nose exactly prograde.)

To model the dependence of drag on airspeed, beyond the simple V² factor, KSP multiplies the leading and trailing surface drag coefficients by numbers from curves defined in physics.cfg.  You see in the plot the sound barrier and how the trailing face matters less after flow separates.

Strangely, the A×Cd of the side surfaces is used, with a much lower mach-dependent multiplier, to model skin-friction drag. This has the odd effect of putting less drag on un-faired engines within a stack, than those with a fairing, because the fairing shows more area than the engine and doesn't get a realistic Cd for the skin-friction geometry.  Usually this is <10% the total craft drag.

The Cd0 values in the drag-cubes look like they were originally coefficients of drag in the low-speed limit. Starting around version 1.2, they are adjusted; first with a look-up curve that emphasizes the benefit of pointy low-Cd0 parts, and then by raising that Cd to a power (!) making the benefit of pointy parts extreme at supersonic speeds. Thus Mk2 cargo bays can, at high mach number and with some AoA, show a bit less drag when open than when closed. Opening them increases the area A_z by 50%, and decreases C_dz slightly, but the version-1.2 adjustments emphasize that slight reduction in C_dz enough to dominate over the increase in area.

When parts are attached at the green-ball 'nodes,' KSP reduces the drag at the mating faces.
    protected( A_y C_dy ) = A_y C_dy − A_y,mate × 1  or zero if the math gives a negative.
Often the mating faces are flat, with C_d near 1, and pointed straight into the airflow, so adding a C_d=0.2 nose-cone is important.

The full area of the silhouette of the protecting part is removed, so a tapered tank can shield is larger area, no matter which way it is oriented.  This quirk means that enabling the fairings on engines in a stack is not important, because KSP considers the trailing decoupler to be fully protected in any case.

Strangely, parts attached to all nodes pointing in the direction of a face, will count as shielding that face.  So a part on the inside node on the floor of a service bay (even though that part and the inner wall of the service bay are contribute zero drag when the bay is closed) counts as covering the exposed area of the roof of the service bay.  This makes no sense, but is useful if the service bay is larger than the part attached to its top.

Offsetting parts after connecting at nodes leaves the drag model unchanged.  Rotating parts after connecting leaves the originally-mating faces protected, but can change the remaining surfaces from leading to trailing faces -- thus the exploit of rotating nose-cones to reverse orientation, so they get the lower tail drag at supersonic speeds, fooling KSP into thinking no part gets the brunt of the airflow.

Surface-attached parts, by contrast, are treated as if separated from the craft, moving through the air in parallel to it.  They neither protect the part they are attached to, or receive any protection from drag. 

EAS-4 struts add no drag, just mass at the location of the part their first end connects to.

Fairings and cargo bays and service bays (parts with a ModuleCargoBay in their configuration) protect anything inside them from heat and drag, whether attached at the green 'nodes' or to surfaces (developer article). Beware, however,  a bug if the bay is the root part. KSP determines which items are 'inside' every time we load a save,  switch to the craft, dock or undock, or open or close the cargo bay.  For all parts within a defined 'lookupRadius' of a 'lookupCenter' defined in the cargo bay's cfg-file, KSP checks if the center of the bounding box around the visible part is inside the walls of the bay; if so the part gets zero drag and zero compression heating, and is prevented from usefully interacting with the outside.  This method can cause trouble with landing gear mounted to a cargo bay, because their center will shift when you raise the gear and might go inside the bay, so there is an option 'deploy shielded' to let KSP know it should allow you to lower the gear.

Most parts get their A and Cd0 in an automatic way from their model---the model we see, not the often-simpler collision mesh.  
When there are holes all the way through a part, which would be closed up when the part is in a stack,  the automatic calculation gives a small Ay, discounting the hole, and the next part in the stack is treated as if hit with airflow rushing through said hole.  The Structural Tubes from the Making History mod is an example of this going wrong.  Modders need to put a custom drag cube in the cfg file of the part showing the full cross-section as blocked to airflow.

1.25-meter parts vary a bit from the π(1.25m)²/4 area you would expect.  When a bigger area sits behind a smaller, behind a bigger, behind a smaller, each step up in area gets drag with Cd near 1. Sorting parts by area, where feasible, can make a noticeable improvement.  

Edited January 12, 2020 by OHara
removed error: the fairing/clean distinction still works for parts that have it in the cfg

[FleshJeb]

@OHara Are you able to explain these lines in the part configs? This particular example is the Mk1 LF tank. I’ve always wondered why the min is larger than the max. I assume the first line is for the auto-generated A and Cd0.

dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.3
angularDrag = 2

[OHara]

7 minutes ago, FleshJeb said:

these lines in the part configs?

I think minimum_drag and maximum_drag are leftover from the 'souposphere' before the overhauls for 1.0.  There may still be an option in KSP settings to go back to the old method.

Edited March 4, 2019 by OHara

[FleshJeb]

15 minutes ago, OHara said:

I think minimum_drag and maximum_drag are leftover from the 'souposphere' before the overhauls for 1.0.  There may still be an option in KSP settings to go back to the old method.

Heh, I should try that. It was less “interesting”, but way more fun. Also it was  much kinder to those who design intuively as opposed to us spreadsheet jockeys.

[MrSystems]

11 hours ago, OHara said:

When there are holes all the way through a part, which would be closed up when the part is in a stack,  the automatic calculation gives a small Ay, discounting the hole, and the next part in the stack is treated as if hit with airflow rushing through said hole.  The Structural Tubes from the Making History mod is an example of this going wrong.  Modders need to put a custom drag cube in the cfg file of the part showing the full cross-section as blocked to airflow.

Fantastic info! Thank you for sharing.

I have a question specifically as concerns structural tubes and custom drag cubes. If I wanted to write a custom ModuleManager cfg to fix the tubes, what ought the custom cubes to look like? My PartDatabase.cfg shows the following for the shortest length of the 1.25m tube (annotated as in your example above):

Spoiler

// 1.25m tube
	//	Area   Cd     Depth
cube = 0, 	0.7813,0.7782,0.7051,	// XP right
		0.7813,0.7782,0.7051,	// XN left
		0.2105,0.9583,0.1003,	// YP forward
		0.2105,0.9583,0.1003,	// YN rear
		0.7813,0.7779,0.7051,	// ZP top
		0.7813,0.7779,0.7051,	// ZN bottom

//		X       Y       Z
		0   ,-0.3125,0, 	// bounding box offset
		1.25, 0.625 ,1.25	// bounding box size

 

Is the problem that the area in the YP and YN dimensions is only PI × (outer_radius² – inner_radius²) when (if the rocket is in a stack) it ought to be PI × outer_radius² (thus 1.227 for the 1.25m size, despite the fact it's 1.217 in all the PartDatabase listings for the other 1.25m parts)?  And am I correct in thinking a mod with this "fix" would break (odd, rare) cases where a series of hollow structural tubes with no nose and no tail is used?

A second question: how is drag at the trailing edge calculated? 

On a related note, (thanks to you I now know how to read the drag cubes and where to find them) I dumped all the cubes from my install into a spreadsheet and sorted them by Cd_YP. Drag coefficients for leading-edge parts, and some oddball parts that outperform leading-edge parts, include:

Spoiler

• winglet, Cd_YP = 0.06919
• wingShuttleStrake, 0.09556
• Size1p5_Tank05, 0.1723 (this is the radially-attachable FL-C1000 tank from Making History)
• CanardController, 0.1791
• AdvancedCanard, 0.1904
• mk2Cockpit_standard, 0.1996
• landingleg-pod-1, 0.2057 (from Near Future Spacecraft)
• basicFin, 0.2101
• wingStrake, 0.2125
• Mark1Cockpit, 0.2305
• tailfin, 0.2436
• sweptWing, 0.283
• shockConeIntake, 0.3000
• pointyNoseConeA_1p5, 0.3045 (from Missing History; oddly better than the stock pointy nose cone)
• noseCone, 0.3215
• rocketNoseCone_v2, 0.3478 (the stock 2.5m "Mk7" cone)
• standardNoseCone, 0.3672 (the stock 0.625m version)
• ramAirIntake, 0.3750
• noseConeAdapter, 0.3752
• Size3_Size2_Tank, 0.3930 (deprecated MissingHistory part, "Kerbodyne S2-S3 Adapter Tank (Deprecated)")
• miniIntake, 0.4000
• avionicsNoseCone, 0.4074
• mk3Cockpit_Shuttle, 0.4245
• Size3To2Adapter,  (stock "Kerbodyne ADTP-2-3" fuel tank, versions 1 and 2)
• pointyNoseConeB, 0.4482
• probeCoreSphere, 0.4488 (Stayputnik)
• CircularIntake, 0.4500
• mk1pod_v2, 0.4621
• parachuteSingle (packed), 0.6401 (Mk16 Parachute)
• parachuteLarge (packed), 0.7296 (Mk16-XL Parachute)

Noteable takeaways from the data above include:

• Never use a Type-B nose cone
• The Mk1 Cockpit makes a better nose cone than any of the 1.25m nose cones
• Always use radially-attachable parachutes

[MrSystems]

The OP inspired me to do a bit of testing on 1.25m nose cones.  My methodology was: start with a flea set to 23.5% thrust (pad TWR ~ 2.11), top with a RC-001S pod, an FL-T100 fuel tank, and various nose cones. I adjusted the fuel in the T100 so the launch mass would be the same each time (2,172 ± 10 kg). I launched straight surface-relative Radial Out from KSC and measured the apoapsis achieved.  The maximum speed achieved was about Mach 1.3, so the results should extrapolate to actual rocket launches.  The results were:

•   8,580 m, no nose cone (bare FL-T100). (Interestingly, the amount of drag from the Flea was the same as the drag from the T100)
•   9,551 m, MK16-XL parachute
• 12,067 m, Advanced Nose Cone Type A
• 12,475 m, Small Nose Cone resized to 1.25m using TweakScale
• 12,844 m, Aerodynamic Nose Cone (the blunt one)
• 13,702 m, Small Nose Cone on top of an FL-A10 fuel tank
• 14,063 m, Tail Connector A
• 14,611 m, Small Nose Cone on top of a "C7 Brand Adapter - 2.5m to 1.25m" fuel tank resized using TweakScale

Of the four best options, SNC with empty scaled-down C7 has a mass of 81 kg, SNC with FL-A10 has a mass of 60 kg, Tail Connector A has a mass of 200 kg, and the Aerodynamic Nose Cone has a mass of 30 kg.  So I might conclude:

If you have TweakScale, use an empty C7 with the Small Nose Cone; otherwise use the Aerodynamic Nose Cone (the blunt one). Also, a mod-maker could improve the stock parts selection by creating a nose cone with the same profile as the C7/SNC.

[OHara]

10 hours ago, MrSystems said:

a custom ModuleManager cfg to fix the tubes,

There is a cfg file  at the bug tracker report 19376 about the Structural Tubes.

10 hours ago, MrSystems said:

Is the problem that the area [...] ought to be PI × outer_radius² [...]
this "fix" would break (odd, rare) cases where a series of hollow structural tubes with no nose and no tail is used?

Yes, and yes --- but of course that odd case is one where the original approximation of A=silhouette_area and Cd=1 was an underestimate.

10 hours ago, MrSystems said:

how is drag at the trailing edge calculated? 

All I know about that is already said above.  The area and Cd in the YN entry (or whichever is the trailing face) times the different sped-dependent multiplier (that drops at high mach number) goes into D = ½ ρ V² A C_d

10 hours ago, MrSystems said:

Always use radially-attachable parachutes

At first I was skeptical because radially-attached parts have drag, too, but looking at the numbers I see your point.  The similar-deployed-size radial chutes have a very small area facing the wind, small enough that their drag is less than what you can save by using a pointy nosecone in place of nose-parachute.

Edited March 5, 2019 by OHara
splng

[Loskene]

So basically what you're saying is they should make FAR stock. I couldn't agree more 

[OHara]

I really do think that FAR's simulation of airflow around the whole craft works great --- surprisingly well in a lego-style craft-building game like KSP (maybe KSP 2). 

You would think that computational fluid dynamics would be too time consuming for a game, but FAR re-computes its voxels only when needed. I have no bothersome lags on my PC.  Consoles might have to pause, though, whenever a cargo bay opens/closes within an atmosphere.  Spaceplanes are more difficult in FAR as it comes, but tweaking the lift-vs-mach curve there would be just as easy as it was on stock, and no harder for hard-core players to un-tweak.

Some of this might be the grass looking greener on the other side of the fence.  I've used FAR much less than stock aero, and since more people try more strange things in stock, we also see the bugs they notice, here on the forum.  Somebody suggested FAR for the bug with Kerbals in chairs  and I found that FAR doesn't even try to handle drag of seated Kerbals.  Mod parts need well-made models or custom configs for FAR, but that is true of stock aero as well. (See the PartDatabase.cfg entry for the new aerodynamicNoseCone, for example.)

Given that most people use stock aero, and that the current art-pass focus of Squad is causing some degradation, I think we players will do better to collect what we know about it, to either fix our own problems, complain armed with facts, and/or embarrass Squad into action if needed.

Edited March 6, 2019 by OHara

[MrSystems]

On 3/5/2019 at 12:41 AM, OHara said:

There is a cfg file  at the bug tracker report 19376 about the Structural Tubes.

Thank you. I'll take a look.

On 3/5/2019 at 12:41 AM, OHara said:

The area and Cd in the YN entry (or whichever is the trailing face) times the different sped-dependent multiplier (that drops at high mach number) goes into D = ½ ρ V² A C_d

Thank you again.

I was curious what the most- and least-draggy parts were for the back end of a rocket, particularly as regards engines. Sorting first by diameter and then by Cd_YN×A_YN, I found the following: (note this is for parts in the ordinary prograde orientation, and sticking for instance a nose cone pointing backwards on the butt end of the rocket isn't considered an option in this analysis)

Spoiler

• 0.625m:
  • best: miniJetEngine (Juno), liquidEngineMini (Spark) (twice as draggy as Juno) 
  • worst: probeCoreHex, probeCoreOcto, Separator_0, Decoupler_0, HeatShield0. All about 33% worse than a bare fuel tank
• 1.25m:
  •  best: airplaneTail, by far. 1/3 the drag of JetEngine ("Wheesley"), Near Future LV Kite, NF Spacecraft LV-601, MissingHistory Valiant. The best stock engine of this size is the SSME (Vector), followed closely by the Terrier
  • worst: Decoupler, Separator, advSasModule (Advanced Inline Stabilizer), ServiceBay_125, HECS2_ProbeCore
• 1.875m: 
  • best: LiquidEngineRK-7 (Kodiak) in the default bare configuration. Skiff (Bare cfg) and Bobcat (Tank Butt cfg) are close behind (but 
  • worst: probeStack_1p5 (from MissingHistory), HeatShield1p5, ServiceBay_187 (MissingHistory), reactionWheel_1p5 (MissingHistory)
• 2.5m: 
  • best: NFLV Osprey (default cfg), NFLV Buzzard (default cfg), MakingHistory Mastodon Bare cfg, Mastodon Mid cfg.  The Skipper and the Mastodon default cfg are each about 50% draggier than the others listed.
  • worst: ServiceBay_250, cupola, HeatShield2, probeStackLarge (RC-L01), Large_Crewed_Lab
• 3.75m: 
  • best: Rhino
  • worst: Separator_3, Decoupler_3
• 5.0m: 
  • best: SpaceY-Lifters Heavy Moa, SpaceY-Lifters Super-Ratite
  • worst: pretty much all the other 5m stock and SpaceY parts
• mk2:
  • best, Mark2Cockpit.
  • worst, mk2CockpitInline (only slightly worse than all other mk2 parts that aren't the pointy cockpit)
• mk3:
  • best, mk3CargoRamp.
  • worst, mk3CargoRamp in open position

 

[VMQ]

On 3/4/2019 at 1:02 AM, OHara said:

Let's collect the facts we've reverse-engineered from KSP's drag model, that we sometimes need to know when playing KSP.
...
Missing kspDragPost121.jpg
...
Missing generousProtection.jpg

@OHaraThank you for this nice explanation! It seems over the last years two pictures went missing. Could you bring them back? Or is there a follow up article somewhere?

[OHara]

4 hours ago, VMQ said:

two pictures went missing

Oops.  They are restored now.