Replies: 1 comment
-
If I remember correctly, Keaton Bell used (or is still using) I wonder if it'd make sense to move generic timeseries related logic to a separate package. E.g., # rv_time_series is of a new Enhanced TimeSeries class, basically a subset of `Lightcurve` class that is generic for TimeSeries
rv_time_series = some_reader_of_rv_data()
rv.meta["Y_COLUMN"] = "RV" # define the primary column of the "y-axis" data that various functions would operate on
# the enhanced TimeSeries class has various helper methods.
rv.plot()
folded_rv = rv.fold(...)
folded_rv.errorbar();
... |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Often in spectroscopic time series we construct some summary statistic for a collection of spectra observed at a range in times. For example a collection of Equivalent Widths: the area under the curve of an observed spectrum over some subregion of a (continuum normalized) spectrum.
It strikes me that one could use
lightkurve
for this application, which is useful to take advantage of the phase folding operations, or possibly even periodogram methods.I think it would be neat to demonstrate this "off label" use of lightkurve in a tutorial, to expand the domains in which folks could use lightkurve.
There may be limitations to such mission creep: One could hypothetically go further and input RVs as the time series "flux" dimension. Those unusual units could break things, since flux units are not compatible with velocity units. So promoting the off-label use case might backfire if users expect lightkurve to support unusual scenarios that don't apply to the core lightcurve mission.
Thoughts? I'd be open to adding a tutorial about this.
Beta Was this translation helpful? Give feedback.
All reactions