TITLE: 06/15 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
INCOMING OPERATOR: Travis
SHIFT SUMMARY: locked in Observe entire shift

Locked and almost no glitches in the last 2 hours, winds are below 10mph accross the site.

TITLE: 06/15 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 113Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
    Wind: 8mph Gusts, 7mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY: locked and in Observe for 6+ hours

TITLE: 06/15 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 51Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:

Quiet shift. Nothing eventful. Handing off to Cheryl.
LOG:

This afternoon we spent about 3 hours struggling to lock ALS.

At 20:45 UTC we lost lock while transitioning to Earthquake mode (though the ground motion wasn't really that high)

While reacquiring we kept losing lock while trying to lock ALS. We saw a few different problems:

• We were frequenctly losing the IMC. Sheila went to the PSL racks and measured the IMC UGF while it was locked at 2W. It was ~39 kHz, comparable to the last measurement of 40kHz.
• For a while we could not get through ALS_COMM's Handoff_Part_2, where we transition the IMC control from IMC_MCL to LSC_MCL and ALS_COMM. As we increased the analog gain of the LSC refl servo we saw glitches in the Y arm and sometimes in both arms.
  • We temporarily reduced the fianl analog gain from 17 dB to 10 dB.
  • First attachment shows some glitches seen in the transmission of both arms during/after the slider adjustment, followed by the y-arm losing lock, followed by the x arm losing lock
  • Second attachment shows another time when the glitches were more obvious in the y arm, but both arms lost lock at the same time
  • We tried locking COMM before DIFF (normally we lock DIFF first following the saga where ALS-DIFF PLL caused glitches in COMM documented here). And at this point we survived, but not because we changed the locking order - we lost lock again afterwards and reacquired just fine with the normal old guardian settings

In conclusion: for some reason we don't know, we couldn't lock ALS for a couple of hours this afternoon. Then for some reason we don't know, we could lock it again.

While watching operators relock today there were two things that we changed to help make future re-locking more reliable.  (This wasn't commissioning, we just addressed some existing problems with the locking while we were relocking).

New state for green arm guardians:

• We added offloading of the green WFS to ETM +TMS a few weeks ago.  This morning Travis encountered a situation that guardian wasn't set up well to handle, where the arm unlocked while it was offlaoding.  The offloading state doesn't check for locklosses, since we want it to complete the offloading even if the arm unlocks.  However, since ISC_LOCK was requesting the offloaded state, the arm guardian never went through down and relocked.  I added a new state, called ETM_TMS_WFS_OFFLOADED directly after the offload state in the graph, which is now requested in LOCKING_ARMS_GREEN.  This state checks if the green arm is still locked, and will respond appropriately if not. 
• One note: we still need to look at the offloading sequence, which doesn't seem as smooth as it should be, although we didn't have time for that today. 

Offsets in AS36 for DRMI ASC:

• We have a long standing problem that AS36 has offsets that seem to change.  We first engage the DRMI ASC with the beamsplitter controlled by AS45, then after the other loops have all converged we change over to 36 before doing the CARM offset reduction.  But DRMI usually becomes misaligned when we change over, and sometimes this is bad enough to cause locklosses.  After today's first lockloss we tried putting offsets in the AS36 Q pit and yaw filters after the ASC converged with the beamsplitter controlled by AS45,  switched over to 36 for the CARM offset reduction, and turned off the offsets before engaging the full lock ASC. Since it worked, we added it to the guardian to set the offsets based on an average of the AS36 value once the ASC has converged. 

Relocking after and earthquake last night our range dropped from around 115 to around 107Mpc, this was because a bug in the squeezer LO guardian would under some circumstances not engage the boost in the LO servo . 

TJ noted the range drop and Cheryl looked at some alignment changes: 

• https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=49905
• https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=49912
• Patrick has started some BRUCO scans to compare before and after lock stretches:
  • https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=49913

The problem was that there was a check on the power in the 3MHz beatnote that was executed twice, in a way that left us open to unintended configurations.  This wrong configuration must have also been accepted in SDF. There was probably confusion because there was also a beckhoff crash from which things were not correctly restored last night. 

I've edited the SQZ_LO_LR guardian to avoid this situation in the future.  I also simplified the graph for the LO guardian because there were unneeded and potentially problematic connections in it. (screenshot of the changes to the graph attached). 

The last attachment shows the change in the DARM spectrum when the LO boosts were off, there is excess noise around 100Hz.  

(Kyle R, Gerardo M)

The crane was used at Y-Mid to lift the new turbo pump assembly, to aid on drilling 4 holes on the turbo support structure for feet.  The crane movement took place during 3 different intervals:

Starting at 20:20 - stopping at 20:45 utc.

Starting at 21:10 - stopping at 21:17 utc

Starting at 21:27 - stopping at 22:15 utc

TITLE: 06/14 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Travis
CURRENT ENVIRONMENT:
    Wind: 16mph Gusts, 10mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY:

Commissioners working on ALS

TITLE: 06/14 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Ed
SHIFT SUMMARY:  A couple of locklosses early during the first half of the shift.  The second half of the shift has been used for Commissioning since ALS has been having issues relocking.
LOG:

19:56 Kyle and Gerardo to MY

22:32 Kyle and Gerardo back

Lockloss while transitioning to EQ mode.  Maybe I waited to long to transition. 

Ran through initial alignment after which it relocked without issue.

Some SDF diffs for ASC, PRM, and TCSCS that I accepted.  Screenshots attached.

Searches started for before and after lock loss last night
Started around 16:32 UTC

https://ldas-jobs.ligo.caltech.edu/~ldvw/bruco/patrick.thomas/H1-CAL-DELTAL_EXTERNAL_DQ_2019-06-13-18.30.53-600
https://ldas-jobs.ligo.caltech.edu/~ldvw/bruco/patrick.thomas/H1-CAL-DELTAL_EXTERNAL_DQ_2019-06-14-11.09.47-600

Currently talking to Patrick to get it going again.

h1ecatc1 C1_PLC1_Device3 is under reporting its slave count (actual = 156, configured = 291). 

We took a look at several ALS PLLs to check if the ALS DIFF/COMM glitches we saw last night were associated with them.
From Plot 1 we see that both the COMM and DIFF PLL control signals glitch strongly at the same time as the ETMY coils.

Plot 2: We ran a test where we locked ALS COMM normally and looked for glitches, which we found (red).  Then we shuttered the Y arm and the glitches in ALS_COMM went away.
Seems that the COMM PLL was partially polluted by Y arm light, which is close in frequency to the X arm light.

Solutions being considered are fixing the ISCT1 alignment/changing the polarization of the X vs Y transmission beam, or moving the VCO frequencies.

Attachment 3 shows the beat frequencies of the entire ALS system.  Seems that the X and Y arm beat frequencies are within 10s of kHz and the X and Y beatnotes could be getting confused on ALS COMM.