H1 called for assistance at 07:13 UTC when ISIs tripped for every QUAD, BS, and HAM8 due to a M7.7 earthquake and M6.4 aftershock out of Myanmar. Lockloss happened earlier at 06:33 UTC because of the S-waves of this quake, I'm assuming. At the worst of the shaking, peakmon was at the highest I can recall seeing it at over 128,000 counts.

H1 will be down for a while. I'll check in after a bit and untrip platforms if the shaking has calmed enough and start locking.

Follow up to LHO alog 83200 and LHO alog 80863.

Brian and I thought of a better way of getting the M1 OSEMs in PR3 calibrated relative to the HAM2 GS13s: Use the ISI drives in L, T, V for frequencies above the suspension resonances to get an absolute calibration.

We can use the measurements Jeff took in LHO alog 80863 and project them in the OSEM basis, then use the translational (Longitudinal, Transverse, Vertical) drives to calibrate the OSEMs. Since the GS13s are calibrated to [m] all of the transfer functions (shown in the first attachment) are in [OSEM meters]/[GS13 meters]. At high frequencies (sufficiently above the resonances) the OSEMs should just be measuring (-1)*ISI motion, because the suspension is isolated. The calibration error will depend on how well we are able to drive L,T,V from the ISI without cross-coupling to any other DOF.

Figure 1 attached shows the 6x6 transfer matrix between the ISI drives and OSEMs (inputs are columns, and outputs are rows). We highlight the 6 translational transfer functions that can be used to calibrate the OSEMs in red. The drives seem decoupled enough to do the calibration (for example, we expect to see a length drive only in LF and RT, no motion anywhere else).

Figures 2,3, and 4 show a detail of the 6 transfer functions we will use for calibration, all of them should be scaled to 1 [OSEM m]/[GS13 m]. The scalings are:

TITLE: 03/28 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Just got to NLN and into Observing. When trying to relock earlier, we did have a lockloss from DHARD_WFS for some reason, but no issues after that. The wind is currently low but has had a couple instances of quickly spiking up above 20/25mph before dying back down, the second of which came with very heavy rain. Hopefully that doesn't happen again during the night. The secondary microseism is still very high, but doesn't look to be getting worse.
LOG:

23:30 Relocking and in OMC_WHITENING damping violins

00:33 NOMINAL_LOW_NOISE
00:34 Observing

03:03 Lockloss
    - Lost lock at DHARD WFS
    - Ran an initial alignment

05:06 NOMINAL_LOW_NOISE

05:07 Observing

Lockloss @ 03/28 03:03UTC after 2.5 hours locked. Of course right after I put in my midshift report saying that we were locked

Observing at 155Mpc and have been Locked for 2.5 hours. Nothing to report

TITLE: 03/27 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Microseism
INCOMING OPERATOR: Oli
SHIFT SUMMARY: Calibration and commissioning started the day. After a lock loss at 12PT we have been struggling to relock. We just recently made it to the last state before low noise, but the violins are very high from a few lock losses at Transition_From_ETMX and Move_Spots. Oli is damping those now and hopefully we'll be back to observing soon. It's not entirely clear why we had issues relocking. The primary and secondary useism are definitely elevated, but at levels that we have locked before. Wind is under 20mph, as well.
LOG:

• 1810, 1815, 1818, 1832 HAM7 WD tripped when squeezing was turned off
• 1900 Lock loss                                                                                                                                                                                                                                                                             

TITLE: 03/27 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Microseism
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 17mph Gusts, 11mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.51 μm/s
QUICK SUMMARY:

In OMC_WHITENING and damping violins. Hopefully we'll be back to Observing soon.

After this morning's SRCL offset change and SQZ NLG change 83589, I returned FC de-tuning to -34Hz, SQZ angle to 171, and OPO trans setpoint to 80uW. Adjusted OPO temp and measured NLG to be 12 following 76542

FranciscoL, SheilaD, JeffK

