Speed up transit calculations

[rodluger]

Currently four orders of magnitude (!!!) slower than the Mandel and Agol model because I'm solving for the points of intersection between the planet and the concentric circles numerically. This is analytic!

[rodluger]

While I'm at it, I should find a better solver for the quartic, as the current one spends a lot of time finding imaginary roots.

[ericagol]

You should be able to tell from some simple algebra whether there are two or four roots... Eric Agol Astronomy Professor University of Washington

…

On Jul 13, 2017, at 8:18 PM, Rodrigo Luger ***@***.***> wrote: While I'm at it, I should find a better solver for the quartic, as the current one spends a lot of time finding imaginary roots. ― You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[rodluger]

I replaced the numerical stuff with analytic expressions when the ellipses are circles, but it only sped up the code by a factor of 10. Currently there's a ton of overhead that comes along with my integration scheme, which requires sorting all the boundary functions. It also subdivides the occulted body into way more segments than is necessary when the curves of constant brightness are circles. So I'm going to add a module to compute light curves using the batman algorithm -- which is really a special case of our algorithm, but is definitely optimized.

[rodluger]

Optimized several things about the code. It's now a factor of < 10 slower than batman for transit calculations, so I'm going to put that on the back burner for now. Airless PPO calculations are still slow -- I need to implement a faster quartic solver still.

[rodluger]

Switched from the Numerical Recipes algorithm to the open source GSL code for computing polynomial roots so that we don't infringe the (very silly) copyright.

[rodluger]

I implemented an algorithm that finds the roots numerically using Brent's method. This is advantageous in that it doesn't waste time finding imaginary roots and is more stable than the polynomial solver. However, it's actually slower, at least in Python. Perhaps in C it will be faster than the polynomial solver, but I'm not that hopeful.

[PS-OnGit]

Could it help to change the integrator for the rebound simulations to a less accurate one, while keeping the current precission?
Or give the option to choose the integrator?

It seems that there has been an attempt on this, bit yet without success..