I took a look at the YAW angle for the HAM HEPIs associated with PR2 (incorrect by me) (HAM2), SR2 (HAM4), and SR3 (HAM5) based on this previous alog83705. I believe the IPS channel units are in nrad, so the largest yaw angle I see is on HAM2 with 1800 nrad or 1.80 urad, HAM2 and 4 are different by ~ 1.10 urad.
I added on the RESIDUALMON channels at Jims recommendation which directly tells you the error from the reference location.
Here's HAM3, 0.392 urad as seen by HEPI
Wed Apr 30 10:11:57 2025 INFO: Fill completed in 11min 53secs
Gerardo confirmed a good fill curbside.
TJ was unable to run the 'guardutil archive-clone ...' command due to permission issues. We looked at it, and the relevant error message was: fatal: failed to copy file to 'IMC_LOCK/.git/objects/2f/826f205c25a6189503d831106e2dd97d7a39dc': Permission denied' Tracing through paths, this was in /guardian/archive/IMC_LOCK/.git/.... The permissions + ownership of that file where 0600 (rw for the user), everything else was 0444 (r only for everyone) and owned by guardian:controls. Changing the permissions to 0444 fixed things. We did a search from the guardian machine for other files with that problem and found 24 files under /srv/guardian/archive, so we reset the permissions to clear up future problems. Find command for searching: find . -type f -perm 600 Command for updating: find . -type f -perm 600 | xargs chmod 0444 I suspect this is a umask issue that someone had a umask of 077 set when they did an archive request.
Morning dry air skid checks, water pump, kobelco, drying towers all nominal.
Dew point measurement at HAM1 , approx. -41C
TITLE: 04/30 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_ENV state: MAINTENANCE
Wind: 4mph Gusts, 2mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY:
The planned work today includes:
PCal team took PS4 to EY again today for the first every April measurement of End Y! Previous Aprils' measurements have apparently all been EndX.
Following T1500062V-18, Nothing really out of the ordinary except I put RX here instead of bolting to the side of the breadboard like I normally do, to see if that has any effect on the load balancing of the RX optical bread board or any impact to the overall measurement during the time when WS was in the RX side.
Beam spot
python3 generate_measurement_data.py --
WS "PS4" --date "2025-03-24"
Reading in config file from python file in scripts
../../../Common/O4PSparams.yaml
PS4 rho, kappa, u_rel on 2025-03-24 corrected to ES temperature 299.4 K :
-4.701550919294612 -0.0002694340454223 4.0632996079052654e-05
Copying the scripts into tD directory...
Connected to nds.ligo-wa.caltech.edu
martel run
reading data at start_time: 1429997850
reading data at start_time: 1429998230
reading data at start_time: 1429998550
reading data at start_time: 1429998990
reading data at start_time: 1429999330
reading data at start_time: 1429999640
reading data at start_time: 1430000100
reading data at start_time: 1430000600
reading data at start_time: 1430000920
Ratios: -0.5349326615859125 -0.5432025342228874
writing nds2 data to files
finishing writing
Background Values:
bg1 = 17.394679; Background of TX when WS is at TX
bg2 = 4.438216; Background of WS when WS is at TX
bg3 = 17.479506; Background of TX when WS is at RX
bg4 = 4.610581; Background of WS when WS is at RX
bg5 = 17.487987; Background of TX
bg6 = -0.718008; Background of RX
The uncertainty reported below are Relative Standard Deviation in percent
Intermediate Ratios
RatioWS_TX_it = -0.534933;
RatioWS_TX_ot = -0.543203;
RatioWS_TX_ir = -0.527567;
RatioWS_TX_or = -0.535369;
RatioWS_TX_it_unc = 0.055737;
RatioWS_TX_ot_unc = 0.055881;
RatioWS_TX_ir_unc = 0.056510;
RatioWS_TX_or_unc = 0.055480;
Optical Efficiency
OE_Inner_beam = 0.985953;
OE_Outer_beam = 0.985408;
Weighted_Optical_Efficiency = 0.985681;
OE_Inner_beam_unc = 0.042868;
OE_Outer_beam_unc = 0.044311;
Weighted_Optical_Efficiency_unc = 0.061653;
Martel Voltage fit:
Gradient = 1637.860873;
Intercept = 0.156301;
Power Imbalance = 0.984776;
Endstation Power sensors to WS ratios::
Ratio_WS_TX = -0.927527;
Ratio_WS_RX = -1.383600;
Ratio_WS_TX_unc = 0.045873;
Ratio_WS_RX_unc = 0.042755;
=============================================================
============= Values for Force Coefficients =================
=============================================================
Key Pcal Values :
GS = -5.135100; Gold Standard Value in (V/W)
WS = -4.701551; Working Standard Value
costheta = 0.988362; Angle of incidence
c = 299792458.000000; Speed of Light
End Station Values :
TXWS = -0.927527; Tx to WS Rel responsivity (V/V)
sigma_TXWS = 0.000425; Uncertainity of Tx to WS Rel responsivity (V/V)
RXWS = -1.383600; Rx to WS Rel responsivity (V/V)
sigma_RXWS = 0.000592; Uncertainity of Rx to WS Rel responsivity (V/V)
e = 0.985681; Optical Efficiency
sigma_e = 0.000608; Uncertainity in Optical Efficiency
Martel Voltage fit :
Martel_gradient = 1637.860873; Martel to output channel (C/V)
Martel_intercept = 0.156301; Intercept of fit of Martel to output (C/V)
Power Loss Apportion :
beta = 0.998844; Ratio between input and output (Beta)
E_T = 0.992240; TX Optical efficiency
sigma_E_T = 0.000306; Uncertainity in TX Optical efficiency
E_R = 0.993389; RX Optical Efficiency
sigma_E_R = 0.000306; Uncertainity in RX Optical efficiency
Force Coefficients :
FC_TxPD = 9.160033e-13; TxPD Force Coefficient
FC_RxPD = 6.229843e-13; RxPD Force Coefficient
sigma_FC_TxPD = 5.093831e-16; TxPD Force Coefficient
sigma_FC_RxPD = 3.305931e-16; RxPD Force Coefficient
data written to ../../measurements/LHO_EndY/tD20250429/
This adventure was brought to you by, Francisco L & Tony S.
Calibration is currently regenerating the O4b uncertainty budgets. Due to a missed change to the ETMX UIM suspension filters, which was found in LHO alog 82804, and then fixed only on Feb 27, 2025 (see LHO alog 83088), we need to add a correction TF to be included in the uncertainty budgets. I attach a graph of that correction TF (corrected model / original model) and the text file needed for that correction. We will be using correction TF in all our uncertainty budgets for O4b, and up to Feb 27, 2025 around 20:00 UTC, or GPS 1424721618 for O4c.
Since after the July-Aug break, the low frequency response got closer to unity due to other mixed effects, we only apply the TF correction in uncertainty calculation before the break:
From 1396796418 = Wed Apr 10 15:00:00 UTC 2024 to 1404864018 = Sat Jul 13 00:00:00 UTC 2024
After the break, we leave it to GPflow to take care of the unmodeled residual using monitoring data.
Although the low-frequency response got closer to unity at later times, we found that GPflow still could not sufficiently capture the unmodeled residual.
We now determine that the above TF correction should be applied thoughout O4b at LHO.
Summary: This work aims to understand the shape of the DARM sensing function as affected by mode mismatches and input power. It seems that the mismatches affect the detuning of the SRCL DOF, that is it affects the locking point, but not the shape of the DARM sensing funciton. However, the input power, which causes radiation pressure, has a bigger effect on it. If I do not include QUADsuspension option, then I get a flat response function regardless of the mismatch or the input power.
For the past week I have been studying the effect of SCRL DOF detuning (or sometimes I refer to it as offset) on the DARM readout using FINESSE.
In FINESSE, that is done by changing SRCL.DC, and looking at the transfer function from DARM.AC.i to AS.DC.o
The reason being to understand the measurement of the sensing function taken and show here.
My system include up to maxtem=4, QUADsuspensions, InitialLock > DARM_RF_to_DC.
Before we start doing that, let’s understand the error signal of SRCL DOF. This is read at POP45_I channel. The ideal tuning of this loop is SRCL.DC=90, that is the case where the carrier beam is anti-resonant in the SRC, while the sidebands are. At that detuning, the error signal is 0. However, since we do not have a perfect model, there is some mode mismatch between SRC and the arm cavities. This will inject some higher order modes carrier and sidebands into the SRC and that changes the locking point. Using the default cold state LHO model, the detuning at which the error signal is 0 is SRCL.DC=-90.4643
This is shown in the plot below (Error_signals_vs_detuning.pdf)
Let’s look at this offset as the mode mismatch changes. I adjust ITMlenses focal lengths and measure the mismatch between SRX and XARM cavities, and SRY and YARM cavities. I also have an amplitude detector to measure the power in the HG20/02 modes at the AS port, which might be partially resonant in the SRC due to its low finesse. (Detuning_vs_SRC_ARMS_mismatch.pdf)
On the x-axis is the SRY to YARM mismatch percentage, and on the y-axis is the SRX to XARM mismatch percentage. I’m not sure why there is such a big difference of mismatches in the default cold state model, but the qualitative behavior is what we need here.
The colors represent SRCL.DC offset while the numbers on each cell represent the power in the 2nd high order mode in W.
We notice that as the SRY to YARM mismatch gets closer in magnitude to SRX to XARM mismatch the offset decreases and goes towards 90, and the power in the 2nd HOM also gets smaller, which suggests that the presence of these modes affects the offset, as we would expect(see also This old technical note)
I believe the reason that the HOM gets smaller as the mismatches get closer together can be imagined similar to what the Michelson interferometer does to the fundamental mode for HG20/02 modes that are at the same phase, they cancel each other out at the AS port.
Finally, let us look at the DARM sensing function, which is our goal of this investigation.
We would expect the sensing function to be flat starting around ~7Hz and keep like that until it starts rolling off at ~ 200 Hz.
Now, here is the surprise, I plotted the response function in the default case where there is mismatch between SRC and the arm cavities, and then I changed ITMXlens focal lengths to get almost perfect mode matching, and it turns out that they are not that different, as seen below (Comparison_with_different_MM.pdf)
What seems to be affecting the response function is not the mode matching (even though it affects the locking point), but the input power value. If I reduce the input power to 1W instead of 60W that is used in the comparison plot, I get the following response function (yes, I checked the error signal zero point is still at 90.464 (1W_DARM_readout_vs_detuning.pdf)
And so, from this investigation, it seems that the input power affects the response function more than the mode matching, while the mode matching affects the locking point.
Next, I reset the model and I started changing the reflectivity of the SRM, narrowing the linewidth and increasing the finesse of the cavity. As the finesse increases, the detuning goes towards 90 degrees. This could be from reducing the effect of the HOM on the fundamental mode in SRCL. (SRM_reflectivity.pdf)
Sheila, Keita, Elenna, Camilla, Jason, TJ WP# 12491.
With MC2 misaligned, TJ transitioned to laser hazard and opened the PSL IR light pipe.
Keita checked that the MC REFL path on IOT2L was aligned-ish. We had a beam on the LSC REFL DC and on WFS A. Not much on WFS B. Sheila moved the input PSL PZT to improve pointing onto WFS A.
We were getting flashes on MC2 trans so went to the control room where Sheila zero’ed H1:IMC-WFS gain (was 0.04) and continued to move PSL PZT to maximize MC2 trans flashes (could also see flashes on IM4 trans).
Once these flashes were maximized, Sheila tried to lock with the guardian (which automatically sets gains and thresholds based on input power). Locked but didn’t look great. Sheila and Keita edited the IMC_power_adjust_fuc() of ISC_libary.py so nothing is done when the PSL input power < 1W. IMC then locked great.
During the IMC locking, we had some troubleshooting here as we kept getting “PMC unlocked” notification taking IMC_LOCK to FAULT. Jason explained this could get it getting to the end of its range and while it swaps to the other side of its lock might trigger the notification, even though we could not see it on ndscope. We also had the FSS unlock and the autolocker not able to relook. Jason took PSL FSS common and fast gains to zero, let it settle then brought common and then Fast gains slowly back. This happened a once more where we also had to turn off /on the auto-locker to make it settled.
On IOT2L, everything (camera and diode) in the IMC trans path was fine, left as is. In the IMC REFL path, the beam was not centered on the high power beam dump (maybe wasn't originally) so we moved IO_MCR_M3. We then checked we were on the plateau of the the LSC diode with IO_MCR_BS1 and checked we weren’t near the edge of the TRIG diode. We moved the IO_MCR_BD6 beam dump so it was centered on the beam. We moved IO_MCR_BS2 and BS3 to center the beams on WFS A and B. Sheila moved IO_MCR_M12 up to get MC TRANS on the GiGe camera. Everything on IOT2L is now aligned.
Checked in-vac and in-air powers are correct-ish by comparing them to 2W IMC locked/ unlocked. Sheila and Elenna locked IMC with WFS centering servos back on and offloaded the WFS.
As Ibrahim checked yesterday 84153, the IMs are a little different but Elenna checked the beam centering on IM4 trans is close to when we were locked: P was 0.24 now 0.2, Yaw was -0.08 now -0.13.
Keita restored SR2, SR3, BS, ITMX to a time 31 days ago when IFO was locked and could see the beam on the AS AIR camera.
We have left the IMC offline and PSL IR light pipe closed.
TITLE: 04/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: We had a few earthquakes roll through in the morning, 6.8 from south of New Zealand and a 4.8 from Puerto Rico. The LVEA is now in LAZER HAZARD.
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
14:20 | FAC | Kim & Nellie | LVEA | N | Tech clean, in at 14:20 | 15:25 |
15:35 | ISC | Betsy, Camilla | LVEA | N | Parts/tools search | 15:46 |
15:48 | FAC | Kim & Nellie | EndY, then X | N | Tech clean | 17:28 |
15:50 | SUS | Rahul, Betsy | LVEA | N | RM2 work | 16:27 |
15:54 | FAC | Eric | LVEA | N | Help with clean room move, BSC8 | 17:22 |
15:55 | IAS | Jason | LVEA | N | Retreive FARO | 15:58 |
15:55 | VAC | Jordan | LVEA | N | Purge air checks | 16:04 |
15:56 | FAC | Tyler | LVEA | N | Cleanroom move (BSC8), scissor lifts, Craning | 17:49 |
16:10 | VAC | Gerardo | LVEA | N | Join HAM1 crew | 16:27 |
16:51 | EE | Fil, Ken | LVEA | N -> Y | HAM4/5 cable tray work | 21:36 |
17:11 | PEM | Sabby | Arms, site | N | Collect flags around site | 20:02 |
17:12 | VAC | Gerardo | LVEA | N | Take septum cover off | 18:02 |
17:13 | ISC | Camilla | LVEA | N | Help with septum covers | 18:33 |
17:16 | EE | Marc | LVEA | N | Check Chassis, check upgrades | 17:36 |
17:20 | VAC | Jordan | MidX | N | LN2 pump | 17:47 |
17:36 | EE | Marc | EX, EY, MY | n | Looking for parts + grabbing serial numbers | 18:51 |
17:37 | FAC | Eric | Fire pump room | n | Running fire pumps | 18:05 |
17:46 | SUS | Rahul | LVEA | N | HAM1 work, move curtains | 18:22 |
17:47 | Mike | LVEA | N | Check out/in with HAM1 | 18:35 | |
17:54 | FAC | Christina | Receiving | N | Moving stuff and trash | 19:39 |
17:55 | ISC | TJ | LVEA | N | Look for tubing | 18:41 |
18:00 | FAC | Kim & Nellie | LVEA | N | Tech clean, Kim out at 18:42 | 19:10 |
18:18 | ISC | Betsy & RyanS | LVEA | n | Inpect CR and boxes | 18:33 |
18:27 | ISC | Ibrahim | LVEA | N | Join Betsy and RyanS | 18:33 |
18:49 | FIT | Ibrahim | Yarm | N | Brisk walk | 19:52 |
19:31 | EE | Ken | LVEA | N -> Y | Roll up high bay door | 20:36 |
19:20 | CAL | Tony | PCAL lab | N | PCAL work, in at 19:20 | 19:40 |
19:49 | OPS | TJ | LVEA | N -> Y | Hazard transition | 19:56 |
19:58 | ISC | Keita | LVEA | Y | IOTL2 work | 20:44 |
19:59 | ISC | Camilla | LVEA | Y | Join Keita | 20:37 |
20:02 | FAC | Tyler | LVEA | Y | Bring bangbox from lVEA to staging | 20:11 |
20:02 | ISC | Sheila | LVEA | Y | Join IOTL2 crew | 20:36 |
18:15 | FAC | Randy, Jim, Mitch | EndY | N | Wind fence | 21:24 |
20:43 | CAL | Tony, Francisco | EndY | Y | End station measurement | 22:49 |
21:52 | ISC | Elenna, Sheila, Camilla | LVEA | Y | HAM1 ISC work | 23:45 |
21:59 | VAC | Jordan | LVEA | Y | Grab parts | 22:11 |
22:08 | VAC | Gerardo | LVEA | Y | See whats needed to decomis HAM2 oplev | 22:16 |
22:24 | SEI | Jim | LVEA | Y | Look for parts and such, klapton | 22:37 |
22:38 | SEI | Jim | Ends, Mids | N | Parts search | Ongoing |
22:49 | CAL | Tony | PCAL lab | LOCAL | FInish end station measurement | Ongoing |
22:53 | CAL | Rick, Dripta | PCAL lab | LOCAL | Checks | Ongoing |
22:53 | SAF | Richard | LVEA | Y | Safety checks | 23:00 |
Some of the work today includes:
Continued from LHO alog 84128.
RM1 (Tip Tilt suspension)
Last week Daniel and I replaced the original TT bosem cable (with a new 25in long, D2100049 S/N 2200358) since the original cable was having issues with grounding. However, Betsy informed us that the new cable might have pin 1 missing (and should be sent back to CIT for repair). I inspected the cable in-chamber and found pin1 missing.
Hence, I replaced the 25in long D2100049 S/N 2200358 (missing pin 1) with 54in long D2100049 s/n S2100426 cable. However, the ground loop issues has now returned (shorting with the chamber itself) and it looks like the culprit is not the cable but the bosem itself (despite having kapton tape for shielding, clearly its not enough). I am still considering to slide a kapton sheet underneath RM1.
Also, I measured the Open light counts of all four bosems for RM1 and they are listed below,
OLC for RM1 bosems | offsets | gain |
UL = 21613 | -10806 | 1.38 |
LL = 22400 | -11200 | 1.33 |
UR = 12380 | -6190 | 2.42 |
LR = 16473 | -8236 | 1.82 |
RM2 (Tip Tilt suspension)
Kissel, Betsy, Rahul
Here, Jeff suspects that the bosem magnet polarity is incorrect (i.e is not as per E1400316) which was recorded in his LHO alog from 2018. To verify Jeff's claim we went back into the chamber to check the polarity of RM2 magnets. However we faced two problems over here. At first I looked into the Tip Tilt assembly drawing and then the Tip Tilt PEEK flags in Triples lab to locate the magnet inside the flag. It turns out that the magnet is buried deep inside the PEEK flag, such that my polarity tester cannot detect its presence. Hence, I took another strong magnet to check if its pulling or repelling it - which worked fine. The second problem we faced was that the PEEK flag are a very tight fit inside the TT mirror holder (in-chamber) and despite our best efforts (both Betsy and I tried unscrewing it) we couldn't remove it for checking. Hence, we were unsuccessful in measuring the magnet polarity and after some discussion we decided to move ahead and reset RM2 (digitally) to how it was before this vent. Jeff will file an FRS ticket regarding this issue.
The Open light counts for RM2 is given below,
OLC for RM2 bosems | offsets | gain |
UL = 15800 | -7900 | 1.89 |
LL = 20048 | -10024 | 1.49 |
UR = 16753 | -8376 | 1.79 |
LR = 21173 | -10586 | 1.41 |
I have accepted the SDFs for both RM1 and RM2 and three screenshots are attached below.
RM1 still needs a cable table bracket.
The first set of transfer function measurement results for both RM1 and RM2 are shown in the attachments below (screenshots for all three L, P, Y degrees of freedom). I am not happy with the coherence in RM1 and still working on improving it. I am also planning on taking osem spectra to analyze the noise levels in bosems (considering that their OLC have degraded considerably).
RM1 Transfer function templates:-
/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/RM1/SAGM1/Data
2025-04-29_2330_H1SUSRM1_M1_WhiteNoise_L_0p01to50Hz.xml
2025-04-29_2330_H1SUSRM1_M1_WhiteNoise_P_0p01to50Hz.xml
2025-04-29_2330_H1SUSRM1_M1_WhiteNoise_Y_0p01to50Hz.xml
RM2 Transfer function templates:-
/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/RM2/SAGM1/Data
2025-04-29_2300_H1SUSRM2_M1_WhiteNoise_L_0p01to50Hz.xml
2025-04-29_2300_H1SUSRM2_M1_WhiteNoise_P_0p01to50Hz.xml
2025-04-29_2300_H1SUSRM2_M1_WhiteNoise_Y_0p01to50Hz.xml
Here's an ndscope of April 24th, the first day that we put RM1 and RM2 back in, to hopefully make stuff slightly less confusing.
After installation, we had checked the open light values for RM1 and updated the OFFSETs (green) before realizing that the ADC count signs on (almost) all the OSEMs had been flipped to positive, whereas previously they had been negative (a result of changing the In-Air to SatAmp cable for both RMs: 84027). We flipped them after realizing this, which then fixed the OSEMINF OUT values (cyan). Throughout this, we also had just left RM1's UL OSEM as it was since it was behaving strangely and was the only OSEM to still be reading in negative ADC counts. At the point of the pink cursor, troubleshooting was started for RM1 UL.
Some additions to this aLOG: - D2100049 is an in-vac quadrapus cable. So the swaps that he's talking about in the above aLOG are *seperate* from the in-air cable swap for RM1 and RM2 that's discussed in LHO:84027 - It's LHO:40853 (indeed, Mar 2018) where I identify that RM2 alone, out of all the remaining tip-tilts in the IFO has it's magnet polarities flipped. I had guessed this was true because the damping loops required a different sign that the other tip-tilts if I had the COILOUTF settings per T1200015 convention.
Edgard, Oli.
Follow up to the work summarized in 84012 and 84041.
TL;DR: Oli tested the estimator on Friday and found the ISI state affects the stability of the scheme, plus a gain error in my fits from 84041. The two issues were corrected and the intended estimator drives look normal (promising, even) now. The official test will happen later, depending on HAM1 suspension work.
____
Oli tested the OSEM estimator damping on SR3 on Friday and immediately found two issues to debug:
1) [See first attachment] The ISI state for the first test that Oli ran was DAMPED. Since the estimator was created with the ISI in ISOLATED (and it is intended to be used in that state), the system went unstable. This issue is exacerbated by point 2) below. This means that we need to properly manage the interaction of the estimator with guardian and any watchdogs to ensure the estimator is never engaged if the ISI trips.
2) [See second attachment] There was a miscalibration of the fits I originally imported to the front-end. This resulted in large drives when using the estimator path. In the second figure, there are three conditions for the yaw damping of SR3:
( t < -6 min ) OSEM damping with gain of -0.1.
( -6 min< t < -2 min) OSEM damping with a gain of -0.5, split between the usual damping path and the estimator path.
( -2 min < t < 0 min) OSEM + Estimator damping.
The top left corner plot shows the observed motion from every path. It can be seen that M1_YAW_DAMP_EST_IN1 (the input to the estimator damping filters) is orders of magnitude larger than M1_DAMP_IN1 (the imput to the regular OSEM damping filters).
The issue was that I fit and exported the transfer functions in SI units, [m/m] for the suspoint to M1, and [m/N] for M1 to M1. I didn't export the calibration factors to convert to [um/nm] and [um/drive_cts], respectively.
____
I fixed this issue on Friday. Updated the files in /sus/trunk/HLTS/Common/FilterDesign/Estimator/ to add a calibration filter module to the two estimator paths (a factor of 0.001 for suspoint to M1, and 1.5404 for M1 to M1). The changes are current as of revision 12288 of the sus svn.
The third attachment shows the intended drives from the estimator and OSEM-only paths. They look similar enough that we believe the miscalibration issue has been resolved. For now we stand by until there is a chance to test the scheme again.
I've finished the set of test measurements for this latest set of filter files (where we now have the calibration filters in)
These tests were done with HAM5 in ISOLATED
Test 1: Baseline; classic damping w/ gain of Y to -0.1(I took this measurement after the other two tests)
start: 04/29/2025 19:22:05 UTC
end: 04/29/2025 20:31:00 UTC
Test 2: Classic damping w/ gain of Y to -0.1, OSEM Damp Y -0.4
start: 04/29/2025 17:16:00 UTC
end: 04/29/2025 18:18:00 UTC
Test 3: Classic damping w/ gain of Y to -0.1, EST Damp Y -0.4
start: 04/29/2025 18:18:05 UTC
end: 04/29/2025 19:22:00 UTC
Now that we have the calibration in, it looks like there is a decrease in the noise seen between damping with the osems vs using the estimator.
In the plot I've attached, the first half shows Test 2 and the second half shows Test 3
I analyzed the output of the tests for us to compare.
1) First attachment shows the damping of the Yaw modes as seen by the optical lever in SR3. We can see that the estimator is reducing the motion of the 2 Hz and 3 Hz frequency modes. This is most easily seen by flicking through pages 8-10 of the .pdf attached. The first mode's Q factor is higher than OSEM only damping at -0.5 gain, but it is lower than if we kept a -0.1 gain.
2) The second attachment shows that we get this by adding less noise at higher frequencies. From 5 Hz onwards, we have less drive going to the M1 Yaw actuators, which is a good sign. There is a weird bump around 5 Hz that I cannot explain. It could be an artifact of the complementary filters that I'm not understanding, or it could be an artifact of using a 16Hz channel to observe these transfer functions.
Considering that the fits were made on Friday while the chamber was being evacuated and that the suspension had not thermalized, I think this is a success. The Optical lever is seeing less motion in the 1-5 Hz band consistent with expectations (see, for example some of the error plots in 84004), with the exception of the 1Hz resonance. We expect this error to be mitigated by performing a fit with the suspension thermalized.
Some things of note:
- We could perform an "active" measurement of the estimator's performance by driving the ISI during the next round of measurements. We don't even have to use it in loop, just observe M1_YAW_EST_DAMP_IN1_DQ, and compare it with M1_DAMP_IN1_DQ.
The benefit would be to get a measurement of the 'goodness of fit' that we can use as part of a noise budget.
- We should investigate the 5 Hz 'bump' in the drive. While the total drive does not exceed the value for OSEM-only damping, I want to rule out the presence of any weird poles or zeros that could interact negatively with other loops.
Attached you can see a comparison between predicted and measured drives for two of the conditions of this test. The theoretical predictions are entirely made using the MATLAB model for the suspension and assume that the OSEM noise is the main contributor to the drive spectrum. Therefore, they are hand-fit to the correct scale, and they might miss effects related to the gain miscalibration of the SR3 OSEMs shown in the fit in 84041 [note that the gain of the ISI to M1 transfer function asymptotes to 0.75 OSEM m/ GS13 m, as opposed to 1 m/m].
In the figure we can see that the theoretical prediction for the OSEM-only damping (with a gain of -0.5) is fairly accurate at predicting the observed drive for this condition. The observed feature at 5 Hz is related to the shape of the controller, which is well captured by our model for the normal M1 damping loops (classic loop).
In the same figure, we can see that the expected estimator drive is similarly well captured (at least in shape) by the theoretical prediction. Unfortunately, we predict the controller-related peaking to be at 4 Hz instead of the observed 5 Hz. Brian and I are wary that it could mean we are sensitive to small changes in the plant. The leading hypothesis right now is that it is related to the phase loss we have in the M1 to M1 transfer function that is not captured by the model.
The next step is to test this hypothesis by using a semi-empirical model instead of a fully theoretical one.
We were able to explain the drive observed in the tests after accounting for two differences not included in the modelling:
1) The gain of the damping loop loaded into Foton is different from the most recent ones documented in the sus SVN:
sus/trunk/HLTS/Common/FilterDesign/MatFiles/dampingfilters_HLTS_H1SR3_20bitDACs_H1HAM5ISI_nosqrtLever_2022-10-31.mat
They differ by a factor of 28 or so, which does not seem consistent with a calibration error of any sort. But since it is not documented into the .mat files makes it difficult to analyze without ourtright having the filters currently in foton.
2) There was spurious factor of 12.3 on the measured M1 to M1 transfer function due to gains in the SR3_M1_TEST filter bank ( documented in 84259 ). This factor means that our SR3 M1 to M1 fit was wrong by the same factor, the real transfer function is 12 times smaller than the measured one, and in turn, than our fit.
After we account for those two erroneous factors, our expected drive matches the observed drive [see attached figure]. The low frequency discrepancy is entirely because we overestimate the OSEM sensor noise at low frequencies [see G2002065 for an HSTS example of the same thing]. Therefore, we have succeeded at modelling the observed drives, and can move on to trying the estimator for real.
_____
Next steps:
- Recalibrate the SR3 OSEMs (remembering to compensate the gain of the M1_DAMP and the estimator damping loops)
- Remeasure the ISI and M1 Yaw to M1 Yaw transfer functions
- Fit and try the estimator for real
I keep forgetting to reset the dust monitor alarm levels after IOC restarts so I wrote a little script to check all of the dust monitor alarms levels and reset them if needed based on E1600132. It does not reset the LVEA ones, it just notifies, as these ones alarm levels are sometimes modified.
The scripts is called check_dm_alarms_lvls.py and lives at /ligo/cds/userscripts/. I've also updated the wiki with this info.
I have added a call to this script to the aliased "check_dust_monitors_are_working" bash script that operators usually run at the beginning of the shift.
Some changes to the RM1/RM2/PM1:
All other things equal the local damping loops should have the correct sign now. Thic change will also require a sign change in the ASC centering servos.
"Yes, and..." - It makes sense to zero the ALIGNMENT offsets for RM1, RM2, and PM1. They're physically aligning the optics in chamber this week, so we don't want to get confused by having digital offsets driven out to the coils. - Daniel says "Changed the signs of the coil outputs for RM1 and RM2. This should account for the sign change of the OSEM voltages." Here, "the change in sign of the OSEM voltages" means the fixing of the "has been like that forever as far as we can tell" issue that the RM1 and RM2 OSEM PD sensor readback's ADC voltage had been negative when under light. The fix was in the in-air DB25 feedthru to satamp cable; see LHO:84027 and subsequent comment about the differences in satellite amplifiers. He acknowledges that this fix will disrupt the overall sign of the damping loops, so he just *picked* a place to flip the sign. He chose the COILOUTF banks, but . we use these banks to explicitly compensate for the magnet polarity, and . RM1 and RM2 have already confirmed to be different in this regard in Mar 2018; see LHO:40853 -- and in that aLOG we concluded it was RM2 that was abnormal because RM2 required a different damping loop gain than RM1, OM1, OM2, and OM3 when all *settings* were otherwise the same. . HOWEVER given that the OSEM sensor readback itself had a negative in it, I'm no longer convinced it's RM2 that's the problem. But at least we know they're different. . I tried to have Betsy/Rahul go in chamber to confirm magnet polarity but these HTTS magnets are particularly hard to get at / measure, given that they're buried within the flag and the PEEK flag can no longer be unscrewed from the aluminum optic holder; see LHO:84178 So, since we're left stuck not understanding the coil actuator magnet polarity, I *don't* want to fix the *sensor* sign here. We've reverted the above change of COILOUTF signs. They're now restored to $ caget H1:SUS-RM1_M1_COILOUTF_UL_GAIN H1:SUS-RM1_M1_COILOUTF_LL_GAIN H1:SUS-RM1_M1_COILOUTF_UR_GAIN H1:SUS-RM1_M1_COILOUTF_LR_GAIN H1:SUS-RM1_M1_COILOUTF_UL_GAIN 1 H1:SUS-RM1_M1_COILOUTF_LL_GAIN -1 H1:SUS-RM1_M1_COILOUTF_UR_GAIN -1 H1:SUS-RM1_M1_COILOUTF_LR_GAIN 1 $ caget H1:SUS-RM2_M1_COILOUTF_UL_GAIN H1:SUS-RM2_M1_COILOUTF_LL_GAIN H1:SUS-RM2_M1_COILOUTF_UR_GAIN H1:SUS-RM2_M1_COILOUTF_LR_GAIN H1:SUS-RM2_M1_COILOUTF_UL_GAIN -1 H1:SUS-RM2_M1_COILOUTF_LL_GAIN 1 H1:SUS-RM2_M1_COILOUTF_UR_GAIN 1 H1:SUS-RM2_M1_COILOUTF_LR_GAIN -1 - He's confirming our work on PM1 from LHO:83293 - 2025-04-29, Daniel has made the model changes in h1sushtts, but they've not yet been installed as this is a trivial top-level model change that has been there forever, and is blocked from reaching the DAC by just turning of the SUS-RM*_ISCINF_L bank inputs. - We'll re-address the damping loop signs once the dust settles with chamber work.
Fil Marc Daniel
We noticed that the photodiode pins of the in-air cable that connects to RM1 and RM2 were flipped. This will flip cathode and anode which will only matter if there is a bias applied.
Going thru the schematics it seems that with 1:1 wiring the PD anode and cathode are flipped compared to what is shown in Sat Amp D080276. I assume somebody noticed this and flipped the corresponding pins of the in-air cable to correct for it back in 2013. The polarity of the PD doesn't really matter, if there is no bias. We checked the RM sat amps and they have no bias.
If the Sat Amp PDs are connected as shown om D080276, the OSEM values will be negative. Indeed, the RMs had negative OSEM values as expected. However, all ZMs have positive values, since nobody bothered to flip the pins. We propose to no longer flip the PD pins for the RMs and work with positive OSEM values in the future.
J. Kissel First, supporting Daniel's findings that the RM1 and RM2 HTTS OSEM sensor readbacks have been incorrectly negative for ages, I attach a trend of the OSEM ADC input values (and OSEMINF OFFSETS and GAINs) back to 2017. Not said explicitly in the above aLOG -- Daniel / Fil / Marc installed fresh new DB25 Sat Amp to Vac Feedthru cables (D2100464) just after this aLOG as a part of cabling up the new signal chain for PM1. These cables are one-to-one pin-for-pin cables so it *should* have played no role in the sign of the sensors or how they're connected. However, it's now obvious that RM1 and RM2 have had the ADC input voltages as negative for a *very* long time. I reviewed the signal chains for the OSEM PDs; see G2500980. The RMs are using a US 8CH satamps D1002818 / D080276. I attach a screen-cap of page 4, which highlights that - UK 4CH satamps D0900900 / D0901284 use . a negative reverse bias configuration, with . anode connected to bias and cathode connected to the negative input of the TIA, and . an inverting differential amplifier stage - US 8CH satamps D1002818 / D080276 use . a positive reverse bias configuration, with . cathode connected to the bias and anode connected to the negative input of the TIA, and [hence the apparent "pin-flip" from the other two satamp types] . a non-inverting differential amplifier stage - US 4CH satamps D1900089 / D1900217use . a negative reverse bias configuration, with . cathode connected to the bias and anode connected to the negative input of the TIA, and . a non-inverting differential amplifier stage [hence the overall "sign flip" from the other two] I disagree with Daniel that "the polarity of the PD" i.e. how the anode and cathode are connected to the transimpedance amplifier. All versions of the PD pinout + SatAmp configure the system in a reverse bias, be it negative or positive. In these configurations, even in a zero bias configuration, photocurrent always flows from from cathode to anode as light impinges on the PD. So if the anode is hooked up to the negative input of the transimpedance amp (as in D1002818), that signal will have a different sign than if the cathode is hooked up to the negative input (as in D0900900 and D1900089). The RMs should have their *positive* bias from the D080276 circuit applied. In 2011, we'd agreed in G1100856 to jumper all OSEM satamps to the "L" position, a.k.a. the LIGO OSEM a.k.a. AOSEM position, which uses a bias voltage and is thus in photo conductive or pc mode. This is mostly because we wanted to not have to think about keeping track of which satamps are jumpered and which are not, but also because the BOSEM PD didn't mind have a bias, even though it was designed to have no bias. Given the "thought of 2nd to last, last, and never" history of the RMs as they traversed subsystem from ISC to SUS circa O1, moving from the ASC front-end to a SUS front-end circa O2, then never really appearing in wiring diagrams until O3, etc. it wouldn't surprise me if the RMs didn't get the memo to put the bias jumper in the "L" position jumpering pins 2 and 3. I disagree with Daniel: only the US 4CH satamp D1900089 / D1900217 should read negative with light on it. So, my guess is that that someone "in 2013" (i.e. during aLIGO install prior to O1) didn't understand these subtleties between the UK 4CH and US 8CH satamp, saw the "different from UK 4CH satamp" and tried fixing the pins of the in-air D25 from satamp to vacuum flange. Regardless, the new cable has cleared up the issue, and ADC voltage from RM1 and RM2 is now positive.