Workstations were updated and rebooted. This was an OS packages update.  Conda packages were not updated.

IFO is in ENGAGE_ASC_FOR_FULL_IFO and LOCKING

Got called at 2:30 AM after guardian failed to lock ALS during 30mph wind gusts (which seems to have been the cause of the lockloss itself) The cause for the call itself was that ISC_LOCK had stalled after a few attempts in which I simply unstalled it. However, DRMI was still having issues locking and alignment looked poor. A 5.7 EQ (+ aftershock) delayed my running initial alignment but it ran automatically after the EQ passed. Locking is so far fully automatic and DRMI locked with a much better signal. The lockloss stalling issue doesnt seem to have recurred while relocking.

TITLE: 07/15 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 144Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Lockloss at the beginning of the shift, high winds made relocking a struggle till they calmed down in the last 1.5 hours. We've been locked for about an hour as of 05:00 UTC.
LOG:

• 00:11 UTC Observing

• 00:23 UTC lockloss after only 15 minutes

  • The winds are teetering around 30-40 mph for gusts and 20-30 mph for the 3 minute avg

  • We've lost lock in the same spot twice during CARM_OFFSET_REDUCTION with a large DHARD oscillation and a "Low recycling gain" warning. Potentially meaning alignment is off somewhere?

  • 02:39 - 02:57 UTC Initial Alignment

  • 04:08 UTC Observing

Originally, the suspensions who have already had their satamps swapped for ECR E2400330 had their compensation filters updated to a generic 5.31:0.0969 zp filter that would get put in using my script /ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools/satampswap_generic_filterupdate_ECR_E2400330.py (r12449).

However, Jeff went through the entire set of new satamps and tested each channel to determine the actual transimpedance and frequency response of each channel. We can use the measured frequency response to replace the generic filter with more precise compensation filters, so I have made a script that does just that -  it updates the compensation filters in OSEMINF FM1 for whichever suspension you want with the more accurate zero and pole values for each channel. This script can be found at /ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools/satampswap_bestpossible_filterupdate_ECR_E2400330.py (r12449).

I have used this script to update the compensation filters for the suspensions that have already had their satamps swapped (see txt file): SR3, SRM, BS, PRM, PR3, ITMX, ITMY, SR2. These new filters have all been loaded in.

Running the Best Possible Filter Update Script

This script can be found at /ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools/satampswap_bestpossible_filterupdate_ECR_E2400330.py. To run it, all you need to do is:

• Make sure the txt measurement files exist for that optic in /ligo/svncommon/SusSVN/sus/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Results/
• In the PythonTools directory, do python3 satampswap_bestpossible_filterupdate_ECR_E2400330.py -o (or --opt), followed by the name of the optic or optics. If updating for multiple optics at once, put a space between each
• Once the txt filter file has been updated, you must then go to the suspension's GDS screen to check the filter diffs and load in the new filters. Before loading in the new filters, make sure we are in DOWN and put the suspension into SAFE

Examples:

python3 /ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools/satampswap_bestpossible_filterupdate_ECR_E2400330.py --opt SR2

Or to update multiple suspensions at once:

python3 /ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools/satampswap_bestpossible_filterupdate_ECR_E2400330.py -o SR2 ITMX PRM

Running the Generic Filter Update Script

In case the measurements aren't done but you would like to update the compensation filters, you can use the generic filter script, satampswap_generic_filterupdate_ECR_E2400330.py. To run this script:

• In the PythonTools directory, do python3 satampswap_bestpossible_filterupdate_ECR_E2400330.py -o (or --opt), followed by the name of the optic or optics. If updating for multiple optics at once, put a space between each
• Once the txt filter file has been updated, you must then go to the suspension's GDS screen to check the filter diffs and load in the new filters. Before loading in the new filters, make sure we are in DOWN and put the suspension into SAFE

00:23 UTC lockloss

Ivey,

