Modshift fails with Divide by Zero error

[fergalm]

212591132, C6 fails with the error ZeroDivisionError('float division by zero')

The backtrace is

Traceback (most recent call last):
  File "/home/fergal/all/svns/dave/pipeline/task.py", line 105, in wrapperForTask
    clip = func(*args, **kwargs)
  File "/home/fergal/all/svns/dave/pipeline/pipeline.py", line 766, in dispositionTask
    fluxVetDict = RoboVet.roboVet(modshiftDict)
  File "/home/fergal/all/svns/dave/vetting/RoboVet.py", line 35, in roboVet
    out = not_trans_like(modShift)
  File "/home/fergal/all/svns/dave/vetting/RoboVet.py", line 60, in not_trans_like
    if modshift['mod_sig_pri']/modshift['mod_Fred'] < modshift['mod_sig_fa1'] and modshift['mod_sig_pri'] > 0:
ZeroDivisionError: float division by zero

The problem seems to be that mod_Fred is zero. Examining the lightcurve suggests that there is only 1 or 2 points in transit, which may be causing the error. The code should exit with a more useful error message, or better yet, check for this problem and return sane values.

[JeffLCoughlin]

The problem here is that modshift was too aggressive on the outlier rejection. This resulted in having only one point in-transit after outlier rejection, which casued the code to choke. I think it was over aggresive due to the very noisy nature of this light curve, combined with a short transit duration.

I've changed the detrending length from one-tenth of a transit duration to a constant value of one long cadence duration (~29.44 minutes). It fixes this system. We'll see if there are any other unforseen consequences - one worry is perhaps it will reject less outliers than before on long-period systems - we'll see.