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

Followed the usual wiki instructions.

Simulines command run:

gpstime;python /ligo/groups/cal/src/simulines/simulines/simuLines.py -i /ligo/groups/cal/H1/simulines_settings/newDARM_20231221/settings_h1_20250212.ini;gpstime

Simulines start:

PDT: 2025-03-27 08:35:50.875109 PDT
UTC: 2025-03-27 15:35:50.875109 UTC
GPS: 1427124968.875109

Simulines stopped prematurely due to some SCRL offsets getting changed midway through:

PDT: 2025-03-27 08:54:32.154549 PDT
UTC: 2025-03-27 15:54:32.154549 UTC
GPS: 1427126090.154549

Simulines started again:

PDT: 2025-03-27 09:01:37.213384 PDT
UTC: 2025-03-27 16:01:37.213384 UTC
GPS: 1427126515.213384

Simulines end:
PDT: 2025-03-27 09:25:15.138110 PDT
UTC: 2025-03-27 16:25:15.138110 UTC
GPS: 1427127933.138110

Files:

2025-03-27 16:25:14,982 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250327T
160138Z.hdf5
2025-03-27 16:25:14,990 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_202
50327T160138Z.hdf5
2025-03-27 16:25:14,995 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_202
50327T160138Z.hdf5
2025-03-27 16:25:15,000 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_202
50327T160138Z.hdf5
2025-03-27 16:25:15,004 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_202
50327T160138Z.hdf5

Tony created the PCAL{X,Y}_STAT nodes a few weeks ago, and has been monitoring and testing over that time. They look to be working as intended, flagging any major issues with the PCAL system. I've now removed them from the excluded nodes list that the IFO node looks at so that now if either of these nodes is out of its nominal state or the node is not OK==True, then the IFO node will not be OK and we will not be able to go to Observing.

J. Kissel, S. Dwyer, T. Shaffer

TJ was diligently running at regularly scheduled calibration measurement suite with the current nominal configuration of the IFO. Sheila and I got too excited about what other measurements we needed to do during the commissioning period today, and I quickly and boldly made the assessment that the simulines sweeps were done by just looking at the front wall DARM FOM. And said "we can go ahead with the first [commissioning] measurements" and changed the SRCL offset to grab an augmented IFO configuration sweep as planned. We realized only ~2 mins after that the nominal configuration sweep *was* still going, and this is me eating my hat. Sorry team.

TJ killed the simulines session, which apparently automatically cleans up the calibration sweep measurement report infrastructure, so there's no evidence of it.
So, today's regular calibration has been spoiled.

The broadband injection in the nominal configuration did go forward to completion, that's
    /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/
        PCALY2DARM_BB_20250327T153021Z.xml
The "nominal" configuration -- compared to what we want to change today:
    Filter Cavity Detuning = -34 Hz offset
    SRCL Offset -191 [ct]

Here's the measurements with the augmented IFO configuration, with 
    Filter Cavity Detuning = -28 Hz offset
    SRCL Offset -306 [ct]

    /ligo/groups/cal/H1/measurements/PCALY2DARM_BB
        PCALY2DARM_BB_20250327T155611Z.xml
    /ligo/groups/cal/H1/measurements$ ls */*20250327*.hdf5
        DARMOLG_SS/DARMOLG_SS_20250327T160138Z.hdf5
        PCALY2DARM_SS/PCALY2DARM_SS_20250327T160138Z.hdf5
        SUSETMX_L1_SS/SUSETMX_L1_SS_20250327T160138Z.hdf5
        SUSETMX_L2_SS/SUSETMX_L2_SS_20250327T160138Z.hdf5
        SUSETMX_L3_SS/SUSETMX_L3_SS_20250327T160138Z.hdf5
Due to the augmented SRCL offset, these measurements should *not* be included in the collection of measurements used for creating estimates of residual sensing function systematic error.
The filter cavity detuning change only impacts the noise performance of the IFO, so if need be, you *can* still use the actuation function portion of the measurement suite.

TITLE: 03/27 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 18mph Gusts, 10mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.34 μm/s
QUICK SUMMARY: Locked for 3 hours. DIAG_MAIN is reporting "RefCav transmission low", tagging PSL. No other alarms or notifications. Planned calibration and commissioning time today from 1530-1900 UTC.

TITLE: 03/27 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Observing at 156Mpc and have been locked for almost 1 hour. One lockloss during my shift but relocking went well and was almost completely hands off besides me selecting an initial alignment.
LOG:

23:30UTC Observing at 156 Mpc and locked for almost 12 hours
    01:55 Kicked out of Observing due to squeezer losing lock
    01:59 Back into Observing after squeezer got back to FDS

02:41 Lockloss
    - I immediately decided to start an initial alignment since the lock had been relatively long
04:13 NOMINAL_LOW_NOISE
04:15 Observing                                                                                                                                                                                                                                                                                                                 

Lockloss @ 03/27 02:41UTC after just over 15 hours locked

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.