Negative Drag and/or Lower-than-typical drag at Mach 1 on thin, but blunt, bodies

[mjn33]

FAR version: 2140f457d105be8cb98911b3e1fe9b1ce6a008dd, verified in 76b736ff022cd36209a5db65e328d2bd3d83495c as well, using latest the version of ModularFlightIntegrator

Reproduction steps:

1. Go to the SPH/VAB
2. Load the FARtest3.craft file and launch
3. Throttle to 100%, turn on SAS, liftoff
4. Once at approximately 400 m/s, cut throttle
5. The rocket will disintegrate
6. Switch to the LV-T45 rocket engine that should have survived
7. Wait for the rocket to start falling back, facing in the direction as shown in screenshot13.png
8. Observe that drag will start decreasing, eventually becoming negative

Also something I noticed that may or may not be related to this bug, the following section of code in CalculateVesselAeroProperties is unused:

else if (sonicBaseDrag < 0)
{
    xForcePressureAoA0.Add((float)criticalMachNumber, (-sonicBaseDrag * 0.25f + hypersonicDragForward * 0.4f * hypersonicDragForwardFrac) * lowFinenessRatioSubsonicFactor, 0f, 0f);
    xForcePressureAoA180.Add((float)criticalMachNumber, (-hypersonicDragBackward * 0.4f * hypersonicDragBackwardFrac) * lowFinenessRatioSubsonicFactor, 0f, 0f);

    sonicAoA0Drag = -(float)(cPSonicForward * (curArea - prevArea)) - sonicBaseDrag + hypersonicDragForward * 0.2f;
    sonicAoA180Drag = (float)(cPSonicBackward * (curArea - nextArea)) - hypersonicDragBackward * 0.2f;

    //sonicAoA0Drag = sonicWaveDrag - sonicBaseDrag + hypersonicDragForward * 0.2f;
    //sonicAoA180Drag = -sonicWaveDrag - hypersonicDragBackward * 0.2f;

}

This is because the last line that modifies sonicBaseDrag is the following:

sonicBaseDrag = Math.Abs(sonicBaseDrag);

All files: FARtest3.craft screenshot10.png (static analysis of test craft) screenshot11.png (test craft at 400 m/s) screenshot12.png (engine rising) screenshot13.png (engine falling) screenshot14.png (engine falling faster, drag decreasing) screenshot15.png (lower drag still) screenshot16.png (crossed over into negative drag) screenshot17.png (peak negative drag) screenshot18.png (drag starting to rise again) Player.log (some exceptions thrown in FAR code)

[ferram4]

Fixed with https://github.com/ferram4/Ferram-Aerospace-Research/commit/5f7a1d265ba6a0e2a0389bffd76683d853aa3c47. Definitely needs testing to ensure that no other negative drag situations popped up as a result.

[mjn33]

The LV-T45 doesn't have negative drag anymore, but it still seems to have minimum drag at Mach 1 (screenshot20.png).

So I've added a little bit of code to print out some values in CalculateVesselAeroProperties (https://gist.github.com/mjn33/178dcc665fd6963d0984) in the hope it might be useful, for the LV-T45 it results in the following:

[0]
HDF: -0.51915, HDFF: 0.63933, SBD: 0.06673, HDB: 0.00000, HDBF: 0.00000, CPSF: -0.43471, CPSB: -0.34747
XFP0: -0.17210
XFP180: 0.02163
XFP0: 0.07267
XFP180: 0.17720
[1]
HDF: -0.10565, HDFF: 0.16617, SBD: -0.01511, HDB: -0.31088, HDBF: 0.33563, CPSF: -0.46946, CPSB: 0.13161
XFP0: -0.01400
XFP180: 0.05410
XFP0: 0.11301
XFP180: 0.12313
[2]
HDF: 0.00000, HDFF: 0.00000, SBD: -0.04854, HDB: -0.02806, HDBF: 0.10141, CPSF: -0.16434, CPSB: 0.35968
XFP0: -0.01573
XFP180: 0.00148
XFP0: -0.12465
XFP180: 0.05538
[3]
HDF: 0.00000, HDFF: 0.00000, SBD: -0.00669, HDB: 0.00000, HDBF: 0.00000, CPSF: 0.37479, CPSB: -0.21555
XFP0: -0.00217
XFP180: 0.00000
XFP0: 0.04517
XFP180: 0.01050
[4]
HDF: -0.00170, HDFF: 0.01744, SBD: 0.00122, HDB: -0.00036, HDBF: 0.00612, CPSF: 0.13467, CPSB: -0.57524
XFP0: -0.00002
XFP180: 0.00040
XFP0: -0.00690
XFP180: -0.01577
[5]
HDF: 0.00000, HDFF: 0.00000, SBD: -0.00967, HDB: -0.00479, HDBF: 0.03820, CPSF: -0.30301, CPSB: -0.55895
XFP0: -0.00313
XFP180: 0.00009
XFP0: -0.01866
XFP180: -0.03406
[6]
HDF: 0.00000, HDFF: 0.00000, SBD: -0.01313, HDB: -0.04036, HDBF: 0.25601, CPSF: -0.34758, CPSB: -0.59562
XFP0: -0.00426
XFP180: 0.00536
XFP0: -0.03491
XFP180: -0.03887

