Swap lightkurve periodogram for astropy method in Ephemeris

[bmorris3]

If you load data into LCviz with sampling varying from minutes apart to decades apart, the lightkurve.periodogram functionality chokes. It chokes because there are some assumptions that lightkurve makes that cause issues here. The main assumption is about time sampling. The time difference between the nearest measurements in this series is of order minutes, but the full span is decades. Sampling evenly at the nyquist frequency gives a tremendous array
and by default, lightkurve uses an O(N^2) implementation of the L-S periodogram. One very simple solution is to not make the same assumptions as lightkurve does.

Ephemeris calls this on the data:

lcviz/lcviz/plugins/ephemeris/ephemeris.py

Line 571 in 9d39dfd

per = periodogram.LombScarglePeriodogram.from_lightcurve(self.dataset.selected_obj)

which is where the problems start.

We can fix that up like this:

lc = self.dataset.selected_obj
ls = LombScargle(lc.time, lc.flux, lc.flux_err, normalization='psd')
freq = ls.autofrequency()
power = ls.power(freq)
self.period_at_max_power = (1 / freq[np.argmax(power)]).value

just using the astropy L-S implementation directly without going through lightkurve overcomes the frequency array problem.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.14%. Comparing base (7b78df5) to head (0475a84).
Report is 52 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #169      +/-   ##
==========================================
- Coverage   93.92%   90.14%   -3.79%     
==========================================
  Files          37       41       +4     
  Lines        1598     2192     +594     
==========================================
+ Hits         1501     1976     +475     
- Misses         97      216     +119     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kecnry]

Is there anything here that can be ported upstream so that we can eventually revert and use lightkurve directly?

We also should probably update the plugin docs which currently state that this just wraps lightkurve methods.

(Also needs a changelog entry - dev test failures are unrelated)

[kecnry]

is BLS not subject to the same issues?