J. Kissel

Last Wednesday -- while initial alignment references were set to the "August" position (see on Aug 01; see LHO aLOG 50954) -- Sheila adjusted the alignment of the ALS DIFF beatnote beam on its diode on ISCT1 LHO aLOG 51280 because we thought that was one of the problems causing the last weeks locking problems (turns out it was BRSX glitching, see FRS Ticket 13417). She improved the beat note power on the diode from ~ -26 dBm to ~ -8 dBm.

Last Thursday (8/15), we adjusted the initial alignment offsets to reference a position centered on the test masses LHO aLOG 51307.

I wanted to confirm that in the new "centered," "acquisition" positions, the ALS DIFF beat note was still nice and high, and we didn't need to go back and revisit the ISCT beat note alignment. 
It is confirmed: Although it did change a bit for the worse, the power, on average, is stil about -9.5 dBm -- plenty high.

See attached ~1 week trend of the ALS DIFF beatnote power vs. the guardian state (to remind us that the ALS DIFF beatnote is only meaningful when ALS is in use during the lock acquisition sequence).

I've been trying to put together some data on improvements to our earthquake robustness, kind of related to work that EyalS has done while LLO works on their earthquake stuff. My attached plot compares the cumulative distributions of earthquakes that we have ridden out over the 3 observing runs. The blue trace is O1, red is O2, gold is O3. I generated this plot by using the matlab peakfinder code to find peaks in the .03-.1hz Z ground blrms to find all peaks in this band above 200nm/s and found all of the peaks that we were in NLN 10 minutes before and 10 minutes after. I would interpret this plot as for a given peak velocity in O3 we are about twice as likely to stay locked as we were during O2. Maybe someone smarter has a better interpretation. 

My original intent was to show that the earthquake mode has improved our ability to ride out an earthquake, and this plot does show that we are doing better now than in previous runs. But, I would like to try to do a comparison during O3 when we used used the earthquake settings and when we didn't touch anything. Still working on that.

TITLE: 08/19 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Jeff
SHIFT SUMMARY: Lost lock an hour into a commissioning break. Running an initial alignment now.
LOG:

• 1539-1540 Out of Observing, ITMY CO2 lost lock, reaquired.
• 1641 Vanessa to MX
• 1726 Karen to MY
• 1844 Karen back
• 2130 Out of Observing to start commissioning
• 2131 Matt to LVEA to set up PEM equipment
• 2241 Lock loss during commissioning

I have updated the GPR HDF5 files for use in computing response function uncertainty.

Scripts used to produce the HDF5 files:
trunk/Runs/O3/H1/Scripts/Uncertainty/process_allmeas_writeGPRHDF5_model20190416-A.py   r8224
trunk/Runs/O3/H1/Scripts/Uncertainty/process_allmeas_writeGPRHDF5_model20190416-C.py   r8228

GPR HDF5 files for use by RRNom.py:
trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_A_GPR_20190416_multi.hdf5   r8186
trunk/Runs/O3/H1/Results/Uncertainty/O3_H1_C_GPR_20190416_multi_nofsQcorr_fmin30Hz_lengthscaleZp5.hdf5   r8230

Note that there is a new file to use for the GPR of the optical plant. The reason for the change is that below 30 Hz, the MCMC does a poor job fitting the data. This impacts the fit for optical gain and coupled cavity pole frequency (see G1901479, slides 10, 11, and 19), which need to be correctly fit in the frequency range of importance. Also, currently C00 and C01 do not correct for any spring frequency or quality factor Q, so we should not be correcting our measurements by these values--our systematic error at low frequency will naturally expand because of this.

Actuation and sensing MCMC values for the reference model remain the same, as per our procedure.

LVEA will be laser SAFE at the start of maintenance tomorrow. We will transition to hazard after this work is complete.

See (sideways) picture for current list of maintenance activities.

ITMY CO2 laser dropped lock, and then reaquired.

I will see if finding a new lock point tomorrow during maintenance will help.

TITLE: 08/19 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Niko
CURRENT ENVIRONMENT:
    Wind: 5mph Gusts, 2mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY: 9.5 hour lock, calm environment.

TITLE: 08/19 Eve Shift 07:00 – 15:00 (00:00-08:00), all times posted in UTC

STATE of H1: Observing

INCOMING OPERATOR: TJ

SHIFT SUMMARY: Quiet shift, small interruption in Observing from TCS ITMY CO2 laser unlocking. Locked for 9 hours, Observing for 5 hours.

LOG:

07:00 (00:00) Start of shift

09:27 (02:27) Dropped out of Observing, TCS_ITMY_CO2 laser unlocked.

09:29 (02:29) Laser re-locked, back to Observing

14:58 (07:58) Ethan to Optics Lab

15:00 (08:00) End of shift

Ops Shift Transition: 08/19/2019, Owl Shift 07:00 – 15:00 (00:00-08:00) - UTC (PT)

State of H1: Locked

Intent Bit: Observing

Weather: 0-10 mph wind

Primary 0.03 – 0.1Hz: 0.01 um/s

Secondary 0.1 – 0.3Hz: 0.1 um/s

Outgoing Operator: Ed

Quick Summary: Quiet at the moment, been in Observing for a little over an hour.

