Last checked in alog85994, closes FAMIS26554.

Both BRS X & Y are within range.

Jeff and I have been noticing an SDF diff going into observing where the input of the PR3 M1 LOCK P and Y filter banks is turned ON. However, there is no ISC signal ever sent to PR3, so there is no reason for this to get turned on. We have been SDFing it OFF, thinking that it was turned on due to some error in the PR3 estimator testing. But we learned today, when we had an observe diff in the PR3 model again, that actually the guardian is turning it on. I found that the input is turned on in PREP_ASC_FOR_FULL_IFO, which I think is some holdover to some PR3 wire heating correction, at least according to a variety of comments in the guardian code. So, to avoid this continuing to be an issue, I commented out lines 3397 and 3398 in ISC_LOCK, which will ensure the input will stay OFF, which we are SDFed as. We are not correcting PR3 wire heating at this time.

When I made these corrections, I pulled us out of observing momentarily to load the guardian, which I felt was a necessary task to prevent confusion and possible OWL shift operators being woken up by SDF diffs preventing observing.

J. Kissel, O. Patane 

Attached are the local performance metrics for the PR3 Pitch and Yaw estimators (explained with SR3's metrics and visual aides in LHO:86553).

Just to reduce plot overwhelm, in the main aLOG here I attach the performance metric comparisons ON vs. OFF for PR3.
I'll post the PR3 vs SR3 plots in the comments.

In summary -- the PR3 estimator performs just as well as the SR3 estimator, reducing the 1-50 Hz off-resonance motion by a factor of ~4x, but leaving the amount of on-resonance damping the same. As with SR3, the performance is limited by the remaining "light" "classical" "broadband" damping that is necessary to keep the estimator plant transfer functions reasonable (i.e. to keep the Q's sufficiently low that fitting and modeling the TFs is reasonable). 

However, because PR3 is sitting on HAM2 a worse performing ISI between 1-50 Hz because it doesn't have stage 0 L4C feed-forward, the estimated contribution of suspension point motion to M1 is much louder / noisier. As such, I provide zoom ins from 5 to 50 Hz. That motion is still *smaller* than the remaining light damping OSEM sensor noise, so it's not (yet) getting imprinted on the SUS. But it's still interesting.

Tuesday Aug 19th I moved the dust monitor #10 from the bier garten area to up on the work platform on BSC2 (alog86444). Attached are some various plots of DM10 and DM6, the monitor next to HAM6 in the mega clean room (turned off atm).

Last checked in alog86387, Closes FAMIS26593

The CS fans look fine, FAN2_{1,2} at EX seem to be showing an increase in motion starting ~3 days.

J. Kissel, O. Patane 

As we looked through plots of the performance of PR3 P and Y estimators throughout the commissioning period, and because we were able to make it through several lock acquisition sequences with both estimators ON, we've elected to keep the PR3 estimators ON permanently.
The H1SUSPR3 P and Y estimators have been ON by 2025-08-28 19:30 UTC.

Stay tuned for performance plots.

Wind fence inspection from the beginning of the month. No new issues noted.

The satellite amplifiers for FC1 and FC2 were swapped out on August 5, 2025 (86207). I checked the filter cavity LSC and ASC signals to see if we can see improvement in the noise before vs after the swap.

For the LSC signals, I looked at H1:SQZ-FC_LSC_DOF2_OUT_DQ, since that is the LSC channel that is on when we are fully locked. 
For the ASC signals, I looked at H1:SQZ-FC_ASC_CAV_{POS,ANG}_{P,Y}_OUT_DQ, since those are the ASC signals inside the filter cavity.

Even just looking at the ndscope of the average noise levels of these channels before and after the satamp swap (swap at t=0), all the ASC channels seem to drop a bit in noise after the swap. It's hard to tell anything from the LSC DOF2 channel.

For comparing spectra, I looked in the range of a few days before and a few days after the swap and found before and after periods of 50 minutes each where the ASC noise looked to be at its lowest. These times and their measurement settings were:
Before: 2025-08-05 03:00 UTC; 0.01 BW, 46 averages (BLUE)
    - Bonus Before for SQZ-FC_LSC_DOF2_OUT_DQ: 2025-08-02 09:23 UTC; 0.01 BW, 46 averages (GREEN)
After: 2025-08-09 12:52 UTC; 0.01 BW, 46 averages (RED)
I also tried out a couple other before times, trying to get the absolute lowest noise before the satellite amplifier swaps, but this before time had the lowest noise that I could find. The bonus Before time for LSC DOF2 is because I was able to find a time where the noise below 0.6 Hz was decently lower than the noise from the default Before time.

Comparison results
ASC
Pitch
SQZ-ASC_CAV_POS_P_OUT_DQ
SQZ-ASC_CAV_ANG_P_OUT_DQ
Yaw
SQZ-ASC_CAV_POS_P_OUT_DQ
SQZ-ASC_CAV_ANG_Y_OUT_DQ
Most of the improvement is seen around 1 Hz, which looks really good!

LSC
SQZ-FC_LSC_DOF2_OUT_DQ
When only comparing to the default Aug 05 03:00 UTC (BLUE) before time, we see broadband improvement almost everywhere below 3.5 Hz. When comparing to the bonus before time (Aug 2 09:23 UTC), however, it looks like the noise between 0.3-0.55 Hz is much better before. I believe this is due to lower ground motion at the time of the green before time (ndscope).

Broad band ran before the Calibration push:
pydarm measure --run-headless bb
2025-08-28 08:03:41,609 config file: /ligo/groups/cal/H1/ifo/pydarm_cmd_H1.yaml
.....computer noises.....
Completeed successfully!

Calibration was pushed by Elena

!!! ANOTHER WILD BROADBAND Appears  !!!

pydarm measure --run-headless bb
2025-08-28 08:37:10,096 config file: /ligo/groups/cal/H1/ifo/pydarm_cmd_H1.yaml
2025-08-28 08:37:10,113 available measurements:
  pcal: PCal response, swept-sine (/ligo/groups/cal/H1/ifo/templates/PCALY2DARM_SS__template_.xml)
  bb  : PCal response, broad-band (/ligo/groups/cal/H1/ifo/templates/PCALY2DARM_BB__template_.xml)
  sens: sensing function (/ligo/groups/cal/H1/ifo/templates/DARMOLG_SS__template_.xml)
  act1x: actuation X L1 (UIM) stage response (/ligo/groups/cal/H1/ifo/templates/SUSETMX_L1_SS__template_.xml)
  act2x: actuation X L2 (PUM) stage response (/ligo/groups/cal/H1/ifo/templates/SUSETMX_L2_SS__template_.xml)
  act3x: actuation X L3 (TST) stage response (/ligo/groups/cal/H1/ifo/templates/SUSETMX_L3_SS__template_.xml)

open
restore /ligo/groups/cal/H1/ifo/templates/PCALY2DARM_BB__template_.xml
run -w
save /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250828T153710Z.xml

"The new calibration looks good" ~Elenna circa late Aug 2025

Finally some SIMULINES :

gpstime;python /ligo/groups/cal/src/simulines/simulines/simuLines.py -i /ligo/groups/cal/H1/simulines_settings/newDARM_20231221/settings_h1_20250212.ini;gpstime
PDT: 2025-08-28 08:45:54.867509 PDT
UTC: 2025-08-28 15:45:54.867509 UTC
GPS: 1440431172.867509

....Computer noises ....

Oh no!!!  : ( 
LOCKLOSS during Simulines!

2025-08-28 16:13:08,168 | ERROR | Aborting main thread and Data recording, if any. Cleaning up temporary file structure.
PDT: 2025-08-28 09:13:08.423541 PDT
UTC: 2025-08-28 16:13:08.423541 UTC
GPS: 1440432806.423541

Answer (from Sheila and Elenna): no.

With Jenne's beamsplitter slow let go servo, we have been wondering if, after lockloss, we should just skip initial alignment while the servo does its job. According to Jenne and Ryan, the beamsplitter takes 17 minutes to cool down. Meanwhile, the start of initial alignment to the start of the beamsplitter initial alignment is 10 minutes, and there is an additional 3 minutes from the start of MICH bright align to MICH bright offload (we looked at the initial alignment today, so these are snapshot numbers).

We think that if an initial alignment is run immediately after lockloss, the resulting error in the beamsplitter alignment by the time we reach DRMI will be small, since the initial alignment process will overwrite the slow let go servo.

However, if we don't run initial alignment (because we think the alignment is good or whatever), the slow let go should help when we get to DRMI.

So the answer is, we should run initial alignment based on the usual judgements, i.e. does the alignment look good enough to lock? We can ignore the beamsplitter heating and the slow let-go as a reason to do or not do initial alignment.

We lost lock in move spots, lockloss tool. It looks like the MICH LSC error signal got very large 1 second before lockloss, not sure why.

The PRC1 pitch ASC is no longer working properly, despite its successful test in this alog. While trying to debug this problem, I monitored the REFL 9, 45 and POP WFS signals and none of them crossed zero at the appropriate time. However, the PRC1 yaw ASC is working just fine.

Thu Aug 28 10:09:21 2025 INFO: Fill completed in 9min 18secs

Gerardo confirmed a good fill curbside.

Closes FAMIS 28420, last checked in alog 86471.

IX did not run with the following error popping (only error lines copied):

Coherence for bias_drive_bias_off is 0.015409917227075794, which is below the threshold of 0.1. Skipping this measurement
Cannot calculate beta/beta2 because some measurements failed or have insufficient coherence!
Cannot calculate alpha/gamma because some measurements failed or have insufficient coherence!
Something went wrong with analysis, skipping ITMX_13_Hz_1440255043"

Coherence for bias_drive_bias_off is 0.0825334918693312, which is below the threshold of 0.1. Skipping this measurement
Cannot calculate beta/beta2 because some measurements failed or have insufficient coherence!
Cannot calculate alpha/gamma because some measurements failed or have insufficient coherence!
Something went wrong with analysis, skipping ITMX_13_Hz_1438440647

Previously analyzed ETMY_12_Hz_1439650262 - skipping

Analyzing data in ITMX_13_Hz_1437835843...
Reading time series for bias_drive_bias_on
Reading time series for L_drive_bias_on
Reading time series for bias_drive_bias_off
Reading time series for L_drive_bias_off
Coherence for bias_drive_bias_off is 0.07205627679480447, which is below the threshold of 0.1. Skipping this measurement
Cannot calculate beta/beta2 because some measurements failed or have insufficient coherence!
Cannot calculate alpha/gamma because some measurements failed or have insufficient coherence!
Something went wrong with analysis, skipping ITMX_13_Hz_1437835843
 

Today we pushed calibration report 20250823T183838Z, which updates the calibration model after changes to the actuation (ESD bias change) and sensing (SRC alignment offset change).

These are the steps I took (and two mistakes I made):

• [several days ago] ran pydarm report --regen 20250823T183838Z with the ESD bias and drivealign L3 L2L gains updated in the ini file. I checked to make sure the results were sensible. There is a change in the sensing function at low frequency, probably from an L2A2L related change.
  • note, we checked with the usual sqz "brontosaurus" measurement that the SRCL offset does not need to be updated. Any appreciable spring in the sensing function now is not due to SRC detuning.
• [yesterday] ran pydarm report --regen 20250823T183838Z to get the GDS filters, checked the GDS filters to ensure they looked normal
• [today] ran a broadband PCAL measurement, to get a "before" measurement of the systematic error
  • we had been locked 41 hours at this point, so it's safe to say we were thermalized :)
• committed the report, pydarm commit 20250823T183838Z --valid --message 'new calibration push, new ESD bias and SRC ASC offsets'
• exported the report pydarm export --push 20250823T183838Z
• uploaded, pydarm upload 20250823T183838Z
• restarted gds, pydarm gds restart
  • I marked the GDS restart time as 8:13 local
• waited for GDS to restart
• I was watching the CDS screen for the CALCS model, and once the filter modifications were detected, I reloaded the model, which should load in the appropriate filter changes
• MISTAKE 1: Jeff and I noticed that CAL DELTA L looked very weird and miscalibrated. We realized that the H1:CAL-CS_DARM_FE_ETMX_L3_DRIVEALIGN_L2L_GAIN had not been updated with the new drivealign gain. Once I updated it, CAL DELTA L then looked correct
  • find the screen to check this via sitemap>cal cs>DARM calib> actuation function>ETMX actuator model>L3 drivealign
• Then, I waited and watched the grafana to see when the line monitoring came back online, which a sign that GDS is up and running
• MISTAKE 2: it seemed to be taking a suspiciously long time for grafana to come back online. Joe suggested I check if GDS is available in DTT. It was. I realized I had the grafana page set to "analysis ready" and we were out of observing. Once I switched the setting to "locked", indeed GDS had been back online for 10 minutes at that time.
  • this only delayed the process, but it means we will go over time by a few minutes
• I ran the second broadband, and great success! The systematic error has improved, and is now 2% or less.
• Tony then proceeded to run the simulines measurement.

The attached plot compares the before and after PCAL broadband to GDS CALIB STRAIN. Tony will post the usual alog about the simulines measurement once it is complete.

Instead of redesigned the MICH ASC loops, I just updated the lowpasses to be at 12 Hz instead of 15 Hz, which should reduce the gain by 15 dB between 10-20 Hz for both pitch and yaw. I tested them today with no issues, so I adjusted the MICH ASC engagement in ISC_DRMI guardian, and updated SDF (accidentally overwrote the screenshot with my screenshot of the filter).