<p>I think you may be seeing the planet in the periodogram! But also another signal - higher harmonics of other periodic signals</p>

<p><a href="https://i.sstatic.net/Y9WjF.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Y9WjF.jpg" alt="https://en.wikipedia.org/wiki/Solar_cycle"></a>example - various periodic signals in our sun - with a characteristic period of 11 years (in the bottom panel you also see Earth's, as this is a local measure, and thus is mostly affected by our distance from the sun)</p>

<p>Patterns of stellar activity often have some long frequency of periodicity - starspots on our sun are a great example - and you may be seeing the higher harmonics of those signals here - they often have amplitudes much larger than the planetary signal and are often responsible for the noise-floor* of the system</p>

<p>*the smallest amplitude signal we could pick out from the lightcurve</p>

<p>If you actually wanted to retrieve the periodogram signal of the planet you could think about estimating this noise and subtracting it</p>

<p><a href="https://i.sstatic.net/qfJlT.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/qfJlT.png" alt=""></a></p>

<p>a sketch of the effect - each hill is a harmonic (roughly <span class="math-container">$sinc^2$</span>) peak - spaced like mountains receding into the distance. note that in a periodogram error in the power grows with the period for a finite length dataset - there's a smaller number of those periods observed - and hence it's the closest peaks which are most difficult to resolve. </p>

<p>These are exactly the kind of peaks you pick up on in the planet for which the process works - you have the peak at 2.2 days, but also 1.1 (=2.2/2), ~0.7 (=2.2/3) and below, each with less power - but also other periodic signals doing the same giving the other peaks. They may or may not be planets (for example they can be clumps of starspots) but they are real signals going on in the star (or some other object in the frame).</p>

<p><a href="https://i.sstatic.net/aBtfQ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/aBtfQ.png" alt="enter image description here"></a></p>

<p>Below you can see an example of the effect of changing the observational error (rows) and the number of data points (columns) in mock data.</p>

<p><a href="https://i.sstatic.net/Zlp94.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Zlp94.png" alt="https://ui.adsabs.harvard.edu/abs/2019MNRAS.488.4181P/abstract"></a>
figure from <a href="https://ui.adsabs.harvard.edu/abs/2019MNRAS.488.4181P/abstract" rel="nofollow noreferrer">this paper</a></p>

<p>So to summarise - you're not doing anything wrong, the planet's just small and there's a lot of noise. If you really want to drill down to the planetary signal you'd need to remove that noise - not an easy task but an interesting and seemingly possible one.</p>

CC BY-SA 4.0
2020-06-07T10:16:43.043Z
also you might want to try PDCSAP flux (instead of SAP) - the exact details are a bit arcane but it mostly focuses on removing telescope based systematics and *shouldn't* (but probably can in some edge cases) effect the planetary signal
zephyr
CC BY-SA 4.0
2020-06-06T19:07:13.857Z
2020-06-06T19:07:13.857Z
zephyr
<p>The second light curve you show has no obvious periodic behaviour and I cannot see any sign of a planetary transit. The period-finding algorithm appears to be working correctly.</p>

<p>The planet (if it exists) is supposed to be one of the smallest planetary candidates found by Kepler and will have a barely detectable transit (depth of order 0.004%). The small light curve variations you see are either from the star or remaining instrumental artefacts. If you wish to verify or otherwise the results published by <a href="https://arxiv.org/abs/1605.02825" rel="noreferrer">Morton et al. (2016)</a>, who show no light curves, you will have to do considerably more work to "detrend" the other variability in the light curve.</p>

CC BY-SA 4.0
2020-06-06T08:39:22.443Z
2020-06-06T08:39:22.443Z
ProfRob
<p>I am using astropy and I would like to calculate orbital period of an exoplanet by its star's light curve. I follow <a href="https://docs.astropy.org/en/stable/timeseries/" rel="noreferrer">tutorial</a> in astropy docs and I use data from Kepler in <a href="https://exoplanetarchive.ipac.caltech.edu/bulk_data_download/" rel="noreferrer">Nasa Exoplanet Archive</a>.</p>

<p>There is <a href="http://www.openexoplanetcatalogue.com/planet/HAT-P-7%20b/" rel="noreferrer"><code>KIC 10666592 b</code></a> (expected period: 2.2 d) in tutorial, it works for me. But if I try another planet (e. g. <a href="http://www.openexoplanetcatalogue.com/planet/Kepler-1558%20b/" rel="noreferrer"><code>KIC 10000941 b</code></a> (expected period: 3.5047 d)), it gives bad results.</p>

<h1>Load and plot light curve</h1>



<pre><code>from astropy.utils.data import get_pkg_data_filename, download_file
from astropy.timeseries import TimeSeries, BoxLeastSquares
from matplotlib import pyplot as plt
import numpy as np
from astropy import units as u

# First url is for KIC 10666592, the second one is for KIC 10000941 b.
URL = "http://exoplanetarchive.ipac.caltech.edu:80/data/ETSS//Kepler/005/755/19/kplr010666592-2009131110544_slc.fits"
#URL = "http://exoplanetarchive.ipac.caltech.edu:80/data/ETSS//Kepler/005/159/31/kplr010000941-2009166043257_llc.fits"

filename = get_pkg_data_filename(download_file(URL))
curve = TimeSeries.read(filename, format="kepler.fits")  

plt.plot(curve.time.jd, curve["sap_flux"], "k.", markersize=1)
</code></pre>

<p><a href="https://i.sstatic.net/Jz9ss.png" rel="noreferrer"><img src="https://i.sstatic.net/Jz9ss.png" alt="enter image description here"></a></p>

<h1>Apply periodogram</h1>

<pre><code>periodogram = BoxLeastSquares.from_timeseries(curve, "sap_flux")  
results = periodogram.autopower(0.2 * u.day)  

plt.plot(results.period, results.power)
</code></pre>

<p><a href="https://i.sstatic.net/4U2l9.png" rel="noreferrer"><img src="https://i.sstatic.net/4U2l9.png" alt="enter image description here"></a></p>

<h1>Calculate orbital period</h1>

<pre><code>best = np.argmax(results.power)
period = results.period[best]
print(period)
</code></pre>

<p><span class="math-container">$$\begin{array}{|c|c|c|} \hline
 &amp; \text{KIC 10666592 b} &amp; \text{KIC 10000941 b} \\ \hline
\text{Calculated period} &amp; \text{2.2055172 d} &amp; \text{13.595231 d} \\ \hline
\text{Expected period} &amp; \text{2.2 d} &amp; \text{3.5047 d} \\ \hline
\text{Result} &amp; Correct &amp; Incorrect \\ \hline
\end{array}$$</span></p>

<p>Why period for second planet is wrong? I'm doing something wrong? How can I get the correct result?</p>

<exoplanet><python><planetary-transits><astropy><light-curve>
Get orbital period of exoplanet from light curve using astropy.timeseries
Michal
# Get orbital period of exoplanet from light curve using astropy.timeseries

(Asked by: username_0 on 2020-06-06)

I am using astropy and I would like to calculate orbital period of an exoplanet by its star's light curve. I follow tutorial in astropy docs and I use data from Kepler in Nasa Exoplanet Archive.
There is KIC 10666592 b (expected period: 2.2 d) in tutorial, it works for me. But if I try another planet (e. g. KIC 10000941 b (expected period: 3.5047 d)), it gives bad results.
Load and plot light curve
from astropy.utils.data import get_pkg_data_filename, download_file
from astropy.timeseries import TimeSeries, BoxLeastSquares
from matplotlib import pyplot as plt
import numpy as np
from astropy import units as u

# First url is for KIC 10666592, the second one is for KIC 10000941 b.
URL = "http://exoplanetarchive.ipac.caltech.edu:80/data/ETSS//Kepler/005/755/19/kplr010666592-2009131110544_slc.fits"
#URL = "http://exoplanetarchive.ipac.caltech.edu:80/data/ETSS//Kepler/005/159/31/kplr010000941-2009166043257_llc.fits"

filename = get_pkg_data_filename(download_file(URL))
curve = TimeSeries.read(filename, format="kepler.fits")  

plt.plot(curve.time.jd, curve["sap_flux"], "k.", markersize=1)


Apply periodogram
periodogram = BoxLeastSquares.from_timeseries(curve, "sap_flux")  
results = periodogram.autopower(0.2 * u.day)  

plt.plot(results.period, results.power)


Calculate orbital period
best = np.argmax(results.power)
period = results.period[best]
print(period)

$$\begin{array}{|c|c|c|} \hline
 & \text{KIC 10666592 b} & \text{KIC 10000941 b} \\ \hline
\text{Calculated period} & \text{2.2055172 d} & \text{13.595231 d} \\ \hline
\text{Expected period} & \text{2.2 d} & \text{3.5047 d} \\ \hline
\text{Result} & Correct & Incorrect \\ \hline
\end{array}$$
Why period for second planet is wrong? I'm doing something wrong? How can I get the correct result?

**Tags:** exoplanet, python, planetary-transits, astropy, light-curve

---

## 2 answers

### Answer by username_1 on 2020-06-06. Score: 3 | Accepted answer

I think you may be seeing the planet in the periodogram! But also another signal - higher harmonics of other periodic signals

[![https://en.wikipedia.org/wiki/Solar_cycle](https://i.sstatic.net/Y9WjF.jpg)](https://i.sstatic.net/Y9WjF.jpg)example - various periodic signals in our sun - with a characteristic period of 11 years (in the bottom panel you also see Earth's, as this is a local measure, and thus is mostly affected by our distance from the sun)

Patterns of stellar activity often have some long frequency of periodicity - starspots on our sun are a great example - and you may be seeing the higher harmonics of those signals here - they often have amplitudes much larger than the planetary signal and are often responsible for the noise-floor\* of the system

\*the smallest amplitude signal we could pick out from the lightcurve

If you actually wanted to retrieve the periodogram signal of the planet you could think about estimating this noise and subtracting it

[![](https://i.sstatic.net/qfJlT.png)](https://i.sstatic.net/qfJlT.png)

a sketch of the effect - each hill is a harmonic (roughly $sinc^2$) peak - spaced like mountains receding into the distance. note that in a periodogram error in the power grows with the period for a finite length dataset - there's a smaller number of those periods observed - and hence it's the closest peaks which are most difficult to resolve.

These are exactly the kind of peaks you pick up on in the planet for which the process works - you have the peak at 2.2 days, but also 1.1 (=2.2/2), ~0.7 (=2.2/3) and below, each with less power - but also other periodic signals doing the same giving the other peaks. They may or may not be planets (for example they can be clumps of starspots) but they are real signals going on in the star (or some other object in the frame).

[![enter image description here](https://i.sstatic.net/aBtfQ.png)](https://i.sstatic.net/aBtfQ.png)

Below you can see an example of the effect of changing the observational error (rows) and the number of data points (columns) in mock data.

[![https://ui.adsabs.harvard.edu/abs/2019MNRAS.488.4181P/abstract](https://i.sstatic.net/Zlp94.png)](https://i.sstatic.net/Zlp94.png)
figure from [this paper](https://ui.adsabs.harvard.edu/abs/2019MNRAS.488.4181P/abstract)

So to summarise - you're not doing anything wrong, the planet's just small and there's a lot of noise. If you really want to drill down to the planetary signal you'd need to remove that noise - not an easy task but an interesting and seemingly possible one.

> **Comments:**
> **username_1**: also you might want to try PDCSAP flux (instead of SAP) - the exact details are a bit arcane but it mostly focuses on removing telescope based systematics and *shouldn't* (but probably can in some edge cases) effect the planetary signal  

---

### Answer by username_2 on 2020-06-06. Score: 5

The second light curve you show has no obvious periodic behaviour and I cannot see any sign of a planetary transit. The period-finding algorithm appears to be working correctly.

The planet (if it exists) is supposed to be one of the smallest planetary candidates found by Kepler and will have a barely detectable transit (depth of order 0.004%). The small light curve variations you see are either from the star or remaining instrumental artefacts. If you wish to verify or otherwise the results published by [Morton et al. (2016)](https://arxiv.org/abs/1605.02825), who show no light curves, you will have to do considerably more work to "detrend" the other variability in the light curve.


---

