search

barentsen / dave

Discovery And Vetting of K2 Exoplanets
MIT License
6 stars 3 forks source link

Only one point in Transit Failure for Mod Shift #12

Closed mustaric closed 8 years ago

mustaric commented 8 years ago

The Exception is as follows: IOError('FAIL: modshift returned error: Only one point in-transit. Exiting...\n')

Now this happens because trapFit decides to return a model with a very short duration (like 1 hour or less). When this happens, it appears that modshift doesn't return gracefully. Could it instead return non-sensical values, or a SinglePoint Failure type comment.

See the following example on so-nfs: clip=c.loadClipboard('/soc/nfs/so-nfs/dave/c7-sff-short/214354254/c214354254-07.clip')

fergalm commented 8 years ago

The other reason modshift fails with this error is that all but one or two points have been flagged as bad. Any solution would have to behave sensibly for this case too.

Maybe the best solution is for the dispostionTask to check for very short durations and refuse to run modshift if that's a problem?

mustaric commented 8 years ago

Fergal, I think that would be a reasonable solution as well.
Are we convinced that if trapFit says the duration is tiny, that the event is due to an outlier and we can safely call it a false positive?
Another option would be to have modshift run using the bls duration.

JeffLCoughlin commented 8 years ago

Yea right now modshift basically says it's silly to run modshift with zero or only one point in-transit, so it exits with that error code. I could change it so that it spits out values of say -1 for everything, but I thought Fergal preferred the exit w/ error code.

I agree if the trapFit duration is crazy small then we should just throw it out as not transit-like and move on. The error means that there is literally one point in-transit, via the model, for the whole phased light curve. So that really means there is only one transit detected, and we are requiring a two-transit minimum for a Dave TCE.

JeffLCoughlin commented 8 years ago

Another option would be to have modshift run using the bls duration.

This is possible - to run modshift this way we'd have to generate a model from the bls results, which would be fairly simple since it's just a box. I guess the question is how often the trapezoid fit mistakenly results in a too-short duration when there really is a real transit-like feature there.

JeffLCoughlin commented 8 years ago

Posted on the other ticket, but posting here now as well...I think this solves this ticket's problem.

I ended up changing the code so that in the case of no in-transit points it will just exit the function that it's in, not the whole program. I also added default values to the outputs of 0 or 1. (0's for the sigmas, 1's for the errors and Fred, so it avoids any divide-by-zero errors).

This means that when there are no in-transit points for the odd- or even- only, it will just default to a odd-even statistic of zero (default pass). The code will run normally for the light curve as a whole. Also, if there are no in-transit points for the entire light curve, as we've seen for a few other systems, then it should gracefully return default values of 0.0 for sig_pri. Right now that should make it fail in vetting (as something with no points in transit probably should), but we can change that in the vetting code if we want it to pass.

fergalm commented 8 years ago

If there are no data points in any of the odd transits (or any of the even) ones, should that not be a fail? I haven't thought it through all the way, but I would think so.

JeffLCoughlin commented 8 years ago

I think normally yes Fergal, but I can't guarantee 100% that the outlier rejection didn't accidentally kill the one point in-transit. Normally shouldn't happen, but if it's a really crazy LC, it might. So best to default to pass I think, and modify the BLS to not produce a candidate when there isn't data for the odd or even events.