Since we slowly stepped through the LOWNOISE ASC state yesterday, I was able to plot ASDs of the DHARD P error signal and determine what exactly creates the 1 Hz peak. My hypothesis was it was something from the damping loops, but I was wrong! The peak appears after we engage the low bandwidth DHARD P controller. I will take a look at the loop design and adjust to reduce this peak. My guess right now is some gain peaking is present at 1 Hz.

Attachment shows the sepctrum of the error signal during the state. If you are looking at the calibration lines in DHARD P and getting worried- this was before we fixed the A2L gains, and in full lock low noise there are no cal lines present in either DHARD P or Y.

It looks like the ITMX green camera is poorly centered.  We should repoint this soon, as we are using it for green alingment.

Ibrahim, Sheila, Elenna

We were having trouble in the "FIND IR" state, ans Sheila realized that it was due to the guardian thinking the x-arm alignment was poor. However, X arm had locked fine and Ibrahim had run the initial alignment. We asked Ibrahim to run it again, and noticed that it continued to lock the X arm green with a transmission of 0.6 (when it should be like 1). However, the convergence of the WFS and camera signals did not improve the arm alignment.

We saw that the COMM beatnote was also low, so I trended PR3 osems. The OSEMs show a few microradian movement in pitch and no movement in yaw. I tried moving PR3 pitch in the "right" direction according to the osems, but it only made the beatnote worse. Same moving in the opposite direction. Based on the ALS X camera, it looked like the beam was off in yaw, so I instead moved PR3 in yaw, which returned the beatnote to a good place and increased the X arm transmission to >1. So, we are baffled, but we trust our current table alignment so we are going to go with this PR3 placement. Overall, this is a 2 microradian movement in PR3 yaw to regain the beatnote/ALS X transmission.

The y cursor on the top plot shows the pitch position of PR3 two weeks ago when we originally aligned the table. There was not a significant change in PR3 yaw in the osem.

In light of 84770 and 84811, I've taken BR0604 out of the MICH LSC loop.  This filter was added to try to address a line in DARM, but didn't ulitmately help with that line, 78205. 

The filter is costing us 50 degrees of phase at 16.9 Hz, where this loop has been ringing. 

This morning the DRMI problem wasn't happening, it seems to be happening in the evenings lately. 

Thu Jun 05 10:09:05 2025 INFO: Fill completed in 9min 2secs

FAMIS H1 ISI CPS Sensor Noise Spectra Check - Weekly 26045
This CPS noise check doesn't include HAM1 yet.

 

TITLE: 06/05 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 11mph Gusts, 6mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.13 μm/s
QUICK SUMMARY:

IFO is in DOWN and PLANNED ENGINEERING

This morning we have vacuum going into the LVEA to find out which annulus on the HAM1 doors is leaking (WP 12591). TJ is transitioning LVEA to laser safe for this (WP 12590). Commissioning will then resume.

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

Just put the IFO in DOWN for the night after losing lock from ENGAGE_ASC_FOR_FULL_IFO. I was having trouble all evening getting DRMI to stay locked - we kept losing lock from the 16.2 Hz oscillation that Craig and Elenna had found yesterday (84769). I have no idea why it's only been appearing in the evenings - yesterday evening we had these issues, then this morning no issues at all, and then this evening issues again!! I would lose lock from it anytime after ENGAGE_DRMI_ASC, but even just in DRMI_LOCKED_PREP_ASC, the oscillation was there, just not ringing up.

One of the times I was able to get DRMI to lock, I stayed in DRMI_LOCKED_PREP_ASC and took MICH, PRCL, and SRCL OLG measurements. Later on, Sheila called and figured out it must be due to the MICH gain being too high, so I lowered MICH2 gain, originally at 1, by 30% to 0.7. After doing that, the 16 Hz oscillation went away (diaggui) and we were able to get through DRMI. Sheila said we probably needed that gain back to 1 for DRMI_TO_POP, so I paused at RESONANCE, reset the MICH2 gain to 1, and then continued. We lost lock during ENGAGE_ASC_FOR_FULL_IFO.

