[1.3] Trajectories - Prediction of atmospheric trajectories

[Kobymaru]

This is the development thread for the Trajectories Mod, which predicts atmospheric trajectories.

This thread is mainly for Bug reports and discussions about the development (with icky code and stuff )

For the download of the latest release and information on the usage, please see this thread: 

 

Edited June 20, 2017 by Kobymaru

[atomicfury]

This is the development thread for the Trajectories Mod, which predicts atmospheric trajectories.

This thread is mainly for Bug reports and discussions about the development (with icky code and stuff )

For the download of the latest release and information on the usage, please see this thread: http://forum.kerbalspaceprogram.com/threads/104694

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.

[atomicfury]

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.

[Kobymaru]

Wow, thanks for your work. I will release a new version with FAR enabled when ferram releases a new FAR version to the public.

[atomicfury]

Thank you for keeping the mod going! I like landing as close as possible to KSC. Glad to help.

[Kobymaru]

Progress on FAR support! Good news: I think I found a fix.

When you say "fix", do you mean that it doesn't lock up anymore, or that the prediction accurately works? Because I am having an issue that with FAR, the impact marker constantly drifts to the West as soon as the craft enters the atmosphere.

Edit:

Ok, at least that's not a new bug. Tested with KSP 0.25, Ferram 0.14.4 and Trajectories 1.0.0.0 and the behaviour is the same. Still kind of unpleasent if the marker keeps drifting.

Edit 2:

"Fixed" if you set the AoA in the descent profile to -180°. On one hand that's logical because if you point your nose retro, then the air is coming from behind you. On the other hand, then 0° should not be default. And +180° should give the same result as -180° (but it doesn't). Note to self: some thinking about reference frames is in order.

Edited December 25, 2014 by Kobymaru

[Youen]

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.

If I remember correctly, I already had to set a private member variable of FAR (through reflection) because indeed rho wasn't passed where it should be. But the code probably changed since then. The correct way is probably to tell ferram about it (as you already have if I follow correctly) instead of trying to hack even more than I already did ;-)

[Kobymaru]

If I remember correctly, I already had to set a private member variable of FAR (through reflection) because indeed rho wasn't passed where it should be. But the code probably changed since then. The correct way is probably to tell ferram about it (as you already have if I follow correctly) instead of trying to hack even more than I already did ;-)

Yeah, that's always preferable We should take advantage of the fact that the KSP community is so close and Mod authors are just around the Forum corners

[Probus]

FYI Kobymaru. If I can be of help, just let me know.

Hi Ferram,

As I mentioned earlier in IRC, AIES is throwing NaN errors. I think KSP is looking for an undefined variable in the CFG files of each part. Here is the error/warning type:

[WRN 16:03:58.165] FAR Error: Aerodynamic force = NaN Aerodynamic moment = 0.189424095163685 CoD Local = 0.0227040961332294 CoD Global = NaN AIES R350 'TOR'

What variables would you guess that I need to define in AIES CFG files to give FAR what its looking for? Or is this task an order of magnitude greater than that?

Thanks for your mods Ferram! I never play with out FAR.

Best Regards,

Probus

I have no idea what is wrong; either AIES has defined FAR modules in the config that need to be stripped out or its models are completely and utterly borked somehow (I don't even think it's possible) and there is no way to get FAR to handle its geometry properly.

Unless it's a wing, there is absolutely nothing that has to be changed in the config files for FAR to function; all that needs to be done is make sure that the configs are running on 0.90-standards, and everything will function fine.

Ferram,

I've been digging into this and I am pretty sure it is the "Trajectories" mod causing the FAR errors on the AIES parts.

[atomicfury]

@Probus - you shouldn't use Trajectories with FAR right now. Those NaN statements are the least of your worries, it can cause KSP to freeze up. There is an incompatibility between FAR and Trajectories that causes that behavior. It'll be fixed up with the next releases.

[Youen]

KSP-AVC seems to think that the version is still 1.1, not 1.1.1

The procedure for that is :

- connect to http://ksp-avc.cybutek.net

- login with the password I gave you on PM

- update info in "My versions" (I see you already have done it)

- either download the updated .version file, or simply edit the one that ships in Trajectories.zip to match the version number

