- Join over
**1.5M+ people** - Join over
**100K+ communities** - Free
**without limits** - Create
**your own community**

Does it still admit 2∗N+1 solutions? I'm having trouble conceptualizing it for exponential sinusoids. And I'll try to reason about how to find Nmax soon.

I'm confused as to how the Lambert solver will fit into the Multi-LTGA problem... Is it assumed that there is an impulse during a swingby?

I found this in the report, is this usable for finding Nmax ? >a particular heuristic has been implemented: for a given transfer the number

of allowable revolutions can not be larger than the ratio between the transfer time and the

shortest revolution period between the departure celestial body and the target celestial body

of allowable revolutions can not be larger than the ratio between the transfer time and the

shortest revolution period between the departure celestial body and the target celestial body

Could Nmax be computed by computing the max and min tof for each N ? Or this would be too slow?

The √θ˙1 graph is nicely symmetric

My idea is to ignore ϕ and k0 and μ and interpolate between the minima on either side of the origin

and then reconstruct the integral once we have a good polynomial representation of that slice with ϕ, k0, and μ in mind

I don't know how it will work performance-wise, but we can soon find out!

I looked at this a while ago: https://github.com/ChrisAndre/expsin/blob/master/TOF%20Quadrature.ipynb

I've put it directly into my PyKEP fork, but I've kept it isolated

I'll start commiting it to Github later today

The code is not great, I can't remember the last time I coded in cpp. It shouldn't be hard to fix bad form hopefully...

Do you use any performance tools for optimizing speed? I looked into valgrind/callgrind, but something C++-specific might be better.

https://gist.github.com/ChrisAndre/42bd5682b282cea27b30 will run an example

It will attempt to detect the maximum number of revolutions for the first direction and solve all of them. Right now it has trouble if feasible solutions require revolutions greater than zero (change lw to False to see), so I will fix that today. Or the last parameter in the constructor can be set to some revolution number and it will only try that one.

Sorry for the wait, I wrote up a progress report. The core is complete (I hope!) https://github.com/ChrisAndre/expsin/blob/master/Exposin%20Project.ipynb

It should be suitable to try out now. I added an extra test in https://github.com/ChrisAndre/expsin/blob/master/Exposin%20Project.ipynb to reproduce one of the graphs from the study but I had no luck in getting similar results.

I still did not have time to review your exp sin work .. will try to do so in conjunction with another module that includes some debris simulation stuff

Hey Dario, it was great to meet you in Napa at the conference. Unfortunately I was not able to speak with you long. I understand that PyKEP/PaGMO are on hold for now, but I am still interested in doing some work on some of your projects. Do you have any simple work that needs to be done?

I was also considering implementing a general thrust-law propagator sometime soon and was wondering if you would be interested in merging that into PyKEP... does that sound like a good fit for the toolkit?

As we do not have much time these days to follow the projectc, we would only merge pull requests that need close-to-zero work from our side