search

ferram4 / Ferram-Aerospace-Research

Aerodynamics model for Kerbal Space Program
Other
238 stars 131 forks source link

Miraculously low drag? #159

Open bshepherdson opened 7 years ago

bshepherdson commented 7 years ago

I've got Jeb stranded in orbit right now, because every angle on reentry results in thermal detonation.

The skin temperatures grow without limit, because even as I get down into altitudes like 16-20km, my speed is still increasing and the G-force is 0.002 or so.

I'm using the update branch as of 8864fab. Let me know if the .craft or any other information would help.

Fl4shblade commented 7 years ago

@shepheb Your report is unworkable this way. You need to provide ferram4 with a step by step manual how to get to that point or he can't do anything with it.

ferram4 commented 7 years ago

If you have not installed MM 2.7.5 and MFI 1.2.3, these behaviors would be expected. Most likely the lack of MFI.

If that doesn't fix it, yes, you need to provide craft files, the full output log, full reproduction steps. Remember that leaving out anything, however simple, can hide what is necessary to cause a bug.

bshepherdson commented 7 years ago

I'm running MM 2.7.5 and MFI 1.2.3. Craft file is attached and so is KSP.log.

The craft is a pretty easy-to-fly two-stage rocket with ~4500m/s of dV, easily capable of a low orbit.

Repro steps:

I messed up the staging of the rocket, so it ends up reentering with the Science Jr. and utility bay still attached. I expected them to burn off gradually, and the heat-shielded capsule to survive the landing.

What happens instead is that the lower parts do burn off gradually, but I'm not decelerating at all. As the air gets denser, skin heating from the full orbital speed (now over 2200m/s) destroys the craft. G-force never ticks above 0.003, even as I hurtle below 20km at more than 2km/s.

Let me know if running against FAR only, and/or against the latest version of the branch, would be helpful. I don't think any of the other mods I have loaded impact aerodynamics, except for RealChute, and I was using stock chutes here anyway.

P.S. Sorry for the incomplete report. As an option, you can make the guidelines display automatically when creating new PRs and issues by defining a CONTRIBUTING.md file.

ferram4 commented 7 years ago

Your log indicates that most, if not all, of your vessels are failing to voxelize. You have no aerodynamic forces acting on your vehicles at all. However, following your reproduction steps does not produce an issue for me. Deceleration from an 84 km x -4 km reentry orbit beings at ~40 km.

So, something besides FAR, KER and the MM and MFI dependencies is causing this. I'm going to need more information about what mods you have installed to see if there's a way to trace what's breaking things.

Fl4shblade commented 7 years ago

@shepheb You will be surprised what mods that are supposedly not effecting aerodynamics can cause. I installed BetterBurnTime and it made all of my crafts unusable. They would perform a looping on take-off and crash, no control whatsoever. Turns out in the SPH I could see that the COL marker wasn't in the middle of the craft where it was supposed to be but basically where the cockpit was. So any mod could screw with FAR. You just don't know until you have found the culprit.

andrewcchen commented 7 years ago

I am also having this issue. FAR starts failing to voxelize after playing for some time. The crafts themselves are not the cause as restarting the game makes the same craft voxelize properly again.

Here is the relevant section from the log:

[LOG 16:37:23.519] Updating vessel voxel for Minmus Flyby
[LOG 16:37:23.533] Voxel waiting for chunks to be released

[LOG 16:37:25.909] Unpacking Minmus Flyby
[LOG 16:37:25.955] Updating vessel voxel for Minmus Flyby
[LOG 16:37:25.978] Updating vessel voxel for Minmus Flyby
[LOG 16:37:26.032] Updating vessel voxel for Minmus Flyby

with last message repeated lots of times

I cannot compile the code to debug so I'll make a few guesses here. It seems like subsequent calls TryVoxelUpdate() is repeated failing, which can only be caused by another voxelisation thread being already running.

The first call does seem to start a voxelization thread, but gets stuck on Voxel waiting for chunks to be released (deadlocked?), and so the voxelization never completes.

I still cannot find a reliable way to reproduce this bug, but has occurred quite a lot of times (since I started playing with FAR in 1.0.5 iirc), usually after hours of playing. Currently playing on 1.2.1 and KSP_update branch.

Full log

Mods list

ferram4 commented 7 years ago

