atomicfury

Thanks ferram. On a side note, I'm really enjoying the fact you put in a Reynolds number display. The only aero engineering I know comes from KSP and your mod, but I deal with internal flow, so it's near and dear to me.

OK, I let ferram4 know about this and I put a pull request in. He said it will be fixed for the dev version and then the next release. So as of that release Trajectories can support FAR.

Ferram, I've been helping debug loss of FAR support for the Atmospheric Trajectories mod with 0.14.5.1. I traced part of it to the new skin drag coding. I might have found something but I don't know what your intended behavior of FAR is. When Trajectories initializes, to initialize FAR it runs a drag calculation with some high values, looking for a number greater than 1 to tell if FAR is working. With the new skin drag code in FAR 0.14.5.1, something was spitting NaN's back. I put some debug statement in FAR and found that in FARBasicDragModel.cs, DragModel was using a zero rho. Trajectories was passing rho=10 to RunDragCalculation, which was using rho=10. I think DragModel is getting a different rho from another scope. Maybe, I'm not terribly familiar with C# so I could be off base here. A possible fix is to pass rho to DragModel from RunDragCalculation. I put that change into a local version, compiled it, and it appears to work fine. I've put a pull request in if this makes sense. Thoughts?

Progress on FAR support! Good news: I think I found a fix. Bad news: It involves FAR. I'll pop over the FAR thread next, but here's the scoop. When Trajectories initializes, to load FAR it runs a referenceDrag calculation with some high values, looking for a number greater than 1. With the new skin drag code in FAR 0.14.5.1, something was spitting NaN's back. I put some debug statement in FAR and found that one of the functions had a zero rho (density) value. Trajectories was passing rho=10, the first FAR method had rho=10, but then another resulted in a rho=0 causing the NaN's. This is FAR, in FARBasicDragModel.cs: public Vector3d RunDragCalculation(Vector3d velocity, double MachNumber, double rho) It later calls: DragModel(local_velocity, MachNumber); DragModel uses rho, but seems to get it from some other scope, and uses a rho = 0 for a vessel in space using Trajectories, rather than the rho requested by the call. A possible fix is to pass rho to DragModel. FAR is such an impressive piece of work though that I don't know what ferram's intended behavior is. I'll stop over there next.

Great question. I think I may have something! I'm a total noob with C# but my day job involves detangling 1970's FORTRAN stuff, this was good learning opportunity. I might be totally off base here - please let me know. I confirmed Trajectories 1.0 worked with KSP 0.25 and FAR 0.14.4, so I looked at the FAR source code differences between 0.14.4 and 0.14.5.1 that Trajectories calls. I diff'd FARBasicDragModel.cs between the two versions. Most of the changes couldn't cause any issues, but... In 0.14.5.1 this got added: Cd *= MachMultiplier; if (HighLogic.LoadedSceneIsFlight) Cd += FARAeroUtil.SkinFrictionDrag(rho, lengthScale, local_velocity.magnitude, M, FlightGlobals.getExternalTemperature(part.transform.position) + FARAeroUtil.currentBodyTemp); //Skin friction drag else Cd += 0.005; The section in 0.14.4 is: Cd += 0.003; //Skin friction drag Cd *= MachMultiplier; That call the FARAeroUtil.SkinFractionDrag seems to be the culprit. I compiled a custom FAR version with the 0.14.4 code and got Trajectories prerelease to work with the example savefile from earlier in the thread. In addition to being a C# noob, I'm new to the forum and don't know how to proceed, so I'll just offer this up.

I just confirmed Trajectories 1.0 works with FAR 0.14.4 and KSP 0.25. FAR has seen a fair number of commits since 0.14.4.

I've got something that might be it. In VesselAerodynamicModel, computeFARReferenceDrag() calls computeForces_FAR which is causing all the NaN stuff in the log. You'll see a loop over the vessel parts, matching the NaNs in the log per part. In the Kobymaru save file vessel, computeFARReferenceDrag() is always returning 0, if you look in isFARInitialized(), it always returns false with the NaN calls. I think somewhere that condition isn't getting caught causing the infinite loop. If you create a new craft at the launchpad, it successfully returns a positive value for computeFARReferenceDrag() if you turn trajectories on. So somehow FAR isn't getting initialized in orbit, but does get initialized in atmosphere. Any ideas anyone? I'm going to dig in some more.

