TITLE: 03/26 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 64Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY: Only out of observing to run a2l when LLO lost lock.
LOG:

11:38 UTC LLO lost lock. Out of observing to run a2l.
11:44 UTC a2l done. Back to observing.
11:45 UTC GRB

Have remained in observing. No issues to report.

TITLE: 03/26 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 65Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    Wind: 5mph Gusts, 4mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.22 μm/s 
QUICK SUMMARY:

No issues to report.

TITLE: 03/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: 

• one lockloss and relock: alog 35084
• lockloss plot: alog 35087
• Verbal Alarm output is odd: alog 35085
• Control Room computers powered off, much better now: alog 35086
• Currently:
  • engaged FM1 on ETMX and FM7 on ITMY bounce mode filtering, and they will show up on relocking in SDF
  • H1 could use an a2l, but so far L1 has remained locked, so haven't run a2l yet

OMC DC SUM and DHARD Y seem to glitch at the same time

• 02:01UTC - March 26th - H1 Intention Bit Undisturbed
• a short time later I see H1 glitch in DARM on NUC3
• Verbal Alarms display in the CR shows:
  • "OMC DCPD Saturation (Mar 10 08:42:47 UTC)"
• for sure the date and time are not current
• not sure if the claimed glitch was really OMC DCPD Saturation
• screenshot of the Verbal Alarm display is attached

About an hour after coming on shift I noticed something in the CR air and put on my mask, but after a while it was clear that that didn't help, so I started looking for other things, and realized it sort of smelled like burnt plastic.  Called Corey, Richard, Dave, and a couple other people.  Turned off most of the CR computers (about 4 warm ones), checked the MSR, checked the Computer user's room, and the smell was only in the CR.  Tried to contact Robert, waited, but then turned off his computer, and am now waiting to see if that computer was overheating, and if turning it off clears up the air.

Currently watching H1 from the Computer Users Room, and have Verbal Alarms running in here.

TITLE: 03/26 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 68Mpc
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
    Wind: 8mph Gusts, 6mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.25 μm/s
QUICK SUMMARY:

• 01:05UTC - lockloss
• 02:01UTC - Observe

TITLE: 03/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:
LOG:
Quiet shift. Nothing to report. Amber was on site about 21:00 with a tour. Robert has been on site waiting patiently for LLO to go down.

TITLE: 03/25 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 64Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY: Observing entire shift. No issues to report.
LOG:

07:57 UTC GRB
13:42 UTC Changed sign of gain to damp PI mode 27

Have remained in observing. No issues to report.

TITLE: 03/25 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 61Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    Wind: 9mph Gusts, 6mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.30 μm/s 
QUICK SUMMARY:

No issues to report.

TITLE: 03/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: one lock loss, easy relocking
LOG:

• 00:49:00UTC - airplane
• 01:12UTC - airplane
• 02:24UTC - a rumble heard in the CR, not an airplane to my ears
• 02:57UTC - lock loss, IMC remained locked, which I haven't noticed before, then broke lock during the down script, plot attached, OMC appears to go first
• PI Mode 28 range up at the beginning of the lock, none since

[Suresh D, Bubba G, Jason O, Rick S., Sudarshan G]

We have seen that a non-glitchy oplev laser could be pushed into a glitchy behaviour if the ambient temperature changes.  Since we presently tune the lasers for single-mode (non-glitchy) operation in the PCal lab and then transport them to their respective oplev locations, we are required to retune their power in-situ to recover glitch-free behaviour.  This is often a time consuming process.  We therefore wished to be able to set the PCal room to the temperature of LVEA (or XVEA or YVEA as needed) so that we may be able to increase the reliability of this process and reduce the time needed to tune them in-situ.

At this time the two end-station VEAs in LHO have glitchy lasers.  We therefore wish to replace these with tuned lasers at the earliest opportunity.   We measured the temperature of these VEAs.

Bubba reset the air-conditioning control settings in the LSB labs, so that we can set the PCal lab temperature to required value.

We have prepared three lasers for glitch free operation. [SD, JO].  One of them is presently ready for installation at Y-end (tuned at 66.1 degF room temperature).  See attached pics for further details.  