- edit the version of the DLL (in visual studio, in properties of the Trajectories project, in the Application tab, click "Assembly information...")

- build in release which should also package the new zip

This is not really a smooth process, feel free to improve if you can :-) I'm not sure the DLL version really has to mach, but I think it's cleaner.

[Kobymaru]

The procedure for that is :

- connect to http://ksp-avc.cybutek.net

- login with the password I gave you on PM

- update info in "My versions" (I see you already have done it)

- either download the updated .version file, or simply edit the one that ships in Trajectories.zip to match the version number

- edit the version of the DLL (in visual studio, in properties of the Trajectories project, in the Application tab, click "Assembly information...")

- build in release which should also package the new zip

This is not really a smooth process, feel free to improve if you can :-) I'm not sure the DLL version really has to mach, but I think it's cleaner.

Thanks! I reuploaded a new build with the proper version number.

[Kobymaru]

I've got good news and bad news.

Good news first.

I found the culprit of the inaccuracies when FAR is used! Turns out the cache system uses a constant altitude (half the atmosphere height) for Mach Number calculation (see VesselAerodynamicModel.cs, Line 228-230). This means the Mach number is wrong for pretty much all of the trajectory.

Disabling the cache (see VesselAerodynamicModel.cs, Line 463) fixes everything. I hit the KSP runway the first time I tried it.

Now the bad news:

Apparently, without the cache system the performance degrades dramatically and makes the game unplayable. So much for that :/

Any ideas how to proceed now?

My wild guesses are:

- Temporarily using a much lower altitude for Mach Number calculation, because that's where most of the forces go missing.

- Somehow (???) improving calculation performance of the trajectory

[zengei]

Any ideas how to proceed now?

I don't know the particulars of the code but couldn't you precalculate the Mach number for ranges of altitudes and then do a dictionary lookup for the Mach number (i.e. cache multiple values rather than one)? Then you just adjust the size of the ranges for more accuracy/more performance. I would imagine even with very small ranges such performance would be pretty good. The system right now would just be equivalent to having a single range for the entire atmosphere.

[Youen]

I don't know the particulars of the code but couldn't you precalculate the Mach number for ranges of altitudes and then do a dictionary lookup for the Mach number (i.e. cache multiple values rather than one)? Then you just adjust the size of the ranges for more accuracy/more performance. I would imagine even with very small ranges such performance would be pretty good. The system right now would just be equivalent to having a single range for the entire atmosphere.

If I remember correctly, I took out the mach number as a constant, because it reduced the number of dimensions of the cache array. Currently the cache is two-dimensional : angle of attack and velocity. If you add the mach number, you multiply the cache size by as much different mach values you want to use. It might work, and might actually not use too much more memory if other dimensions resolution are reduced. Also, be carefull to make the system work for all bodies, Jool has a very different mach number range for example.

The idea to use a lower altitude mach number as a constant could improve landing precision, but maybe deteriorate aerobraking precision?

Also, something I didn't have time to try, is to add a simple scale factor to all forces, because they are always too low (or too high? don't remember). Whatever the cause is, it could workaround the accuracy issues (maybe).

Edited January 3, 2015 by Youen

[Kobymaru]

If I remember correctly, I took out the mach number as a constant, because it reduced the number of dimensions of the cache array. Currently the cache is two-dimensional : angle of attack and velocity. If you add the mach number, you multiply the cache size by as much different mach values you want to use. It might work, and might actually not use too much more memory if other dimensions resolution are reduced.

TBH I'm not that worried about the Memory, I'm more worried that the cache will be hit much much less and the CPU load will be way too high.

Also, be carefull to make the system work for all bodies, Jool has a very different mach number range for example.

Thanks for the note!

The idea to use a lower altitude mach number as a constant could improve landing precision, but maybe deteriorate aerobraking precision?

Yes, definitely. It's a fallback solution.

Also, something I didn't have time to try, is to add a simple scale factor to all forces, because they are always too low (or too high? don't remember). Whatever the cause is, it could workaround the accuracy issues (maybe).

TBH I'm not really for "scale factors", especially if we know that without the cache, the calculations are precise.

[Youen]

I'm more worried that the cache will be hit much much less and the CPU load will be way too high.

Indeed, and also you'll have to interpolate in three dimensions (maybe not a big deal though).

