TITLE: 06/14 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Aquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY: A quaternary of issues, environmental (wind and an earthquake), hardware, and software it seems. The new DAMP_BOUNCE_ROLL seems to be killing it everytime it engages so I've commented it out.
LOG:                                       

• 23:44 UTC After the IA DRMI locked with a very nice looking spot after struggling earlier despite good flashes.
• 00:00 UTC I noticed that the OMC was having trouble locking, it wasn't able to get any data/find any peaks. I reached out to Keita and I tried to manually lock it following Camilla's instructions in alog67897 but I wasn't able to see any peaks stepping through the offset. It looks like the PZT voltage wasn't actually changing to actuate it. Keita went to the mezzanine and the voltage was zero, I set the offset to zero and he reset it which brought the DC voltage back and I was able to relock it with the guardian. alog85030
• 00:57 UTC right after we were able to lock the OMC we unfortunately lost lock at POWER_10Ws
  • The wind started to pick up
  • 01:47 UTC, we lost lock a few seconds into the state for the 2nd time in a row. Both LLs tagged WINDY, and ADS_EXCURSION, 1st LL, 2nd LL
  • 02:50 UTC lockloss at DAMP_BOUNCE_ROLL after I slowly stepped through states starting at PREP_ASC, during TMS_SERVO I got "POP X PZT Railed" notifications
    • The comment above this notification in ISC_LOCK says it may be due to PR3 pointing, so I compared its alignment to when we locked earlier using top mass inmons and I adjusted PR3 and PR2
    • In DRMI I had no flashes and AS AIR looked yawed, so I moved PR2 back in yaw like halfway back to where it was and flashes came back and it locked
    • We lost it at DAMP_BOUNCE again, I don't think its an alignment issue anymore, I reverted the PR2 & 3 moves
  • 03:40 UTC I reduced the gain on the DAMP_BOUNCE_ROLL filter from 40 to 30 and doubled the tramp to 10 seconds
  • 03:52 UTC Earthquake mode
  • 04:35, even with the reduced gain and increased tramp we still lost lock right as it engaged, I've commented it out of ISC_LOCK - line 3937

Ryan had a hard time locking the OMC, and there was no DCPD_SUM spikes as Ryan moved the PZT offset manually. We saw nothing in the OMC trans camera either.

I found that the OMC PZT2 monitor dropped to zero-ish at 14:23 PDT (21:23 UTC). That coincides with vacuum-related activity for HAM1, not sure if they are related.

In the mezzanine I found that the output of the HV driver was zero.

Pressing VSET and ISET, I saw that the driver was set up to 110V 80mA. Pressing RECALL -> ENTER didn't do anything. I also noticed at this point that the unit was somehow in CC (constant current ) mode, which is usually automatically determined by the power supply. It should be in CV mode.

I turned the output off, asked Ryan to turn the PZT offset to zero (which means the middle of 0-100V range, i.e. 50V, so I should have asked -50V offset), power cycled the unit just because, pressed VSET again (it was still 110V), pressed ENTER, turned the output ON, and it started working again.

Ryan moved the PZT offset and the HV monitor responded. Shortly after this the IFO lost lock but I don't think that was related to the HV.

Jordan, Janos

Today, at ~14 pm after a lockloss, we valved out the annulus Pfeiffer aux carts. We let them run until both the AIPs turned over. This happened first with the HAM1 AIP (Noble diode), which despite the higher gas load, turned over earlier. At ~16:30 pm the HAM2 AIP also turned over (Starcell), so at ~16:45 I stopped the Pfeiffer-carts, with this, eliminating the 2 biggest noise-sources.

Also, today at ~14 pm we valved in the main IP (IP13), that brought down the pressure to ~5.3E-7 Torr, and it stabilizes at ~5.8E-7 Torr.
The main turbo's backing cart is still on (standing on vibration dumping pads); we are planning to valve out the turbo early next week.

TITLE: 06/13 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Somewhat uneventful day with just one lockloss that we're still trying to come back up from. H1 is relocking and currently up to LOCKING_ALS.