I compared the sensing functions from calibration reports 20250327T160138Z, and 20250322T190652Z to look for correlations with the SRCL offset change done before the routinely Thursday calibration measurement. We see a decrease of the detuned SRC spring frequency from 7.343 Hz to 2.191 Hz.

I am attaching each sensing model generated by pydarm. Second attachment (20250322T190652Z_sensing_mcmc_compare) is for the measurement done last Saturday, third attachment (20250327T160138Z_sensing_mcmc_compare) for the measurement done today. We trust the model because the fit (orange trace) and the data (green dots) match well above the 10 Hz fit range. Additionally, the data on both measurements below 10 Hz shows a similar behavior. This gives us (1) confidence that the change in the sensing function was indeed from SRCL detuning and (2) we may have other sources of coupling into the sensing function -- thinking about DHARD as the main culprit.

The first attachment (sensing_ratio) shows the relative change of each measurement labeled by their report id. We see that the latest calibration measurements (orange and black), have been consistent with the latest front-end calibration (blue) -- more confidence towards SRCL changing the sensing function.

While this improves the detuning of the interferometer, the overhead to update the calibration has deemed to high for the few days left that will be running. We will reassess when we are close to coming back into observing mode (June)

What I did to make plots:

(1) Get the report from the calibration measurement this morning:

In the terminal -- no need to activate any environments or configuring the terminal in any way -- running

will create a report of the latest measurement that was done. This command will not change FE calibration so, for now, this is a safe way to get data and manipulate/evaluate it.

(2) Used script to retrieve sensing function measurements from calibration reports:

The script located at

will load the measurements as provided by their report id. I personally chose a dictionary to add comments for labeling purposes. The function 'sensing' will load the measurement and get the response. The rest is plotting aesthetics.

NOTE To enable the pydarm package -- and run the script -- run in terminal

J. Kissel, S. Dwyer

Sheila and I were finally able to use an SR785 by HAM6 ISC-R5 (see setup and discussions in LHO:83523, LHO:83466, and LHO:83468) to inject a loud sinusoidal excitation into the OMC DCPD transimpedance amplifier TEST inputs via analog interface of the OMC DPCD whitening chassis. 

Remember, this is in hopes to mimic a PI ring-up and identify whether or not this would cause ~10-100 Hz broadband noise increase in the detector sensitivity, as was seen on 2025-03-12 (LHO:83335).

We saw NO broadband low frequency noise increase with an excitation amplitude that results in a factor of 5x *higher* photocurrent on the DCPDs than during the PI ring-up.

I attach a four-panel plot, and because that makes each panel small, I also attach the same plots zoomed in to each panel.
In the plots, I'm comparing four different times:
    - (RED) 2025-03-12 17:32 UTC -- the time of the 10.4 kHz PI mode ring-up from LHO:83335
    - (BLUE) 2025-03-20 16:13 UTC -- the time I used in LHO:83468 to assess how much drive I should be able to put in,
    - (GREEN) 2025-03-27 17:16 UTC -- a time during the loudest, 250 [mVpk_SE, SR785 SRC output] excitation
    - (BROWN) 2025-03-27 17:30 UTC -- just after we're done with our tests and everything is unplugged in the nominal configuration

Upper panels of 1st Attachment (zoomed in with 2nd and 4nd attachment)-- the 65 kHz version of the OMC DPCD A channel that has NO digital anti-aliasing (under the obfuscated channel name H1:OMC-PI_DCPD_64KHZ_AHF_DQ), calibrated into photocurrent on DCPDA (which needs only a conversion of 0.001 [A/mA]).
    - Left panel (and 2nd attachment) is zoomed in around the 10.2 - 10.5 kHz region, showing the excitation, The acoustic mode forest, and except for the unthermalized data, the 02 (or 20) optical mode hump.
    - Right panel (and 4th attachment) is the full ASD across the 10 Hz - 25 kHz frequency range.

Lower panels of 1st Attachment (zoomed in with 3rd and 5th attachments) -- GDS-CALIB_STRAIN converted to DARM displacement (which needs only a multiplication by the length of the arms, L = 3995 [m]).
    - Left panel (and 3rd attachment) zooms in on the 10-100 Hz frequency region, and
    - Right panel (and 5th attachment) shows the whole 10 - 7000 Hz sensitivity.

