TITLE: 03/21 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: None
SHIFT SUMMARY:

H1's been having issues staying locked for more than 45-90 minutes in the last day.  Acquisition is decent, although most lock attempts I have proactively went to CHECKMICHFRINGES + PRMI.  LOCK CLOCK is not working. Automatic Operation appeared to not work once, but for other couple of attempts it worked.
LOG:

•  
• 2256-2330 Initial alignment
• 2313 Run down X+Y arms (gabriele)
• 2329 End of SHG optics lab work (julian)
• 2330-0010 Lock#1:  Nice & straightforward lock.  For the last 45min Evan had some MICH excitations, and Naoki did some SQZ work.
  • 0010-0055 NLN, but another short lock similar to what (4) other locks during the day.  :-/
• 0156 Observing  (NLN at 0152)--Automatic Operation did NOT take H1 to Observing for some reason.
  • 0320 Lockloss with an ITMx SEI ISI Watchdog trip via the CPS'.
• 0323-0340 Lock#2:  Lockloss during PRMI after Check Mich Fringes
• 0341-0424 Lock #3:  Went directly to Check Mich Fringes and then PRMI.
• 0428-0559 OBSERVING (NLN @ 0424) via Automatic Operation (woo woo!)
• 0600-0605 Lock #4:  Lockloss at LOCKING ALS.  X-arm was harder to offload, but eventually did (with out flashes)
• 0606-0653 Lock#4:  Xarm clearly less stable than Y.  But it gets there (offloaded) within 2min this time.  Gave DRMI 3min to lock and then moved to CHECK MICH FRINGES + PRMI & then DRMI locked within 2min.  
• 0657 Back to Observing and placed in Auto Ops.

For the first lock of tonight's shift, noticed that the Lock Clock (or Lock Status) on nuc28would only go to "0:01" and stop during the entirety of the (45min lock).  I tried running the Lock Status script on my local computer and it would do the same thing....so this is why I did not restart nuc28.

(Later I also noticed that for the next lock, when I set GRD_IFO to Automatic Operation, this node did not take H1 to OBSERVING.)

Just had almost 90min of a lock.  And for this lockloss, ITMx ISI had a CPS watchdog trip.  Winds are much more calmer tonight than last night.

As shown in the attachment, I turned on the beam spot control. The flag of the beam spot control in sqzparams is set to True. The beam spot control seems working well, but I feel the yaw was too slow so I removed the -20dB gain (FM7 in INJ_ANG_Y). I will tune the green QPD offset with FC2 dither tomorrow.

[Jennie, Gabriele]

We tried again to move the input beam.

For pitch, we directly ramped IM1, IM3, IM4, PRM and PR2 with sliders deltas measured from the test yesterday. IM1 and IM3 were the mirrors we move yesterday, while the other were moved by ASC loops. Today with the ramp we helped the ASC loops by moving those mirrors in the right direction too. We first diod one step 1/10th of the target step, then 2/10th and then the remaining 7/10th. All went well: IM4_TRANS increased, but we did not see much change in POP_LF. However ASC-POP_B dropped near the end of the ramp, while ASC-POP_A didn't, so maybe we were moving near the edge of B.

We then started a  motion in yaw (both IM1 and IM3 negative). This seems a very good direction, and both IM4 and POP_LF got better quickly. However, right after we started the second step, we lost lock. This is similar to what happened in the previous test. We should probably move more slowly in yaw, but it worth repeating the test, since we are gaining power in POP_LF and arms.

