spacetelescope / exovetter Goto Github PK

odd_even and phase coverage both need a vetter class added.

Follow up of #49 .

Blocked by: #54

The current design of a vetter is

class Vetter:
    def run():
        pass

    def plot():
        pass 

The thinking was that computing metrics and plotting results were two separate operations. We've discovered that plotting typically happens deep inside the code wrapped by the class, and we had to store a lot of intermediate data in the vetter, violating the principle of encapsulation.

A better way to do things is to have

def run(self, tce, lc, plot=False):
     ...

The plot keyword can then be passed into the code executing the logic. We can then get rid of the plot method

Veselin pointed out that It might be worth adding to the code a difference image comparison between the measured In-Transit centroid and the catalog position of the target from e.g. Gaia instead of the IT vs OOT centroids. I’ve often noticed that the large TESS pixels and corresponding contamination from nearby field stars can make the IT vs OOT comparison highly challenging (or even downright meaningless). The downside for a comparison with Gaia is that the proper motion needs to be properly taken into account, but this would be a small price to pay.

I think this was what we decided to do? Feel free to edit if I got it wrong.

• Store data somewhere sanctioned by STScI. Also see this STScI style guide about storing data. OR we can simply grab it from the other repository currently holding it (SourceForge?).
• Use astropy caching mechanism to handle its download and caching.
• There should be a helper function to check if it is already cached. If so, use cached copy. If not, do the download from a pre-determined location and cache it; i.e., using astropy.utils.data.download_file(..., cache=True).
• There will be no automatic cache invalidation. That is, if user wants to re-download, user needs to explicitly tells the function to do so; i.e., astropy.utils.data.download_file(..., cache='update') to force an update to the existing cache.

@mustaric will provide the data. @jbcurtin will implement the functionality.

Use tools here: https://matplotlib.org/3.1.0/api/testing_api.html to find a way to write tests that the plots at least run, preferable that they also produce the right values.

Follow up of #26 and #33 .

This needs fixing:

This test needs to be updated:

But I don't know what is going on with tzero in the test, so maybe @mustaric or @fergalm can fix it properly.

Currently, the instruction is to create two functions for each model (#26). Why can't we:

1. Make each model a class with constructor taking fundamental inputs (arrays, etc) and a separate class method to take TCE?
2. Inherit from astropy.modeling.models base class by taking advantage of its ability to specify custom models.
3. And if we want to enable the machinery beyond boxcar and trapezoid, define an abstract base class for all models (existing and future).

Maybe this is one of the last steps in the project but should be done before close-out.

Also add PyPI badge to README.

Goal: Bring the sweet vetter into exovetter.
Submitted by: @mustaric (See below for details.)

https://github.com/exoplanetvetting/DAVE/blob/master/tessPipeline/sweet.py

It was written by @fergalm . The top function is runSweetTest which basically just runs computeSweetMetrics which returns a 3x3 array. I think we want exovetter to return that 3x3 array. We don’t need to keep the messages. As a result we also don’t need to input threshold_sigma.

The period, epoch and duration inputs can be replaced with the tce dictionary we created. And the time and flux should be input as a lightkurve object, like we did for lpp.

We need a trapezoid fitter separate from each of the vetters.

Probably GitHub Actions unless we need internal access. Blocked by #1.

@mustaric will scope this out.

When built locally, they show up fine. Not sure what is going on.

put transit number on centroid test plots.

From base class:

Example implementation in ModShift (returns None):

Example implementation in Lpp (returns dict):

Sooner than later

Add a vetter that returns the fraction of the folded transit that contains data. Sparsely sampled transits end to be noise. This requires knowing the duration of the tce.

The folding for the odd even test returns the wrong phase. This probably happened when we switched to only one way to fold at the period of the tce. It would be good to check the other phased tests are also at the correct phase.

Do we need to add Fergal Mullally and Chris Burke, given they are technically Co-I's too?

Within vetters.py have it return quantities instead of floats for the vetter values. this includes the values that get fed into the plotting function.

Do this when we have some real documentation.

sweet test left an unclosed file after the lightkurve function read it in. Somehow we need to close that file in order for that test to be accepted by the continuous integration.

Add a vetter that takes a light curve and tce and determine the difference between the depths of the odd and the even transits. It should return both depths and the errors. Usually a cut is made when significant depth differences are seen.

The astropy BLS code actually is one path forward for this test.

Mask the transit when fitting the sine waves

Need to give the purpose of the package, and what data it works on.

A follow up of #50. Blocked by lightkurve/lightkurve#988 .

Project needs planning.

Also create relevant milestones.

As part of this find a way for users to input TCE information in natural Kepler units or in natural TESS units and then have the class convert these to the generic TCE inputs.
@fergalm

Follow up of #19. Would be nice to implement unit tests for all the functions in the package.

See https://codecov.io/gh/spacetelescope/exovetter

We should add the MJD offset to the exo const function.

mjd = bjd - 2_400_000.5. * u.day
"""MJD"""

We either need to add useful materials to the example_notebooks and fix any that has broken since, or just delete the whole folder.

astropy units and Quantity is useful because it keeps track of the units for you and works pretty well with Numpy arrays (except for some known issues). Things like trapezoid_fit (see also #14) could benefit from it.

Pros:

• Automatic units bookkeeping. For example, we can get rid of warnings like "must pass in value as hours, not days" and reduce to risk of wrong calculations due to user error. You would be able to pass in either hours or days (or anything that can convert to them for that matter) and not have to worry about wrong results.
• Works well with Numpy arrays.

Cons:

• Extra computation overhead. There are some performance tips but some overhead is unavoidable. Units bookkeeping does not come for free.
• Risk of introducing new bugs during refactoring. Some existing magic numbers need to be well understood and/or eliminated. For example, is that 1.0e6 used to convert units or for something else?
• scipy.optimize cannot understand astropy units and Quantity, so the units still need to be stripped before that is called and then re-applied. It is important that we convert the Quantity to expected units before stripping the units.

Do the benefits outweigh the costs?

VizTransits Folder
-- Getting negative phases
-- mark where the transit is supposed to be
-- change automatic selection of binning, so it always does some binning. Select based on whole lc not just in transit.
-- change dimensions of the folded light curve page size, should be wider.
VizTransits individual transits plot
-- increase distance between plots (2x depth or noise?) so they don't overlap.

ModShift is not working, why?

Add outlier rejection to light curve before creating the VizTransit plots.?