Description
Describe the bug
When running TLS on light curves from the prime Kepler mission, the algorithm sometimes (but not always) fails to find viable solutions, even though alternative implementations of BLS succeed. The following warning is raised: transitleastsquares/main.py:205: UserWarning: No transit were fit. Try smaller "transit_depth_min", and the chi2 at all proposed periods is returned as the number of data points in the light curve. Per #86, this is because TLS is not finding any proposed periods or durations that give a lower chi^2 residual than just a pure straight line. The point of this bug report is that there is a set of Kepler light curves for which TLS should be finding good, finite solutions, but it seems to not be doing so.
To Reproduce
Using TLS version 1.0.31, attached are two light curves that exemplify the bug:
KOI-7368_npoints50000.csv
KOI-7368_npoints5000.csv
When I run TLS on the former light curve, I get the aforementioned chi2 = 50,000 for all cases. When I run it on the latter, which is just the first 5,000 points of the same time-series, I get a finite periodogram.
Here's a MWE:
import pandas as pd, numpy as np
from transitleastsquares import transitleastsquares
import multiprocessing as mp
n_threads = mp.cpu_count()
csvpath = 'KOI-7368_npoints50000.csv'
df = pd.read_csv(csvpath)
time, flux = np.array(df.time), np.array(df.flux)
model = transitleastsquares(time, flux, verbose=True)
results = model.power(
use_threads=n_threads, show_progress_bar=True, R_star=0.88,
R_star_min=0.85, R_star_max=0.91, M_star=0.88, M_star_min=0.85,
M_star_max=0.91, period_min=5, period_max=10, n_transits_min=10,
transit_template='default', transit_depth_min=10e-6, oversampling_factor=5
)
# raises the following warning:
# /home/lbouma/miniconda3/envs/py37/lib/python3.7/site-packages/transitleastsquares/main.py:205:
# UserWarning: No transit were fit. Try smaller "transit_depth_min"
print(results['period'])
# gives nan! (since the chi^2 = 50,000 == the number of data points for all
# proposed periods)
Desktop (please complete the following information):
- OS: Linux (debian). Have also gotten the behavior on MacOS.
- Python version: 3.7 and 3.8
- TLS Version: 1.0.31
Additional context
Dependence on parameters that shouldn't matter
This behavior seems to change with both 1) the number of data points in the light curve 2) the amplitude of the transit signals in the data. I've described the first (e.g., using 5,000 points, the above code gives finite results). Regarding the second, if one injects a large transit signal into the data, TLS sometimes actually converges, and finds the correct period. However this signal needs to be much larger than transit_depth_min (like ~2000 ppm depth, versus the 10 ppm default minimum). I think this behavior might suggest that the root problem could be related to the default TLS period grid, but I'm not certain.
The desired behavior
The KOI-7368 light curve I attached has had a stellar rotation signal removed. It contains a real 6.843 day transit with depth ~500ppm, and also an injected 7.202 day transit with depth 400 ppm. It would be nice if we could get TLS to find these signals.
Here's the periodgram astropy bls gives (takes hours to run b/c not multithreaded):
Here's the periodogram astrobase bls gives (with a different searched period grid)