Typically, I think the CPU load related to forces computations would double (because you need two values to interpolate instead of one), but not more because you don't need to compute values that are not on your trajectory (I guess values that get computed would form a (curved) line of 2x2x2 blocks in the 3D grid, and if the trajectory changes significantly this line will slowly sweep new values). If the trajectory is stable, only the first computation would be slower (0 cache miss multiplied by two still gives 0).

without the cache, the calculations are precise.

Are you 100% sure? I thought I had precision issues even without the cache (but also I fixed some bugs and made improvements all the time, so maybe it's better now and the cache is the biggest remaining contributor to inacuracy)

Edited January 5, 2015 by Youen

[peachoftree]

Correct me if im wrong, but doesn't mach value vary with air density, so couldnt you calculate mach from altitude without it being too CPU intensive and still get the same effect. something like mach = altitude * magic_density_to_mach_coefficent, maybe something with the formulas found at http://www.engineeringtoolbox.com/speed-sound-d_82.html

EDIT: after looking through the code, I see that density is included in the array and if you calculate pressure using that mach number calculation becomes dead simple

Edited January 6, 2015 by peachoftree

[prophet_01]

Since 0.90 the trajectories mod causes a glitch for me. If I launch a vessel from the VAB or SPH the game refuses to load basically everything. I'm simply looking at the sky textures and the sun, no kerbin, no vessel, no buildings, but also the game hasn't crashed completely. If I launch from the space center directly on the launch pad (without entering the VAB/SPH) everything is fine.

I'm using a number of mods (including FAR) on 32 bit. I reinstalled the mods one by one on a fresh backup until the problem showed up again, so I'm pretty sure it's this mod I have yet to test if a fresh install with trajectories only will still do that or if it's a compatibility issue with another mod. Will test that later and post the result. Apart from that the mod worked as it's supposed to do, although I frequently had fps drops if it tried calculed multiple passes at kerbin

[Kobymaru]

Ok, about that NaN bug:

It seems that FAR is not fully initialized after launch, afteer a certain condition (such as altitude maybe) is reached.

Steps to reproduce the bug:

1) Launch vessel with wings

2) Activate trajectories immediately

3) Observe NaN's

Steps to avoid the bug:

1) Launch new Vessel with wings

2) Wait until FAR logs

- Normal Shock Mach Number Curve Initialized

- Normal Shock Pressure Curve Initialized

- Prandlt-Meyer Expansion Curves Initialized

- Stagnation Pressure Curve Initialized

3) Activate trajectories

4) Observe that everything is fine

Now I have to dig into the conditions of when the curves are initialized and not calculate trajectories before. (Happens the first time the vessel goes over about 200 m/s).

- - - Updated - - -

Correct me if im wrong, but doesn't mach value vary with air density, so couldnt you calculate mach from altitude without it being too CPU intensive and still get the same effect. something like mach = altitude * magic_density_to_mach_coefficent, maybe something with the formulas found at http://www.engineeringtoolbox.com/speed-sound-d_82.html

EDIT: after looking through the code, I see that density is included in the array and if you calculate pressure using that mach number calculation becomes dead simple

Sure, calculating the Mach number is dead simple. But calculating the drag is not! We currently use a 2-dimensional lookup table, think of it as a function of (Velocity, AoA) |-> F_drag . The mach number is currently fixed. If it were NOT fixed, the Mach calculation would be simple, but the drag function would become

(Velocity, AoA, MachNumber) |-> F_drag and we would require a 3-dimensional lookup table. That's not impossible, but it might lead to the problems mentioned above. Or not. I dunno. I think I'll just implement it and see what happens.

Since 0.90 the trajectories mod causes a glitch for me. If I launch a vessel from the VAB or SPH the game refuses to load basically everything. I'm simply looking at the sky textures and the sun, no kerbin, no vessel, no buildings, but also the game hasn't crashed completely. If I launch from the space center directly on the launch pad (without entering the VAB/SPH) everything is fine.

I am very sorry, but I cannot reproduce this. I constantly launch from VAB/SPH and never had this. Maybe you should reinstall/repair your KSP installation?

Apart from that the mod worked as it's supposed to do, although I frequently had fps drops if it tried calculed multiple passes at kerbin

