Reports until 11:57, Tuesday 13 December 2016
H1 CAL (CAL)
alexander.urban@LIGO.ORG - posted 11:57, Tuesday 13 December 2016 - last comment - 12:35, Thursday 15 December 2016(32517)
GDS calibration pipeline restarted at LHO with gstlal-calibration-1.1.2

I've restarted the primary and redundant h(t) pipelines at Hanford at GPS second 1165664237. This restart picks up a software update to gstlal-calibration-1.1.2-v1, which contains a couple of bug fixes:

(1) The h(t) data product should now be identical between the primary and redundant pipelines when time-dependent corrections are applied (i.e., the previously observed numerical roundoff error has been addressed);

(2) The pipeline will now run properly in offline mode, which had become a serious problem after the first bug fix referred to above.

The filters file has also been changed; see this aLOG: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=32389

Note, time-dependent corrections to h(t) (the kappa factors) are still being applied in low latency at Hanford, with the exception of changes to the coupled cavity pole frequency.

Comments related to this report
aaron.viets@LIGO.ORG - 12:35, Thursday 15 December 2016 (32603)
Link 

The most recent bug fix that prevents the pipeline from hanging does so by adding a 20 second latency to the low-pass-filter used in demodulating the time-dependent calibration factors. This was necessary so the the timestamps on this stream are aligned with the timestamps of the coherence uncertainty channels. Otherwise, the gate element that receives these misaligned streams will lock up, causing the pipeline to hang.

However, I have now realized that this introduces minor subtlety -- the coherence gating does not take this additional 20 seconds into account. This introduces the possibility that there could be undesirable jumps in the kappas in C01 frames produced by this version of the code that do not show up in C00 (Similar to what is discussed in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=31911 , which has been addressed in a recent bug fix).

I have a different fix to this, for which I will request another release for next Tuesday. Instead of adding a latency to the low-pass filter, I have added queues before the gate, which allow it to run properly. (Note that we never encountered this problem online; the reason is because there are queues that have this effect when running online that were not previously in all the right places for the offline version.)