Request: Add orbit when reentry happens to orbit analyser

[tivec]

Problem

Sometimes I want to make a quick check to see how long a satellite stays in a given orbit, so that I can judge if an orbit works for a particular contract or mission. In these cases I run a check of 1000 days. In case of a reentry, I now have to binary search my way down to figure out when this reentry happens. 500 days? No reentry. 750 days? Reentry. 650 days? No reentry. So on and so forth. On my computer specs, this can take a very long time (1000 days take approximately a minute to search for me).

I assume the solver knows how many iterations it did to find the first failed orbit.

Suggested solution:

Show, instead of "reentry", "reentry on orbit x".

This might be less useful since there are a lot of orbits over that long time period, so that leads me to:

Alternative solution

Have it show, instead of "reentry", "reentry after x days, hours etc".

[pleroy]

Note to self:

For a planet with an atmosphere, it's probably feasible. We would need to call ComputeCollisionIntervals with the radius of the atmosphere instead of that of the planet, and run a root finder on the first interval. The annoyance is that it's another place that needs to compute apsides, and that's known to be fairly expensive. But it's perhaps acceptable because this is on its own thread. There is however a definitional problem: if you just graze the atmosphere a bit, it's probably fine. If you go deep, then that's a problem, but how deep is deep? We are surely not going to do atmosphere modelling in the orbit analyser.

For a planet without an atmosphere, it is madness. The code that computes the collisions of the prediction with the planet is our best bet, but it is driven by the C# side: it creates a PushPullExecutor, and waits for the executor to ask questions about the terrain; in parallel, on the C++ side the code analyzes the trajectory, and at some point pushes in the executor the coordinates where it wants to know the altitude, and blocks; this unblocks the C# side, which computes the altitude, pushes it in the executor, and goes back to waiting; the C++ side unblocks once it gets the altitude, and proceeds with its computations. This continues until the C++ side signals to the C# side that it has completed its work. The C# code then proceeds with other stuff (this dance happens at each frame).

But note how it is critical that this is all driven from C#, because we cannot have C++ randomly calls into C# (this is KSP/Unity, there is no thread-safety). Now the orbit analyser is asynchronous; this is necessary because it can do expensive computations that should not block the UI. Therefore, it cannot call into C#. It also cannot be called from C# because that would force synchronizing it with the UI.

[Clayell]

There is however a definitional problem: if you just graze the atmosphere a bit, it's probably fine. If you go deep, then that's a problem, but how deep is deep?

80km, on Earth at least, is probably the limit. This is the lowest that any VLEO orbits can go to, even if they are highly eccentric.
For other planets, that limit has yet to be defined. Perhaps a good estimation could be based on a fraction of the atmosphere depth based on the above value. (80/140 = 4/7)