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.)

I have added an (unreleased) algorithm into the GDS/DCS pipeline to compute the SRC spring frequency and Q. This algorithm was used to collect 18 hours of data on February 4 (first plot) and 18 hours of data on March 4 (second plot). The plots include kappa_c, the cavity pole, the SRC spring frequency, the SRC Q, and 4 of the coherence uncertainties (uncertainty of the 7.93 Hz line is not yet available).

The derivation this algorithm was based on is similar to what Jeff has posted ( https://dcc.ligo.org/DocDB/0140/T1700106/001/T1700106-v1.pdf ), with differences noted below:
1) The approximation made at the bottom of p4 and top of p5 was only used in the calculation of kappa_c and the cavity pole. So SRC detuning effects were not accounted for in computing S_c. However, kappa_c and the computed cavity pole were used in the calculation of S_s.
2) In eq. 18, I have a minus (-) sign instead of a plus (+) sign before EP6. S_c = S(f_1, t) has been computed this way in GDS/DCS since the start of O2 (I assume during O1 as well).
3) Similarly, in eq. 20, I have a minus sign (-) before EP12.
4) In the lower two equations of 13, I have the terms under the square root subtracted in the opposite order, as suggested by Shivaraj. (Also, I noted that the expression for Q should only depend on S(f_2, t), with no dependence on S(f_1, t). )

The smoothing (128s running median + 10s average) was done on f_s and 1/Q, since that is the way they would be applied to h(t). Therefore, the zero-crossings of 1/Q show up as asymptotes in the plot of Q. I think it would be better to output 1/Q in a channel rather than Q for this reason.

There is a noticeable ramping up of f_s at the beginning of lock stretches, and the range of values agrees with what has been measured previously.

I've noted that it is quite difficult to resolve the value of Q with good accuracy. These are some reasons I suspect:
1) Higher uncertainty of calibration measurements at low frequency can add a systematic error to the EPICS values computed at 7.93 Hz. This may be why the Q is more often negative than positive ??
2) In the calculation of S_s, the actuation strength is subtracted from the ratio of pcal and DARM_ERR. Since this is such a low frequency, the subtracted values are close to the same value in magnitude and phase. Thus, subtracting magnifies both systematic error and uncertainty.
3) The imaginary part of S_s (see eq. 13, bottom equation) in the denominator, is very close to zero, so small fluctuations (about zero, as it turns out) in 1/Q cause large fluctuations in Q.

These reasons make it difficult to measure Q with this method. The effect of these measured-Q fluctuations on S_s, the factor we would actually apply to h(t) (see eq. 22), is not enormous, so long as we apply the smoothing to 1/Q, as I have done here.

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 67Mpc
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
    Wind: 5mph Gusts, 4mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.38 μm/s
QUICK SUMMARY: Glad to see us recovered from yesterday and we are now riding a 4 hours lock at 67Mpc

TITLE: 03/24 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY: One lock loss. Cause not immediately apparent. No major issues relocking. Had a verbal alarms notification of a timing system error (see alog 35058). Tumbleweed baling has started at LSB.
LOG:

Closed bash terminal that was obscuring screenshot of nuc0 DMT Omega plot
10:27 UTC Lockloss
11:07 UTC Back to observing
11:11 UTC PI mode 28 rang up and back down on its own
11:19 UTC Changed phase to damp PI mode 27
11:50 UTC Verbal alarm: Timing system error.
14:04 UTC Tumbleweed balers started tractor, waiting for it to warm up, then driving it to start baling at the LSB.
14:38 UTC Damped PI mode 27

I have shut down the instrument air compressors at M X. All of the pneumatic actuators have been replaced with electric actuators. The only call for air at that station would be when the vacuum system needs to run the turbo pumps or for the water storage tank. The compressors are still readily available for these functions, they will just need to be turned back on. 
Eventually all of the I A compressors will be placed in this stand by mode and not continually running and cycling, saving both electricity and maintenance cost.
I do plan to cycle these on a monthly basis just so they will be ready when needed.  

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.

Lost lock at 10:27 UTC. Cause unclear. Almost back to NLN.

Upon entering the control room, I noticed that we have a low frequency oscillation in the PRC gain, POP DC, etc. on our front wall striptool.  Turns out, this is the same as what Jim documented last night in alog 34999, and likely comes from Sheila's changing of the oplev damping cutoff in alog 34988.

I would like to go back to the old 10 Hz cutoff that we used to have in the oplevs, to see if that fixes this.  However, Sheila noted to me that the old cutoff is zero history, no ramp, so we can't just go out of Observe and switch filters.  I'll need to change the filters to always on, few sec ramp, load the filters, then we can switch back.

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.