Fixed Rendezvous constantly chosing course through atmosphere, and a windows related build issue.

[Jaheay]

Hello,

This pull request fixes one of the most indurating issues with Rendezvous with Mechjeb, when using the two-impulse (Hohmann Transfer) mode - It can often plot a course through Kerbin's atmosphere. After losing one too many capsules to my own inattentiveness, I decided to fix it.

While fixing it, I ran into a build script issue on windows, and fixed that too. Hope this is helpful.

[lamont-granquist]

I merged the build fix separately.

I see two problems with the proposed fix to the NLP:

1. It produces a non-C0 objective with a discontinuous jump in the objective and the derivative, right where the optimizer is likely to land.

2. If the periapsis of the transfer orbit is not on the transfer arc, it'll still consider the transfer to be infeasible.

The solution is probably to introduce a real nonlinear constraint g(x) <= 0, where g(x) uses the minimum radius along the arc--not the whole orbit. So if the periapsis lies between the endpoints, then the minimum radius is the periapsis; otherwise it is the radial distance of the smaller of the two endpoints. Then you can keep the objective the way that it was.

Now that elevates into a real KKT system (although it is nearly the world's smallest KKT system). So you're going to need to use minnlc, and since it is non-C1 with a kink in the g(x) constraints, it'll probably require using AUL rather than SQP. For something this simple AUL could probably be used with "0" as the stopping condition and just let alglib determine when it has run into numerical noise. If it isn't accurate enough then SQP might be able to be used on a second pass to "sharpen" the solution, but if we're right against the non-C1 kink that might not work.

I've still got a little bit of a concern (a third issue) which is that in some problems it might hit the barrier and get stuck and not be able to move around on the surface, and not find the optimum. I'm kind of 60/40 thinking it probably will be able to find a gradient to slide around, but I'm pretty far from 100%, and I've learned not to trust my intuition. This feature could really use some tests throwing random problems at it. And one thing to test is that if you solve it without the constraint being used, and get a solution that would not violate the constraint, that you should get the same solution when you solve the problem with the constraint being active.

[Jaheay]

I merged the build fix separately.

I see two problems with the proposed fix to the NLP:

1. It produces a non-C0 objective with a discontinuous jump in the objective and the derivative, right where the optimizer is likely to land.

2. If the periapsis of the transfer orbit is not on the transfer arc, it'll still consider the transfer to be infeasible.

The solution is probably to introduce a real nonlinear constraint g(x) <= 0, where g(x) uses the minimum radius along the arc--not the whole orbit. So if the periapsis lies between the endpoints, then the minimum radius is the periapsis; otherwise it is the radial distance of the smaller of the two endpoints. Then you can keep the objective the way that it was.

Now that elevates into a real KKT system (although it is nearly the world's smallest KKT system). So you're going to need to use minnlc, and since it is non-C1 with a kink in the g(x) constraints, it'll probably require using AUL rather than SQP. For something this simple AUL could probably be used with "0" as the stopping condition and just let alglib determine when it has run into numerical noise. If it isn't accurate enough then SQP might be able to be used on a second pass to "sharpen" the solution, but if we're right against the non-C1 kink that might not work.

I've still got a little bit of a concern (a third issue) which is that in some problems it might hit the barrier and get stuck and not be able to move around on the surface, and not find the optimum. I'm kind of 60/40 thinking it probably will be able to find a gradient to slide around, but I'm pretty far from 100%, and I've learned not to trust my intuition. This feature could really use some tests throwing random problems at it. And one thing to test is that if you solve it without the constraint being used, and get a solution that would not violate the constraint, that you should get the same solution when you solve the problem with the constraint being active.

I hate that you're right. I was hoping this would be an easy fix. Gate it, wire it through, and tada.

Part of me wants to say "eh, add it as a non default toggle, it works well enough and its better than the nothing useful I get now when 75% of all LKO rendezvous think that I can plot a course through the dirt to the space station". For the record - rejecting optimal is still better than sending my poor rockets back to kerbin.

But you are right, and I'm out of my depth. So, give me some time to read up on the things I dont know enough about, and I'll come back with a better pull request in August. I'll put in the time - thank you for your time, writing up such detailed feedback and your complete thought train.

[lamont-granquist]

Yeah, I'll keep this open and I may come around to this in the somewhat-near future, I also need to add the analytic Lambert derivatives to this problem now that I've got them and stop doing finite differencing. I also need to take another run at wrapping this with some kind of monotonic basin hopping algorithm and revist some of the jank coding in here. I recently did a lot of fixing of ReturnFromMoon, FineTuneClosestAppraoch, and InterplanetaryTransfer, but just kinda ran out of steam...