Iteration 21
RetrieveGate decision
RetrieveReasoningAdditional evidence is warranted because the current search has plateaued after several timing-grid refinements, while the remaining improvement likely requires a materially different optimization or Lambert-branch…
Additional evidence is warranted because the current search has plateaued after several timing-grid refinements, while the remaining improvement likely requires a materially different optimization or Lambert-branch strategy. Previously retrieved documents are high-level or indirect and do not resolve the specific implementation questions, so a fresh targeted search should go beyond them.
Knowledge before this stepThe experiments show that deterministic Voyager-like phasing and denser launch/arrival grids reliably produce a valid Earth-Jupiter-Saturn-Neptune solution near combined scores 0.7341-0.7342, with boundary delta-v…
The experiments show that deterministic Voyager-like phasing and denser launch/arrival grids reliably produce a valid Earth-Jupiter-Saturn-Neptune solution near combined scores 0.7341-0.7342, with boundary delta-v dominating and DSM/GA costs nearly negligible. Increasing grid density and adding timing clusters has produced only marginal, inconsistent gains, so the current bottleneck is likely unresolved trajectory-branch selection and continuous optimization of launch and flyby epochs rather than basic feasibility. The retrieved documents establish that differential evolution, hybrid global/local optimization, and explicit Lambert branch handling are relevant, but they do not provide sufficiently concrete implementation guidance for this codebase, especially for selecting short/long-way or multi-revolution Lambert solutions and efficiently optimizing the coupled epoch variables. New information on practical Lambert branch enumeration, constrained differential evolution or basin-hopping for MGA trajectories, and robust local refinement would therefore be useful.
Population analysis
📊 State: The retained population contains 27 programs, with scores spanning 0.56184–0.73415 and the current parent at 0.61677, 0.11738 below the retained best.
Key Numbers:
• Score distribution: mean 0.71457, median 0.73211, and population standard deviation 0.04077.
• Score concentration: 15 unique scores among 27 retained programs; the top score is 0.73415, while the worst is 0.56184.
• Recent trajectory: in the 20-row trace window, 13 outcomes improved, 5 regressed, and 2 were unchanged.
• Global progress: the retained best increased from 0.73395 before iteration 19 to 0.73411, then to 0.73415 at iteration 20.
Patterns Observed:
• Parent selection used 14 unique IDs across 20 selections; the most-selected parent appeared 2 times, or 10% of selections.
• Context selection used 11 unique IDs across 23 slots; the most-selected context appeared 4 times, or 50% of its programs-with-selection count.
• Recent child scores ranged from 0.61677 to 0.73415; parent scores in the same trace ranged from 0.56184 to 0.73395, with the largest positive child-parent delta equal to 0.16158.
Query · round 1
Python Lambert solver enumerate short-way long-way prograde retrograde multi-revolution branches Izzo implementation code
Find practical implementation guidance for generating and evaluating all relevant Lambert transfer branches for each MGA leg, including short-way/long-way, prograde/retrograde, and multi-revolution solutions.
Query rationale
The current program already obtains reliable Voyager-like solutions through dense timing grids, but further gains are limited by unresolved trajectory-branch selection. Existing searches identified Lambert branch handling as relevant but did not provide concrete code or API details. A branch-enumeration implementation could expose lower-cost Earth-Jupiter-Saturn-Neptune trajectories that the current single prograde Lambert call never evaluates, while remaining compatible with the existing flyby feasibility and local epoch-refinement stages.
What this round establishedThe new documents confirm that Lambert solutions can have distinct short-way/long-way, prograde/retrograde, and multi-revolution branches, and that a robust Izzo-style implementation can enumerate multiple valid…
The new documents confirm that Lambert solutions can have distinct short-way/long-way, prograde/retrograde, and multi-revolution branches, and that a robust Izzo-style implementation can enumerate multiple valid solutions rather than returning only one. This directly identifies a plausible source of missed trajectory branches in the current program, whose repeated calls to tools.lambert(..., prograde=True) appear to evaluate only a single branch. The Izzo paper provides the most useful algorithmic foundation, while the poliastro material gives practical confirmation of multi-revolution handling; the Rust documentation reinforces the desired output structure but is less directly applicable to this Python codebase, and the forum document adds little implementation detail. What remains untested is whether the injected Lambert wrapper exposes branch-selection or multi-solution APIs, whether the relevant branches are physically feasible for the Voyager E-J-S-N sequence, and whether enumerating them can be done within the evaluation budget. Concrete integration details for this wrapper and a more effective constrained global/local optimization of the coupled epoch variables are still needed. The current low score also indicates that branch enumeration alone may not recover the known 0.734 solution unless the search and refinement remain robust.
Kept-document mean prediction 0.66233
Query · round 2
"tools_wrapper.py" Tools lambert all solutions branch prograde retrograde multi-revolution Python
Determine whether the injected Tools.lambert wrapper supports branch selection or returning multiple Lambert solutions, including long-way, retrograde, and multi-revolution cases, and identify the exact callable signature needed to integrate branch enumeration safely.
Query rationale
The current program repeatedly calls tools.lambert(..., prograde=True) and therefore may miss valid trajectory branches, but the available documents only describe Izzo's algorithm conceptually and do not reveal the wrapper API or implementation constraints. A concrete API-level example could enable evaluating several branches per leg while preserving the existing Voyager E-J-S-N search and runtime budget.
What this round establishedThe new documents reinforce that Lambert transfers may have multiple valid branches: short- and long-way, prograde and retrograde, and multiple-revolution solutions. The poliastro material is the most practically useful…
The new documents reinforce that Lambert transfers may have multiple valid branches: short- and long-way, prograde and retrograde, and multiple-revolution solutions. The poliastro material is the most practically useful because it demonstrates an Izzo-style API capable of returning multiple solutions, while the GitHub summary explicitly indicates four branch combinations in representative cases. The theoretical documents clarify that branch multiplicity grows with revolution number and that some branches may not exist for a given geometry and time of flight. This strengthens the hypothesis that repeated tools.lambert(..., prograde=True) calls can miss useful trajectories. However, no document establishes that the injected tools wrapper exposes these APIs, nor how its units, return format, branch flags, or failure behavior should be handled. It also remains untested whether non-default branches are feasible for the Voyager E-J-S-N sequence, whether multi-revolution branches are physically useful over its leg durations, and whether branch enumeration fits the evaluation budget. The next attempt should first probe or defensively detect wrapper capabilities, enumerate only a small set of plausible branches, retain the existing single-branch result as a fallback, and compare branches during both grid evaluation and DSM refinement. Missing knowledge also remains around a more efficient constrained global/local optimization of coupled launch, flyby, and terminal epochs; the Lambert documents do not resolve that search problem.
Kept-document mean prediction 0.658
Query · round 3
poliastro Izzo Lambert API low_path prograde M multiple solutions return format Python
Determine the exact callable signature, branch flags, iterator/return format, and failure behavior for enumerating short-way/long-way, prograde/retrograde, and limited multi-revolution Lambert solutions so the trajectory search can add defensive branch selection while retaining the current single-branch fallback.
Query rationale
The current program evaluates only tools.lambert(..., prograde=True), and the retrieved theory confirms useful branch multiplicity but does not establish how the injected wrapper exposes it. The next improvement should safely probe or emulate a small branch set during both grid evaluation and DSM refinement without breaking validity or exceeding the evaluation budget.
What this round establishedThe new documents reinforce that Lambert transfers may have multiple valid branches: short- and long-way, prograde and retrograde, and multiple-revolution solutions. The poliastro material is the most practically useful…
The new documents reinforce that Lambert transfers may have multiple valid branches: short- and long-way, prograde and retrograde, and multiple-revolution solutions. The poliastro material is the most practically useful because it demonstrates an Izzo-style API capable of returning multiple solutions, while the GitHub summary explicitly indicates four branch combinations in representative cases. The theoretical documents clarify that branch multiplicity grows with revolution number and that some branches may not exist for a given geometry and time of flight. This strengthens the hypothesis that repeated tools.lambert(..., prograde=True) calls can miss useful trajectories. However, no document establishes that the injected tools wrapper exposes these APIs, nor how its units, return format, branch flags, or failure behavior should be handled. It also remains untested whether non-default branches are feasible for the Voyager E-J-S-N sequence, whether multi-revolution branches are physically useful over its leg durations, and whether branch enumeration fits the evaluation budget. The next attempt should first probe or defensively detect wrapper capabilities, enumerate only a small set of plausible branches, retain the existing single-branch result as a fallback, and compare branches during both grid evaluation and DSM refinement. Missing knowledge also remains around a more efficient constrained global/local optimization of coupled launch, flyby, and terminal epochs; the Lambert documents do not resolve that search problem.
Evidence sent to the solver
Python Lambert solver enumerate short-way long-way prograde retrograde multi-revolution branches Izzo implementation code
"tools_wrapper.py" Tools lambert all solutions branch prograde retrograde multi-revolution Python
poliastro Izzo Lambert API low_path prograde M multiple solutions return format Python
Knowledge after searchThe new documents reinforce that Lambert transfers may have multiple valid branches: short- and long-way, prograde and retrograde, and multiple-revolution solutions. The poliastro material is the most practically useful…
The new documents reinforce that Lambert transfers may have multiple valid branches: short- and long-way, prograde and retrograde, and multiple-revolution solutions. The poliastro material is the most practically useful because it demonstrates an Izzo-style API capable of returning multiple solutions, while the GitHub summary explicitly indicates four branch combinations in representative cases. The theoretical documents clarify that branch multiplicity grows with revolution number and that some branches may not exist for a given geometry and time of flight. This strengthens the hypothesis that repeated tools.lambert(..., prograde=True) calls can miss useful trajectories. However, no document establishes that the injected tools wrapper exposes these APIs, nor how its units, return format, branch flags, or failure behavior should be handled. It also remains untested whether non-default branches are feasible for the Voyager E-J-S-N sequence, whether multi-revolution branches are physically useful over its leg durations, and whether branch enumeration fits the evaluation budget. The next attempt should first probe or defensively detect wrapper capabilities, enumerate only a small set of plausible branches, retain the existing single-branch result as a fallback, and compare branches during both grid evaluation and DSM refinement. Missing knowledge also remains around a more efficient constrained global/local optimization of coupled launch, flyby, and terminal epochs; the Lambert documents do not resolve that search problem.
Stop: search budget exhausted
Web sources
Predictions are model estimates before evaluation.
poliastro-py.readthedocs.ioMultiple revolutions on Lambert's problem
Docs » Jupyter notebooks » Multiple revolutions on Lambert’s problem Edit on GitHub # Multiple revolutions on Lambert’s problem¶ After the implementation of Izzo’s algorithm in poliastro, it is possible to solve the Lambert’s problem with a multiple revolution solution. Let us remember first what is this problem about and which applications does it have. Lambert problem tries to solve the orbit that passes trhough \(\vec{r\_{0}}\) and \(\vec{r\_{f}}\) being given an amount of time usually denoted by \(\Delta t\). This can be used to solve for interplanetary flights, for example if we know the position of Earth at \(t\_{0}\) and the position of Mars at time \(t\_{f}\) we can solve for the orbit that we must follow in order to …
forum.orekit.orgOrekit Lambert Solver
I have some experiencing implementing Izzo's algorithm, so I might take a crack at it and see how it compares to the IOD package algorithm. I
docs.rslambert_izzo - Rust
## Crate lambert\_izzo # Crate lambert\_izzo Source Expand description Izzo’s revisited Lambert solver — single + multi-revolution, short/long way. Reference: D. Izzo, Revisiting Lambert’s problem, Celestial Mechanics & Dynamical Astronomy, 2014. arXiv:1403.2705. PDF in `docs/izzo.pdf`. Inline `Eq. N` / `Algorithm N` references in the source point to that paper. ## §Public API Two entry points: `lambert` — single Lambert solve from a `LambertInput`. `lambert_par` (`rayon` feature) — parallel batch solve over a slice of `LambertInput`s. Both return `LambertSolutions`, which always carries the single-revolution trajectory, every reachable multi-rev pair, and the per-branch `SolverDiagnostics` (Householder iteration counts). ## §Units [...] ## §Cargo features Both features are off by default. `serde` — derives `Serialize` + `Deserialize` on every public type, including `LambertError`. Stays …
www.esa.intRevisiting Lambert's problem
123 D. Izzo Fig. 5 Absolute errors introduced by the Gooding initial guess (left) and the proposed initial guess (right) for the single revolution M = 0 case. Each line correspond to a different λ value ranging from −0.99 to 0.99 Algorithm 1 Lambert solver: inputs, r1 = [r11,r12,r13], r2 = [r21,r22,r23], t and μ Require: t > 0, μ > 0 c = r2 −r1 c = |c|, r1 = |r1|, r2 = |r2| s = 1 2 (r1 + r2 + c) ˆ ir,1 = r1/r1, ˆ ir,2 = r2/r2 ˆ ih = ˆ ir,1 × ˆ ir,2 λ2 = 1 −c/s, λ = √ λ2 if (r11r22 −r12r21) < 0 then λ = −λ ˆ it,1 = …
docs.poliastro.spaceMultiple revolutions on Lambert's problem - poliastro
» Background » Multiple revolutions on Lambert’s problem Edit on GitHub # Multiple revolutions on Lambert’s problem¶ After the implementation of Izzo’s algorithm in poliastro, it is possible to solve the Lambert’s problem within the multi-revolution scenario. Before introducing the usage of this feature, let us remember what is the Lambert’s problem and explain some of the misconceptions behind the problem. ## Review of Lambert’s problem scenarios¶ The Lambert’s problem tries to solve for the orbit which passes trhough \(\vec{r\_{0}}\) and \(\vec{r\_{f}}\) being knwon the time of flight \(\Delta t\) between these two positions. It is, in fact, the boundary value problem (BVP) of the two body problem. There are two scenarios for solving Lambert’s problem:
docs.poliastro.spaceRevisiting Lambert’s problem in Python — poliastro 0.17.0 documentation
### Multiple revolutions¶ ``` k = Earth. k r0 =[22592.145603, -1599.915239, -19783.950506] u. km r =[1922.067697,4054.157051, -8925.727465] u. km tof = 10 u. h expected_va =[2.000652697,0.387688615, -2.666947760] u. km/ u. s expected_vb =[-3.79246619, -1.77707641,6.856814395] u. km/ u. s expected_va_l =[0.50335770,0.61869408, -1.57176904] u. km/ u. s expected_vb_l =[-4.18334626, -1.13262727,6.13307091] u. km/ u. s expected_va_r =[-2.45759553,1.16945801,0.43161258] u. km/ u. s expected_vb_r =[-5.53841370,0.01822220,5.49641054] u. km/ u. s ``` ``` v0, v = izzo. lambert(k, r0, r, tof, M = 0) v ``` $[-3.7924662,~-1.7770764,~6.8568144] \; \mathrm{\frac{km}{s}}$ [...] ### Single revolution¶ ``` k = Earth. k r0 =[15945.34,0.0,0.0] u. km r =[12214.83399,10249.46731,0.0] u. km tof =76.0 u. min expected_va =[2.058925,2.915956,0.0] u. km/ u. s expected_vb =[-3.451569,0.910301,0.0] u. km/ u. s v0, v = izzo. lambert(k, …
space.stackexchange.comMultiple revolution Lambert problem
The Lambert problem solution determines the ΔV required to transfer from r1 to r2 in t time. There are single and multiple revolution solutions
github.commultirevolutions-solution-in-lamberts-problem.myst.md - GitHub
A total of four solutions are found: Red orbit (high path) prograde. Red orbit (high path) retrograde. Blue orbit (low path) prograde. Blue orbit (low path)
investigacion.unirioja.esMulti-Revolution Perturbed Lambert's Problem
m , in which µ is the gravitational parameter and am = 1 4 (r1 + r2 + ||r1 −r2||). There are two solutions for each revolution number, thus there exists 2Nmax + 1 number of solutions to a MRLP. [...] (19) In Eq. (19), T r F f (vi) is a high order Taylor polynomial that maps a variation in the initial velocity to the final time in the full dynamical model. The Taylor representation of the residual is computed by subtracting r2 from Eq. (19), ∆r2 = rF f −r2 = T ∆r2(vi). (20) Eq. (20) can be inverted with DA tools, delivering vi = T vi (∆r2). (21) 7 An approximated solution of the problem is then …
www.mdpi.comAn Effective Multi-Revolution Lambert Solver Based on ...
Multi-revolution Lambert solvers are intended to find the elliptic transfer orbits that are traveled multiple times and connect two specified positions in prescribed time, under the assumption of considering natural (Keplerian) orbital motion in the presence of a single attracting body. This study proposes and tests a new, effective multi-revolution Lambert solver that employs the initial true anomaly, which identifies the initial position along the transfer ellipse, as the unknown variable. The related search interval is identified through closed-form expressions for upper and lower bounds. A simple numerical algorithm is developed and employed over the entire search interval to detect all Lambert solutions. The new multi-revolution solver proposed in this work is simple to understand [...] Multi-revolution Lambert solvers are …
docs.poliastro.spacepoliastro.core.iod — poliastro 0.17.0 documentation
» API reference » `poliastro.core` » `poliastro.core.iod` Edit on GitHub # `poliastro.core.iod`¶ ## Module Contents¶ ### Functions¶ | `vallado`(k, r0, r, tof, M, prograde, lowpath, numiter, rtol) | Solves the Lambert's problem. | | `izzo`(k, r1, r2, tof, M, prograde, lowpath, numiter, rtol) | Aplies izzo algorithm to solve Lambert's problem. | poliastro.core.iod.vallado(k, r0, r, tof, M, prograde, lowpath, numiter, rtol)¶ : Solves the Lambert’s problem. The algorithm returns the initial velocity vector and the final one, these are computed by the following expresions: \[\begin{split}\vec{v\_{o}} &= \frac{1}{g}(\vec{r} - f\vec{r\_{0}}) \\ \vec{v} &= \frac{1}{g}(\dot{g}\vec{r} - \vec{r\_{0}})\end{split}\] [...] Notes This procedure can be found in section 5.3 of Curtis, with all the theoretical description of the problem. Analytical example can be found …
docs.poliastro.spaceRevisiting Lambert's problem in Python - poliastro
``` _, v_l = izzo. lambert(k, r0, r, tof, M = 1, lowpath = True) _, v_r = izzo. lambert(k, r0, r, tof, M = 1, lowpath = False) ``` $[-5.5384132,~0.018222134,~5.4964102] \; \mathrm{\frac{km}{s}}$ $[-4.1833463,~-1.1326273,~6.1330709] \; \mathrm{\frac{km}{s}}$ [...] ### Multiple revolutions¶ ``` k = Earth. k r0 =[22592.145603, -1599.915239, -19783.950506] u. km r =[1922.067697,4054.157051, -8925.727465] u. km tof = 10 u. h expected_va =[2.000652697,0.387688615, -2.666947760] u. km/ u. s expected_vb =[-3.79246619, -1.77707641,6.856814395] u. km/ u. s expected_va_l =[0.50335770,0.61869408, -1.57176904] u. km/ u. s expected_vb_l =[-4.18334626, -1.13262727,6.13307091] u. km/ u. s expected_va_r =[-2.45759553,1.16945801,0.43161258] u. km/ u. s expected_vb_r =[-5.53841370,0.01822220,5.49641054] u. km/ u. s ``` ``` v0, v = izzo. lambert(k, r0, r, tof, M = 0) v ``` $[-3.7924662,~-1.7770764,~6.8568144] \; \mathrm{\frac{km}{s}}$ [...] …
pypi.orgpoliastro
poliastro is an open source pure Python package dedicated to problems arising in Astrodynamics and Orbital Mechanics, solution of the Lambert's problem,
docs.poliastro.spacepoliastro.iod.izzo — poliastro 0.17.0 documentation
New in version 0.5.0. Parameters : k (Quantity")) – Gravitational constant of main attractor (km^3 / s^2). r0 (Quantity")) – Initial position (km). r (Quantity")) – Final position (km). tof (Quantity")) – Time of flight (s). M (int"), optional) – Number of full revolutions, default to 0. prograde (boolean) – Controls the desired inclination of the transfer orbit. lowpath (boolean) – If True or False, gets the transfer orbit whose vacant focus is below or above the chord line, respectively. numiter (int"), optional) – Maximum number of iterations, default to 35. rtol (float"), optional) – Relative tolerance of the algorithm, default to 1e-8. Returns : v0, v – Pair of velocity solutions. [...] » API reference » `poliastro.iod` » `poliastro.iod.izzo` …
github.compoliastro/src/poliastro/iod/izzo.py at main
Astrodynamics in Python. prograde: boolean Controls the desired inclination of the transfer orbit. lowpath: boolean ` or `False`, gets the
No recorded documents for this selection.
04Code & measured result
8 candidate attemptsChange 1: Modified function `_candidate_intermediate_times`: Sample flyby epochs over the full tour, including Voyager phasing clusters. Change 2: 'n_grid = 5 if n_ga == 0 else 7' → 'n_grid = 5 if n_ga == 0 else (18 if n_ga >= 2 else 8)' Change 3: Near `try:...` (12→40 lines)
Code diff recorded excerpt+84−21
- slack = float(tf) - float(t0) - MIN_TOF * (n_ga + 1)+ usable_span = float(tf) - float(t0) - 2.0 * MIN_TOF- fractions = np.linspace(0.0, 1.0, n_ga + 2)[1:-1]- fractions = np.sort(rng.uniform(0.0, 1.0, n_ga))+ fractions = tuple(sorted(rng.uniform(0.03, 0.97, n_ga)))- float(t0) + MIN_TOF * (k + 1) + float(fractions[k]) * slack+ n_grid = 5 if n_ga == 0 else (18 if n_ga >= 2 else 8)- options={"maxiter": 250 * n_vars, "xatol": 1e-4, "fatol": 1e-6,- "initial_simplex": np.array(simplex[:n_vars + 1])})- if nodes_new is not None and dv_new < dv0 - 1e-6:+ rng_local = np.random.default_rng(RNG_SEED + 9173)+ perturb = rng_local.normal(0.0, 0.28, size=n_vars)+ starts.append(x0 + perturb * np.asarray(scales))+ if (nodes_new is not None and np.isfinite(dv_new)