When fitting transfer functions for the OSEM estimator, I tested several transfer function fitting programs to find one that is both accurate and efficient.

A brief side note: In the 6/24 M1-to-M1 dataset that Oli took, we observed an unexpected right-hand zero near 1.2 Hz (see attached plot), where we had expected a left-hand zero. After comparing with the 4/15 and 4/18 datasets, we found no corresponding right-hand zero, suggesting the 6/24 zero is likely due to noise.

I wrote a document highlighting the pros and cons of each of the fitting programs here:
TF Fitting Comparison (Google Doc)

The programs include:

Vectfit3 (I recommend using this with strong inverse weighting): Uses vector fitting. Created by Bjorn Gustavsen. Not built into MATLAB. Performs nearly identically to Vectfit4, but has more documentation.

Rational: Built-in MATLAB function. Uses the AAA algorithm.

Spectrumest: Built-in MATLAB function. Chooses an internal algorithm based on the data.

Rationalfit: Built-in MATLAB function. Uses vector fitting.

Generally, these programs fit poles and end behavior well, but often compromise the accuracy of the fit in the zero regions. In these cases, we often have to manually refine the fit in the zero regions. However, Vectfit3 performs very well on the 6/24 M1-to-M1 and SusPoint-to-M1 datasets when used with strong inverse weighting. We were able to produce better fits than manual methods, and expect this approach to be more efficient for future use.

Example plots are available here:
Plot Comparison Slides (Google Slides)

Attached is the MATLAB code used for the M1-to-M1 fits.
To use vectfit3, you must download the package
here.
All other functions used are built into MATLAB's toolboxes.

Measurement file paths:

 /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/Common/Data/2025-06-24_1700_H1ISIHAM5_ST1_WhiteNoise_SR3SusPoint_L_to_Y_0p02to50Hz.xml 
 
 /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/2025-06-24_1900_H1SUSSR3_M1_WhiteNoise_L_to_Y_0p02to50Hz.xml 

TITLE: 07/14 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Two locklosses today, one of which during commissioning time from a M6.8 earthquake out of Panama. The second lockloss we're still recovering from, and even after running an initial alignment, there have been several lockloss at low states, possibly from rising wind speeds.

• 14:26 - Lockloss from LOWNOISE_ASC
• 15:42 - Reached NLN, jumping into commissioning
• 17:25 - Entered EQ mode
• 17:48 - Lockloss
• 18:28 - Ground has calmed down, starting lock acquisition
• 20:18 - Observing
• 21:56 - Lockloss - alog85747
  • 22:33 - Lockloss during DRMI, starting initial alignment
  • 22:52 - Alignment finished, starting lock acquisition

LOG:

TITLE: 07/14 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 25mph Gusts, 16mph 3min avg
    Primary useism: 0.09 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY:

• We're relocking after a 21:56 UTC lockloss
  • The wind is a little high
    • From windy.com the wind is predicted to get a little worse before calming down later tonight
  • Lots of low state (pre-DRMI) and one at DARM_TO_RF

Lockloss @ 21:56 UTC after almost 2 hours locked - link to lockloss tool

This appeared to line up with an incoming M5.8 EQ from Japan, but the R-waves hadn't fully arrived and the ground wasn't moving all the much at the time. Also, the first errant thing happening I can see is a hit on DARM, which seems unusual.

Ivey, Edgard

Follow up to Oli's estimator test [LHO: 85615]. 

Ivey took the data for the three tests that Oli ran and got some spectra to show that the estimator is working as expected. We can see three traces in each one of the figures attached:

• The Blue traces are using light damping, that is, using the OSEMs as we have them right now, but dividing the M1_DAMP_Y gains by a factor of 5. [Light damping]
• The Red traces are the current settings. [ OSEM only damping ]
• The Yellow traces are the estimator damping. This tries to get the best of both worlds by using the HAM5 GS13 and the models we posted in [LHO: 85446] [ Estimator damping ]

