Matt E., James R., Sheila D., Terra H., Hang Y.

We are developing a tool to automate lock loss analysis, and an initial version is availabel at

/opt/rtcds/userapps/trunk/isc/common/scripts/lockloss

There is a matlab version and a python version, and right now they are essentially equivalent. An example generated using the python version is attached to this entry.

=================================================================================================================================

The code takes in a gps time around which a lock loss happens. It first looks through GUARDIAN to get a rough time of lock loss. Then it looks at 'LSC-POP_A_LF_OUT_256_DQ' to find a sudden drop, and the time of this drop will be used as our more accurate lock loss time.  It then reads in data from an user defined list of channels (or if none, all DQ channels by default) and breaks the data into three frequency bands (>0.125 Hz for low, 16 ~ 128 Hz for mid, and >128 for high). The code can identify big jumps in each channel's BLRMS and order the channels by the time of the jumps. The first 16 channels goes wrong will be plotted (as the attached one) and all channels in which big jumps are seen will be recorded into a .txt file.

In the figure attached (a lock loss at GPS time 1122672396 UTC), black lines are raw data of 'POP_A_LF_OUT_256_DQ', blue lines are the raw data of the channel in the corresponding subplot, and red lines are BLRMS for the band that first goes wrong. X-axes are time in second, with zero defined as the time of lock loss (value shown in the main title), and y-axis is an arbitary scale as we only care about trend but not absolute values. Each subplot's title consists of three parts: channel name, time of the first jump prior lock loss, and the frequency band that first goes over the critical value.

Checking all DQ channels take a considearable amount of time, so in the attached one we looked only at suspension channels. A full analysis is on going when this entry is created.

=================================================================================================================================

For future imporvement, we are working on creating a cron job which periodically check GUARDIAN and whenever a lock loss happens this analysis code will be automatically triggered. Sheila and Terra are working on a complementary code to this which looks all channels that saturates or hits some known bad zone before lock loss. More ideas/ thoughts/ comments are welcome.