• 14:30 - Running auto initial alignment
• 14:45 - IA finished, starting lock acquisition
• 15:52 - Observing
• 16:27 - Dropped observing for SQZ fixes and ETMY roll mode damping
• 16:39 - Observing
• ~19:00 - Rode through M6.1 EQ from Japan
• 21:11 - Lockloss (alog85023)
• 21:32 - Starting lock acquisition after VAC team addresses pumps at HAM1
• 22:51 - Haven't been able to lock DRMI, cutting losses and starting initial alignment
• 23:07 - IA finished, starting lock acquisition

LOG:

Kiet and Sheila,

Following up on the investigation posted in aLOG 84136, we examined the impact of higher-order violin mode harmonics on the contamination region.

We found that subtracting the violin peaks near 1000 Hz (1st harmonic) from those near 1500 Hz (2nd harmonic) results in frequency differences that align with many of the narrow lines observed in the contamination region around 500 Hz.

Violin peaks that we used (using O4a+b run average spectra)

F_n1 = {1008.69472,1008.81764, 1007.99944,1005.10319,1005.40083} Hz 
F_n2 = {1472.77958,1466.18903,1465.59417,1468.58861, 1465.02333, 1486.36153, 1485.76708} Hz 

Out of the 35 possible difference pairs (one from each set), 27 matched known lines in the contamination region to within 1/1800 Hz (~0.56 mHz)—most within 0.1 mHz. Considering that each region actually contains >30 peaks, the number of matching pairs likely increases significantly, helping explain the dense forest of lines in the comtaimination region.

Next steps:

• Testing all the peaks in the 1st and 2nd harmonic region.
• We propose to identify lines with highest power in the contamination region, trace them back their source modes and discuss the feasibility of target damping them. 

The Fscan run average data are available here (interactive plots): 

Fundamental region (500 Hz): 

• 400–500 Hz
• 500–600 Hz

1st harmonic region (1000 Hz): 

• 900–1000 Hz
• 1000–1100 Hz

2nd harmonic region (1500 Hz): 

• 1400–1500 Hz
• 1500–1600 Hz

TITLE: 06/13 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 17mph Gusts, 11mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

• 21:11 UTC lockloss, I ran a coherence measurement at ~5 hours in
• Windy.com forecasts the wind picking up around 04:00 - 05:00 UTC tonight
• We're currently running an IA as DRMI/PRMI has been having trouble locking

TCS Chiller Water Level Top-Off - BiWeekly FAMIS 27817

TSCY: Found at 10.4 and added 0
TSCX found at 30.3 and added 50mL
Everything looks like its functioning well.
 

Lockloss @ 21:11 UTC - link to lockloss tool

No obvious cause, but looks to have been sudden. We're taking advantage of the downtime to have the VAC team address pumps on HAM1.

Yesterday we ran a bruco on Francisco's post-vent SQZ time from 84996. Link to bruco here.

Command used: python -m bruco --ifo=H1 --channel=GDS-CALIB_STRAIN_CLEAN --gpsb=1433758866 --length=600 --outfs=4096 --fres=0.1 --dir=/home/camilla.compton/public_html/brucos/1433758866 --top=100 --webtop=20 --plot=html --nproc=20 --xlim=7:2000 --excluded=/home/elenna.capote/bruco-excluded/lho_DARM_excluded.txt

Links to to a few coherences, although I haven't done a deep dive: SRCL (some 100-250Hz), PRCL, MICH (bad 2-4Hz), PSL ISS 2nd loop, can see the jitter peaks in IMC WFS 

Closes FAMIS26392

For the CS fans, they look fine althought MR_FAN5_170_2 is a bit noisy.

For the OUT building fans, there's a periodic noise increase on a few different fans. EY_FAN2_470_2, EX_FAN1_570_{1,2} and MX_FAN2_370_1.

Summary of (our knowledge about) 2nd loop array units are available on DCC: https://dcc.ligo.org/LIGO-D1101059

We opened the container of S1202966 in the optics lab for inspection. This is a unit removed from LHAM2 in 2016.

We found no damage (1st picture), all photodiodes and the QPD look OK, no chipping of the optics, but many components are missing.

• Missing upgrade components to lift QPD higher to make it closer to the optical plane of the array photodiodes. We'll search for spares.
  • D1300718. This is a kit comprising two 4.501" poles with cutout, one 6.511" pole and two thinner 3" poles.
  • D1300719. This is called QPD MT PLATE, it's a top platform to mount the QPD as well as the ISS array cover assembly.
  • Related hardware.
