options for loading multi-sector light curves

[havok2063]

Is there an option for loading lightcurves from multiple sectors of an observation, or from multiple observations? Is this something that is feasible, or does it have any performance drawbacks?

I could imagine a few different workflows:

1. Loading all table rows from a lightkurve search.

lc = search_lightcurve("HAT-P-11", mission="Kepler",
                       cadence="long", quarter=10)

If I run the download_all method here and load each file in LCviz, how performant is that?

2. Users selecting several observations from Portal / MissionMast and loading into a single LCViz (viewer)

[kecnry]

You can currently call .download_all().stitch() which will result in a single light curve object which can be parsed directly by lcviz, or you can loop through the individual entries from download_all() and load them as separate entries (see below for more details on calling syntax). I can see use-cases for both and they probably both have their own performance implications.

We could extend the lcviz parser to accept the output from download_all() or even just search_lightcurve directly and handle the logic automatically. So instead of the current:

lcviz.load_data(search_lightcurve(...).download_all().stitch()

or

for lc in search_lightcurve(...).download_all():
    lcviz.load_data(lc)

we could support:

lcviz.load_data(search_lightcurve(...), stitch=True/False)

I'd also like to some day have a split/join functionality as a plugin in jdaviz - do you think that would be helpful? Especially if from the MAST-side, you'll need to hardcode one of these options and the user won't be able to choose in advance.

[havok2063]

Yeah, I like the idea of supporting this syntax lcviz.load_data(search_lightcurve(...), stitch=True/False), passing in a search_lightcurve table directly.

I think we'd also like the ability to pass in a general list of lightcurve files, with the stitch=True/False flag. Searches in MAST will primarily be this output right now, but I can envision adding a new UI hook that exposes the search_lightcurve table.

In our case, what I want to avoid is having lcviz download any files again on the server-side. Ideally lcviz could be smart enough to know when it's running on MAST to lookup the isilon paths instead of downloading the files, but that might be a big ask. I think we could add some logic in our notebook to do that conversion.

[havok2063]

oh and yeah, I do think a plugin for splitting/joining would be helpful. If we didn't expose that interaction in the UI, I think the only option would be to write an event handler that calls a notebook function to do it programmatically, and reload the viewer.

[kecnry]

First stab at stitch functionality as a plugin (after loading into lcviz - haven't forgotten about the other use-case) is implemented in #107 - let me know if you have any thoughts/concerns.

[havok2063]

Great. I'll be able to take a closer look at this next week.