-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
phase viewer and ephemeris plugin #19
Conversation
* this does NOT yet actually compute/plot phases
* with just really rough estimates... we'll likely want to tweak the actual expressions
can test by manually forcing component options (until the UI is developed for adding components and UI/API for renaming/deleting): ``` ephem = lcviz.plugins['Ephemeris'] ephem.component._manual_options = ['default', 'new'] ephem.component.items = [{"label": opt} for opt in ['default', 'new']] ```
* NOTE: per-lightcurve reference times are not correct!
migrated from abandoned spacetelescope/jdaviz#2205
* export plot, for example, needs to be aware of viewer renames done via the ephemeris plugin
Starting to test this, my initial reaction is that I like it other than one minor quibble and a possible bug. The quibble is that I'm not sure I like having the viewer automatically appear the first time you interact with the plugin. It seems a little arbitrary that I change, for example, the period, and suddenly the viewer appears. I wonder if it would be better to either have the default phase folded viewer be tabbed but unpopulated on load, or have a button to create the viewer. The bug is that when the viewer first appears, the data isn't folded correctly (or at least isn't displaying correctly), and then fixes itself when I tweak any of the values slightly. In the screenshots below I first set the period to 5, and |
We can easily iterate on this in the future as we get a feel for how users (including ourselves) use the tool. Since there will be so many different possible viewers, I thought it made sense to have them handled as dynamically as possible, and I can't think of any reason why you would want to change an ephemeris but not see the phased light curve. The button is already implemented though, so we could easily just remove one line of code to prevent the automatic creation on changing a traitlet.
Is this with the data from the example notebook? It is possible that this is just aliasing based on the cadence of the data (period=0.42912 for example is a multiple of the cadence and looks similar), but I can't reproduce with that same data (HAT-P-11 Q10) and period of exactly 5... can you post a screen recording? |
This is for the example data, it's not an aliasing issue since it doesn't depend on what the initial period you put in, here you can see it happens if you initialize to either the Lomb-Scargle calculated value or to a user input. I forgot to show this, but if you go from the initial value of 5 to 5.001 and then back to 5, the plot looks fine with period of 5 the second time. Screen.Recording.2023-05-23.at.10.20.17.AM.mov |
That is bizarre - I can't reproduce on my end. If you call the following when the phasing is incorrect (before updating anything to fix it otherwise), does it show the correct ephemeris and then update the plot correctly?
|
ok, then can I ask you to just try to parse |
* seems to fix a bug that can sometimes result in the phased-data showing incorrectly on the first change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't go over the code with too much rigor, but after the fix to the initial viewer population everything seems to work pretty well. The period finding doesn't seem very good, but I think that's an consequence of the example light curve being a mess with lots of stellar variability. We can definitely iterate from here.
jdaviz main will now require #20 and spacetelescope/jdaviz#2214 (or just use jdaviz before spacetelescope/jdaviz#2199) |
Just had to share – this works so beautifully for use cases on spotted, flaring stars. Thanks to @jradavenport for the rotation period measurement 👌🏻 . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. Feel free to merge after you've responded to the comments below (even if you don't adopt all suggestions; I just want to start these conversations).
<lcviz-editable-select | ||
:mode.sync="component_mode" | ||
:edit_value.sync="component_edit_value" | ||
:items="component_items" | ||
:selected.sync="component_selected" | ||
label="Component" | ||
hint="Select an ephemeris component." | ||
> | ||
</lcviz-editable-select> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It isn't clear to me what this is meant to do, which might mean we need a better name/label. It seems like this controls part of the name of the ephemeris tab in the viewer, which is the viewer reference name.
I think you named it "Component" because it could be a "component" of the physical system, like planet b or c, or the rotation period of a primary or secondary "component" of a binary. Is that right? If so, maybe a better name for this box is "Ephemeris viewer label" or similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I struggled with this a bit as well, and think as we start to write other plugins it might become more clear and we might want to revise this. Elsewhere I think we'll want to refer to this label just as "ephemeris" - binning_plugin.ephemeris
to bin the data phased by a specific ephemeris, for example - but that feels awkward here since I wanted to use the ephemeris
property to return the actual ephemeris information. I do want to keep some synergy between the plugin attribute name (currently ephemeris_plugin.component
) and the UI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood. The crux of my concern is that the word "component" has too many meanings (glue Component? system component? viewer component?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed (and especially with model components), please do bring this back up when we get more context with other plugins starting to fall into place and let's see if we can come up with a consistent but intuitive solution.
<v-icon style="cursor: pointer" @click="period_halve">mdi-division</v-icon> | ||
</j-tooltip> | ||
<j-tooltip tooltipcontent="double period"> | ||
<v-icon style="cursor: pointer" @click="period_double">mdi-multiplication</v-icon> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wanted to add here that I had expressed early on that I might want something other than the mult/div buttons, but now that I've played with it this way, it's actually really clear that this is a handy and intuitive interface. Neat!
This PR introduces a new ephemeris plugin with support for multiple ephemeris "components", which then creates and updates phase arrays and viewers which are kept up-to-date with the ephemeris and linked correctly to support subsets. This also includes a very simple interface to periodagrams which just propose the top peak - note that we will likely split periodograms/FFTs/PDM into their own plugins which interact with the ephemeris plugin, but this is at least useful for now.
Screen.Recording.2023-05-14.at.2.56.24.PM.mov
Possibly in scope:
Intentionally deferred: