LightKurve Exoplanet Orbital Periods Disagree With NASA Exoplanet Archive Values

Problem description

Tried to confirm/verify exoplanet orbital periods as published in https://exoplanetarchive.ipac.caltech.edu/cgi-bin/TblView/nph-tblView?app=ExoTbls&config=cumulative

When orbital periods match, it’s almost an exact match. So there’s high confidence in the LightKurve period tool.

But the match percentage is like below 50%. Very frustrating.

So I opened an issue ticket with NASA and LightKurve.

Most likely there’s a simple explanation, something I’m missing. But given the accuracy of LightKurve, it opened the question of whether NASA Exoplanet orbital period values are wrong

Should be interesting…

Example

#target1 = ‘Kepler-1’ # [Kepler-1 b] 2.47 days Confirmed #target1 = ‘Kepler-10’ # [Kepler-10 b] 0.83 days Wrong #target1 = ‘Kepler-69’ # [Kepler-69 b] 13.72 days Confirmed #target1 = ‘Kepler-100’ # [Kepler-100 c] 12.81 days Confirmed #target1 = ‘Kepler-101’ # [Kepler-100 b] 3.48 days Confirmed #target1 = ‘Kepler-101’ # [Kepler-100 c] 6.02 days Wrong #target1 = ‘Kepler-102’ # [Kepler-102 b] 5.28 days Wrong #target1 = ‘Kepler-102’ # [Kepler-102 c] 7.07 days Wrong #target1 = ‘Kepler-102’ # [Kepler-102 d] 10.31 days Wrong #target1 = ‘Kepler-1001’ # [Kepler-1001 b] 14.3 days Wrong #target1 = ‘Kepler-1002’ # [Kepler-1002 b] 4.33 days Wrong #target1 = ‘Kepler-1003’ # [Kepler-1003 b] 3.55 days Confirmed #target1 = ‘Kepler-1004’ # [Kepler-1004 b] 5.28 days Confirmed #target1 = ‘Kepler-1005’ # [Kepler-1005 b] 6.49 days Wrong #target1 = ‘Kepler-1007’ # [Kepler-1007 b] 5.18 days Wrong #target1 = ‘Kepler-1008’ # [Kepler-1008 b] 12.43 days Wrong #target1 = ‘Kepler-1009’ # [Kepler-1009 b] 11.35 days Wrong #target1 = ‘Kepler-1011’ # [Kepler-1011 b] 5.75 days Wrong #target1 = ‘Kepler-1012’ # [Kepler-1012 b] 5.50 days Wrong #target1 = ‘Kepler-1016’ # [Kepler-1016 b] 1.95 days Confirmed #target1 = ‘Kepler-1017’ # [Kepler-1017 b] 7.23 days Wrong (only one match) #target1 = ‘Kepler-1019’ # [Kepler-1019 b] 1.41 days Wrong #target1 = ‘Kepler-1021’ # [Kepler-1021 b] 13.47 days Wrong #target1 = ‘Kepler-1022’ # [Kepler-1022 b] 10.99 days Wrong #target1 = ‘Kepler-1027’ # [Kepler-1027 b] 1.90 days Wrong #target1 = ‘Kepler-1028’ # [Kepler-1028 b] 2.51 days Confirmed #target1 = ‘Kepler-1029’ # [Kepler-1029 b] 4.41 days Wrong #target1 = ‘Kepler-1031’ # [Kepler-1031 b] 1.22 days Wrong

insert code here …

#### Expected behavior
Expected a better confirmation percentage.
When it's wrong, the values are not even close.

Check out the orbital periods of the above targets for yourself.

#### Environment

-  platform ( OSX):
-  lightkurve version (2.0.11):
-  installation method (pip)
- 
Will post screen shots in the secondary comments.
Drag and drop doesn't seem to work well.
:

[barentsen]

@JosephKarpinski Determining the orbital period of a planet in an automated way from a Box Least Squares (BLS) diagram can be quite tricky.

The BLS diagram often shows a handful of peaks at multiples of the period (for example, 2x period, 3x period, 1/2x period, 1/3x period). In a perfect light curve the correct period would show up as the strongest peak, but in reality various sources of instrument and astrophysical noise can cause the alternative peaks to appear stronger. Another common issue is that the BLS diagram may not have been sampled well enough around the correct period.

A common method to verify whether a given period is correct is to inspect a plot of the phase-folded light curve using lc.fold().plot(), and verify that the transit has a well-defined shape and only appears at phase=0.

It would be a valuable project to figure out what the best parameters are for Lightkurve’s flatten() and to_periodogram() functions would be to enable the largest number of confirmed periods to be recovered automatically. We could consider updating the default parameters accordingly!

[JosephKarpinski]