[Jeff Kissel, Aaron Viets]

Recent issues with the calibration lines and kappa calculations have raised questions about how the h(t)-ok bit is affected by the kappas (see https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=35184 ).

For CALIB_STATE_VECTOR documentation, see https://wiki.ligo.org/viewauth/Calibration/TDCalibReview#CALIB_STATE_VECTOR_definitions_during_ER10_47O2.

For each kappa, there is a "median-ok" bit and a "smooth-ok" bit. The "median-ok" bit tells whether the kappas are being gated due to bad coherence (thus "corrupting" the median with previously measured values). The "smooth-ok" bit tells whether the kappa values are in an expected range (1.0 +- 0.2). Since the coherence was bad, but the gating worked during the time documented in the aforementioned aLOG, the median-ok bit was off and the smooth-ok bit was still on. When we apply the kappas, h(t) OK depends on the smooth-ok bits and not on the median-ok bits, so it was unaffected by this. If, on the other hand, we do not apply the kappas, the kappa bits do not affect the h(t) OK bit.

The above description has been the case since the start of ER10, with the exception of one slight change:
On 2016-11-29 Tuesday maintenance (near the start of O2), the smooth-ok bits were generalized further to also mark bad any time when the kappas are equal to their default values (indicating they have not yet been computed by the pipeline). This scenario is only expected to possibly occur at the start of the first lock stretch following a restart of the pipeline. The purpose of this change was to insure that "h(t)-ok" implies "kappas-applied quality" when we are, in fact, applying the kappas. For documentation on this change, see:
https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=29947
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=31926