Yes, I'm well aware of what's happening once everything is broken. The problem is that if the voxelization never completes (which is not caused by chunks waiting on being released, more will inevitably be allocated if needed above what is normally allocated if need be) things will break. Normally this is caused by some part from some mod having bad geometry. Every report of this issue that I have ever been able to reproduce since the last unstable FAR builds for 1.0.2 have been traced back to a mod part. Yes, even if they behave correctly on respawning, that is not necessarily proof that the geometry is good; it could simply be the intersection of the bad geometry of the problem part with another part's geometry results in a workable voxel model.

Unfortunately, without knowing which mod part is the culprit or otherwise getting repro steps to address this, I cannot hope to fix it.

codesquid commented 7 years ago

I've been noticing drag oddities with the builds in the KSP_update branch as well.

I have attached a craft file with panels at the wingtips:

screenshot0

Airflow perpendicular to the surface on the left, parallel to the surface on the right. The plane should not be stable and should yaw to the left. Using stock aero this vessel it is almost impossible to control. Using FAR it flies perfectly straight.

To reproduce I did the following:

Auto-Saved Ship.craft.txt

KSP.log.txt

ferram4 commented 7 years ago

Both you and codesquid are talking about known behavior that isn't this bug; this bug is about drag that isn't being applied due to voxelization not occurring at all, not weirdness in handling unexpected vehicle configurations. Please don't derail this bug, I still need repro steps for the original issue.

gordonfpanam commented 7 years ago

@codesquid ferram4's right; this isn't for this bug and I moved my post to a new issue.

But if you want to reproduce a drag problem in stock parts, using structural panels isn't a good idea as there doesn't appear to be any Module Manager definitions for them. Using a wing panel C in place of the M 2x2 panel causes the behaviour you expected.

bshepherdson commented 7 years ago

I haven't seen this issue since, so far as I can tell. In fact, I reloaded and left the same craft that had this problem in orbit, intending to rescue the pilot later. I went back to it later and, on a whim, tried the reentry again - no problem.

I'll leave closing the issue up to you - since we haven't found a repro, I'm not sure it's worth leaving this open.

Xorgon commented 7 years ago

I have had similar behaviour (no drag) on the most basic of builds. As you have stated, there were no aerodynamic forces and a voxelization error was thrown: [ERR 00:41:20.896] Voxel Volume was infinity; ending voxelization

Not entirely sure if this is relevant, but the graphing functionality for stability analysis also failed to generate anything.

Full logs: https://gist.github.com/anonymous/b66a7405af6a34082adae5afb4b90623

Craft file: http://xorg.us/R1.craft

The only mods I have installed are:

I have experienced the same issue on both 32 bit and 64 bit versions.

ferram4 commented 7 years ago

I cannot reproduce the issue, indicating that there are missing reproduction steps or that something about your entire KSP install is not set up correctly.

Xorgon commented 7 years ago

Okay, I'll do a fresh install and make a note of each step. ~~1) Completely deleted KSP from Steam directory (Steam/steamapps/common) 2) Selected version 1.2.2 using the "Betas" tab in the game properties Steam window and installed. 3) Downloaded the Ferram-Aerospace-Research-master zip from GitHub. 4) Copied the GameData folder onto the main GameData folder. 5) Launched KSP (64 bit version). 6) As expected, FAR doesn't load. 7) Downloaded and installed ModuleManager v2.8.0 and ModularFlightIntegrator v1.2.4.0.~~

~~8) Launched KSP (64 bit version), FAR has loaded. 9) Built and launched basic rocket in career mode (http://xorg.us/R1.craft). Encountered same problem again (log: https://gist.github.com/e16267e602715a1181c5a59c0b79eab8). 10) Launched KSP again in 32 bit mode. 11) Attempted same launch, encountered same problem (log: https://gist.github.com/cf310e8e519a521a3f5b218fc37ef444).~~

It may be that I'm an idiot and doing something silly, but I think I've followed all instructions correctly.

I was scanning through the README to see if I missed anything, I ran into the patch notes and noticed this line:

Update to MM 2.7.6

I had been using the latest version of MM, whoops! Using the correct version fixes the problem. Apologies for the inconvenience. Would it be possible to include the MM and MFI versions in the installation instructions?

ferram4 commented 7 years ago

Well, then that's not a FAR issue and you've added unnecessary complication to this issue by burying a possible FAR bug under installing dependencies that are not compatible with that version of KSP.