It appears that the PSL may have tripped after the last lock loss. The NPRO output power is 0.

Start of shift: Sitting at DRMI_LOCKED. SRC1 Pitch and Yaw are not converging. EX constantly saturating. Diag message that PSL_ISS diffracted power is high (around 9%).
23:56 UTC H1IOPASC0 has its TIM bit red. Diag Reset cleared it.
00:01 UTC Cleared history for H1ASC-SRC1_P filter to see if it would help SRC1 Pitch converge. It did not.
00:06 UTC Stepped to DRMI_ASC_OFFLOAD. SRC1 Pitch and Yaw converged. EX still saturating.
00:09 UTC Stepped to PREP_TR_CARM. EX still saturating. ISS second loop is on.
00:13 UTC Stepped to CARM_ON_TR. EX still saturating.
00:14 UTC Stepped to REDUCE_CARM_OFFSET. EX still saturating.
00:15 UTC Stepped to SWITCH_TO_QPDS. EX still saturating. AS Air looks unstable.
00:17 UTC Stepped to RF_DARM. EX no longer saturating.
00:24 UTC Stepped to DHARD_WFS.
00:27 UTC Stepped to REDUCE_CARM_OFFSET more.
00:30 UTC Stepped to CARM_15PM. PRC2 YAW error signal stepped up.
00:34 UTC Stepped to CARM_10PM. PRC2 YAW error signal stepped up.
00:38 UTC Stepped to CARM_5PM. Almost immediately lost lock.
00:40 UTC Starting initial alignment.
00:47 UTC Video 5 images frozen. Power cycled.

Trouble locking Y arm on green. Loses lock when WFS engage. Set to LOCKED_NO_SLOW_NO_WFS and it remains fairly stable around .5. Brought Y arm to around 0.8 by adjusting ETMY, TMSY and ITMY at LOCKED_NO_SLOW_NO_WFS. Cleared WFS history. Lost the lock on Y. Put ITMY and TMSY back to original values. This time able to lock just by adjusting ETMY. It remained locked and the power increased when I changed the state back to INITIAL_ALIGNMENT.

02:16 UTC Video 4 striptool jittery. Power cycled.
02:31 UTC Initial alignment done.
02:57 UTC Stopping at CARM_10PM to try and diagnose.
03:12 UTC Lost lock sitting at CARM_10PM some time after setting the following in guardian by hand:
ezca.switch('LSC-REFLBIAS', 'FM2', 'ON')
ezca['LSC-TR_CARM_TRAMP'] = 5
ezca['LSC-PD_DOF_MTRX_TRAMP'] = 5

03:23 UTC Back to CARM_10PM. Will wait to see how stable this is.

Something happened early in the morning today (about 2016-10-08 12:50 UTC +- 10 min) and the transmission is only 78W as of now while the reflection is 38W or so.

State of H1: no locking beyond DRMI, breaking lock at CARM_5PM

Assistance: Peter King

Details:

• H1 can reach DRMI, but cannot make it through CARM_5PM
• ISS Inner Loop has been ocillating at random times during locks, and toggling the AUTO servo has helped get it back
• FSS on lockloss has gone into oscillation almost every lock
• Peter was helpful in showing me how to turn the ISS Second Loop OFF during locking
• However, the ISS Second Loop is turned on in DRMI_LOCKED
• I tried getting past CARM_5PM without the ISS Second Loop on, but that didn't work

Diagnostics:

• I tried to run the lockloss tool, but it's giving me an error and not showing anything after 10/8, 00:07UTC - no help
• What I did capture on the StripTool on Video0 is... PRC2_Y rang up and then dove toward 0 in the last minute of lock - picture attached
• Then I looked up that PRC2_Y comes from RF9I, which I believe was worked on yesterday
• Having just found this, and assuming settings were changed on RF9, the next step is to set RF9 back to Thursday's settings and attempt lock

A scan of coherences during last night's lock can be found here:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1159948817/

Nothing new:

• The low frequency seems dominated by ASC-CHARD_P
• MICH/SRCL/PRCL are still very high
• Jitter is still visible in the IMC WFS signals
• It looks like the diagnostic breadboard signals are not transfered to the frames in the local cluster, so they are not included in the scan