So the MICH2 gain is currently at its original gain of 1.

Evening task progress for today:

• SRCL offset check FDS + range DONE
• Try new LSC FF DONE 84807
• Run CAL sweep PARTIALLY DONE 84808
• Close ISS 2nd loop
• Try LASER_NOISE_SUPPRESSION
• OMC alignment offsets
• IMC injection (overnight) IN PROG RUNNING SOOOOON

LOG:

23:30 Sitting in NOMINAL_LOW_NOISE while tests are being run
00:32 Started BB calibration measurement
00:37 BB measurement done
00:38 Lockloss due to earthquake
    - started a manual initial alignment
        - tried to leave SCAN_ALIGNMENT for UNLOCKED and got a Guardian node error about the time being in the past - had to manual before reloading to get out of it (txt)
    - After the initial alignment was done, I relocked SRY and left it there for a while while Vicky and Kevin worked on SQZ stuff
    02:24 Lockloss from ENGAGE_DRMI_ASC due to the 16.2 Hz oscillation (84769)
    02:37 Lockloss from TURN_ON_BS_STAGE2 due to the 16.2 Hz oscillation
        - I paused in DRMI_LOCKED_PREP_ASC and adjusted SRM to make POP look better, then went into ENGAGED_DRMI_ASC. We had an oscillatoni start, but we were able to survive it. Then I went into TURN_ON_BS_STAGE2 and we immediately lost lock
    03:24 Lockloss from ACQUIRE_DRMI_1F while trying to acquire. We had gotten it earlier and I stayed in DRMI_LOCKED_PREP_ASC and took MICH, PRCL, and SRCL OLG measurements, but we lost DRMI when I aborted the SRCL measurement and we weren't able to grab it again
    03:40 Lockloss from ACQUIRE_DRMI_1F
    - Ran another initial alignment
    04:20 Lockloss from TURN_ON_BS_STAGE2 due to the 16.2 Hz oscillation
    04:31 Lockloss from ENGAGE_DRMI_ASC due to the 16.2 Hz oscillation
    - Sheila called, I lowered MICH2 gain (originally at 1) by 30% to 0.7, then the 16 Hz oscillation went away and we were able to get through DRMI
    - Paused at RESONANCE, reset the MICH2 gain to 1, and then continued
    04:58 Lockloss from ENGAGE_ASC_FOR_FULL_IFO

After losing lock earlier due to an earthquake, we went through an initial alignment. After that had finished, I put the ifo back into SRY so that they could calibrate the ADF. They finished that a bit ago, and after touching up SRC1 and rerunning the SRC alignment, we are now starting to relock.

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

M. Todd, C. Cahillane, G. Mansell

We're curious if any of the IMC WFS channels (DC and RF) are seeing some of the peaks we witness in DARM. Most of the sensors seem dominated by phase noise due to being in air; IMC-TRANS seems the best witness. Not sure if there is anything meaningfull from these, indicating coherence with the DARM peaks.

List of Figures: references are from March 12th, 2025 -- lives are from June 4th, 2025

1. IMC REFL and TRANS PSD estimate comparison before (March 12, 2025) and after vent (June 4, 2025)
2. IMC WFS A/B DC/RF-I PITCH
3. IMC WFS A/B DC/RF-I YAW

The template to measure these again is found at /ligo/home/matthewrichard.todd/Templates/imc/imc_wfs_comparison.xml

I ran an iterative tuning of the LSC feedforward today. The feedforward was already decent, but there was some room for improvement. The two attached screenshots compare injections from the new feedforward fit and the old fit. The only place to pay attention to moving forward is the high frequency coupling of SRCL, which may be effected by the large SRCL offset measured (and potentially corrected) today. If we see any >100 Hz noise coupling from the LSC, maybe we can do another iterative fit. I also injected in PRCL and the noise coupling has not changed, so the previous feedforward is just fine.

The new filters are in FM7 for both MICHFF and SRCLFF, and I updated the guardian.

TITLE: 06/04 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Oli
SHIFT SUMMARY:

IFO is in NLN_CAL_MEAS and PLANNED ENGINEERING