Performance is a problem, but unfortunately not one that is going to be fixed anytime soon. Sorry about that

[sralica]

For me this mod does not function correctly with FAR. I am trying to land on Kerbin, not using a plane; no wings on a craft. It decelerate faster then predicted and completely misses landing prediction. if I remove FAR it is OK.

Using ksp 0.90, 32bit, mods: toolbar, ATM, DeadlyReentry, HyperEdit, MechJeb2, Trajectories

Descent profile set to AoA -180 or +180, using MJ to keep heading (ether Orbit-> retrograde or SURFace -> SVEL negative) so I am falling in reverse trough the atmosphere.

Am I the only one with this problem?

[Baythan]

For me this mod does not function correctly with FAR. I am trying to land on Kerbin, not using a plane; no wings on a craft. It decelerate faster then predicted and completely misses landing prediction. if I remove FAR it is OK.

Using ksp 0.90, 32bit, mods: toolbar, ATM, DeadlyReentry, HyperEdit, MechJeb2, Trajectories

Descent profile set to AoA -180 or +180, using MJ to keep heading (ether Orbit-> retrograde or SURFace -> SVEL negative) so I am falling in reverse trough the atmosphere.

Am I the only one with this problem?

As per the first page of this thread: It is a known issue that FAR/NEAR landing predictions are inaccurate due to the methods used by Trajectories to calculate with the new drag model. Methods to improve accuracy without drastically reducing performance are being developed.

Even with the inaccuracies, you are MUCH more likely to get in the area you want to be in while using this mod than if you did not use it. Adding in the difficulty of using DeadlyReentry, you'll have to experiment with how far past your landing point you want that X... and because of FAR it will be different for every vehicle. Without DR I just like to drop near-vertical on top of my targets and I use trajectories to plan when to start the drop from orbit because this mod will still predict how much the planets will rotate under you.

Keep at it Kobymaru!

[Youen]

Also, make sure you set all sliders to +180 (or all to -180), not just the first one (maybe you already did, just in case)

[Youen]

I thought I would not fall again, but apparently I couldn't resist trying KSP 0.90 and have been playing again for some days (and nights). I used the latest Trajectories release, which works great with stock and NEAR, but, as has been reported, the cache system is really wrong with FAR. I just made some measurements : I get forces about two times too low when the cache is enabled. Without the cache, there's only about 0.1% difference with the actual forces applied by FAR on the vessel at any time.

I'm currently investigating, apparently it isn't related to the mach number, which appears to have a very low influence on the final result.

- - - Updated - - -

OK, found the problem.

First, there was a bug with mach number estimation. I wanted to get the mach number at an average altitude, but body.maxAtmosphereAltitude is above-sea altitude, and I thought it was relative to the body center, so I incorrectly subtracted body.Radius. That wasn't really making a difference though (maybe FAR clamps the altitude anyway).

The real problem however is that FAR forces are no longer proportional to rho (air density). So we'll have to add a third dimension to the cache system (altitude), and compute rho for each altitude (as a bonus, we can also compute the real mach number). My guess is that a very low resolution on that axis will do though. I'll make some more tests to find a good tradeoff for accuracy/memory/CPU usage on the cache resolution.

Bottom line is, we really need a debugger for KSP modding :-( Several hours spent displaying stuff on the screen until I could pinpoint the culprit... Should have been solved in a matter of minutes with a debugger.

- - - Updated - - -

And there was also a bug in the cache interpolation code (it was inverting the interpolation coefficients for some axes, which had little impact due to the quite high resolution of the cache, but was wrong nonetheless). With this fix, I'll probably be able to reduce the cache resolution and still be more accurate than before. This bug might also explain why setting +180° in the descent profile was different from -180° (because it was sampling the wrong side of the cache cell on both ends).

- - - Updated - - -

I'm getting lots of errors "FAR Error: Aerodynamic force = NaN Aerodynamic moment = 0 CoD Local = 0 CoD Global = NaN" when reaching the edge of the interface, is that a known issue? (FAR 0.14.6)

Edited January 23, 2015 by Youen

[AngelLestat]

I never test it in near, I have far..

But I had understand that the only difference that nears has with far is all the UI that show your flying data.. but if in nears works fine, then I am mistake.