• Slight retouch on X Arm
• Y Arm needed much more help - was able to recover alignment
• had a rather tough time with manual PRMI to bring it to a poinmt that ASC could take it
• DRMI was unseuccessful - back to PRMI
• Lock failed at ENGAGE_ACS_FOR_FULL_IFO - error signals didn't look bad...hmm. Perhapes I'll let it "cook" for a bit
• next attempt had lockloss trying to acquire DRMI - broke IMC for a bit
• Acquire DRMI broke the IMC again
• relocking IMC - cleared WFS and reset PZTs - WFS are steering it
• I think newly centered IMC spot looks pretty good - trying the re-lock again.
• DRMI caught - ASC drove it right into the ground while OMs were railing
• DRMI locked again and OMs ok this time - ASC not acting destructive
• NLN 5:41UTC
• Accepted new PZT alignment diffs for IMC - ALSEX, ALSEY, and MC3 all had accuracy diffs I acceoted as well
• 5:42UTC H1 Observing - WHEW!

TITLE: 08/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 25Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    Wind: 3mph Gusts, 1mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY:

H1 Locked and Observing for 2.5 hours. no noticinble 1-20 Hz glitching at this time. EX saturations happening at 30-40 minute intervals

TITLE: 08/18 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 107Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY:

Had a lockloss due to an earthquake (EARTHQUAKE ISI state not possible currently).  Back to OBSERVE after waiting for Earth to quiet down and also while babysitting ASC.  Range currently hovering around 112-119Mpc.
LOG:

• 18:08 Notification of 5.8 south pacific earthquake (~30min out).  EARTHQUAKE state not useful without BRSx, so will just monitor (this one looks to be square in the "earthquake" zone.  *crossing fingers* to ride through it.
• 18:39 Lockloss due to 5.8 the EQ
• 20:53:  Back to Observing
  • OBSERVATORY MODE marked by EARTHQUAKE from 18:39 - 20:53utc
• 22:00 Restarted video4 & video0.

After the lockloss at ENGAGE SOFT LOOPS, made sure to babysit the ASC error signals.  Ended up making adjustments for CHARD pit/yaw mostly & then a little DHARD pit.  Here are my locking notes:

• 18:39 Lockloss due to 5.8 the EQ in South Pacific.  Took OBSERVATORY MODE to EARTHQUAKE to mark this down time.
• LOCK#1
  • ALS TOOK A WHILE TO calm down so stayed with green arms a wahile
  • PRMI looked dead and obviously would not lock, visibly off in yaw.  Tweaked PRM & BS in yaw and had short locks which only lasted about 1 sec (not great alignment and earth still swinging things).  Tried tweaks for 20min because it looked like it was getting better.....
• 19:30 Just as I was going to try anInitial Alignment, PRMI locked and I was able to tweak BS/PRM up to nice values.  Then went to PRMI_ASC.
• DRMI locked in 4min
• LOCKLOSS AT ENGAGE SOFT LOOPS
• Lock #2
  • Error Signal Babysitting:
    • While in ENGAGE_ASC_FOR_FULL_IFO (hung out here for a while and watched ndscopes):  CHARD Yaw:  4-steps of +0.03, then another 3-steps & then lost count, because I also had to do this for CHARD Pit.....these moves from made via script (alog here).  
    • When everything looked happy, moved on to...
  • ENGAGE_SOFT_LOOPS.  Paused here for a while and observed ASC signals:  adjusted DHARD Pit a few steps.  Since everything looked OK, moved on and made it all the way to NLN with no issues.  (only SDF diffs were teeny tiny ones & were ACCEPTED.
• 20:53:  Back to Observing
  • OBSERVATORY MODE marked by EARTHQUAKE from 18-39 - 20:53utc

After waiting for EQ to die down, tried locking.  PRMI was dead (but off in yaw, so tweaked BS/PRM).  Eventually had some action and locked/optimized PRMI by hand. 

Then continued with locking.  DRMI locked fine and went through most steps fine, except....

Lockloss at:  ENGAGE SOFT LOOPS

Here it looks like we might have been having ASC driving off PRC/SRC (see attached ndscopes).  So maybe I'll need to scripts Jeff K posted about last time I was on shift (alog here) and there were ASC issues last week.  But looking at this lockloss, I'm seeing all kinds of signals getting big (CHARD, CSOFT, DSOFT, etc.) ...so not sure who I would try!  :-/

NOTE:  Did not do an Initial Alignment.  That is another idea to try.

I'm putting a summary of the things we tried with BRSX today here. It might be fixed, but we need to monitor it overnight.

First thing, Patrick and I remotely restarted the BRSX beckhoff computer. This didn't resolve the glitching. 

Next, Hugh, Fil and I went to the end station. We checked nothing was hitting the box, the inside looked undisturbed. Fil and Hugh power cycled the 24V power to the beckhoff (not sure what all that involved) and I restarted the beckhoff computer again. Still glitching.

Later, I found that there were fluctuations on the reference spots on the CCD, as Jeff K put in the DCC earlier.

Hugh and I went to EX again, this time we pulled the power on the light source, then plugged it back in. While we were there, we also opened the BRS enclosure again and pulled the CCD of the top of the light pipe. After looking down into the light pipe, we noticed two pretty good sized, dead, bugs sitting on the viewport at the bottom of the light pipe.  I couldn't get my phone to focus on them through the beamsplitter. Since we couldn't reach them and didn't want to take the light pipe off, we put the CCD back on.

The BRS is more or less back in it's nominal state and I've been watching it for the last hour. It hasn't glitched since being restored after this last incursion, but it's still pretty rung up. Looking at trends from earlier, it seems possible that the glitches don't appear when the BRS is moving above some threshold. Could also be that power cycling the light source fixed it.

We should still monitor the BRS for at least overnight, before trying to run with it again.