PyKEP is a scientific library providing basic tools for research in interplanetary trajectory design.
Good afternoon,
1 -
I am trying to use the class "pykep.propagate_taylor", but I get the following error:
Traceback (most recent call last):
File "<input>", line 1, in <module>
Boost.Python.ArgumentError: Python argument types in
pykep.core.core.propagate_taylor()
did not match C++ signature:
propagate_taylor(std::array<double, 3ull> r0=(1.0, 0.0, 0.0), std::array<double, 3ull> v0=(0.0, 1.0, 0.0), double m0=100, std::array<double, 3ull> thrust=(0.0, 0.0, 0.0), double tof=1.5707963267948966, double mu=1, double veff=1, int log10tol=1e-15, int log10rtol=1e-15)
I tried with the example given on the pykep page :
propagate_taylor(r0 = [1,0,0], v0 = [0,1,0], m = 100, thrust = [0,0,0], tof = pi/2, mu = 1, veff = 1, log10tol =-15, log10rtol = -15)
(I can run the class pykep.propagate_lagrangian)
2 -
I would also like to confirm that, for coherence, all units should be in SI, or all normalised coherently (for example, using AU for distance, Earth rotation period for time, and the initial spacecraft mass for mass).
kind regards,
Vasco Grilo
propagate_taylor(r0 = [1,0,0], v0 = [0,1,0], m0 = 100, thrust = [0,0,0], tof = pi/2, mu = 1, veff = 1, log10tol =-15, log10rtol = -15)
@darioizzo Thank you very much, I was using m instead of m0! I suggest you update the example given in
https://esa.github.io/pykep/documentation/core.html#pykep.propagate_taylor
as it has (r0, v0, m) instead of (r0, v0, m0).
2 - I would also like to confirm that, for coherence, all units should be in SI, or all normalised coherently (for example, using AU for distance, Earth rotation period for time, and the initial spacecraft mass for mass).
kind regards,
Vasco Grilo
Good afternoon,
I was trying to use lt_margo, but obtained the following error:
"self.__sc = pk.sims_flanagan._sims_flanagan.spacecraft(m0, Tmax, Isp)
AttributeError: module 'pykep.sims_flanagan' has no attribute '_sims_flanagan'"
Any insight would be appreciated.
Kind regards,
Vasco
Thank you very much, I am able to use lt_margo now! However, not with snopt7, I get the error message below. I have pykep 2.5, pygmo 2.13.0 (the last version is the 2.15.0) and pygmo-plugins-nonfree 0.10 (the last version is the 0.21). Are the last pygmo and pygmo-plugins-nonfree versions required? I did not manage to install them with pip in python 3.6.
ValueError:
function: evolve_version
where: C:\projects\pagmo-plugins-nonfree\src\snopt7.cpp, 617
what:
An error occurred while loading the snopt7_c library at run-time. This is typically caused by one of the following
reasons:
We report the exact text of the original exception thrown:
function: evolve_version
where: C:\projects\pagmo-plugins-nonfree\src\snopt7.cpp, 569
what: The snopt7_c library path was constructed to be: /usr/local/lib/libsnopt7_c.so and it does not appear to be a file
Tried pg.nlopt('slsqp') and it works quite well. I don't have the snopt library, has anyone compared nlopt('slsqp') with pg7.snopt7 for pk.trajopt.lt_margo ? is it much better?
Another question: Is there a tutorial how to configure the pygmo/pagmo archipelago topology for the trajopt/gym problems? I tried to beat the results from https://github.com/dietmarwo/fast-cma-es/blob/master/PYKEP.adoc using pygmo but this is harder than I thought.
Inspired by @DIEGOA363 from the pagmo2 gitter I tried the following:
ftol = 1E-6
G = 100
I = 64
M = 1
P = 500
algo = pg.algorithm(pg.de1220(gen = G, ftol=ftol))
topo = pg.topology(pg.fully_connected(w=1.0))
rp = pg.r_policy(pg.fair_replace(M))
sp = pg.s_policy(pg.select_best(M))
archi = pg.archipelago(n=I, t=topo, algo = algo, prob = prob, pop_size=P, r_pol=rp, s_pol=sp)
for i in range(100000):
archi.evolve()
archi.wait()
# output of the best ...
on a 32 core / 64 thread machine. Got all cores under load and got reasonable results for the easier gym problems. But for tandem(6) and messenger I couldn't reach the results from https://www.researchgate.net/publication/45913344_A_Global_Optimisation_Toolbox_for_Massively_Parallel_Engineering_Optimisation
With fcmaes both problems from https://github.com/esa/pykep/tree/master/pykep/trajopt/gym behave quite similar to their GTOP counterparts, but of course the PYTHON implementation is slower. Increasing to a population size to P=1500 I can at least reach the local minimum at -7.2 for tandem(6), but no improvement beyond 6000 for messenger. Perhaps a mix of algorithms could help?
Another question: Is there a tutorial how to configure the pygmo/pagmo archipelago topology for the trajopt/gym problems? I tried to beat the results from https://github.com/dietmarwo/fast-cma-es/blob/master/PYKEP.adoc using pygmo but this is harder than I thought.
No.
orbital_elements: a sequence of six containing a,e,i,W,w,M (SI units, i.e. meters and radiants)
Good evening,
In the M-ARGO preliminary trajectory design study (https://link.springer.com/article/10.1007/s42064-018-0024-y), I believe you mention that the optimal solution corresponds to a bang-bang thrust profile. In case the constraint d_E_NEO_arr <= 1 AU (where d_E_NEO_arr is the Earth-NEO distance at the end of the interplanetary transfer) to the M-ARGO (optimum control) Problem, would the optimum solution still correspond to a bang-bang control profile?
Kind regards,
Vasco
@mlooz @darioizzo
Updated solutions to compare all three solar orbiter models are at
https://gist.github.com/dietmarwo/86f24e1b9a702e18615b767e226e883f
solodsmtest.py - for pykep.trajopt.gym._solar_orbiter._solar_orbiter_udp_1dsm
solotest.py - for pykep.trajopt.gym._solar_orbiter._solar_orbiter_udp
solomgartest.py - for pykep.trajopt.gym._solar_orbiter._solo_mgar_udp
_solo_mgar_udp, _solar_orbiter_udp and _solar_orbiter_udp_1dsm are of increasing complexity. _solar_orbiter_udp_1dsm has much more dimensions and freedom than _solo_mgar_udp. The challenge is now to utilize this freedom by finding superior solutions - the given solutions are quite similar so far. Using the plot function of _solar_orbiter_udp and _solar_orbiter_udp_1dsm reveals that the plots are incomplete for multi revolution transfers - should be fixed in esa/pykep#127 .