This is a very quick first look at the ASC performance with the HAM1 ISI. Jim is still working on bringing the ISI up to full performance, but the first attached plot compares the INP1 P and CHARD P error spectra from March 31 just before the vent and yesterday, when we locked to full power and low noise with HAM1 in the isolated state.

Before the vent, we were running feedforward of the HAM1 L4Cs to CHARD, INP1 and PRC2. PRC2 is now on the POP sensor, and CHARD and INP1 both use a combination of the REFL WFS 45 MHz signals. The large peak around 20 Hz before the vent appears to have reduced in INP1 P and shifted down in frequency in CHARD P. The second attachment shows that large peak in CHARD P is coherent with the HAM1 GS13s, from about 10 to 20 Hz, especially with RX, RY, RZ, and Z.

There is also a peak at 6 Hz, which we know is a vertical resonance of the RMs, 84712.

WP12596

Daniel, Vicky, Kevin, EJ, Erik, Dave:

We have installed new h1ioplsc0 (RCG5.1.4) and h1omcpi(RCG5.3.0) models. This led to a small IPC receive error rate on h1omcpi. To correct for this we upgraded h1omc0 from RCG5.3.0 to the latest RCG5.5.0, rebuilding all the models [h1iopomc0, h1omc, h1omcpi] against this RCG. Erik booted h1omc0 from the new boot server h1vmboot5-5 (and removed it from h1vmboot0). We are letting it sit for a while to ensure there are no IPC errors before a DAQ restart.

Fri Jun 06 10:04:56 2025 INFO: Fill completed in 4min 52secs

For FAMIS #26389:  All looks well for the last week for all site HVAC fans (see attached trends).

To investigate the 70Hz feature in HAM1 chamber, which Jim reported in his alog (LHO 84638) I started looking into the structural resonances of the periscope which is installed in HAM1 (see two pictures which TJ sent me, was taken by Corey here - view01, view02) .

Betsy, handed me a periscope (similar but not exactly the same) for investigation purpose, which is now setup in staging building. I attached an accelerometer to the top of the periscope and connected it to the front end of the B&K setup for hammer impact measurements - see picture of the experimental setup here. 

At first I used two dog clamps to secure the periscope. The results of the two dog clamp B&K measurement is shown in this plot (data from 0.125 to 200Hz)) - one can see a 39Hz feature in the Z hit direction. See zoomed-in (30-100Hz) figure here.

Next, I attached a third dog clamp, just like in HAM1 chamber and took a second round of measurements (especially for Z direction impact). 

This plot compares the two vs three dog clamps scenario on the periscope and one can see that the resonance mode has been pushed up from 39Hz to 48Hz. 

FAMIS28948

The quarterly reminder came at a good time for us to restart fresh for observation next week. Reboot went as expected, no hiccups. Reboot started at 1553UTC.

Closes FAMIS26502

2025-06-06 08:41:32.265177
There are 2 STS proof masses out of range ( > 2.0 [V] )!
STS EY DOF X/U = -4.667 [V]
STS EY DOF Z/W = 2.386 [V]

All other proof masses are within range ( < 2.0 [V] ):
STS A DOF X/U = -0.521 [V]
STS A DOF Y/V = -0.607 [V]
STS A DOF Z/W = -0.719 [V]
STS B DOF X/U = 0.2 [V]
STS B DOF Y/V = 0.974 [V]
STS B DOF Z/W = -0.422 [V]
STS C DOF X/U = -0.857 [V]
STS C DOF Y/V = 0.855 [V]
STS C DOF Z/W = 0.629 [V]
STS EX DOF X/U = -0.034 [V]
STS EX DOF Y/V = -0.051 [V]
STS EX DOF Z/W = 0.072 [V]
STS EY DOF Y/V = 1.164 [V]
STS FC DOF X/U = 0.195 [V]

STS FC DOF Y/V = -1.134 [V]
STS FC DOF Z/W = 0.628 [V]

Closes FAMIS26423

Laser Status:
    NPRO output power is 1.85W
    AMP1 output power is 70.39W
    AMP2 output power is 140.3W
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 18 days, 0 hr 26 minutes
    Reflected power = 23.16W
    Transmitted power = 105.5W
    PowerSum = 128.6W

