EPIC 205982900: Can Dave find the correct period?

[fergalm]

The attached figure shows the best trapezoid model fit to an eclpsing binary in C3.

As you can see, it's an eccentric eclipsing binary that's been fit at half the correct period. It strikes me that it would be very desireable if DAVE could identify such cases (where the true period is a factor of two of the recovered period) then vet the candidate at the correct period. I don't know how to do this, but I suspect that some combination of the BLS, trapezoid fitter and the modshift code could produce the desired result.

So, does anyone have any ideas?

[mrtommyb]

Perhaps the right thing to do here is to look at a goodness of fit at multiples of the fit period. However, I guess BLS is already doing this....

[JeffLCoughlin]

The soc pipeline does this too. In theory an odd-even test should pick this up. The DaveFit.py I wrote that attempts to fit a full EB model at twice the reported period is the sure-fire way to detect these, since it can fit for eccentricity. The mod-shift odd/even test and other similar odd/even tests should detect it, but there are a handful from the soc pipeline we passed as PC in DR24 because of the way the detected epoch is in-between the primary and secondary (at half orbital period) and the resulting odd/even depth is actually very close --- because they are both measured so horribly heh.

[fergalm]

Can we find a way of catching when BLS is latching on to the wrong period, or maybe have the ModShift return the correct period. Then we could run ModShift and our other vetting tasks on the correct period and our plots would look better.

[JeffLCoughlin]

I'd add a line after vetting that says if it fails odd/even then run everything again at 2x the period.

[christopherburke]

You could identify these cases by sorting the data by phase. Then taking the single lag difference vector (diff=x_i - x_i+1). The std deviation of the diff vector for in transit cadences will be very large compared to out of transit cases. This would be an indication to attempt a 2x period calculation of the same metric which should then show a much lower diff vector after again sorting by phase.

[JeffLCoughlin]

I updated pipeline.py to re-fit and re-vet at x2 the period when an odd-even is detected. Seems to work well. If work is one on BLS to catch this before vetting, great, but I don't think it's necessary. We should just work on making sure the vetting catches all the odd-evens. The modshift odd/even caught this one easy. Chris' idea is very clever too - would be neat to try and implement in vetting as well.

[mustaric]

So, I find that Jeff's changes to the code crash if the vet entry is not added to the clipboard. The result is that it crashes when it looks for vet.reasonForFail. What makes me sad about this is that I cannot see the previous exception that was raised and stored in the clipboard (because everything crashes instead of returning the clipboard.) As a result it is much harder to figure out what when wrong. Anyhow, can we please add code to make this exit elegantly in these cases? (i.e. raise an exception that is added to the clip board or just skip this part of the code if an exception is raised.)

[JeffLCoughlin]

Okay I added some if statements to check if clip.vet and then if clip.vet.reasonForFail exists before looking for the odd/even flag. So if vetting hasn't been done, it'll just proceed as normal and not even consider re-running at twice the period.

[fergalm]

So, one of my design goals for the pipeline is that it will never crash. This is really useful if you want to run on 20,000 stars. Each function in pipeline.py is wrapped with clever code (the @task.task before the definition) to ensure that all errors are handled gracefully. The exception is runOne(), which can crash the pipeline. So this function must be absolutely bulletproof, and the bare minimum of code should be there. Every extra line is an extra chance for something to go wrong. So I'm against any solution which requires changes to runOne unless I can be convinced it's definitely the right way to do things.

I think we need to be cleverer in how we solve this problem. Think of the pipeline as a series of steps, each with substeps:

• Run BLS
• Decide if the event is a transit
  • Does it pass LPP?
  • Does it pass modshift
• Decide if the event is a false positive
  • Does it have a secondary
  • Does it have ellipsoidal variation
  • Is it a background event

As I see it, we can either fix the period before the 2nd or the 3rd option. If we ran odd/even immediately after testing for a real transit, all our other tests would operate at the correct period, but odd/even would frequently run on junk, which might cause problems.

If we ran it after we confirmed the event was really a transit, then we'd be checking for a real transit at the wrong period, which might cause other problems.

So which of these is the better way forward, or is there another approach I'm not thinking of?