There's NO change between BLUE (excitation OFF) and RED (excitation ON), and thus no evidence of broadband noise increase we saw in BROWN (during PI ring-up).

%%%%
Measurement notes
- For no particular reason, we turned on BOTH DCPDA and DCPDB test excitation relays (see LHO:83466 for how). That means our single-ended qqq [mVpk] analog excitation from the SR785, converted to qqq [mVpk] differential by the SR785 Accessory Box (whose TF is 1 [V_DIFF] / 1 [V_SE]), was driving that qqq [mVpk] amplitude into BOTH A & B channels' TEST inputs within the TIA. So, the excitation seen in OMC DCPDA's ADC input is also in DCPDB, and thus the sum of the the two, OMC_DCPD_SUM, the DARM error signal, actually sees twice this amplitude. But, the sum is done digitally, after down-converting to 16 kHz, so it's not relevant to "is the ADC getting saturated" discussions; just important to bring up in "how much of this excitation can the IFO handle" discussions. 

Sheila, Camilla

This morning we changed SRCL offset from -191 to -306 and FC detuning from -34 to -28, as discussed in  83570. Decided to take a  SQZ dataset here.

Increased SHG launch, turned OPO trans setpoint up from 80uW to 95uW to increase NLG from 11 to 19 (as we had earlier in O4). Measured NLG with 76542. OPO gain left at -8.

Had some strange HAM7 CPS glitches and WD trips. Think we manged to avoid these effecting the data.

Forgot to turn of SQZ ASC, realized and then we lost lock, this data is not good as the AS42 and ZM alignment offsets were moving around a lot.

J. Kissel, S. Dwyer

When we apply a large SRCL offset, as we did today LHO:83583, we get more 45 MHz sideband field in the POP port. The POP A LSC RFPD (in HAM1) is demodulated in analog at 45 MHz, and its I & Q signals are piped into a standard 16 bit ADC whose saturation limit is +/- 2^15 = 32768 [ct]. The I channel is used as the error signal for SRCL, and the Q is used as the error signal for MICH, so if we get anywhere near that saturation limit, these loops lose there error signals and the IFO loses lock.

So, just a sanity check, here's the POP A I & Q raw ADC channels across the transition from -191 [ct] to -306 [ct] SRCL offset.

-306 [ct] does not saturate the POP A I or Q ADC channels.

While the SQZ team was commissioning in the control room, the HAM7 ISI tripped 4 times on the CPSs. Looking at the trip plots this looks like the CPS glitches that we have seen in the past (attachment 1).

HAM7 definitely trips more forequently than other ham chambers (attachment 2), and we know that we have seen these when there are people working in the racks nearby, but today the sqz team was adjusting TEC temperatures, closing beam diverters, or just doing nothing when these happened.

FRS33714 filed since I couldn't find one specifically for this, though we do have tickets open for other HAM6 CPS gltiching: FRS: 11640 FRS: 11642 Aggregate IIET: 11643.

Thu Mar 27 10:13:56 2025 INFO: Fill completed in 13min 52secs

Jennie W, Sheila

