Last week (87801) Jeff took a bunch of transfer function measurements for PRM for the PRM L, P, and Y estimators. There were some he wasn't able to take:
- H1ISIHAM2 to H1SUSPRM M1 for all dofs with DAMP L, P, and Y all with 20% gain
- H1ISIHAM2 to H1SUSPRM M1 for all dofs with DAMP Y at 20% gain
- H1SUSPRM M1 to M1 for V, R, P, Y with DAMP Y at 20% gain
Today I was able to get the first two bullet points done
Measurements:
First, I made sure the SUSPOINT matrix had the correct values for driving PRM, which it did.
First set (L P Y DAMP gain at 20%):
L, P and Y DAMP gains were set to 20% of their nominal values, so they were set to -0.1, and T, V, and R were left at their nominal -0.5 gain values.
Measurements can be found in
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/Common/Data/2025-11-04_1800_H1ISIHAM2_ST1_PRMSusPoint_M1LPYDampingGain0p1_WhiteNoise_*_0p02to50Hz.xml r12766
Second set (Y DAMP gain at 20%):
After those measurements were taken, I set the L and P DAMP gains back to their nominal values of -0.5 and took another set of SUSPOINT measurements with only the Y gain at 20%.
Those measurements can be found in
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/Common/Data/2025-11-04_1930_H1ISIHAM2_ST1_PRMSusPoint_M1YawDampingGain0p1_WhiteNoise_*_0p02to50Hz.xml r12767
I ran out of time and wasn't able to finish the four M1 to M1 dofs that were left for the reduced Y damping, so we'll have to get those next week.
I also wasn't able to get in any measurements for SRM, but that's okay since we're not in a rush.
The LVEA has been swept, I unplugged an extension cords that were not connected to anything, and the genie lift near the west bay.
The test system for 4k Ethernet was moved from EY to EX, ending the test at EY.
The link was tested between the MSR and EX at 100G for a short itme. The link tested at 80G, the maximum the software can test.
The link is now being tested long-term at 25G. So far, no issues.
Earlier log entry about test at EY https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=87811
After ~1 week, no long RTTs, and no NIC reported error counters of any type (Attached is one sides output).
I inspected the PSL chiller lines external to the PSL enclosure this morning and found no issues or anomalies. This closes FAMIS 27545.
[Jenne, TJ, Elenna]
The last three locks saw a violin mode ring up (see 87933), which managed to saturate the DCPDs and cause a large amount of excess noise, see this screenshot of DARM near the time of lockloss. I am assuming that all of the extra noise is a result of some crazy nonlinearity due to the saturation DCPDs.
Jenne and I have concluded that the mode that rung up must be ETMX mode 1, which the violin mode monitor screen reports is at f = 511.2993 Hz. However, we have looked at GDS calib strain when the mode has rung up using both diaggui_test and with exported data in python at double precision with fft length of 4096 and 1024 seconds respectively and find that the mode is at 511.269 Hz, DTT screenshot, matplotlib screenshot.
Jenne has plotted both the damping filter and the monitor filters here. We can see that the damping filter is broad enough to cover this frequency, but the monitor filter is not. The violin mode guardian is supposed to track the modes via the monitor filters and disengage damping if the mode is ringing up. However, we think the monitor filter might be missing this frequency and this is why the damping did not turn off.
The attached timeseries also shows that the DCPDs were railed for some time, the suspension drive on ETMX L2 was very nearly saturated, and the monitor filter level was low overall, near 3.5. Jenne has included channel H1:FEC-88_ACCUM_OVERFLOW, maybe this is a useful channel for us to monitor.
I just want to add that I am being specific about how we measured the mode frequency above because we have been confused by insufficient precision before. I think we have sufficient precision to measure this frequency accurately, but the results show a shift of 0.02 Hz from the previously reported value.
Here is a follow up on the mode frequency that is very confusing! The ETMX mode 1 and mode 6 damping was disengaged about 20 minutes before our last lockloss. If I plot the strain spectrum in the 20 minutes before the damping was off and then the 20 minutes after, I see the expected ETMX mode 1 and 6 peaks at 511.18 Hz and 511.2993 Hz Hz. Only in the spectrum with the damping on do I see a large peak at 511.27 Hz. Jenne and I don't understand that yet, but are thinking about it. Plotted in diaggui_test with fft length 512 seconds, 2 averages with 50% overlap in each measurement.
The attached plot shows ETMX mode 1 and 6 damping ON in red and ETMX mode 1 and 6 damping OFF in blue.
However, the mode 1 filter is more likely to be the culprit, since it actually covers 511.27 Hz whereas the mode 6 filter does not, filter screenshot.
And, here is a version of the spectrum over time. Probably the 'true' ETMX mode 1 is the one closer to 511.3 Hz, which is consistent with the filters as well as Rahul's violin mode identification spreadsheet, and the 511.269 Hz that we've had trouble with today is something else that is outside the width of the monitor filter, but inside the width of the damping filter. As Elenna's alog shows, it's not really clear what the filters are picking up to drive at 511.269 Hz, but probably the damping filter was set up for 511.3 Hz and so when being applied to something at 511.269 Hz it just feeds nonsense.
In the attachment, I show strain spectra from 3 different times when the alog has mentioned violin modes at around 511 Hz. Green is today (after we were saturating, hence the elevated background), brown is this Oct 2025, and pink is Aug 2023. All of the times have a small peak at 511.302 Hz (which is not so far from the ETMX mode1 monitor and damping filter central frequecy of 511.299 Hz), so that's probably the true violin mode. Oct and Nov have also this much larger peak at 511.269 Hz, which is this new confusing peak. I haven't looked at any times other than these 3, so it's possible that the 511.269 Hz has come and gone before Oct 2025.
Also shown is the ETMX mode 1 monitor and damping filters, showing that as Elenna said the monitor filter seems to only catch the 'true' mode, while the damping filter is broad enough for both of these frequencies.
I had to do this check a week ago, but no damage was observed at either end.
Closes FAMIS 27396. Last checked in alog 87787
Plots look fine compared to last week but BSC High-Freq noise is elevated for these sensors:
ITMX_ST1_CPSINF_H1
ITMX_ST1_CPSINF_V1
ITMX_ST2_CPSINF_V1
Note - it is Tues Maint. so there are people in the LVEA.
There was a 7.5Hz peak in TJ's last-week check that is now gone. It was most prominent in HAM1 it seems.
Pdf Attached.
Tue Nov 04 10:05:35 2025 INFO: Fill completed in 5min 31secs
Gerardo confirmed a good fill curbside.
Randy and I installed new CR ceiling.
Betsy had a local company fabricate a C3 ceiling for our Mega Cleanroom. This ceiling has velcro opening to allow access for Septum removal. Opening extends to end of CR opening on the -X side and ends just short of the +X opening.
I've removed the Misaligned states and their associated edges for the IMs and MC1 nodes to avoid a similar mishap from last week (alog87793) of going up to 60W but misaliging optics that should not be moved at that power.
To do this I needed to make h1 versions of these nodes. Most other sus nodes are common, and these do use the common SUS.py file, but we redefine the edges and removed the misaligned and misaligning states.
Sheila, TJ
We also added the OMs, OPO, and OFI to the list. This brings the total list of sus nodes without misaligned states to:
The quarterly maintenance of Chiller 3 and pump at the Corner Station has been done. Additionally, all chillers site-wide have been rotated.
TITLE: 11/04 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 8mph Gusts, 5mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.29 μm/s
QUICK SUMMARY: Violin modes are very rung up, although our violin monitors dont agree with that. Our range has been very low for the past 2 hours, as if the squeezer isn't squeezing. While the magnetic injections are running right now, I don't think they are getting anything useful. Still trying to figure out what's going on.
Maintenance day today.
Looks like this happened to Ryan C last night as well - alog87930. I did just as he did and turned off the damping to violin ETMX modes 1&6, and the saturations went away and DARM looked better. The 500Hz line in DARM is still very elevated, but the harmonics are much lower and the DCPDs are no longer saturating.
Now that the gains are off, the monitors are making more sense for those modes. They immediately went up when the gain was turned off.
SUS in lock charge is running and should be good, at least for the latter half of the measurements.
I've set the gain of ETMX mode 1 to zero in lscparams for now.
Workstations were updated. This was an OS packages update. Conda packages were not updated.
TITLE: 11/04 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Oli
SHIFT SUMMARY: One lockloss, we are relocking at MAX_POWER.
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 23:50 | CAL | Tony | PCAL lab | LOCAL | Prep for end station meas tomorrow | 00:35 |
| 00:49 | CAL | Rick | Receiving | N | Pick up PSL parts | 01:25 |
| 00:52 | OPS | Ryan | Optics lab | N | Check on dust monitor | 00:58 |
03:45 UTC Something started to ring up in the DCPDs and the 500Hz line looked large on DARM. None of the vioins were ringing up though, I eventually found that both ETMY and ETMX (mostly ETMX) mode1/6's drive was ringing up and once I turned off the damping the DCPDs came back down and so did the line on DARM. (tagging SUS). I then put the nominal gain back into ETMX mode6 and it started to damp back down.
04:03 UTC We dropped observing, I brought us to Hi gain ASC as a semi large earthquake from Eastern Russia was hitting us (6.0)
04:19 UTC lockloss from the Earthquake
04:55 UTC MC2 M3 tripped as the IMC was trying to relock after a lockloss from FIND_IR, a look at some of the OSEMs
04:56 UTC IA, after INPUT_ALIGN it took the IMC 6 minutes to relock itself
J. Kissel
Gathered H1SUSPRM M3, M2, and M1 Drive to M1 Response TFs to inform the "drive" models for a future H1SUSPRM estimator. I'll post the locations / file names in the comments. Here in the main entry, I discuss the state of the control system for H1 SUS PRM so we understand with how much salt would should take these measurements.
Executive summary :: there are some side quests we can launch -- especially on the actuation side of this suspension -- if we think that these measurements reveal "way too much cross coupling for an estimator to work." The first things I'd attack would be
- the frequency-dependent and scalar gain differences *between* the nominal low noise state of the coil drivers and the state we need to characterize the suspension.
- the very old coil balancing, which was done *without* first compensating for any frequency-dependent gain differences in the channels at the frequency used to balance the coils (see LHO:9453 for measurement technique.)
Here's the detailed summary of all the relevant things for these measurements:
- The suspension was ALIGNED, with alignment offsets ON, with slider values (P,Y) = (-1629.783, -59.868) ["urad"]
:: ALIGNED is needed (rather than just DAMPED [where the alignment sliders are OFF] or MISALIGNED where extra large alignment offsets are ON; per discussion of how the alignment impacts the calibration in LHO:87102)
:: the usual caveats about the slider calibration, which is still using the [DAC ct / "urad"] gains from LHO:4563).
- The M1 damping loop were converted to Level 2.0 loop shaping in Jan 2023; LHO:66859, nominally designed to have an EPICs gain of -1.0. However in Aug 2023, the EPICs gains were lowered to -0.5, and have been that way for most of O4, and remain that way now. For all of these measurements, I set the L, P and Y gains to -0.1; the "20% of nominal" gain mantra we've used for the HLTS estimators. I also gathered *almost* all the measurements again with only the Y gain at -0.1, but ran out of time to complete that set for comparison.
- Even though it was maintenance day, when we typically turn site-wide sensor correction OFF, I manually turned ON sensor correction for ISI HAM2 to get better coherence below 1 Hz (using instructions in LHO:87790)
- The M3 L to M3 P filter (and gain) in the M3 DRIVEALIGN frequency-dependent matrix is OFF, per LHO:87523.
- There are (M3 P to M3 L) = 1.7 and (M3 Y to M3 L) = 0.52 scalar gains ON in to off-diagonal elements of the M3 DRIVEALIGN matrix whose purpose is change the center of P and Y actuation to be around where the IFO's beam spot typically is.
- There is a set of M1 L to M1 P filters, "M1L_M3P" and "invM1P_M3P," in the M1 DRIVEALIGN matrix, with a EPICs gain of -1. I think these came from LHO:42549. The measurements I took aren't impacted by this, as I drove from the M1 TEST bank which does not send excitation through the DRIVEALIGN Matrix. HOWEVER, we'll definitely need to consider this when we model the ISC drive which *does* go through the M1 DRIVEALIGN matrix.
- All M1, M2, and M3 stages of OSEM PDs sat amp whitening filters have been upgraded with ECR E2400330's filter design, and compensated accordingly.
:: M1 stage LHO:85463
:: M2 & M3 stages LHO:87103
- All M1, M2, and M3 stages of OSEM PDs have been calibrated via the ISI GS13s, and calibrated in the ALIGNED state (LHO:87231)
- In order to get decent coherence over the band of interest for the M3, M2, and M1 drives, I had to drive the suspension actuators in their highest range state, which is different from the state the IFO usually needs.
:: M1 = State 1 "LP OFF" (a Triple TOP Driver)
:: M2 = State 2 "Acq ON, LP OFF" (An ECR E1400369 Triple Acquisition Driver "TACQ" modified for an extra 10x actuation strength. Modified in Sep 2013 LHO:7630)
:: M3 = State 2 "Acq ON, LP OFF" (An ECR E1400369 Triple Acquisition Driver "TACQ" modified for an extra 10x actuation strength. Modified in Sep 2014 LHO:13956)
:: The nominal state for the switches are M1 = State 2 "LP ON," M2 = M3 = State 3 "ACQ OFF, LP ON."
- No actuator channels have had any precise compensation for their coil driver's frequency response in any state.
:: M1 state 1 channels are all compensated with (z:p) = (0.9 : 30.9996) Hz
:: M2 state 2 channels are all compensated with (z:p) = (64.9966 : 13) Hz
:: M3 state 2 channels are all compensated with (z:p) = (64.9966 : 13) Hz
- There are scalar "coil balancing" non-unity magnitude gains on each of the M2 and M3 stage channels, but it's the same values that have been in play since Jan 2014 (LHO:9419; so, after the M2 TACQ driver mod, but before the M3 TACQ driver mod). There is no coil balancing gains on the M1 stage, they're all either +/- 1.0.
Here's the complete data set with L, P, and Y damping loop gains set to -0.1, with the T, V, and R gains at -0.5.
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/
2025-10-28_H1SUSPRM_M1toM1_CDState1_M1LPYDampingGain0p1_WhiteNoise_L_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M1toM1_CDState1_M1LPYDampingGain0p1_WhiteNoise_P_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M1toM1_CDState1_M1LPYDampingGain0p1_WhiteNoise_R_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M1toM1_CDState1_M1LPYDampingGain0p1_WhiteNoise_T_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M1toM1_CDState1_M1LPYDampingGain0p1_WhiteNoise_V_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M1toM1_CDState1_M1LPYDampingGain0p1_WhiteNoise_Y_0p02to50Hz.xml
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM2/Data/
2025-10-28_H1SUSPRM_M2toM1_CDState2_M1LPYDampingGain0p1_WhiteNoise_L_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M2toM1_CDState2_M1LPYDampingGain0p1_WhiteNoise_P_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M2toM1_CDState2_M1LPYDampingGain0p1_WhiteNoise_Y_0p02to50Hz.xml
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM3/Data/
2025-10-28_H1SUSPRM_M3toM1_CDState2_M1LPYDampingGain0p1_WhiteNoise_L_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M3toM1_CDState2_M1LPYDampingGain0p1_WhiteNoise_P_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M3toM1_CDState2_M1LPYDampingGain0p1_WhiteNoise_Y_0p02to50Hz.xml
Here's the almost entirely complete data set for *only* the Y damping loop gain set to -0.1, and L, T, V, R, P set to -0.5.
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/
2025-10-28_H1SUSPRM_M1toM1_CDState1_M1YawDampingGain0p1_WhiteNoise_L_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M1toM1_CDState1_M1YawDampingGain0p1_WhiteNoise_T_0p02to50Hz.xml
[did not get V]
[did not get R]
[did not get P]
[did not get Y]
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM2/Data/
2025-10-28_H1SUSPRM_M2toM1_CDState2_M1YawDampingGain0p1_WhiteNoise_L_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M2toM1_CDState2_M1YawDampingGain0p1_WhiteNoise_P_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M2toM1_CDState2_M1YawDampingGain0p1_WhiteNoise_Y_0p02to50Hz.xml
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM3/Data/
2025-10-28_H1SUSPRM_M3toM1_CDState2_M1YawDampingGain0p1_WhiteNoise_L_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M3toM1_CDState2_M1YawDampingGain0p1_WhiteNoise_P_0p02to50Hz.xml
2025-10-28_H1SUSPRM_M3toM1_CDState2_M1YawDampingGain0p1_WhiteNoise_Y_0p02to50Hz.xml
Took some more of the meaurements for PRM estimator here: 87950
Those four M1 to M1 with DAMP Y at 20% for V R P and Y are still needed
Here's the list of estimator measurements for PRM: 88063
complete PRM measurements: 88063