• Missing upgrade components to tilt QPD. We have spare parts.
  • D1400146 Beveled C-bore Washer to tilt the QPD assy by 1.41deg to avoid direct reflection back. We have spares we can use.
  • D1300963-V2 updated QPD clamp plate to accomodate 1.41deg tilt. V1 doesn't work. We have spares we can use.
•  Missing extended ISS array cover/lid assembly parts (ECR https://dcc.ligo.org/LIGO-E1300662). We will search for spares.
  • D1300717 Array Cover (Extended). Unlike the name would make you believe, this is not the cover assembly, but is a kit comprising one each of 5 different panels i.e. D1300717-101, D1300717-102, D1300717-103, D1300717-104 and D1300717-105. 
    • At least 5 kits have been made according to ICS. We know of four kits used for existing arrays, i.e. two in the existing IFOs (one each at LHO and LLO), one in the optics lab for S1202965, and the last one for S1202967 that was bent and contaminated. Assuming that the 3IFO unit (S1202968) has the cover, we might not have a spare.
    • But the same ICS record also shows 5 pieces of mysterious (to me) D1300717-00, four of which are supposed to be at LHO. If D1300717-00 means the entire kit comprising 5 panels, we might have spares.
  • D1300890 Array Cover Corner Support. This is a kit of 3 different corner braces, i.e. 1 piece of D1300890-1, 2 pieces of -2 and 1 piece of -1. 
    • According to ICS we seem to have produced 9 kits. Like D1300717, we know four kits used for existing assemblies (H1, L1, S1202965, S1202967), and I assume that the 3IFO unit (S1202968) has one. So we should have four spares somewhere.

I decided to disassemble the damaged/contaminated S1202967 partially to send some of the parts to C&B and keep them as the last-resort spares. Jennie sent the following parts to C&B. There are deep scuffs which should be the result of repeated metal-to-metal contact/scratching, but they should be OK for use once they go through C&B.

• D1300718. A kit comprising two 4.501" poles with cutout, one 6.511" pole and two thinner 3" poles.
• D1300719. Top platform to mount the QPD as well as the ISS array cover assembly.
• Related hardware.

ISS array cover might be salvageable but the place where the poles are attached is bent so badly, bending it back might break it. See the 2nd picture, the surface is supposed to be flat.

Since we've been seeing the ETMY roll mode consistently ringing up over the start of lock stretches and that it can cause locklosses after long enough, Sheila modified the 'DAMP_BOUNCE' [502] state of ISC_LOCK to now engage damping of this mode with a gain of 40. The state has also been renamed to 'DAMP_BOUNCE_ROLL'. I have accepted the gain of 40 and timeramp of 5 sec in the OBSERVE.snap table of h1susetmy and only the timeramp in the SAFE.snap table (screenshots attached; we had originally set the gain at 30 but then updated it to 40, which I forgot to take a screenshot of).

We are still unsure as to why this roll mode has been ringing up since the vent, but so far Elenna has ruled out the SRCL feedforward and theorizes it could be from ASC, specifically CHARD_P (see alog84982 and comments).

Fri Jun 13 10:07:30 2025 INFO: Fill completed in 7min 27secs

Jordan confirmed a good fill curbside.

The squeezer ASC was misaligning the squeezer early in the lock as it has been doing this week. 

Ryan took us out of observing to deal with this and the roll mode. I went to no squeezing and reset the AS42 offsets for no squeezing, a little more than 1 hour after power up.  These offsets have changed with thermalization in the past. 

I reset the sqz ASC using the "graceful clear history".  Once the squeezing was injected the RF3 level was too low to lock, so I adjusted ZM6 manually. I could perhaps have done this (without reseting the offsets) by asking SQZ_MANAGER to RESET_SQZ_ASC, as Oli and Camilla suggested last night.

I accepted the offsets in the observe.snap, but forgot about the safe.snap.  Ryan verified that SQZASC is not included in SDF revert, so this will be fine for the weekend, but we should accept these in safe.snap sometime soon.

If we have another lock today we can see if reseting the offsets has helped with the asc issue during thermalization.  If we do not, we can set the flag to not run sqz ASC over the weekend.