Two others lasers are under preparation for installation at X-end and possibly BS.

Note: The same thermocouple sensor (Fluke hand-held device) was used  at all locations to avoid calibration differences between various wall mounted sensors at these locations.

TITLE: 03/25 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    Wind: 19mph Gusts, 17mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.32 μm/s
QUICK SUMMARY: locked in Observe

Why?--Robert is going to guide me on helping him with Chamber Pinning investigation.  That is, does proximity to the chamber reduce wind induced tilt of the floor?

SEI is using just one of our three LVEA STS2s, ITMY (STS2B) for HEPI and ISI Sensor Correction.  So we'll move an under utilized STSs around the floor to see how distance from/to the Chamber Legs affects the tilt of the floor induced by wind.

Right now, the HAM5 machine is actually in the BierGarten a couple meters -Y of the ITMY machine; I'll call the machine in this position Roam1.  Not quite close enough for a huddle test (especially if it were windy) so I'll move it closer next week.

Meanwhile, we can compare things now to access the seismometers' health.

Had a fairly quiet wind last night so attached are low wind comparisons.

Plot1 are the X-axes.  Roam1 and ITMY compare pretty well until we get down to about 20mHz. HAM2 X may have a problem or it is just the location.  With these light winds, really less than 5mph mostly during the 5500sec spectra, it is troubling to see the ETMY X channel.  The wind is light, it is 4:30am, no reason for that noise compared to the others.

The Y axes in Plot2 reveal the good agreement between ITMY and Roam1 is now down to below 10mHz.  HAM2 again we assume is suffering either from it's location or its rough LIGO life over the years.  The End Machines compare quite well to below 10mHz as well.

The 3rd plot shows great z axis agreement between the site instruments to well below 10mHz (except maybe HAM2 again, around 5-6mHz.)  Too bad this channel wasn't the one we need for tilt studies.

TITLE: 03/24 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 63Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: 11.5 hour lock observing for most of the time, other than for a 24min while Robert turned on the fire pump while LLO was down. DARM seems to be a bit more noisy since then and our range has been dipping a bit. I'm not sure where the balers are, but they are not where Bubba said they were suppose to be. We are still seeing some large spike in the seismic 3-10Hz BLRMS so maybe this is the cause, but this is just a wild guess.

LOG:

• 15:37 Running a2l while LLO is down
• 15:44 Observing
• 16:41 Balers headed to Yarm, near MY.
• 19:36 Balers done on Xarm, will be working on the machine in its normal parking spot.
• 20:21 Out of Observing so Robert can turn on the fire pump while LLO is down.
• 20:45 Observing

In brief, I found some significant correlation between (a class of) blip glitches and the values of some suspension signals coming from the OSEM and local sensor readout.

I found that some of the blip glitches tend to cluster around particular values of the signals. In particular the signals listed below are the most significant ones:

• ETMX_M0_DAMP_L_INMON, ETMX_M0_DAMP_R_INMON, ETMX_M0_DAMP_V_INMON, ETMX_M0_DAMP_Y_INMON,
• ETMY_M0_DAMP_P_INMON, ETMY_M0_DAMP_T_INMON,
• ITMX_M0_DAMP_P_INMON, ITMX_M0_DAMP_R_INMON, ITMX_M0_DAMP_V_INMON,
• ITMY_M0_DAMP_P_INMON, ITMY_M0_DAMP_R_INMON, ITMY_M0_DAMP_V_INMON
• ETMX_L1_WIT_YMON,
• ETMY_L1_WIT_PMON, ETMY_L1_WIT_YMON,
• ITMX_L1_WIT_LMON,
• ITMY_L1_WIT_LMON, ITMY_L1_WIT_PMON
• ITMX_L2_WIT_PMON,
• ITMY_L2_WIT_YMON

Read below for more details on the methodology and the results.

Method