Extremely productive day in which we got to Nominal Low Noise for the first time in two months!

Very briefly, here's what we did today:

• Discovered that the HAM1 ISI watchdog was tripped for 1 full day, contributing to DRMI instabilities in the last EVE
• Violins are looking okay and being actively damped by OPS and Fellows
• REFL rephasing was done to max SNR from Q into I.
• ADS optimized via A2L
• HAM1 Leak checks are ongoiong because it has been determined that the annulus gap between HAM1 door is probably leaking. Tomorrow, vacuum will go into the LVEA and find out which door it is (if possible).
• DC Centering issues fixed
• SQZ being worked on

Relevant alogs:

alog 84800: low range coherence checks

alog 84798: a2l optimized pre-NLN

alog 84796: IM4 and MC2 TRANS

There are undoubtedly more in-progress alogs about work done today.

LOG:

Looking at IM4 and MC2 trans, we see that the amount of power on MC2_TRANS and IM4_TRANS has decreased by around 1%.
The plot shows a time in March 12, 2025, with white dashed lines where those values are now on June 04, 2025.
The IM4_TRANS calibration was fixed after the HAM1 work in alog 82260.

The PRG is around 3% higher now, going from 52.2 to 53.9.
The PRG calculation already incorporates this apparent 1% fall in IM4_TRANS.
Matt Todd checked the PRG at 2W in alog 84668.

As far as alignment, MC2_TRANS is servoed to zero by the input PZT using IMC ASC DOF3, so that is "unchanged".
IM4_TRANS has drifted only a small amount, from 0.1 to 0.2 in PITCH, and -0.04 to -0.10 in YAW.

This is all loosely consistent with the small changes in input pointing we've seen in the ISS array pointing seen in alog 84728.
Keita noticed that the SEG3 on the ISS QPD is totally saturated at -32768 cts due to the misalignment onto that PD, so it becomes even harder to trust the ISS QPD reference.

We have not yet closed the ISS secondloop as a part of the locking sequence, so we don't know if the beam jitter coupling to DARM problem will get worse when we close this loop.
I reckon there is a very high likelihood that it will.

Keita had more suggestions, including
1) injecting into the IMC and checking coherence between IMC WFS and the ISS array and DARM (Mr. Todd has already started this analysis alog 84775).
2) moving the input pointing into the array in PITCH and YAW and checking the PHASE between each individual array diode, maybe via line injection, to see if there is any cancellation happening, or if some diodes are more susceptible to misalignments
3) far future: change around plugs for INNER and OUTER so that the INNER diodes are the most stable, best-aligned ones.  This could improve our overall beam jitter coupling, if we think it's coupling via the intensity loop.

Oli, Georgia, Elenna

While we were taking care of several LSC items, Georgia pointed out that we are seeing the 0.8 Hz buzzing in INP1 yaw again, and to a lesser degree CHARD Y. While we did several useless things to debug, I noticed that the DC centering loops were also buzzing with the same frequency oscillation. I decided to try changing the DC centering loop gain (since I had raised the loop gain significantly last week), and noticed that NONE of the DC6 pitch or yaw filters were engaged, but a gain of 1 was engaged, essentially feeding the input signal right back to PM1. Bad!!

Searchingh DC6 in the guardian shows that in PREP_ASC_FOR_FULL_IFO, I found these lines of code:

Not good! Since the gain of DC6 is set on, this effectively keeps the gain on but turns off all the filters and just feeds back the pure error signal to the suspension.

I commented those lines out of the guardian and loaded, and then reengaged all the proper filters. A large 28 Hz line that had been present in DARM disappeared at this point, likely because the DC centering loops require a 28 Hz notch to avoid some suspension mode.

After this, I then tried turning down the DC1 and DC2 pitch and yaw gains to -1. This seemed to help the buzzing in CHARD and INP1. Georgia and I were able to engage all the low noise ASC settings without any issues (CHARD P had been held in high bandwidth to avoid a ring up and the soft loops had high gain for the same reason).

We need to monitor for a while longer and also try relocking, but these changes may fix many of our ASC issues.

I have SDFed these gain changes.