Sheila, Ed, Ross, Evan
This morning we had another incident where we seemed to have glitches in the channel H1:ALS-Y_REFL_CTRL_OUT_DQ that could have been the cause of ALS locklosses, similar to what was described in alog 15242 and alog 15402. Some screenshots are attached. There is a distinctive pattern in the REFL CTRL signal, and the error signal (ALS-Y_REFL_ERR_OUT_DQ) has a large glitch, as well as the transmitted green light (ALS-C_TRY_A_LF_OUT_DQ). Today these things were happening only every 10-15 minutes, but that is often enough to prevent locking. As before this problem went away after a while, without us doing anything to fix it. Several screen shots are attached. These glitches sometimes show up in the X arm, but that could be because the DIFF control imposes them on the X arm even if the originate in the Y arm. The glitches still happen when we had tidal off, and COMM unlocked, so I would not think that there was anyway a glitch that originated in the X arm could have been imposed on the Y arm. There are no coincident gliches in the Optical levers or in the Fiber control or error signals.
It would be good to know how often these glitches happen, how intermitent the problem has been over the last several months, and how often they coincide with a lockloss. Ed and Ross started to look into this, and started a script to identify these glitches in a way that is easier than looking though a time series. I made an attempt to use omega scan on ligodvweb, but I ran into trouble producing a plot.
I am wondering if anyone from Detchar has tools that could be helpful (and maybe used from the control room?) in finding times when these glitches have happened.
We don't currently have glitch-finding algorithms running on those channels, but we'll start running them today and also produce results for the last week. In the meantime, just looking at one event, it looks like a BRMS from 50 to 100 Hz on ALS-Y_REFL_CTRL_OUT_DQ would do a good enough job of finding these.
The primitive code for finding these ALS glitches is attached; it uses the MATLAB frontend to NDS2 to get the data, and in this data it searches the H1:ALS-Y_REFL_ERR_OUT_DQ channel for the following: a data sample that exceeds 20000 counts, followed in less than 500 bins (30ms) by at least one sample that is lower than -20000 counts. This is a crude bipolar burst search of the channel, and it seems to find ALS glitches with high efficiency. There seem to be three classes of ALS glitches - 1) streams of large glitches that occur far from IFO locks, where the ALS servo is just not working very well/ hopping between spatial modes, 2) smaller glitches coincident with losses of lock 3) other smaller glitches whilst locked that are not coincident with loss of lock. I have also attached 4 pdfs. Attachments are explained below: 1. findalsglitch.m - a glitch search code that downloads and searches a predetermined amount of full rate data from ALS-Y_REFL_ERR_OUT_DQ 2. rangealsglitch.m - a code that calls findalsglitch.m multiple times, after breaking a predetermined data stretch into manageable chunks. 3. A pdf of a stream of large glitches in ALS occuring when the machine is out of lock 4. A pdf of a small ALS glitch during a lock stretch where the IFO did not lose lock coincident with the glitch. 5. A pdf of a small ALS glitch during a lock stretch coincident with an IFO loss of lock. 6. A zoomed in version of 5 showing the shape of the glitch in detail.
Here is one more example of this kind of glitch, I think this is an example of the Y arm ALS glitch causing a lockloss.