Additional BruCo scans are available for the PRCL and SRCL error signals:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_prcl_1159948817/

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_srcl_1159948817/

• H1 has made it to and through DRMI_LOCKED a few times, but not to ENGAGE_SRC_ASC.
• This last attempt I went through each stage after DRMI_LOCKED by hand, and it lost lock at RF_DARM.
• Calling to find help from a commissioner.

Last night the IFO was locked stably for a long period of time, so I had a look of the coupling of the HPO jitter into DARM.

Stability of the coupling over time

I measured the transfer function from DBB_Q1Y (the largest one) with CAL_DELTAL every ten minutes, over the entire lock. It turns out that the shape of the transfer function is quite constant over time, while the overall gain was clearly changing, and increasing during the lock. The first attached plot shows a time-frequency plot of how the transfer function changed, with respect to the mean. In other words, the plot shows TF at a give time divided by the mean TF over the entire period. There is a clear trend to increase. This is also visible in the second plot, which shows the value of the TF in three selected bands, as a function of time. All three bands moves roughly in the same way.

Time domain subtraction

As done before, I computed and fitted the transfer function from DBB_Q1Y to CAL_DELTAL. Figure 3 shows the coherences for all DBB signals, and figure 4 shows the transfer function from Q1Y and the fit. Note that the coherence was somehow smaller than what measured yesterday. I converted the fitter transfer function to an IIR filter and computed the time domain subtraction. The improvement in sensitivity is there, but not quite as impressive as yesterday (see 30300), see figure 5. However, coherence with Q1Y is reduced basically to zero, see figure 6.

SInce there was some small coherence with Q1X, I measured and fitted that transfer function too, and then subtracted Q1X. The result is shown in figures 7 (spectra) and 8 (coherences). The improvement is small, but there is clearly no more coherence with any DBB signal.

Coherence with IMC WFS

At that point I looked at the coherence of the double subtracted DARM with the IMC WFS centering signals. As shown in figure 9, this coherence is very large and could explain a lot of the noise in the 100-1000 Hz region. Figure 10 shows a coherence-based estimation of the subtracted noise. Unfortunately, the transfer function from IMC-WFS to DARM is very complex, and a time domain subtraction is not easy to do.

We should work on improving the IMC alignment, this used to be the right cure to reduce the coupling of jitter peaks into DARM.

• Y arm was very misaligned - WFS was driving the alignment to a bad place
• I cleared WFS and tried again to align the arm enough to hand off to WFS, but multiple times WFS drove the arm to lock loss
• thought I might have to do an initial alignment, but instead put the Y arm guardian into Manual and aligned with the arm unlocked
• after that WFS engaged and held, however, the only way I know how to restore Y arm to being managed by ISC_LOCK is to go through INIT
• I had to go to PRMI to tune up PRM and BS
• I had to set PRMI to PRMI_LOCK_WAIT because WFS was also killing PRMI (multiple times)
• in this case I did not have to go back to INIT, since we've set up the PRMI guardian to remain in managed by ISC_LOCK
• first attempt at going beyond DRMI broke lock somewhere before ENGAGE_SRC_ASC, I had paused in DRMI_LOCKED
• second attempt at going past DRMI I didn't pause and the DRMI_ASC_OFFLOAD broke the lock
• third attempt is now in progress, H1 is back to DRMI_LOCKED and I'm pausing here again
• during all of this every power signal from PMC trans to MC2 Trans glitched when the ISS Second Loop was engaged - maybe what happened last night - plot attached

State of H1: unlocked, relocking, needing some alignment, currently on it's way to DRMI_LOCKED

On Site: me, Robert, and Gabriele

I checked the IOT2 tables for scattered light. The beam on IOT2R was hitting an optic mount, so I blocked it. However, the beam was reflected from the black glass dump on the top mirror so it was already small. I also checked the tables by shaking them and got no coupling. I shook the output arm vacuum enclosure, no evident coupling. I shook several HAMs. Shaking HAM2 seemed to significantly increase the jitter peaks, periscope and HPO, while shaking HAM 3 did not. This may suggest clipping on HAM2. Ill look into this more in the morning.