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

Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 38 seconds. LLCV set back to 16.0% open.
Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 1902 seconds. TC A did not register fill. LLCV set back to 43.0% open.

model restarts logged for Thu 23/Mar/2017 - Mon 20/Mar/2017 No restarts reported

no code changes during Tuesday maintenance.

We always thought that the video of ITMY is worse than ITMX but we were not sure about the camera/lens setting.

Richard opened the iris of both ITMX and ITMY gige camera all the way on Tuesday, and they still look the same. In the attached, several pictures with different exposures are combined, but even without doing anything ITMY looks obviously brighter.

Is there any hidden variable here?

(Added later: Non-conclusion of this alog is, it seems as if ITMY HR has larger scattering than ITMX HR, and that ITMX HR doesn't seem to have a  single big scatterer, but I'm still wondering if this is due to some hidden setting somewhere.)

At 11:50:12 UTC verbal alarms reported: 'Timing system error'. I worked my way through the timing medm screens, trending each error channel to see which screen to go to next. In the end I found H1:SYS-TIMING_C_FO_A_PORT_2_SLAVE_ERROR_CODE went to 40 briefly. I'm not sure how to interpret this. Trends of the sequential error codes are attached.

I analyzed the HWS data for the lock-acquisition that occurs around 1173641000. The "point source" lens appears very quickly (within the first 60s) and then we see a larger thermal blooming over the next few hundred seconds. I've plotted the data below (both gradient field and wavefront OPD). There are a few obviously errant spots in the HWS gradient field data. Since I'm still getting used to Python, I've not managed to successfully strip these off yet. However, it is safe to ignore them.

Check out the video too. Next step is to match a COMSOL model of thermal lensing with a point absorber to the data to get a best estimate of the size of absorber and the power absorbed (preliminary estimates are of the order of 10mW).

FYI: this measurement compares the system before, during and after a lock-acquisition (ignore the title that says "lock-loss"). The previous measurement, 34853, looked at lens decay before, during and after a lock-loss.