H1 is now in NLN and I just ACCEPTED the one OMC diff (see attached) related to the OMC Frequency per (alog #76587 from Louis earlier today).

Updated notes from incorrect 73801 SQZ NLG instructions

To measure amplified signal for NLG:

1. SQZ_MANAGER to LOCKED_SEED_NLG (this locks the OPO on dual green + seed IR resonance, starts the SEED_PZT scanning, misaligns FC)
2.  Adjust temperature to maximize the H1: SQZ-OPO_IR_PD_LF_OUT   signal.
3. Measure the max as your amplified signal.

To measure unampilifed signal for NLG:

• SQZ_MANAGER to NO_SQUEEZING and SQZ_OPO to DOWN,
• Block the green beam via H1:SQZ-SHG_FIBR_FLIPPER_CONTROL
• Scan the OPO PZT with PZT_1 Enable, Use trigger: No (via SQZ Overview > HAM7 > OPO IR > OPO PZT1)
• Should see mode scan on H1: SQZ-OPO_IR_PD_LF_OUT. Measure the highest peak as "Unamplified" and the zero level as "Unamplified Dark Offset".
• Only need to this once (we did at start and end)

Calculation for NLG:

• Can now calculate NLG = Amplified / (Unamplified - Unamplified Dark Offset).
• SQZ_MANAGER to SQZ_READY_IFO (will swap back from SEED to CLF)
• SQZ_FC to IR_FOUND (so SQZ_MANGER doesn't ignore FC)

TITLE: 03/21 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 12mph Gusts, 7mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.23 μm/s
QUICK SUMMARY:

• Oli handed over an aligning H1.
  • It was having the INPUT_ALIGN issue again, so Oli had it hang out in the WFS_CENTERING_XARM (few minutes & then selected INPUT_ALIGN_OFFLOADED (on ALIGN_IFO).  Then to get INIT_ALIGN take over, Oli had me (MANUAL to INPUT_ALIGN_OFFLOADED, then switch back to AUTO and select INIT_ALIGN_COMPLETE, and we were back in business).  Winds are similar to 24hrs ago (but forecast does not have the strong winds for the night *crossing fingers!*
• We have COMMISSIONING time until 6pm local, so we'll see if anything can happen, otherwise, aim for OBSERVING starting at 6pm (or earlier).

TITLE: 03/21 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Five locklosses today, two known and three unknown.
LOG:

1500 Detector has been Locked for 9.5 hours
1555 Lockloss (unknown)
1633 We were going through CHECK_MICH_FRINGES so I took us to DOWN and then started an INITIAL_ALIGNMENT
1653 INITIAL_ALIGNMENT done, relocking

1738 NOMINAL_LOW_NOISE
1805 Lockloss (unknown)

1846 NOMINAL_LOW_NOISE
1934 Lockloss (unknown)
    - Multiple locklosses from LOCKING_ALS and ENGAGE_DRMI_ASC, and DRMI/PRMI locklosses
    - Ran MANUAL_INITIAL_ALIGNMENT for MICH, PRC, SRC

2041 NOMINAL_LOW_NOISE
2115 Lockloss (During InLock SUS Charge Measurements)

2158 NOMINAL_LOW_NOISE
2246 Lockloss (from commissioning)
    - Running an INITIAL_ALIGNMENT

I created a script update_sus_safesnap.py saved in $(USERAPPS)/isc/h1/guardian/ that updates the OPTICALIGN_{P,Y}_OFFSET values saved in the safe.snap files for the optics. These values are not monitored by SDF, but we still want these to be reasonably up-to-date for when computer issues mess up our offsets.

This script can be found in $(USERAPPS)/isc/h1/scripts/update_sus_safesnap.py and can be run from the terminal for many different optics or optic groups (attachment1). The default when no arguments are entered is to update the OPTICALIGN_{P,Y}_OFFSET values in safe.snap for the following: IMs, RMs, MCs, PRs, BS, SRs, OMs, TMSs, ETMs, and ITMs (basically everything except squeezer optics).

I have also added new states to the end of ALIGN_IFO(attachment2) and INIT_ALIGN(attachment3) called UPDATE_SAFE_SNAP that when selected, will update the OPTICALIGN_{P,Y}_OFFSET values in safe.snap for the default optic groups. We are still unsure as to how often this should be run, since we don't want to overwrite offset values with those from a bad initial alignment and lock, but we'll figure that out eventually. For now it will have to be selected either while the ALIGN_IFO OR INIT_ALIGN nodes are in DOWN or when INIT_ALIGN is at INIT_ALIGN_COMPLETE.

EvanH, FranciscoL

Because we've been loosing lock for unknown reasons, we measured OLG transfer function of MICH, SRLC, and PRLC. The UGF for each one is (see attached figures for reference) roughly

MICH: 10 Hz

SRCL: 12 Hz

PRCL: 35 Hz

We may want to lower the MICH UGF to avoid cross coupling with the SRCL loop.

We tried the in-lock charge measurements but forgot about the New-DARM configuration so caused a lockloss in the SWAP_TO_ITMX state.

Looking at last night lock stretch [1395051437, 1800 seconds]

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

Lot of coherence with CHARD_Y, maybe a consequence of 76541

Lot of coherence with MICH and PRCL. and SRCL. What changed in the feed forward?

At 11:15AM the Juniper SRX was found to have stopped communicating on the 198.129.208.0/24 and 198.129.209/24 GC Compute subnets respectively. This was found to have been configured as residing on LAG ae0 at the router to LAG ae3 on the switch and vlans 3 and 4. All routes were found to have traversed this link in common. Physical reset of interfaces, by physically removing fiber and SFP+ Transceivers from the Juniper SRX-4100 at ports xe-0/0/2 and xe-0/0/3, waited 30 seconds, reseated the transceivers, and reconnected the fiber. Immediate restoration of lost services was observed. There was no observable information in the message logs on the SRX or on the CORE switch to indicate any problem. Interface reset was diagnosed by observable traffic flows. No other information is available. 

Outage secured at 12:30PM 3/21/2024

Onsite internet has been down for about 1.5 hours now and CDS and GC are working on bringing it back

Sheila, Camilla

We started to repeat the ADF scan from 76561 after the IFO had been locked only ~20minutes. Using 'ezcastep H1:SQZ-ADF_OMC_TRANS_PHASE -s '180' '+6,12'', lost lock before the scan finished. Leaving H1:SQZ-ADF_OMC_TRANS_PHASE to 100 so we can do this again once relocked.

Plan to repeat once the IFO is thermalized (~4+ hours). In theory the optimum ADF phase setting shouldn't change, want to confrim this.

[Gabriele, Sheila, Louis]

We changed the OMC lock dither frequency to 4190 Hz. 

As mentioned in LHO:76582, we moved the OMC Lock dither frequency from 4100 Hz to 4101 Hz and saw the 4Hz bump in the OMC lock control loop error signal, H1:OMC-LSC_I_OUT, move to 5Hz as the ramp progressed. 

This confirms that the 4Hz bump was due to mixing between the frequency of the OMC lock dither (nominally, 4100 Hz) and the 4096 Hz. It's not completely clear why 4096 Hz is special now but we note that it's equal to 16384 Hz / 4. This bump wasn't present in O4a so why is here now?

In any case, moving the lock dither frequency up to 4190Hz should take care of this issue. We expect the bump to move up to 94Hz, well above the UGF of the OMC lock loop where it won't dominate the error signal RMS.

[Jennie, Louis, Gabriele]

This morning we carried out some tests to understand if the excess DARM noise could be OMC length noise. We increased the OMC  in-lock residual length RMS (by changing the loop gain and by injecting a 4 Hz line), and changed the OMC lock offset. We expect the coupling from OMC length to DARM to scale linearly with both the RMS and the offset.

More details will follow in comments, but we increased the OMC length RMS by about a factor 10 and saw no visible change in the DARM noise in the bucket. We also added several lock offsets and saw no change in DARM noise in the bucket.

So the DARM excess noise is not OMC length noise.

During the test we injected a 135 Hz OMC length line, and checked that the coupling scales as expecetd with the RMS and the offset.

We lost lock at the end of the ramp when we were changing the OMC length dither frequency from 4100 Hz to 4101 Hz with a 30 second ramp. We saw that the 4 Hz bump in the error signal was moving toward 5 Hz during the ramp: this confirms that the origin of the 4 Hz bump is due to some "beat" between 4100 Hz and 4096 = 16348/4 Hz

In addition to the BSC10 accelerometer, the amount of floor motion also increases over the past 6 weeks, though not in a sudden fashion.

This does not correspond to the time of the most recent fan swap, judging by fan accelerometers.