kentaro.mogushi@LIGO.ORG - posted 12:12, Thursday 19 January 2017 - last comment - 20:03, Thursday 19 January 2017(33430)
Monday 16th 00:00 UTC - Wednesday 18th 23:59 UTC
The full report can be found on the detchar wiki: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20170116 Below I summarise the main highlights of this shift: • The overall duty cycle through 3 days was ~10 hours (19.3%) • On 16th the maintenace continued from the previous day for 38 horus, diagnosing issues related to possible ITMX and the X-arm compensation plate rubbing possibly due to the cold outside vs warm inside. • On 17th the duty cycle is 7 hours (29.7%). The range is 50 - 65 Mpc in the first lock, then declined drastically in the second lock due ot unknown reason. • preventive maintenace from 16:30 UTC on Tuesday to ~20:00UTC on Wednesday due to the storm. There was an outstanding winter weather alert in effect until mid-day Wednesday so most of the people went home. • On 18th the duty cycle is 3 hours (28.4%). The range is about 60 Mpc. Only the front end calibration data is shown in the range plot. • The scattering tool shows noise from H1:SUS-PRM_M1_DAMP_L_IN1_DQ and H1:SUS-SRM_M1_DAMP_L_IN1_DQ during the lock although the glitch rate and omicron glitchgrams don't seem to suggest anything bad going on in DARM. • software saturations - H1:ASC-POP_X_PZT_PIT and H1:OAF-DARM_AUDIO seem to be saturating continuously over the lock stretch from Tuesday 17th to Wednesday 18th.
I have been looking into the software saturations issues reported on the DQ shift for channels H1:ASC-POP_X_PZT_PIT and H1:OAF-DARM_AUDIO.
While the report says that they were saturating during the few days reported on the DQ shift, however I have noticed that these two channels have always been usual suspects, so a closer look was required.
First of all notice that the way the software saturations are reported is by comparing the OUTPUT of the Filter Banks with their LIMIT setting, such that that saturation occurs when OUTPUT >= LIMIT * 0.99 to account for precission problems.
Taking this into account let's look to the MEDM screen of the filter banks associated to both channels above, see attached files
* H1:ASC-POP_X_PZT_PIT: see attached file named: MEDM_FilterBank_channel_ASC_POP_X_PZT_PIT.png
In this case we observe that the LIMIT is set at 20000 (circled red). The signal going through this LIMIT can have values of a few thousand during normal operation, so all should be OK regarding saturation. However immediately after this limit there is an OFFSET/BIAS of 16000 (circled in blue), which easily can bring the OUTPUT value to values bigger than the LIMIT. However this does not mean that there is any issue because the LIMIT applies before the offset.
The problem is with the way Software Saturations are being generated. Most if not all Filter Banks have an OUTMON after the LIMIT (circled yellow), if we were to look at that channel for comparison with LIMIT, instead of OUTPUT, then this issue would be resolved.
*H1:OAF-DARM_AUDIO: (see attached file named: MEDM_FilterBank_channel_OAF_DARM_AUDIO
This is a more standard type of Filter Bank where there is no BIAS or OFFSET after the LIMIT, however at the current setup the signal is alway +-1. Notice however that this channel is only used to listen to DARM from the Control room so it does not feed anywhere else on the system and it is not dangerous. If needed be it could be turned off.