Add Transit Least Squares algorithm to search for periodic transits

I am the author of Transit Least Squares, an optimized transit-fitting algorithm to search for periodic transits of small planets. Is it of interest to include TLS into lightkurve? As of now, there is only BLS integrated.

Rationale

While the commonly used Box Least Squares (BLS, Kovács et al. 2002) algorithm searches for rectangular signals in stellar light curves, TLS searches for transit-like features with stellar limb-darkening and including the effects of planetary ingress and egress. Moreover, TLS analyses the entire, unbinned data of the phase-folded light curve. These improvements yield a ~10 % higher detection efficiency (and similar false alarm rates) compared to BLS.

TLS status

While TLS is relatively new, the paper has been accepted to A&A and the code is open source under the MIT license.
The code quality is good to be used productively in large-scale surveys.
We are currently re-examining Kepler and K2 data using compute clusters.
We have detected many strong planet candidates with TLS which are undetectable with BLS (papers in prep.).
We are also working on integrating TLS into the TESS Quick Look Pipeline

Inputs and robustness

TLS needs a detrended and normalized-to-unity-flux light curve as input. It must contain time and flux values, and uncertainties can be provided. The data should be detrended before feeding it to TLS so that most of the stellar variation is removed. A sliding median with a window of 1-day width is often a good choice.

TLS is build to be robust to any kind of data. It automatically removes nan, inf, and other values which are not usable. It warns the user if the data appears to be dubious, e.g. if its mean is not close to unity. We have tested TLS with thousands of K2 light curves and it processed every single one.

TLS API and output

TLS has been designed with a similar interface as the BLS implementation in Astropy:

from transitleastsquares import transitleastsquares
model = transitleastsquares(time, flux)
results = model.power()

Its return values (results.XYZ) are documented here. TLS provides:

Spectra, such as the well-known SDE-ogram (but in its cleanest version)
Statistics, such as the peak SDE, best period, T0, duration, and transit depth
Diagnostics such as odd-even metrics, SNR, Rp/R*, depths and uncertainties of each individual transit, and much more
Models such as the best-fit transit model, also available in a phase-folded form

A number of visualizations can be found at the tutorials.

Useful links

Questions:

Is it of interest to include TLS into lightkurve?
If yes, how can this be done without duplicating the code base? I can not maintain a fork in addition to the main TLS. There are many feature requests open for TLS and much development is expected for the future. In contrast to BLS which is 17 years old, TLS will grow and change a lot in the next years.
Are there any requirements/feature requests from your side? I am open to modify TLS in order to make it useful for everybody.

Thank you for opening this issue @hippke, and congratulations with your work on transitleastsquares. It looks like a very innovative and valuable piece of work!

I'd like to answer in more detail as soon as I get the chance to properly play around with transitleastsquares, but here are three quick initial thoughts:

The BoxLeastSquaresPeriodogram class in Lightkurve is a convenience interface which wraps astropy.stats.bls. We wanted a convenience wrapper because BLS is such a common operation (e.g. we wanted to make sure you can recover a planet in one line, example: lc.to_periodogram("bls").period_at_max_power). We did not want to duplicate Astropy's excellent BLS reference implementation, so we wrapped it.
Likewise, it would be fine in principle for Lightkurve to import the transitleastsquares package to enable e.g. lc.to_periodogram("tls").plot(). No fork or code duplication will be needed as long as the API of transitleastsquares remains reasonably stable.
Lightkurve does not intend to be the single package for light curve analysis, instead we hope it can provide the building blocks (or glue) for more advanced and experimental packages to use. Hence we'd like to limit Lightkurve to provide only widely-accepted and well-understood operations and data structures. Of course TLS is still brand new, so I'd be hesitant to have 100s of lines of code dedicated to it inside Lightkurve until the dust settles, but a ~10 line convenience wrapper can certainly be considered.

The first step would be for a simple demo to be created to show the benefit of integrating transitleastsquares with Lightkurve's LightCurve and Periodogram classes!

Again, thanks++ for opening the issue, and thank you for the new package and paper!

lightkurve / lightkurve