Dumb guess! I checked again and have some more curious behavior that might be a clue. I don't have time to check the code but... I reloaded my save, loaded a craft that had been working, turned on trajectories and it froze right when the path hit the atmosphere. I reloaded again, turned OFF trajectories, dipped into the atmosphere (once it hit 4X warp) and then turned ON trajectories, and it worked. Any else able to reproduce this?

So I did just as you asked - and got the lockup as soon as the orbit hit the atmosphere - I can reproduce what you see. Then I tried with a new craft I had working before (mark 1-2 pod, 800 tank, poodle, parachute), orbited and re-entered and I saw a trajectory in atmosphere. Hmmm. Then I tried again with a new craft built like yours (oops, I added a parachute). Hyperedit'd it to orbit, then burned retrograde. I saw a trajectory in atmosphere! Looking at the VESSEL entries in the savegame, I saw that your "k0" craft is missing the FAR modules... Which get created when you make a new vessel in FAR. The following is my GUESS at what is happening: If you have a craft that was built without FAR installed, FAR ignores it (?) but then Trajectories comes along at requests FAR data for something w/o FAR modules, and it goes haywire? This would match the behavior Eleven and myself saw.

So I decided to help and pulled your debug release, slapped in a few extra debug statements around that while loop and ran Trajectories on a Dev install I have. This is KSP 0.90.0, with FAR 0.14.5.1, Hyperedit, toolbar and Mechjeb Dev 366 from a few days ago. I do not have any MechJeb FAR extensions on. It worked with no crashes. So I went to your pre-release version and tried an ascent and re-entry with predictions on ... seemed to work fine. Only thing I noticed is that I needed to correct a little more than I remember to land at KSC. This was a capsule landing. So, I didn't see any framerate issues and the mod is working.

I'm a huge fan of this mod, and since 0.90 came out I've been watching this thread for an update. In the meantime, I've been tinkering with the source and I got biomes working again by updating with some of the latest ScanSat changes. I'm not releasing this into the wild because stock does biome display now (debug menu) so there is no real need. I'm going to try to get resources working again (with Regolith) next.

Edit: I tried to reproduce this and couldn't. I'm going to chalk this up to a mod conflict during some testing. Unless someone else sees this, disregard. I'm getting a RealChute error related to FAR in the output log regarding getting the density, snippet below. My capsule landed safely. I'm pretty sure its related to an added boolean value to the FAR density call, this just cropped up on the Trajectories thread. Ferram added the boolean in the GetCurrentDensity declaration in FARAeroUtil.cs: publicstaticdoubleGetCurrentDensity(CelestialBodybody, doublealtitude, booldensitySmoothingAtOcean=true) log snippet: [RealChute]: Encountered an error calculating atmospheric density with FAR. Using stock values. at System.Linq.Enumerable.Single[MethodInfo] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in <filename unknown>:0 at System.Linq.Enumerable.Single[MethodInfo] (IEnumerable`1 source, System.Func`2 predicate) [0x00000] in <filename unknown>:0 at RealChute.RCUtils.get_densityMethod () [0x00000] in <filename unknown>:0 at RealChute.Extensions.CelestialBodyExtensions.GetDensityAtAlt (.CelestialBody body, Double alt) [0x00000] in <filename unknown>:0

