We're having locking troubles due to Microseism and EQs.

After failing to get past DRMI and experiencing ~10 LLs, we finally did it and got all the way to powering up. Then a 5.6 EQ hit and we lost lock at TRANSITION_ETMX, with clear seismic signs in the few seconds leading up to the Lockloss (similar to the last LL). Lock reacquisition has been as rocky as pre-EQ. Meanwhile, Microseism has continued to increase, with traces now passing the 1 micron threshold, making lock reacquisiton harder yet.

We've just gotten back to PRMI post EQ so hoping this will be a successful reacquisition.

Sheila, Matt, Daniel, Camilla.

We went to the SQZ racks to check the loops, all (LO, OPO, CLF) looked stable, the OPO looked peaky but stable. Once we opened beamdiv and were squeezing there was the large oscillation in ndscopes which SR785 showed to be at 14kHz.

Issues seen:

• Yesterday AM: 82874 and plot attached, issue started when IFO unlocked and Beam divertor closed, continued once IFO re-locked and SQZ injected.
• Today while we were measuring SQZ loops. plot attached, issues worse and OPO_TRANS_POWER bad  when in FDS with beam div open (POISTION = 0) and LO locked,  issues less when beamdiv closed.

We think it could be FSS or PMC or laser going multi mode. Can see EOMRMSMON gets worse when this noise appears. Will continue to investigate tomorrow.

Tagging OpsInfo, if you see this oscillation i.e. SQZ is injected but DARM looks terrible like NO SQZ, try taking SQZ out and in again, if this doesn't help, go to Observing with NO SQZ tonight, using Ryan's wiki Instructions.

Due to so much SQZ strangeness over the weekend, Sheila set the sqzparams.py use_sqz_ang_servo to False and I changed the  SQZ_ANG_ADJUST nominal state to DOWN and reloaded SQZ_MANAGER and SQZ_ANG_ADJUST.

We set the H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG to a normal good value of 190. If the operator thinks the SQZ is bad and wants to change this to maximize the range AFTER we've been locked 2+ hours, they can. Tagging OpsInfo.

TITLE: 02/19 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Maintenance day. Notable tasks from today's maintenance are below. We recently had another lock loss, we have started initial alignment and will start main locking shortly.

• Some squeezer table work
• MC1,MC3, PRM, PR3 camera server change
• Timing card at EY started to show signs of failing in the past few hours. Dave and others are currently investigating this.
• DAQ and NDS1 restart
• Heater element swap, 3A

LOG:

• 2244 Back to low noise, but some squeezer work needs to happen
• 2357 Lock loss                                                                                       

TITLE: 02/19 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: SEISMON_ALERT_USEISM
    Wind: 9mph Gusts, 5mph 3min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.77 μm/s
QUICK SUMMARY:

IFO is in INITIAL_ALIGNMENT and MAINTENANCE

We're still recovering from maintenance today with a few key issues:

• Dave and Marc working on EY CDS Timing, potentially needing us to go down
• SQZ Team says the Squeezer is "as ready to go as it has been all weekend"
• ALS Locking issues still prevalent

Given all that, we shall begin locking when initial alignment is done.

The new clean air supply (compressor, tank, dryer and a series of extra filters), which was received in the end of 2024, was installed in the EX mechanical room as a replacement for the old system. The installation work was carried out in the last few weeks, the last step - the startup by Rogers Machinery - happened today.
This new system has a 69 cfm air delivery operating with 3 pcs. of 7.5 HP motors (in sum 22.5 HP). In comparison, the old system had a 50 cfm air delivery, operating with 5 pcs. of 5 HP motors (in sum 25 HP). Moreover, the new system (unlike the old one) has an automatic dew point monitor, and a complete pair of redundant dryer towers.
So, this new system is a major improvement. The reason for this 69 cfm limit (and not more) is that the cooling of the compressor units in the MER is still feasible, moreover, the filters and the airline do not need any upgrades, they can still accommodate the airflow.
Both the new and old systems are able to produce at least -40 deg F dew point air on paper. During the startup, the new system was however able to produce much better than this - it was ~-70 deg F (and dropping) - as you can see in the attached photo.

Last but not least, a huge congratulations to the Vacuum team for the installation, as this was the first instance, when the installation of a clean air system was carried out by LIGO staff, so this is indeed a huge achievement. Also, big thanks to Chris, who cleaned some parts for the compressor, to Tyler, who helped a lot in the heavy lifting, and to Richard & Ken, who did the electrical wiring.

From next week on, we repeat this same installation at the EY station.

[ Matt, TJ ]

We looked at the transfer functions of the suspensions of the Test Masses, SR3 and PRM (top stage of each), to see if we could see signs of rubbing. This is a limited number of transfer functions; however, it does seem like there is some peak shifting in the ITMY-P.

I swept the LVEA after maintenance activities today. I unplugged one power strip in the CER, and heard a UPS in one of the vacuum racks going off. I silenced the alarm and talked to Gerardo and Richard, but we should keep an ear out.

As per WP 12333 we installed a POE switch (sw-lvea-aux1) in the CER, moved four cameras onto the switch and migrated them to h1digivideo4.  This is to expand and test our infrastructure to host more digital cameras.

Jonathan H. and Austin F. moved the switch from its test location in the MSR to the CER.  As part of the work we moved sw-lvea-aux up 1 space in the rack to make more room and installed a cable management bar beneath the switches to provide some strain relief.

Fil C. setup the DC power for the switch.  We had wanted to also convert sw-lvea-aux to full DC power, but Fil would like us to split the load between the two switches more before removing the 1 AC power supply from sw-lvea-aux.

Patrick worked to migrate the cameras from h1digivideo1 to h1digivideo4.

