Principia Flight Plan Optimizer Sticking on Inclination-Only Change

[DRVeyl]

Principia Optimizer Issue.zip

Attempting to use the flight plan optimizer to modify the approach/arrival at a celestial body. Manually created a flight plan for vessel "Venus Lander 1" departing Earth for Venus. Got in the vicinity, then set arrival altitude 300,000m, inclination 0, and optimizer iteratively produced a reasonable solution.

Issue arises here: when requesting the optimizer to change the arrival inclination, it does not meaningfully change the flight plan.

Making a significant enough change to the requested altitude (200k -> 2M) tends to also cause the optimizer to adjust the inclination. Making a small (200k -> 300k) or no change to the altitude with any-size change to the requested inclination usually but not always results in an approximately-unchanged flight plan.

I've attached a representative save (I think) with an existing flight plan, re "Venus Lander 1".

(Trying to reproduce the issue was where I noticed the altitude change is relevant. So there's an obvious user work-around: first optimize with a large altitude change, then optimize again with the new desired altitude & inclination.)

Size of the target celestial body seems related: I did not reproduce this behavior planning arrival at Vesta, and asking for inclination-only changes seemed to work.

[pleroy]

I have not analyzed the problem yet, but from the description this could be a case of "we only do local optimization, dude".

You are at a minimum of the metric, which looks fine, i.e., matches the desired altitude and inclination. Now you tweak the inclination. This changes the phase space "surface" on which optimization happens. But it is completely possible that it doesn't change it that much, so that you are still in the basin of the same local minimum. So optimizing will land you more-or-less at the same place, which may not have the inclination you like.

If on the other hand you change the altitude a lot, you might be climbing up a mountain from which a different minimum will be reached that is a better match for both the altitude and inclination.

A smaller change to the altitude might lead to either scenario.

I'll investigate further, but it will take some time.

[DRVeyl]

That makes sense to me, but raises a question.

When watching the optimizer across multiple frames in KSP, it appears to effectively solve altitude first and then progress towards better inclination solutions. This takes ~10 seconds for large inclination changes [so it is easy to watch]. I understand the optimization surface is a surface and it is not "solving" things in a linear sequence, though perhaps the slope for the altitude dimension is just always steeper. Rather, I am asking how this situation "never" [confirmation bias?] falls into some local minima to get stuck?

I'm guessing I'd need to ask it to do a lot more changes to baseline that "never" and inclination error is harder to see.

[pleroy]

So the optimization code is full of magic numbers. The distance tends to be optimized first because (expressed in metres) it's the largest number. As the optimizer goes down the optimization surface the inclination becomes more significant and with some luck the optimizer manage to optimize both at the same time. That starts to happen when the inclination and altitude errors are of the same magnitude. I have a hunch that if you change the inclination by x degrees you'd have to change the altitude by 60 x kilometres so that the two components of the metric have roughly the same size (60 is because of degree-to-radian conversion; kilometre is because there is a factor 10⁶ in the metric applied to the square of the angle).

It's not true that you never fall into some local minima, but the magic numbers were chosen so that the inclination optimization kicks in at the right place (far enough from the celestial that you still have a change to tweak the inclination).

None of this is rigorous, of course.

[DRVeyl]

Not rigorous perhaps, but qualitatively responsive and helpful. Thankyou.

Is perturbing the starting state to avoid situations where you likely begin in/around a minima reasonable?
(I do not assume so: you can easily argue the user got themselves into this situation and already has the tools to get themselves out.)