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.

M. Todd, C. Cahillane

I've scheduled a suite of injection measurements (low-risk, I don't forsee it unlocking the IFO), to start at 10:30 tonight (2025-0603 22:30:00 PDT), as we are interested in figuring out the loop gains for the IMC DOFs Pitch and Yaw.

If it needs to be stopped, you can Ctrl+C my work station or xkill 248480.

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...

I updated the beam mode model prevously generated in alogs 30126-30130 (20160930) and alog 39706 (20171208).
It includes arm optics changes, as well as and output path model based on alog 84089 (20250425). With Kevin's help, I checked it aganst the default FInesse model. The models are reasonably close, although this mo9del does not include a) astigmatism, and b) thick otpics.
The model is available here:

/ligo/home/controls/sballmer/20250603/beamCalc.m

Some conclusions:

- In the cold state the SRC eigenmode has a beam size on the ITM of about 6.3cm (the arm mode is 5.3cm).
- To get to the matched "HOT" state, the ITMs need a 25uD lens.
- To match a thermal lens twice as big (50uD), the SR2-SR3 distance would have to shrink 8mm. None of tf the existing mode actuators can get us there.
- I haven't looked whether the PRC needs a simlar fix. I also didn't check whether out sidebands could accomodate this shift with a simple single-optic move.
 

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=39706

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=30126

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=84089

This study looks at the effects of differential ITM/ETM RoC change, common ITM/ETM RoC change, and differential ITEM lenses change on the DARM sensing function as we track several quantities such as the mismatch between the ARM cavities, ARMs-SRC mismatch, and the beam spot size on TMs. 

FINESSE results suggest that the mismatch between the arms through the ITMs (both RoC and lenses) has the biggest effect on the sensing function. 

In all of these cases, we start with a minimized mismatch between all cavities to less than 0.01% by changing the RoC of several optics until the mismatches are minimized. All mismatches are calculated with the “model.cavity_mismatches_table()” function in FINESSE .

Steps to generate these plots:

1. Changing a parameter (RoC or focal length)
2. Lock the model using DC readout after each change
3. Calculate and plot the sensing function

For the RoC, the 3rd line is always the minimized mismatches case. Maximum mismatch I created was ~0.9% 

Case1: Differential ITMs RoC

Starting with the case of differential ITMs RoC changes by ±2%. ITMX RoC increases while ITMY RoC decreases. The mismatch between the ARMs and the SRC also changes, but that is smaller than the mismatches between the ARMs themselves. 

This has a strong effect on the sensing function shape at low frequencies. It seems that there is a stronger optical spring as the mismatch between the arms increases. The label on the plots show the ITMs RoC in diopters calculated as 2/RoC. 

Changing which RoC increases and which decreases results in the same sensing functions. 

The plot attached shows that result. And a table (attached as .png) shows the mismatches, diopters and more. 

Case2: Differential ITM lenses focal lengths

Similarly, I change ITM lenses' focal lengths. Since, as defined in FINESSE at least, ITMXlens is negative and ITMYlens is positive, a differential change means that ITMXlens diverges the beam stronger every time (becomes less negative. e.g -3*10^5 m instead of -5*10^5) , and ITMYlens converges less, meaning it becomes a bigger positive number. Diopters in this case are calculated as 1/f

This creates a differential mismatch between the ARM cavities. The result is very similar to that of differential ITMs RoC changes. 

The plot and the table attached show the sensing functions. 

Case3: Differential ETM RoC 

This also creates a mismatch between the arms that is bigger between the ARMs and the SRC. This will only affect the carrier’s mode, but not the sidebands, like the ITMs do. 

This case does not have a big effect on the sensing function, as the ITMs (RoC and lenses). The sensing function plot and table are attached.

Case4: Common ITM RoC 

Now, I keep the ARMs mode matched to each other but I mismatch the ARMs to the SRC by changing the ITMs RoC. This has a bigger effect on the DARM sensing function compared to ETMs but smaller than the ITM. Interestingly, this is the only case that shows a pro-spring behavior

The sensing function plot and table are attached. 

 

From this investigation, it seems that the mismatch between the ARM cavities has the biggest effect on the sensing function, rather than the mismatch between the ARM cavities and the SRC. 

Qualitatively, this suggests that the sensing function’s shape is an indicator of how well the arms are mode-matched to each other.

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).