FSS:
    It has been locked for 0 days 1 hr and 12 min
    TPD[V] = 0.801V

ISS:
    The diffracted power is around 3.8%
    Last saturation event was 0 days 13 hours and 21 minutes ago

Possible Issues:
    PMC reflected power is high

Randy, TJ, Fil, Richard, Camilla, WPs: 12593, 12594

After Fil and Richard un-cabled ISCT1, TJ and I added guillotines to HAM1 +Y VPs, removed bellows and attached yellow VP covers. Randy then fork-lifted ISCT1 away from HAM1 and placed it next to IOT2L.

TITLE: 06/06 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 11mph Gusts, 5mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY:

• HAM1 vent pt.2 is starting today, to repair a gasket

TITLE: 06/06 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

The detector is in DOWN for the night and there is a test running right now for Matt for the IMC. The HAM1 cleanroom is on and will be on all night to prep for the +Y door coming off tomorrow morning. Craig and I had turned it on earlier, but then I got worried that it was causing locklosses so I went out and turned it back off, and just now went and turned it back on for the night. It looks like the temperature in that zone (zone 5) was really affected by the cleanroom being turned on (and off) (ndscope1), but the locklosses that we had after it was turned on and back off I don't think should be related to the temperature of the input arm.

After the lockloss earlier in the day during the calibration simulines measurement, we really wanted to get back up and at least check that simulines was running fine and had not caused the lockloss (it didn't look like it did 84836, but still). Unfortunately we weren't able to get back up, as the ifo hasn't really liked me much lately and we had constant locklosses from different places:

• We had a couple locklosses from ENGAGE_ASC_FOR_FULL_IFO, and Elenna figured out it was due to the DC6 centering loops not being able to keep up with the movements. Elenna upped the gain and this looked like it basically? fixed the issue (84843). However, we do get a pretty large glitch in the PR gain during that time, and we did have a lockloss after that in the same spot one other time afterwards.
• Later on, we were getting PRC2 P ringups at 0.28 Hz during MOVE_SPOTS  (ndscope2). The first time it happened we lost lock from it, and the next time it started happening, I lowered the ASC PRC2 P gain from 500 to 400, and that saved us! Later on, Elenna and I were looking at the ISC_LOCK code, and Elenna saw that earlier when she had been uncommenting some other lines for 84843, she had accidently uncommented a line that raised the PRC2 P gain up to 500! She commented it back out and reloaded ISC_LOCK, and we didn't encounter that issue again.
• We also had a lockloss from TRANSITION_FROM_ETMX due to a 1 Hz oscillation in DHARD P and PRC2 P (ndscope3)(84844). Elenna said this was an issue from LOWNOISE_ASC, so I prepped to turn off the DHARD P FM4 and FM8 filters in case we saw the oscillation on the next lock. Additionally, Elenna added 60s timers to multiple chunks of the LOWNOISE_ASC code, to hopefully step everything up nicely and slowly. Unfortunately, on the next lock, we started seeing the oscillation again. I turned off the two DHARD P filters at the same time using the interactive guardian shell, but the oscillation didn't stop. In a futile attempt to save the lock, Elenna and I teamed up to revert the filters and gain for CHARD P at the same time, but alas our noble attempt failed and we lost lock, either from the oscillation, or from trying to save the lock.

LOG:

23:00UTC in NLN_CAL_MEAS
23:14 Started calibration measurement
23:16 Lockloss during calibration measurement, cause unknown
    - Lockloss from ENGAGE_ASC_FOR_FULL_IFO
    - Lockloss from ENGAGE_ASC_FOR_FULL_IFO (from same location)
        - Figured out it was due to the DC6 centering signals not being able to keep up with the movements. Elenna upped the gain for the DC6 loops and this fixed the issue (84843)
    - Lockloss during MOVE_SPOTS due to Craig and me turning on the HAM1 cleanroom
    - Lockloss from MOVE_SPOTS due to a PRC1/2 P ringup at 0.27 Hz
    - Lockloss from ENGAGE_ASC_FOR_FULL_IFO due to 84843
    - I turned the HAM1 cleanroom back off in case it was affecting our ability to lock
    - Lockloss from TRANSITION_FROM_ETMX due to 1 Hz oscillation in DHARD P and PRC2 P from ringup (84844)

I noticed that the LLCV is railing at its top value, 100% open, it can't open no more.  This is a known issue, but it appears as if the valve is reaching 100% sooner than expected, meaning when the tank is almost half full.  First, I'm going to try a re-zero the LLCV actuator and await for the results.  First attachment is a 2 day plot of LLCV railing today and yesterday.  The second plot is a 3 year history looking at the tank level and the LLCV, it rails at 100% a few times.

Oli, Elenna

This is incredibly baffling, but we are still seeing locklosses from lownoise ASC due to a 1 Hz ring up. We have stepped through this state multiple times by hand, and we seem to survive when we do the steps very slowly, with 2-5 minute breaks between each step.

The culprit at times has appeared to be either CHARD P or DHARD P (and maybe also the soft loops?). I have looked at the loop design and measurements of both DHARD P and CHARD P but they show stable loop designs with no gain peaking at 1 Hz. DHARD P has a very large 1 Hz peak in it's error signal spectrum, but I don't know where it comes from.

Tonight, I rewrote the lownoise ASC state to step very slowly through each change and wait 60 seconds after each change, but that did not help. After we left the state and moved into the next, the ring up occurred again and Oli and I tried to save the lock by reverting changes. We're not sure if it was the ring up or our change reversion that broke the lock.

I think this may be an ongoing problem that we didn't realize was a "problem" because the ring up likely occurs during the transition from ETMX state, so we might have classified those locklosses as a problem with the transition, and not a problem with an ASC instability.

Bin Wu, Julia Rice

We have been working on writing a new Guardian script that will allow us to switch off the dither loops sooner in the power up process and instead use cameras.

We first looked at the error signals in the ASC cameras to see if we could adjust offsets to better values. We did this for the CAMERA_SERVO guardian, and added new intermediate states, including TURN_ON_CAMERA_25W_OFFSETS and TURN_ON_CAMERA_MOVESPOTS_FIXED_OFFSETS. We've attached screenshots showing the graph before and after our additional states. Below are the values we used for offsets for each. The weight from DITHER_ON to TURN_ON_CAMERA_25W_OFFSETS is set to be 10.

TURN_ON_CAMERA_25W_OFFSETS

TURN_ON_CAMERA_MOVESPOTS_FIXED_OFFSETS

We also adjusted the offsets for TURN_ON_CAMER_FIXED_OFFSETS:

These are added in lscparams.py. We also added the necessary code into CAMERA_SERVO.py.

We also added a parameter in lscparams.py for new ADS camera CLK_GAIN at 25W  ('ads_camera_gains_25W', screenshot included)

Right now the new states are not requestable, so they will need to be ran manually to test. We haven't made any change to the ICS_LOCK guardian.

I was only able to take the broadband measurement due to an earthquake that knocked us out of lock a minute later. We had been at full power for around 5 hours at the time this measurement was run. Unfortunately since we weren't able to take the Simulines measurements, I am not able to run the report.

Broadband:

Start time: 1433118749 (2025-06-05 00:32:11 UTC)

End time: 1433093874 (2025-06-05 00:37:36 UTC)

Data found in: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250605T003226Z.xml

I haven't had time to post this because of the wind fence work, but I haven't been able to finish the commissioning of the HAM1 ISI because of a 70-ish hz feature in mostly the X and RZ plants. I didn't see or appreciate how large this 70hz feature was in my close out measurements before doors went on, and it's making the loop design very difficult. I was trying to notch the loops to make the ISI work, but 70hz is very close to the nominal 30hz loop ugf. The X,Y,RZ and Z loops are marginally stable right now, and the  70hz feature gets injected into the IMC when ALS is locked. I think that I can get the loops working, but probably with less gain than we would otherwise get.

Attached PDFs are the loops currently installed, the ISI is set to not use the RX and RY loops, but the X loop is probably ringing at 70hz when the ISI is isolated. We are currently running with just the damping loops though.