For my own use I figured out the scaling for the various parameters for the liquid fuel + reactor + thermal rocket combos. It occurred to me this might be useful for others. I've got LFO numbers that jive with what wavefunctionp posted a little bit ago. Let me know if you see anything wrong. Note the isp is for vacuum. Spot checked with Kerbal Engineer. Cost is for the reactor only. [TABLE] [TR] [TD]Fission[/TD] [TD][/TD] [TD=width: 107][/TD] [TD=width: 107][/TD] [TD=width: 107][/TD] [TD=width: 107][/TD] [/TR] [TR] [TD]Scale (m)[/TD] [TD]Temp (K)[/TD] [TD]Power (MW)[/TD] [TD]Vac. Isp (s)[/TD] [TD]Thrust (kN)[/TD] [TD]Cost[/TD] [/TR] [TR] [TD]0.625[/TD] [TD]4595[/TD] [TD]31[/TD] [TD]1516[/TD] [TD]4.2[/TD] [TD]625[/TD] [/TR] [TR] [TD]1.25[/TD] [TD]4287[/TD] [TD]250[/TD] [TD]1465[/TD] [TD]34.8[/TD] [TD]5000[/TD] [/TR] [TR] [TD]2.5[/TD] [TD]4000[/TD] [TD]2000[/TD] [TD]1415[/TD] [TD]287.9[/TD] [TD]40000[/TD] [/TR] [TR] [TD]3.75[/TD] [TD]3841[/TD] [TD]6750[/TD] [TD]1387[/TD] [TD]991.5[/TD] [TD]135000[/TD] [/TR] [TR] [TD]5[/TD] [TD]3732[/TD] [TD]16000[/TD] [TD]1367[/TD] [TD]2384.3[/TD] [TD]320000[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD]Pfission[/TD] [TD][/TD] [TD=width: 107][/TD] [TD=width: 107][/TD] [TD=width: 107][/TD] [TD=width: 107][/TD] [/TR] [TR] [TD]Scale (m)[/TD] [TD]Temp (K)[/TD] [TD]Power (MW)[/TD] [TD]Vac. Isp (s)[/TD] [TD]Thrust (kN)[/TD] [TD]Cost[/TD] [/TR] [TR] [TD]0.625[/TD] [TD]2297[/TD] [TD]31[/TD] [TD]1072[/TD] [TD]5.9[/TD] [TD]625[/TD] [/TR] [TR] [TD]1.25[/TD] [TD]2144[/TD] [TD]250[/TD] [TD]1036[/TD] [TD]49.2[/TD] [TD]5000[/TD] [/TR] [TR] [TD]2.5[/TD] [TD]2000[/TD] [TD]2000[/TD] [TD]1000[/TD] [TD]407.1[/TD] [TD]40000[/TD] [/TR] [TR] [TD]3.75[/TD] [TD]1921[/TD] [TD]6750[/TD] [TD]980[/TD] [TD]1402.2[/TD] [TD]135000[/TD] [/TR] [TR] [TD]5[/TD] [TD]1866[/TD] [TD]16000[/TD] [TD]966[/TD] [TD]3371.9[/TD] [TD]320000[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD]Fusion[/TD] [TD][/TD] [TD=width: 107][/TD] [TD=width: 107][/TD] [TD=width: 107][/TD] [TD=width: 107][/TD] [/TR] [TR] [TD]Scale (m)[/TD] [TD]Temp (K)[/TD] [TD]Power (MW)[/TD] [TD]Vac. Isp (s)[/TD] [TD]Thrust (kN)[/TD] [TD]Cost[/TD] [/TR] [TR] [TD]0.625[/TD] [TD]9190[/TD] [TD]62[/TD] [TD]2145[/TD] [TD]5.9[/TD] [TD]12500[/TD] [/TR] [TR] [TD]1.25[/TD] [TD]8574[/TD] [TD]500[/TD] [TD]2072[/TD] [TD]49.2[/TD] [TD]100000[/TD] [/TR] [TR] [TD]2.5[/TD] [TD]8000[/TD] [TD]4000[/TD] [TD]2001[/TD] [TD]407.1[/TD] [TD]800000[/TD] [/TR] [TR] [TD]3.75[/TD] [TD]7682[/TD] [TD]13500[/TD] [TD]1961[/TD] [TD]1402.2[/TD] [TD]2700000[/TD] [/TR] [TR] [TD]5[/TD] [TD]7464[/TD] [TD]32000[/TD] [TD]1933[/TD] [TD]3371.9[/TD] [TD]6400000[/TD] [/TR] [/TABLE]