• First of all I downloaded a list of identified blip glitches from the GravitySpy page (thank you TJ for pointing me to this). In O2, at Hanford, there are in total 5548 glitches that are identified as blips. Most of them are identified with high confidence (>99%). The time spans between 1164564597 (Nov 30 2016 18:09:40 UTC) and 1171671859 (Feb 21 2017 00:24:01 UTC).
• I downloaded 60 seconds of data (using the 16 Hz monitoring channels) around each blip glitch (-30s to +30s) for all the test mass SUS-XXX_M0_DAMP_*_INMON, SUS-XXX_L1_WIT_*MON, SUS-XXX_L2_WIT_*MON, SUS-XXX_L3_OPLEV_*_OUT16 signals. I have 56 channels in total. 
• Even though I have 60 seconds of data, I just extracted the value of each signal at the time of each blip glitch. I also computed the first and second derivative of each signal at the same times.
• Then I randomly selected 5548 more times, uniformly distributed in the same range covered by the blip glitches. I ensured that the times I selected were in ANALYSIS_READY, not vetoed by any known flag (thanks again TJ for sharing the code to read the veto definer file) and at least 60 seconds from any known blip glitch. Those 5548 times can be considered as clean, glitch free times.
• For those clean times, I downloaded and sampled the same channels I used for the blip glitches.

At this point I have 5548 times identified as blip glitches, and the value of the suspension channels for each of those. And 5548 more times that are clean data, with the value of the suspension channels for each of those. 

• For each of the suspension signal, I computed the histogram of its values at the time of blip glitches, and another histogram at the clean times. By comparing the two histograms I can tell if blip glitches tend to happen for some particular values of the signals.

Results

Here's an example plot of the result. I picked one of the most interesting channel (SUS-ETMX_M0_DAMP_Y_INMON). The PDF files attached below contains the same kind of histograms for all channels, divided by test mass.

The first row shows results for the SUS-ETMX_M0_DAMP_Y_INMON signal. The first panel compares the histogram of the values of this signal for blip times (red) and clean times (blue). This histogram is normalized such that the value of the curve is the empirical probability distribution of having a particular value of the signal when a blip happens (o doesn't happen). The second panel in the first row is the cumulative probability distribution (the integral of the histogram): the value at an abscissa x gives the probability of having a value of the signal lower than x. It is a standard way to smooth out the histogram, and it is often used as a test for the equality of two empirical distributions (the Kolmogorov-Smirnov test). The third panel is the ratio of the histogram of glitchy times over the histogram of clean times: if the two distributions are equal, it should be one. The shaded region is the 95% confidence interval, computed assuming that the number of counts in each bin of the histogram is a naive Poisson distribution. This is probably not a good assumption, but the best I could come up with.

The second row is the same, but this time I'm considering the derivative of the signal. The third row is for the second derivative. I don't see much of interest in the derivative plots of any signal. Probably it's due to the high frequency content of those signals, I should try to apply a low pass filter. On my to-do list.

However, looking a the histogram comparison on the very first panel, it's clear that the two distributions are different: a subset of blip glitches happen when the signal SUS-ETMX_M0_DAMP_Y_INMON has a value of about 15.5. There are almost no counts of clean data for this value. I think this is a quite strong correlation.

You can look at all the signals in the PDF files. Here's a summary of the most relevant findings. I'm listing all the signals that show a significant peak of blip glitches, as above, and the corresponding value:

Some of the peaks listed above are quite narrow, some are wider. It looks like ITMY is the suspension with more peaks, and probably the most significant correlations. But that's not very conclusive.

To do next

• My guess is that all the peak above are coming from the same family of glitches. But this has to be checked. I can select a subset of blip glitches by setting some cuts in the signal values. And I can check if I get the same subset from all signals
• Once I have a family of glitches (for example those that correspond to SUS-ETMX_M0_DAMP_Y_INMON ~ 15.5 above), it's interesting to check if they are randomly distributed over the duration of the run, or if they cluster around a specific time
• Also, I have to try and see if that family of blip glitches can be characterized by some properties (like bandwidth, central frequency, duration, etc...)
• And there are many more channels to check. My initial motivation for looking at suspension signals was to check for crackling glitches: stress releases in the suspension blades, wires or fibers.
• Just for fun I trained a simple (shallow) neural network to try to distinguish glitches from clean times. Results were not good enough to be reported here, mainly because it's quite cleat than only a subset of blip glitches are correlated with suspension signals