J. Oberling, R. Short

After the recent PRC alignment work (moving PR3 to better center the beam on PR2) the OpLev beam had fallen off of its QPD, so today I attempted to re-center the QPD.  Using only the translation stages, I could not re-center the QPD since the horizontal translation stage hit its max travel limit well before the beam was back on the QPD (SUM counts went from ~700 to ~850, well short of the usual ~22k).  I enlisted Ryan S. to help and we set out to adjust the OpLev beam alignment from the transmitter.  Turns out that the beam gets clipped before we can get it centered on the QPD.  We first tried to move the translation stage away from its limit but could only get the beam on 2 of the QPD segments (segments 1 and 3) before the SUM counts started dropping; at no point could we get the beam onto QPD segments 2 and 4 in this configuration.  We then moved the horizontal stage to its limit and tried to align the beam onto the QPD; this worked a little better, but still not great.  The best SUM counts we could get and have a "centered" QPD was ~17k, roughly 75% of the total SUM counts for this OpLev, so still some significant clipping.  We decided to unclip the beam to make the OpLev more trustworthy (we've had questions about this OpLev in the past).  Max SUM counts were ~22.7k, and this gives a Yaw reading of roughly -12.5 µrad; any closer to zero and the beam begins to clip again.  We left the OpLev in this configuration and will investigate the clipping at a later date.

Tagging OpsInfo: Around -12.5 µrad is the current "yaw zero" for the PR3 OpLev until we can figure out and alleviate the clipping.

As for the clipping, my best guess at this point is we're clipping somewhere on/in the ~4' long tube that runs from the exit viewport for the OpLev receiver and the OpLev's QPD.  We'll have to climb on top of HAM3 to check this, which we will do at a later date.

This closes WPs 12336 and 12341.

Edit: Fixed typo in yaw reading in bolded sentence (12.7 to 12.5).

Shiela, Camilla, Sheila and Vicky moved the AOM and realigned in 80830.

Summary: Today we measured the powers on SQZT0, see attached photo. Aimed to understand where we were loosing our green light as we had to turn down the OPO setpoint last week 82787. Adjusted SHG EOM, AOM and fiber pointing are dramatically increased available green light. OPO setpoint back to 80uW with plenty of extra green avaible.

After taking the attached power measurements we could see we the SHG conversion was fine, 130mW green out of SHG for 360mW of IR in.

We were loosing a lot of power through the EOM 96mW in to 76mW out (expect ~100%). We could see this clipping in yaw by taking a photo. Sheila adjusted the EOM alignment increasing the power out to 95mW.

Tue Feb 18 10:08:06 2025 INFO: Fill completed in 8min 3secs

Gerardo confirmed a good fill curbside. TCmins [-51C, -48C] OAT (+2C, 36F) DeltaTempTime 10:08:06.

missing data in plot is due to DAQ restart at that time.

I reviewed the weekend lockloss where lock was lost during the calibration sweep on Saturday.

I've compared the calibration injections and what DARM_IN1 is seeing [ndscopes], relative to the last successful injection [ndscopes].
Looks pretty much the same but DARM_IN1 is even a bit lower because I've excluded the last frequency point in the DARM injection which sees the least loop suppression.

It looks like this time the lockloss was a coincidence. BUT. We desperately need to get a successful sweep to update the calibration.
I'll be reverting the cal sweep INI file, in the wiki, to what was used for the last successful injection (even though it includes that last point which I suspected caused the last 2 locklosses), out of abundance of caution and hoping the cause of locklosses is something more subtle that I'm not yet catching.

The operator team have been finding 11Hz oscillation locklosses.  Attached is the spectrum of MICH, PRCL and SRCL from one of our last long (2 day) locks to a more recent 6 hour lock. There is a debatable PRCL bump around 10-11Hz.

BS Camera stopped updating just like in alogs:

• 79685 My alog noting the issue for me back in Aug 2024.
• 79648 Dave's Solution

This takes the Camera Sevo guardian into a neverending loop (and takes ISC LOCK out of Nominal and H1 out of Observe).  See attached screenshot.

So, I had to wake up Dave so he could restart the computer & process for the BS Camera.  (Dave mentioned there is a new computer for this camera to be installed soon and it should help with this problem.)

As soon as Dave got the BS camera back, the CAMERA SERVO node got back to nominal, but I had accepted the SDF diffs for ASC which happened when this issue started, so I had to go back and ACCEPT the correct settings.  Then we automatically went back to Observing.

OK, back to trying to go back to sleep again!  LOL

ALS EY WFS F9's came up as (2) SDFs.  Accepted (see attached).

The last lockloss was most likely due to an EQ (Equador?).  I was already up, so I stayed up to proactively run an alignment and got almost done with SRC OFFLOADED but H1 Manager took ALIGN IFO DOWN (!!!!) and started comepletely over---I guess I shoudl have taken H1 Manager down? 

At any rate, ran a manual alignment for SRC again & H1 made it back up all the way except for the ALSey diffs.  OK, back to bed.

The corner RGA (located on output arm between HAM4 and HAM5) lost connection to the control room computer and stopped collecting data around 6pm yesterday (2/6/25). The software gave an error stating "Driver Error: Run could not be stopped".

I could not ping the unit from the terminal, but Erik confirmed the port is still open on the network switch, so it seems to be an issue with the RGA electronics. Other RGAs connected to this computer can still be accessed.

I restarted the software and attempted to reconnect to the RGA, but no luck. I will have to wait until next Tuesday maintenance to troubleshoot. This unit had been collecting data for the past ~6 months without issue. I will perform a hardware reset at the next opportunity to try and bring the unit back online, otherwise we have a new PrismaPro we can replace this unit with during the next vent.