Poliastro: Review Lambert API

[astrojuanlu]

Some concerns were raised months ago in the mailing list about the solution pairs, as well as the prograde/retrograde nature of the solutions.

When I implemented the Izzo algorithm I used a generator, and that makes me think that I was probably misunderstanding the paper. This affected how the API is used.

https://github.com/poliastro/poliastro/blob/333a2f77f5c4fa1c652bcdd9bea72ce42531b566/src/poliastro/core/iod.py#L235-L241

We should review this in depth and answer this message on the mailing list, even if months have passed:

https://groups.io/g/poliastro-dev/message/118

[jorgepiloto]

I am finally able to properly answer original question raised by Irina Kovalenko and also introduce some ideas about how we could improve the current Lambert's API and associate routines.

Amount of solutions

Even if considering non-degenerate, degenerate and multi-revolutions ones, the solution to the Lambert's problem is an elliptic orbit most of the times. Of course, multi-revolution solutions will be for sure elliptic kind, as the orbit needs to be closed.

Under certain combinations of time of flight and transfer angle, it is possible to find two elliptical orbits as the solution to the transfer. The following figure from the open paper Optimal Two-Impulse Rendezvous Using Multiple-Revolution Lambert Solutions (DOI: 10.2514/2.5014) provides a very illustrative figure:

Notice that there exist a short and long paths for prograde transfer but also another short and long arcs for retrograte motion, making thus a total of 4 possible transfer arcs. The final orbit is selected by imposing the sense of motion and selecting the short or long arc.

State of the current Lambert API

At the moment, only two Lambert solvers are available within poliastro: vallado and izzo. Although both address the same problem, they require different parameters:

https://github.com/poliastro/poliastro/blob/3c1d0eb8382075a8e7a191cd84acf34748c2d649/src/poliastro/core/iod.py#L11

Vallado provides the short boolean parameter but notice when compared to previous figure, this parameter actually controls the prograde or retrograde orbit selection! The algorithm from the original book (the one implemented in poliastro) is a simplified version from the original one in Celestrak and only retrieves two of the possible 4 transfer arcs. The full routine is properly coded within in official link, which reminds me about https://github.com/poliastro/poliastro/pull/895.

https://github.com/poliastro/poliastro/blob/3c1d0eb8382075a8e7a191cd84acf34748c2d649/src/poliastro/core/iod.py#L164

Regarding Izzo's algorithm, both short and long transfers are properly computed. However, the algorithm lacks of prograde/retrograde selection parameter. We could easily implement this feature, it only requires adding a change of sign, see pykep implementation.

Suggestions and possible solutions

• We might consider adding explicit parameters solver(short=True, prograde=True) for better filtering and making more explicit the amount of solutions returned by each of the algorithms. Main drawback is that we would loose the ability to return all kind of solutions at the same time within core functions if implemented in this API level, but I is kind of strange to require all of them at the same time... :thinking:

[astrojuanlu]

A million thanks for this thorough review @jorgepiloto! Some more extra ideas:

• I imagine that prograde orbits are preferred over retrograde orbits in most cases. For short vs long, I am not that sure. In any case, I agree that short=True and prograde=True are good defaults. I am not worried about "losing the ability to return all kind of solutions at the same time" from the core API.
• ...Unless returning all kind of solutions at the same time is faster. I say this because, if we add short and prograde parameters, we might have to repeat some intermediate computations.
• And finally: can we turn the generators (yielding the solutions) into normal functions? I think this would simplify their usage a lot.

[jorgepiloto]

In response to @astrojuanlu,

I imagine that prograde orbits are preferred over retrograde orbits in most cases. For short vs long, I am not that sure.

The "short" or "long" paths are referred by some authors as "low" or "high" paths, so they are not misunderstood with the prograde and retrograde transfers. These parameters can only be selected when there are two solutions to the problem, that is only for M>=1 revolutions. The "low" paths correspond to negative values of "x" (independent variable), while "high" paths are linked to positive "x" values. Hence, it should be easy to filter out the final solution to the problem. I think that usually the low path is the one selected, as both the "low" and "high" solutions lead to an elliptical orbit (remember, multirevolutions => closed paths => ellipses).

And finally: can we turn the generators (yielding the solutions) into normal functions? I think this would simplify their usage a lot.

By using the following keywords, prograde=True and low_path=True, the lambert routines do not longer require a generator and thus, they return a unique solution to the problem.

[jonpsy]

@jorgepiloto @astrojuanlu Glad to see this up and running again. I recall the confusion we had when dealing with retrograde vs prograde and short vs long (very bad choice of param names, I might add).

I agree with jorges idea here; and I suppose we would need to refactor both izzo and vallado? I also beleive both the orbital paths are necessary along with their direction of motion(prograde, retrograde). I've already put-in a lot of work in my PR.If anybody feels like continuing that, feel free. If I have time, I'll do it myself, currently the numerical values don't match with MATLAB answer.

[astrojuanlu]

@jorgepiloto solved this in jorgepiloto/lamberthub#7 🎉 He's a bit short on time these days, but if anyone else wants to see the changes that were needed, feel free to open a pull request here 👍🏽