I did try bumping up the number of voxels for a single piece of debris to that of a controllable vessel, same result. Also, do you have any ideas for test cases to check if the negative drag bug is fixed / didn't introduce regressions?

Thanks.

[ferram4]

Yeah, I noticed that with the engine. Not sure of the exact causes, tbh.

I'd probably just test blunt objects. Those are the ones where the assumptions are weakest and most likely to break, so those are the ones where things are most likely to have very bad things happen.

[mjn33]

I've found a few more cases of negative drag / low Mach 1 drag. Tested using d036cda14c87ed9ce6e3dd43119e0fec07ee35d1, strict area ruling setting.

FARtest6.craft

This one is capable of negative drag at Mach 1, this isn't visible in the static analysis. Also "Mach 1 Wave Drag-Area" reads negative.

screenshot24.png (static analysis) screenshot26.png (Cd = 1.327 @ Mach 0.341) screenshot27.png (Cd = 0.967 @ Mach 0.514) screenshot51.png (Cd = -0.430 @ Mach 1.137)

FARtest8.craft

This is a variant of the FARtest6, it uses a nose cone on the front and seems to prevent the issue going forwards, however it still experiences lower drag at Mach 1 going backwards.

screenshot29.png (static analysis) screenshot30.png (Cd = 0.768 @ Mach 0.194) screenshot33.png (Cd = 1.021 @ Mach 1.151) screenshot34.png (Cd = 0.629 @ Mach 0.479, backwards) screenshot35.png (Cd = 0.223 @ Mach 1.024, backwards)

FARtest7.craft

Another variant, still experiences lower drag at Mach 1 but it is less noticeable than the FARtest8, same behaviour going either direction.

screenshot39.png (static analysis) screenshot40.png (Cd = 0.528 @ Mach 0.091) screenshot41.png (Cd = 0.490 @ Mach 1.020)

screenshot45.png (Cd = 0.529 @ Mach 0.035, backwards) screenshot46.png (Cd = 0.491 @ Mach 1.009, backwards)

[ferram4]

Alright, so https://github.com/ferram4/Ferram-Aerospace-Research/commit/4d09eaca6d1527dccaa507811eebf0731abc1662 fixes the negative drag issue, but these vehicles still seem to have the low-drag-near-Mach-1 behavior.

Here's what I think is happening: drag near Mach 1 is based off of supersonic slender body theory, which works with the 2nd derivative of area for the shape. Obviously, numerically calculated here. All the vehicles that have problems with this have very sudden changes in cross-sectional area, followed by either a decrease or relatively constant area; this will create highly negative 2nd derivatives. If combined with being near the front of the shape, or the shape being thin enough to prevent any more detail from appearing (as seems to be the case with the structural panels), there isn't an equivalent highly positive 2nd derivative to go along with it. The end result is the front of the vehicle being predicted to have low pressure rather than high pressure.

The correct way to do this is to adapt over the hypersonic predictions for this section. Slender body theory's assumptions are heavily violated by these vehicles, so trying to calculate it for that section just doesn't quite make sense. I'll look into having it be an either-or situation there to rectify this; in the mean time, it's not gamebreaking though.

[complynx]

Hi Ferram4, I suppose, this was the issue of ~30 minutes of failing to exploit autorotation in this video by Scott Manley: https://www.youtube.com/watch?v=2f7mvtS7NOM After that they just disabled FAR and made that work in stock (though not without issues).