Iteration 33
RetrieveGate decision
RetrieveReasoningAdditional evidence would help because the current deterministic local-search strategy repeatedly returns the same solution and the stored documents contain only high-level formulations or unrelated examples. A fresh…
Additional evidence would help because the current deterministic local-search strategy repeatedly returns the same solution and the stored documents contain only high-level formulations or unrelated examples. A fresh search focused on evaluator-compatible Lambert branches, Galileo VEEGA numerical solutions, and global optimization strategies could enable a genuinely different approach rather than another local rewrite.
Knowledge before this stepThe existing attempts established a valid Earth-to-Earth-to-Jupiter trajectory with one DSM and achieved a stable combined score of 0.636921, but three full rewrites converged to the same local solution. Retrieved…
The existing attempts established a valid Earth-to-Earth-to-Jupiter trajectory with one DSM and achieved a stable combined score of 0.636921, but three full rewrites converged to the same local solution. Retrieved documents confirm the general MGA-1DSM formulation, DSM epoch/fraction and Cartesian-position decision variables, and the usefulness of global evolutionary search, but they do not provide implementation-level guidance for this specific evaluator or explain whether alternative Lambert branches, broader epoch families, multiple-revolution solutions, or a different VEEGA topology can improve the current result. Prior searches were largely generic and did not resolve the plateau. The next attempt therefore needs new, specific knowledge about robust global optimization of the evaluator's Earth-Earth-Jupiter/possibly VEEGA topology, Lambert branch handling, and practical search bounds or known numerical solutions.
Population analysis
📊 State: The retained population has 40 programs with scores from 0.324205 to 0.636921, while the recent 20-row trace produced 13 parent-relative improvements, 7 regressions, and 0 global improvements.
Key Numbers:
• Score distribution: mean 0.598851, median 0.636872, population standard deviation 0.073622, with quartiles at 0.606500 and 0.636921.
• Best score: 0.6369210202615427; worst score: 0.32420549034128876; unique exact scores: 21 among 40 programs.
• Current parent score: 0.6369210201024604, with a gap of 1.590823028863042e-10 to the retained best.
• Recent trace scores ranged from 0.6311069623314922 to 0.6369210202615427 across iterations 13–32.
Patterns Observed:
• Recent parent-relative outcomes included 13 improved rows and 7 regressed rows, but all 20 rows were marked “not_improved” globally.
• Parent selection used 20 slots across 14 unique IDs; the most-selected parent appeared 3 times, or 15% of slots.
• Context selection used 48 slots across 24 unique IDs; the most-selected context appeared 8 times, or 53.33% of programs with selection.
Query · round 1
"Galileo EVEEJ" VEEGA MGA-1DSM Lambert long-way high-path multi-revolution final Earth-Jupiter leg numerical solution
Determine whether long-way, high-path, retrograde, or multi-revolution Lambert branches on the DSM or final Earth-Jupiter leg produce lower-cost feasible Earth-Earth-Jupiter/VEEGA trajectories, and find implementation details or numerical seeds for evaluating those branches.
Query rationale
The current optimizer hard-codes prograde, low-path, apparently zero-revolution Lambert solutions on the final leg and uses default Lambert settings elsewhere, while repeated local rewrites converge to the same plateau. A source describing branch enumeration, multi-revolution handling, or known Galileo EVEEJ solutions could enable systematic branch comparison and better global-search seeds without changing the evaluator's topology.
What this round establishedThe new documents reinforce that multiple-revolution, high/low-path, and prograde/retrograde Lambert branches can create distinct valid solutions, and that the MGA-1DSM decision vector should include leg times, DSM…
The new documents reinforce that multiple-revolution, high/low-path, and prograde/retrograde Lambert branches can create distinct valid solutions, and that the MGA-1DSM decision vector should include leg times, DSM timing fractions, and maneuver geometry. The EVEEJ literature also confirms that final-leg duration and discrete Lambert revolution choices can materially affect global optima. However, none of the documents supplies a numerical solution for this evaluator, exposes the available Tools.lambert branch or multi-revolution API, or establishes that nonzero-revolution or long-way branches are feasible and beneficial under the current epoch windows and flyby constraints. The current implementation still only tests one fixed branch on the Earth-to-Jupiter leg and relies on local Nelder-Mead searches around one epoch family. Thus the main remaining uncertainty is implementation-level: branch enumeration and robust global exploration remain untested, as do alternative topologies such as VEEGA with Venus and additional DSMs. No further generic formulation knowledge is needed; the next attempt should test these concrete branches/topologies or inspect the evaluator and Lambert wrapper interfaces directly.
Kept-document mean prediction 0.63694
Query · round 2
"Tools.lambert" "tools_wrapper.py" prograde lowpath multi-revolution source code
Determine the exact Lambert wrapper signature and whether it supports long-way, high-path, retrograde, or multi-revolution branches so the optimizer can safely enumerate and evaluate alternative Earth-to-Jupiter transfer branches.
Query rationale
The current program hard-codes a single prograde low-path zero-revolution Lambert branch on the final leg, while the retrieved literature only establishes that other branches may exist. The main unresolved implementation detail is how this specific Tools.lambert interface exposes those branches and what return format or revolution parameter it requires. Finding concrete wrapper documentation or source code would enable a targeted branch-enumeration experiment without destabilizing the known valid solution.
What this round establishedThe new documents reinforce that multiple-revolution, high/low-path, and prograde/retrograde Lambert branches can create distinct valid solutions, and that the MGA-1DSM decision vector should include leg times, DSM…
The new documents reinforce that multiple-revolution, high/low-path, and prograde/retrograde Lambert branches can create distinct valid solutions, and that the MGA-1DSM decision vector should include leg times, DSM timing fractions, and maneuver geometry. The EVEEJ literature also confirms that final-leg duration and discrete Lambert revolution choices can materially affect global optima. However, none of the documents supplies a numerical solution for this evaluator, exposes the available Tools.lambert branch or multi-revolution API, or establishes that nonzero-revolution or long-way branches are feasible and beneficial under the current epoch windows and flyby constraints. The current implementation still only tests one fixed branch on the Earth-to-Jupiter leg and relies on local Nelder-Mead searches around one epoch family. Thus the main remaining uncertainty is implementation-level: branch enumeration and robust global exploration remain untested, as do alternative topologies such as VEEGA with Venus and additional DSMs. No further generic formulation knowledge is needed; the next attempt should test these concrete branches/topologies or inspect the evaluator and Lambert wrapper interfaces directly.
Kept-document mean prediction 0.63695
Query · round 3
GitHub PyKEP Lambert problem multi-revolution highpath lowpath prograde get_v1 get_v2 API
Determine the exact Lambert branch-enumeration API and returned velocity ordering needed to test zero- and multi-revolution, high/low-path, and prograde/retrograde branches in the current Earth-Earth-Jupiter optimizer.
Query rationale
The current program hard-codes a single prograde low-path zero-revolution branch, while the best known solution has plateaued under local Nelder-Mead searches. Existing documents establish that alternative branches can matter but do not reveal the evaluator's Tools.lambert interface. Concrete API details would enable a safe branch-enumeration layer and targeted global exploration without guessing unsupported arguments or corrupting trajectory node velocities.
What this round establishedThe new documents reinforce that multiple-revolution, high/low-path, and prograde/retrograde Lambert branches can create distinct valid solutions, and that the MGA-1DSM decision vector should include leg times, DSM…
The new documents reinforce that multiple-revolution, high/low-path, and prograde/retrograde Lambert branches can create distinct valid solutions, and that the MGA-1DSM decision vector should include leg times, DSM timing fractions, and maneuver geometry. The EVEEJ literature also confirms that final-leg duration and discrete Lambert revolution choices can materially affect global optima. However, none of the documents supplies a numerical solution for this evaluator, exposes the available Tools.lambert branch or multi-revolution API, or establishes that nonzero-revolution or long-way branches are feasible and beneficial under the current epoch windows and flyby constraints. The current implementation still only tests one fixed branch on the Earth-to-Jupiter leg and relies on local Nelder-Mead searches around one epoch family. Thus the main remaining uncertainty is implementation-level: branch enumeration and robust global exploration remain untested, as do alternative topologies such as VEEGA with Venus and additional DSMs. No further generic formulation knowledge is needed; the next attempt should test these concrete branches/topologies or inspect the evaluator and Lambert wrapper interfaces directly.
Kept-document mean prediction 0.63701
Evidence sent to the solver
"Galileo EVEEJ" VEEGA MGA-1DSM Lambert long-way high-path multi-revolution final Earth-Jupiter leg numerical solution
"Tools.lambert" "tools_wrapper.py" prograde lowpath multi-revolution source code
GitHub PyKEP Lambert problem multi-revolution highpath lowpath prograde get_v1 get_v2 API
Knowledge after searchThe new documents reinforce that multiple-revolution, high/low-path, and prograde/retrograde Lambert branches can create distinct valid solutions, and that the MGA-1DSM decision vector should include leg times, DSM…
The new documents reinforce that multiple-revolution, high/low-path, and prograde/retrograde Lambert branches can create distinct valid solutions, and that the MGA-1DSM decision vector should include leg times, DSM timing fractions, and maneuver geometry. The EVEEJ literature also confirms that final-leg duration and discrete Lambert revolution choices can materially affect global optima. However, none of the documents supplies a numerical solution for this evaluator, exposes the available Tools.lambert branch or multi-revolution API, or establishes that nonzero-revolution or long-way branches are feasible and beneficial under the current epoch windows and flyby constraints. The current implementation still only tests one fixed branch on the Earth-to-Jupiter leg and relies on local Nelder-Mead searches around one epoch family. Thus the main remaining uncertainty is implementation-level: branch enumeration and robust global exploration remain untested, as do alternative topologies such as VEEGA with Venus and additional DSMs. No further generic formulation knowledge is needed; the next attempt should test these concrete branches/topologies or inspect the evaluator and Lambert wrapper interfaces directly.
Stop: search budget exhausted
Web sources
Predictions are model estimates before evaluation.
investigacion.unirioja.esMulti-Revolution Perturbed Lambert's Problem
r1 and v1 are the position and velocity vectors of the first body at ti, and r2 and v2 are the position and velocity vectors of the second body at t f , see Figure 1. The total cost of the transfer is the impulse to inject the spacecraft on the transfer arc ∆v1 = ||vi −v1|| and the impulse for the rendezvous ∆v2 = ||v2 −vf ||. The classical formulation of the Lambert problem considers Keplerian motion. In such case, there is no need to numerically propagate the transfer trajectory and the problem reduces to the numerical solution of a nonlinear equation. When the time-of-flight is sufficiently long multiple solutions appear associated with different number of revolutions. The maximum …
fenix.tecnico.ulisboa.ptPreliminary Trajectory Design of a Mission to Enceladus
Decision Vector The decision vector, also referred to as chromosome, is the vector that contains all of the problem’s optimisation variables that define an individual . This vector contains all the parameters that describe the departure geometry, the epoch at which the spacecraft passes by planets, and more. For the MGA-1DSM problem it is defined as p = [ts, V∞0, u0, v0] + [η1, T1] + [rp2, β2, η2, T2] + . . . [...] 4.2.2 Simplified Form of the Problem The simplified and final form of the MGA-1DSM problem is: Optimise: φ(p), (4.2a) Subject to: G(p) ≤0, boundary constraints (4.2b) where φ is the objective function and p is the decision vector. No phase constraints are left as they …
arc.aiaa.orgLambert-Free Solution of Multiple-Gravity-Assist Optimization ...
### A. Fixed Departure Date and Launch v∞ As a first example of the MGA optimization problem, the classical Earth–Venus–Earth–Earth–Jupiter sequence is considered with the following constraints: 1. The departure date is 22 September 2022 at 0000 hrs Coordinated Universal Time (UTC). 2. The initial relative velocity is v1,∞=4km/s. 3. The minimum altitude for Venus and Earth flybys is 300 km. 4. The maximum M values allowed for each sequence leg are [4,2,4,0]. 5. The maximum transfer duration for the final Earth–Jupiter leg is 1600 days. [...] ## II. Problem Description and Modeling ### A. MGA Optimization Problem and Constraints The MGA optimization problem discussed in this work can be summarized as follows. Consider a spacecraft departing at epoch t1 …
amostech.comThe Superior Lambert Algorithm
of Vinti. The outstanding works of the late Professor Sun, regarding the multi-revolution Lambert problem, have been invaluable in developing this analytic solution. Similar to the analytic solution of a Kepler algorithm, the analytic solution of a Lambert algorithm is not in closed form; an iterative method must be used to deduce a numerical solution. Contrary to the analytic solution of a Kepler algorithm, the analytic solution of a Lambert algorithm should be understood and visualized using any formulation, with or without universal variables. Any multiple-revolution Lambert problem has only elliptic solutions, and the conic solutions for trajectories less than one revolution can be simple, if the independent or unknown iteration parameter is chosen wisely. Since the initial value for …
satkit.devTheory: Lambert's Problem - SatKit
\[ T' = \frac{3Tx - 2 + 2\lambda^3 x / y}{1 - x^2} \] \[ T'' = \frac{3T + 5xT' + 2(1-\lambda^2)\lambda^3 / y^3}{1 - x^2} \] \[ T''' = \frac{7xT'' + 8T' - 6(1-\lambda^2)\lambda^5 x / y^5}{1-x^2} \] ### Velocity Reconstruction¶ Velocities are decomposed into radial and tangential components using the solution \(x\): \[ v\_{r,1} = \frac{\gamma}{r\_1}\left[(\lambda y - x) - \rho(\lambda y + x)\right], \quad v\_{t} = \frac{\gamma \sigma (y + \lambda x)}{r} \] where \(\gamma = \sqrt{\mu s / 2}\), \(\rho = (r\_1 - r\_2)/c\), and \(\sigma = \sqrt{1 - \rho^2}\). Angular momentum conservation is guaranteed by construction since the tangential momentum \(r \cdot v\_t = \gamma \sigma (y + \lambda x)\) is the same at both …
docs.poliastro.spaceMultiple revolutions on Lambert's problem - poliastro
When `is_prograde=True`, solution orbit has an inclination less than \(\text{inc} < 180\) degrees (prograde orbit). Otherwise, when `is_prograde=False`, solution orbit inclination has \(\text{inc} > 180\) degrees (retrograde orbit.) ### Type of transfer path: low or high¶ The type of path is a boolean variable which allows the user to filter out the solution when two of them are found. Multiple solutions only appear in the multi-revolution case. The geometry of this scenario is presented in the figure below: Notice there are a total of two orbits (red and blue) connecting the position vectors \(\vec{r\_1}\) to \(\vec{r\_2}\). A total of four solutions are found: [...] ``` frompoliastro.maneuver import Maneuver def lambert_solution_orbits(orb_departure, orb_arrival, M): """Computes all available solution orbits to the Lambert's …
github.comjorgepiloto/lamberthub: A set of Lambert's problem solvers - GitHub
| Rank | Solver | Revolutions | prograde | Path | Median (µs) | Mean (µs) | IQR (µs) | Speedup | Rounds | --- --- --- --- --- | | 1 | `mcelreath2025` | 1 | No | high | 47.7 | 48.8 | 0.7 | 13.2x | 4238 | | 2 | `der2011` | 1 | No | high | 49.8 | 50.7 | 0.7 | 12.7x | 4089 | | 3 | `izzo2015` | 1 | No | high | 61.6 | 63.9 | 1.1 | 10.2x | 3332 | | 4 | `gooding1990` | 1 | No | high | 97.1 | 99.8 | 2.2 | 6.5x | 2110 | | 5 | `arora2013` | 1 …
investigacion.unirioja.esMulti-Revolution Perturbed Lambert's Problem
sin 2θ′ + R′ 1 −2s′2 2Θ′ cos 2θ′ {ν′, W1} = −R2 ec′ 2p′ " 3 φ′ p′ + R′ Θ′ ! + 1 2p′ −2 r′ ! sin 2θ′ + R′ Θ′ cos 2θ′ # {R′, W1} = 1 4 R2 eR′ 2 −3s′2 β′ r′2 + η′ p′2 ! −R2 es′2Θ′ 2p′r′2 sin 2θ′ {Θ′, W1} = R2 es′2 p′ " Θ′ 1 r′ −1 4p′ ! cos 2θ′ + R′ 2 sin 2θ′ # {N ′, W1} = 0 where β′ = 1/(1 + η′) and p′ = Θ′2/µ. [...] as the average over the fastest angle l′: K1 = 3R2 eµ4s′2 4L′6η′3 − R2 eµ4 2L′6η′3 (5) and …
www.semanticscholar.orgAn 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
esa.github.ioPaGMO: Lambert.cpp Source File
31 problem through the variable X=log(1+cos(alpha/2)). By doing so the 32 graphs of the time of flight become defined in the entire real axis and 33 resembles a straight line. Convergence is granted within few iterations 34 for all the possible geometries (except, of course, when the transfer 35 angle is zero). When multiple revolutions are considered the variable is 36 X=tan(cos(alpha/2)\pi/2). 37 38 2) Once the orbit has been determined in the plane, this routine 39 evaluates the velocity vectors at the two points in a way that is not 40 singular for the transfer angle approaching to pi (Lagrange coefficient 41 based methods are numerically not well suited for this purpose). 42 43 As a result Lambert's problem …
github.compykep/src/lambert_problem.cpp at master
s << "lambda = " << lp.m\_lambda << std::endl; s << "non dimensional time of flight = " << lp.m\_tof \ sqrt(2 \ lp.m\_mu / lp.m\_s / lp.m\_s / lp.m\_s) << std::endl << std::endl; s << "Maximum number of revolutions: " << lp.m\_Nmax << std::endl; s << "Solutions: " << std::endl; s << "0 revs, Iters: " << lp.m\_iters << ", x: " << lp.m\_x << ", a: " << lp.m\_s / 2.0 / (1 - lp.m\_x \ lp.m\_x) << std::endl; s << "\tv1 = " << "[" << lp.m\_v0 << ", " << lp.m\_v0 << ", " << lp.m\_v0 << "]"; s << " v2 = " << "[" << lp.m\_v1 << ", " << lp.m\_v1 << ", " …
github.comLambert's problem returning Nan for solutions · Issue #85 · esa/pykep · GitHub
Lambert's problem: mu = 1 r1 = [-25216645728.283768, 144924279081.32498, -38276.915766745136] r2 = [23677305175.045235, 231466356243.12106, 4266858429.7063341] Time of flight: 12960000 chord = 99490481765.445 semiperimeter = 239652783689.69 lambda = -0.7647586039895 non dimensional time of flight = 1.5622347089048e-010 Maximum number of revolutions: 0 Solutions: 0 revs, Iters: 2, x: 10144799071.114, a: -1.1643018370483e-009 v1= [5023.8501386881999, -28872.906706436665, 0.007625815528971497] v2= [2981.7979772545937, 29149.681847056359, 537.34619463111062] Lambert's problem: mu = 1 r1 = [-25216645728.283768, 144924279081.32498, -38276.915766745136] r2 = [-75608690053.379578, 228832446904.45093, 6651899885.3798294] Time of flight: 17280000 chord = 98102941036.502 semiperimeter = [...] of flight: 17280000 chord = 98102941036.502 semiperimeter = 243148200110.85 lambda = 0.77235371442086 non dimensional time of flight = 2.0382251088785e-010 Maximum number of revolutions: 0 Solutions: 0 revs, Iters: 1, x: nan, a: nan v1= [-nan, -nan, -nan] v2= …
github.commultirevolutions-solution-in-lamberts-problem.myst.md - GitHub
A total of four solutions are found: Red orbit (high path) prograde. Blue orbit (low path) prograde. Blue orbit (low path) retrograde.
github.comjorgepiloto/lamberthub: A set of Lambert's problem solvers - GitHub
## Using a solver Any Lambert's problem algorithm implemented in `lamberthub` is a Python function which accepts the following parameters: ``` from lamberthub import authorYYYY v1 v2 = authorYYYY mu r1 r2 tof M = 0 is_prograde = True is_low_path = True # Type of solution maxiter = 35 atol =1e-5 rtol =1e-7 full_output = False # Iteration config ``` where `author` is the name of the author which developed the solver and `YYYY` the year of publication. Any of the solvers hosted by the `ALL_SOLVERS` list. ### Parameters [...] | Rank | Solver | Revolutions | prograde | Path | Median (µs) | Mean (µs) | IQR (µs) | Speedup | Rounds | --- --- --- --- --- | …
esa.intPykep | ACT of ESA
# Advanced Concepts Team ## pykep 24 Sept 2017 # Pykep pykep is a scientific library providing basic tools for astrodynamics research. Algoritmic efficiency is a main focus of the library, which is written in C++ and exposed to Python. At the library core is the implementation of an efficient solver for the multiple revolutions Lambert’s problem, objects representing direct (Sims-Flanagan), indirect (Pontryagin) and hybrid methods to represent low-thrust optimization problems , efficient keplerian propagators, Taylor-integrators, a SGP4 propagator, TLE and SATCAT support and more.
No recorded documents for this selection.
04Code & measured result
8 candidate attemptsFull rewrite
Code diff recorded excerpt+275−348
+from scipy.optimize import differential_evolution, minimize- src = problem["start"] if "state_r" in problem["start"] else problem["end"]- return np.asarray(src["state_r"], float), np.asarray(src["state_v"], float)- term = (4.0 * np.pi ** 2 * mu ** 2 / period ** 2) ** (1.0 / 3.0)+ alt = float(problem.get("flyby", {}).get("min_altitude_km", {}).get(pid, 200.0))+ planets = [str(problem["start"]["planet_id"])] + list(map(str, seq)) + [+ penalty += 1.0e5 * np.sum(np.maximum(MIN_TOF - np.diff(x), 0.0))+ candidates = [result.x] + [np.asarray(s, float) for s in seeds]+ return float(value), [start, dsm, ga_node, end] if build else None+ p = 1.0e5 * np.sum(np.maximum(MIN_TOF - np.diff(y[:3]), 0.0))+ allowed = {str(x) for x in problem.get("allowed_GA_planets", [])}- frac0 = np.clip((td0 - seed[0]) / max(seed[1] - seed[0], 1.0), 0.12, 0.88)- allowed = {str(x) for x in problem.get("allowed_GA_planets", [])}- value, nodes = _direct_earth_jupiter([t0, t0 + MIN_TOF, tj], build=True)