Summary: We altered the offsets on the H1:ASC_OMC_{A,B}_{PIT,YAW} QPDs which are used to align the beam into the OMC. This was aiming to give us a improvement in optical gain. After doing this we aimed to measure the anti-symmetric port light changing as we chnage the darm offset. We are trying to use both these measurements to narrow down where we have optical loss in that could be limiting our observed squeezing. Performed both measurments successfully but the different alignment of the OMC made the squeezing less good so Camilla (alog #83009) needed to do some tuning.

Last time (alog #82938) I did this I used the wrong values as our analysis used the output channels to the loops instead of the input channels which come before the offsets are put in. The new analysis of our measurement of the optical gain as seen by the 410Hz PCAL line, changing with QPD offset, shows that we want the loop inputs to change to:

H1:ASC_OMC_A_PIT_INMON to 0.3 -> so we should change H1:ASC_OMC_A_PIT_OFFSET to -0.3

H1:ASC_OMC_A_YAW_INMON to -0.15 -> so we should change H1:ASC_OMC_A_YAW_OFFSET to 0.15

H1:ASC_OMC_B_PIT_INMON to 0.1 -> so we should change H1:ASC_OMC_B_PIT_OFFSET to -0.1

H1:ASC_OMC_B_YAW_INMON to 0.025 - so we should change H1:ASC_OMC_B_YAW_OFFSET to -0.025

We stepped these up in steps of around 0.01 to 0.02 while monitoring the saturations on OMC and OM3 suspensions and the optical gain, both to make sure we were going in the correct direction and that we were not near to saturation of the suspensions as hapenened last time I tried to do this.

Attached is the code and the ndscope showing the steps on each offset, (top row left plot, top row center right plot, second row left plot, second row center right plot). The top stage osems for OM3 suspension are shown in the third row left plot, the top stage osems for OMC suspension are in the third row center left plot, and the optical gain is shown in the third row right plot.

The optical gain improved from by 0.0113731 from a starting value of 1.00595, so that is an improvement of 1.13 % in optical gain.

Around 19:04:28 UTC I started the DARM offset step to see if the change in optical gain matches that we would see if we measured the throughput of HAM 6. Unfortuntely I forgot to turn off the OMC ASC which we know affects this measurement of the loss. We stood down from changing the OMC and Camilla did some squeezer measurements, then I made the same mistake again the next time I tried to run it (d'oh). Both times I control-C'd the auto_darm_offset.py form the command line which means the starting PCAL line values, and DARM offset had to be reset manually before I ran the script successfully after turning the OMC ASC gain to 0 to turn it off.

The darm offset measurement started at 19:20:31 UTC. The code to run it is /ligo/gitcommon/darm_offset_step/auto_darm_offset_step.py

The results are saved in /ligo/gitcommon/darm_offset_step/data and /ligo/gitcommon/darm_offset_step/figures/plot_darm_optical_gain_vs_dcpd_sum.

From the final plot in the attached pdf, the transmission of the fundamental mode light between ASC_AS_C (anti-symmetric port) DCPD is (1/1.139)*100 = 87.8 %. We can compare this to the previous measurement from last week with the old QPD offsets to see if the optical loss change matches what we would expect from such a change in optical gain.

Jennie W, Sheila

Today I got a chance to redo some of my output chain measurements (alog #82555) that gave us a confusing result when we were heating up and cooling down the OM2 heater. The confusiong was that our optical gain got better for cold OM2 compared to hot, but the loss through HAM6 predicted by stepping the DARM offset and comparing it to the power at the anitsymmetric port predicted that the loss was worse with cold OM2 and gave us unreasonably low (~65 %) throughput estimate for the fundamental TM00 mode through HAM6. We realised that the OM3 and OMC alignment are being changed by the ASC during this time so that could be affecting the comparison.

Steps:

Turn off OMC ASC at 18:43:00 UTC.

Run auto_darm_offset_step.py from /ligo/gitcommon/labutils/darm_offset_step at 18:45:01 UTC.

Results: P_AS = 62.996 mW + 1.162 * P_DCPD

This makes the throughput estimate for the TM00 mode through HAM6 to the DCPDs to be 86.0 % of the power at the AS port. Which seems more reasonable than the 65% we got last time. We need to do this measurements again when we have improved kappa C somehow to check it gives us the same loss estimate between two times.

We were then going to purposely change kappa C as a comparison to the estimate the DARM offset step gives us, byt changing the QPD offsets based on this measurement 82383(I got the sign wrong last time I did this).

I turned the OMC ASC back on before doing this, however when I changed the H1:ASC-OMC_A_PIT_OFFSET to 0.45 this saturated the OM3 suspension so this was set back to nominal.

I think I got signs wrong yet again so we will try what we now think are the correct ones another commissioning period but maybe do it slowly so as not to cause saturations.