M. Todd, C. Cahillane

We are looking at the RIN in LSC-REFL_A to try and understand if there are some cavity dynamics that can give an estimate of the power recycling cavity mode-matching to the arms (for some more background, see Daniel's alog 70985)

I've made a plot that shows some interesting changes in the REFL_RIN asd as a function of thermal state. In particular I've looked at the asd at 4 different times as we thermalize after locking and stabilize the ISS.

There's some very interesting dynamics around 5-50 Hz. For the HF dynamics, I've also plotted the shot-noise limit based on that time's DC REFL_A_LF power; which I think is the limit in that frequency regime.

I've put both the dtt plot as well as my own plot that used quick_psd.

Next, I would like to model what RIN we would expect in that frequency band and compare to these measurements, specifically if this is intensity noise coupling changes due to mode mismatch changes during thermalization.

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.

WP12583

At 15:54 Tue 03jun2025 PDT the EX HWWD showed activity. This was repeated later in the day between 18:40 - 19:10. This could mean I don't need to go to EX to perform a cable-out test.

Attached 10 week trend shows when the various HWWDs went quiet and later resumed activity.

TJ, Dave:

The ADJUST_POWER state of the ISC_LOCK guardian node has been exercised recently during locking, with the unexpected consequence of various CDS system mis-interpreting this as entering/leaving nominal-low-noise. This is because this state's number is 1000, greater than NLN=600. For example, attachment shows CDS overview screen mistakingly showing models' SDF diffs in RED. Yesterday TJ reduced this state's number to 521, a number which wasn't available when this state was first created but has since become available (graph snippet shown).

Wed Jun 04 10:10:09 2025 INFO: Fill completed in 10min 5secs

Gerardo confirmed a good fill curbside.

TITLE: 06/04 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.15 μm/s
QUICK SUMMARY:

IFO is in DOWN and PLANNED ENGINEERING

Plan today is to continue lock acquisition. Might attempt an initial alignment whilst the comissioners arrive.

TITLE: 06/04 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 detector in DOWN for the night (and for Matt's IM test tonight). Elenna and I have been unable to fully lock DRMI for the past hour:

• one (1) lockloss during ACQUIRE_DRMI_1F while we were trying to figure out why we couldn't continue, and eventually realized it was due to unset limiters for DC6 (84782)
• two (2) of the locklosses were from ENGAGE_DRMI_ASC and ACQUIRE_DRMI_1F, where a fast oscillation took us out (16.2Hz in MICH, 30Hz in POP) (seen earlier 84769)
• two (2) locklosses after that were from ACQUIRE_DRMI_1F and were for seemingly no reason - we were not seeing any BS oplev glitches, but something did seem to be kicking the BS every so often while trying to acquire. The oplevs weren't seeing any kicking in the states before ACQUIRE_DRMI_1F

State of today's tasks (posted in my shift start alog, here are their updates):

• Check PRM offset in DRMI ASC DONE
• Craig & Matt rephase LSC POP in lownoise DONE 84776
• Craig & Matt check PRCL/SRCL sensing/inputmatrix DONE 84776
• Elenna measure LSC FF IN PROG
• Vicky & Kevin sqz measurement of SRCL offset do Wed morning after FF fixed
• Check laser noise suppression state no good, check REFL B
• Vicky & Kevin other sqz stuff (in parallel w/LSC stuff)
• CHARD P low noise DONE
• * Matt overnight IMC measurement IN PROG
• ISS realignment onto array
• * Check CHARD Y now that DC centering is fixed

LOG:

22:55UTC Lockloss from LOWNOISE_LENGTH_CONTROL due to commissioner error
23:30 Lockloss from ENGAGE_DRMMI_ASC
02:37 Lockloss during LASER_NOISE_SUPPRESSION
    - ran a manual initial alignment
03:48 Lockloss from ACQUIRE_DRMI_1F due to the limit for DC6 being set to 0 and ISC_DRMI thinking that DC6 was railed (84782)
03:52 Lockloss from FIND_IR
04:00 Lockloss from ENGAGE_DRMI_ASC due to fast oscillation (same as 84769)
04:21 Lockloss from ACQUIRE_DRMI_1F due to fast oscillation (same as 84769)
04:36 Lockloss from ACQUIRE_DRMI_1F
04:43 Lockloss from ACQUIRE_DRMI_1F

Oli, Elenna

Oli and I were just baffled as we were stuck in the DRMI acquisition with ISC_DRMI throwing a warning that "WFS DC centering railed", but of course, nothing looked railed at all. We eventually lost lock just sitting there.

I found that ISC_DRMI runs:

Kevin, Vicky

FDS basically recovered on its own with just selected "FREQ_DEP_SQZ", all we had to really do was align FC1/2 to get the filter cavity IR lock to work. Squeezer ASCs could basically walk alignment back on its own, last screenshot.

We manually turned SQZ IFO AS42 ASC on and stepped up the gain to converge it, adjusted squeezing angle, and FIS realigned itself. We then went to NO SQUEEZING and reset the AS42 "no sqz" offsets; see the offset script and accepted in SDF. For FDS, we had to manually align the filter cavity in order to transition to the IR lock because the FC REFL beam had kinda fallen off the FC WFS, so the handoff wasn't working at first. We realigned with the filter cavity locked in green, and walking FC1/2 (mostly in pitch) to maximize the FC green trans signal. This also walked the beam back onto the FC REFL WFS. Then we brought it back to FDS and manually turned on SQZ ASC gain, then turned on the FC ASC gain, and it all "just worked" getting up to about 4.5 dB.

Resolved our SDFs, and we turned the SQZ + FC ASC flags back to "True" in the guardian. Other settings were left as they were after O4b: FC beam spot control False, OPO_TRANS 95uW, and SQZ ANGLE ADF servo False/DOWN.

Note: running SQZ ASC means the homodyne now needs to be re-aligned, or else we need to set the optics (FC1 + ZMs) back to the homodyne settings (could use the "SET ZM HD" button if/after we offload asc to sliders).

Oli, Elenna

We tried running Laser Noise Suppression, with the risk being that REFL B settings may not be right for the CARM control. Indeed, Oli and I watched the guardian log and it appears that the lockloss was exactly concurrent with the ramping on of REFL B as a second CARM sensor.

Georgia has previously checked the phasing, so I am not certain what the issue could be. If we get a chance to go through this state again tonight, I'll try stepping through everything but the CARM sensor change to confirm that is the issue.

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.

I initially tried rephasing POP 9 by hand, but moving the POP A phase by 5 degrees while we're locked using it was way too much and immediately caused a lockloss.
The next lock, we found Gabriele's old LSC sensing matrix measuring software in 
/ligo/gitcommon/labutils/lsc_sensing_matrix/lsc_sensing_matrix.py
It works great still.
The 250 Hz line is injected using awg, and the FM5 EBS250 notch filters are still in the right location. 
The excitation amplitudes were 10x too strong, so we lowered them and it stopped the saturations.

The resulting phases found initially are posted as the first PDF.
We were pretty far off in POP 9, by 20 degrees, and by -11 degrees in POP 45.

To rephase, I wrote the script to rotate the phase of POP very slowly while in lock:

step_size = 11
steps = 100000
total_time = 110
init_value = ezca["LSC-POP_A_RF45_PHASE_R"]
for ii in range(1,steps):
    small_step_size = step_size * ii / steps
    small_time = total_time / steps
    print(f"{ii}: {small_step_size}")
    time.sleep(small_time)
    ezca["LSC-POP_A_RF45_PHASE_R"] = init_value + small_step_size

This one worked, with only very small glitches visible in DARM.
PDF 2 shows the resulting fixed LSC matrix measurement, at 60 W input power.

Next, we adjusted the LSC sensing matrix according to Jenne's old instructions: alog 68547.
We turned on SRCL2 and MICH2 FM5 EBS250 notch filters, and started a 250 Hz line in PRCL again.

We then plotted SRCL1 and PRCL1 error signals while adjusting the POP 9 I -> SRCL intrix value by 0.005 steps, looking to minimize the appearance of the 250 Hz PRCL line sensed in SRCL.
We didn't move LSC-PD_DOF_MTRX_SETTING_5_1 much: only by 0.02 from 0.10408 to 0.085, but got significant improvement, maybe a factor of 3 better.
Makes some sense we'd have to adjust this after rephasing the POP diodes.
The resulting LSC sensing matrix is posted as the PNG.

ISC_LOCK LOWNOISE_ASC

• ADS clock gains were set to 30, we raised this to 300
• ADS loop gains were increased to 10 but now we leave them at 1
• Some consolidation of switching on filters one-by-one vs in one line
• Removed some ancient TRAMP setting of ASC_AS_A

ISC_DRMI

• We've been manualling over PRMI ASC since there was a convergence checker on PRC1, Ryan, Oli and I added a use_DRMI_ASC and use_PRMI_ASC dictionary to lscparams, replacing the self.usePRC1 flags that were set in individual states of ISC_DRMI. If we did this right, it will only wait for convergence of loops that are engaged :)

CAMERA_SERVO

• We've been switching on the camera servos on earlier using the camera_servo guardian. It has a few points where it checks the ISC_LOCK guardian state. I lowered the number to trick it into letting me turn it on earlier...

Elenna, Georgia, Craig, Stefan, Oli

We saw a very strange oscillation that appears to be beamsplitter related during the engagement of DRMI ASC. I tried turning down various DRMI ASC gains: SRC1, SRC2, MICH P, and it made no difference. We were getting BS saturation warnings. Finally, I just moved from"engage drmi asc" to "turn on BS stage 2" and the oscillations appeared to reduced. We saw large peaks with harmonics in the corner LSC signals starting near 18 Hz. We are wondering if it's an errant beamsplitter bounce mode?

Daniel, Kevin, (Erik, Dave), Vicky

Kevin is interested in taking ADF sweeps around the second higher order mode arm resonance near 10.4 kHz.

We (Daniel) made model changes in h1ioplsc0 and h1omcpi that should enable higher freq ADF demods. Daniel built the models successfully. Then Dave also built these models successfully for the custom RCG running on h1omcpi for the variable duotone. We put in a WP to boot in these changes to h1ioplsc0 and h1omcpi next Tuesday 6/10.

From h1ioplsc0, we added 2 new PCIe channels to write the digital ADF LO oscillator out to PCIe. These are H1:IOP-PCI_ADF_VCXO_{COS,SIN} in screenshot 1. We also changed a rogue limiter such that the ADF should be able to scan +/-1 MHz according to the PLL.

In h1omcpi, we use the fast 64 kHz OMC PI user model to do a fast digital demodulation of the OMC_DCPD_SUM signal using the above ADF-LO PCIe channels. This is beating the fast dcpd output signal (H1:OMC-PI_DCPD_64KHZ_AHF), against the ADF LO's cosine and sine components from PCIe (H1:IOP-PCI_ADF_VCXO_{COS,SIN}), to get the demodulated ADF I/Q signals. The demod signals will have names like H1:OMC-PI_ADF_DEMOD_{I,Q}. Screenshots 2-4.

Operationally nothing should change for the ADF or for OMC-based fast PI damping. We are just using PCI to send 2 IPC channels from an IOP model to a user model on a different computer at ~65kHz, and doing the demod in a 64kHz user model (but the demod does not go anywhere, it is just used for squeezer diagnostics).