The first figure shows the M1 Yaw signals as seen by the M1 OSEMs. As you can see, the spectrum is completely dominated by sensor noise, except at the suspension resonances. Under light damping, the OSEM actually sees the suspension modes ring, but under 'OSEM only' and Estimator damping, the resonances don't show up anymore, as expected. We note that there is a bit of the 3 Hz resonance that seems to not be fully damped by the estimator.

The second figure is one of the money plots. It shows the M3 Yaw as seen by the SR3 OPLEV. In it, we can see that the OSEM only, and the Estimator damping are both successful at damping down the resonances of the suspension. This means that the Estimator is working as intended. We note that in the estimator case, there is a bit of excess noise at 2 Hz.

The last figure shows the total drive request for the M1 OSEMs in drive cts. As expected, the Estimator is requesting less drive above 5 Hz when compared to the OSEM only damping (which is the current setting). Since this is completely aligned with our expectations, we believe this implies that the estimator is working as intended and we are likely reducing the SR3 M1 Y OSEM noise injection into M3 Y by a factor of 5 at 10 Hz and above. 

We also note that the drive request at 2 Hz has a bump likely due to model mismatch. This effect is likely the cause for the excess 2Hz noise seen in the OPLEV signal. We might need to model it to see why it would lead to a coherent addition of motion that can be captured by the M3 OPLEV. 

Since this test was so successful, our expectation is that we will be trying to affix the OSEM calibrations, a Yaw estimator, and then a Pitch estimator for SR3 in the next few weeks. Stay Tuned!

Jim, Elenna

We had a 6.6 earthquake begin rolling in from Panama, so Jim and I tried to take the ASC arm control loops to the high bandwidth state. I also turned off the LSC feedforward which drives the ETMY PUM.

This obviously creates a lot of noise in DARM, but we are curious to see if it helps us ride out a large earthquake.

This consists of:

• turning off low pass and other shaping filters for DHARD P, DHARD Y, CHARD Y and CHARD Y
• adjusting CHARD P and Y gains
• increasing DSOFT P and Y gains
• changing LSC feedforward gains to zero

Some of these things can be done by hand, but others, like transitioning filters and gains together have to be done with guardian code to ensure they are done at the same time. I copied and pasted lines of code into a guardian shell.

These are the lines of code that will do everything I mentioned above:

FAMIS 31094

FSS TPD signal has been dropping over the past week, so it could probably do with some RefCav alignment adjustments soon. Otherwise, not much else to report.

Jennie W, Rahul

Yesterday we made some measurements to calibrate the spot size on the QPD as we scan the beam position across it.

We used a connector Fil made us to plug in the OT301 QPD amplifier into a DC power supply after checking it contained voltage regulators that could cope with a voltage between 12 and 19 V ( as the unit says it expects DC supply but the previous one we were using was AC with a 100mA current rating and was getting too hot so we assume that was the incorrect one). We hooked it up at 16V (this draws about 150mA of current). The QPD readout looks normal and does not have any of the strange sawtooth we saw with the original power cable.

We moved the M2MS beam measurement system out of the way of the translation stage.

To calibrate the QPD we need to change the lateral position of the M1 mirror and lens to change the yaw positioning on the QPD and measure the X and Y voltages from the QPD.

We need to check we are centred first. The QPD bullseye readout shows the beam is off a tiny bit in yaw but this was as good as we could get at centering the beam when we moved the QPD. All 8 PDs are reading about 4.6 V so this means the beam is well centred in the array plane.

We measure 11000 counts on the bullseye qpd readout at this M1 position.

I plotted the data from lowest reading on the translation stage to highest and fitted the linear region using Calibrate_QPD.m which is attached.

Data is shown in attached pdf.

The slop of the linear region in V/inch is 112 V/inch. Which means to if the beam moved 8.93 e-3 inches on the QPD in yaw, the yaw readout would change by 1 Volt.