Jennie, Jordan, Camilla
We covered the REFL septum widow with the cover to protect it and then placed the HAM1 periscope on the table. Then removed the septum covers so that now that REFL, PSL and POP/ALS septum windows are uncovered and we can get beams though. Photo attached.
I was using the RF test input to test the response of the photodetectors in HAM1.
LSC-POP_A, LSC-REFL_A, LSC-REFL_B are working as expected after swapping the cables at the patch panel for Test-Out and RF1.
ASC-REFL_A was working as expected.
ASC-REFL_B showed no response.
ASC_POP_X looks like the RF cables may be switched.
Swapped the coax cables on POP-X and it is working as expected now.
We did flash light tests on all detectors and were able to observe DC shifts on all detectors. LSC REFL_A and POP_A were swapped. This is a wiring diagram error and the in-air d-subs were swapped at the vacuum feedthrough.
We measured the current draw of ASC REFL_A and REFL_B, they are very similar to each other and close to the values measured in the test procedure.
Still no RF transfer functions for REFL_B.
Thu May 01 10:14:06 2025 INFO: Fill completed in 14min 2secs
Jordan confimed a good fill curbside.
Morning dry air skid checks, water pump, kobelco, drying towers all nominal.
Dew point measurement at HAM1 , approx. -42C
The turbo on the YBM tripped as a result of the power glitch reported last night see alog 84217, leading to a slight pressure rise in the corner.
I closed the main gate valve at that turbo and restarted the scroll pump/backing turbo and main turbo. Once the turbo reached full speed and the intake pressure was lower than the main volume pressure I verified trip setpoints and re-opened the gate valve..
This was the only turbo station that tripped. Output tube/XBM & HAM6 turbos were all nominal.
Another site power glitch, caught by GC OSB UPS but not CDS MSR UPS. Seen by CS MAINSMON.
My house lights flickered around this time.
UPS email:
Date : 04/30/2025
Time : 21:39:31
Code : 0x0109
Warning - UPS: On battery power in response to an input power problem.
Jonathan, Dave:
I have added the new third framewriter (FW2) to DAQSTAT.
H1:DAQ-FW2_STATUS is now viewable in the DAQ section of the CDS Overview (see attached).
TITLE: 05/01 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, 3mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY:
Vent work today includes:
Dust monitor 5 could use a power cycle, same with the diode rooms dust monitor. The counts are stuck, I restarted the diode room dust monitor.
Keita, Elenna, Oli, Rahul, Camilla
Summary: Majority of REFL path optics are aligned. Need to beam profile and finish LSC and ASC REFL diode placement on this path and place/check all beam dumps.
This morning, Keita opened the light pipe, locked the IMC but couldn't see the beam as nicely as he did on AS_AIR yesterday. Since that time he had restored PR2 and PR3 to a time we were last locked. He reverted those changes as we could see the beam back at AS_AIR. Checked again IM4 trans QPD was the same as yesterday.
Additionally M16 was placed roughly in the correct position, all optics are now on HAM1 (apart from PM1) and the class-B pans are empty and packed up.
Left IMC locked.
Attaching a bunch of photos of the current alignment:
(I don't have the names of the optics on the SLED so I'm calling them by the order that the beam goes through them)
- Alignment from RM2 onto M5 (attachment1, attachment2)
- Coming from M5, through M6, and onto first lens on SLED (attachment3)
- Coming through first SLED lens onto second SLED lens (attachment4)
- Through SLED lenses and onto first steering mirror (attachment5, attachment6)
- Alignment onto SLED pico mirror (attachment7)
- Top view of pico showing that there is available range in both pitch and yaw (attachment8)
- Distance between L1 and front of LSC REFL A (L1 focal length is 222mm) (attachment9, attachment10)
- Distance from LSC REFL A to M18 (attachment11)
- Distance from LSC REFL B to M18 - needs to be moved closer (attachment12)
About REFL WFS sled:
Tagging for EPO
TITLE: 04/30 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: The vent work continues...
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
14:51 | FAC | Kim & Nellie | LVEA | Y | Tech clean | 15:54 |
15:21 | ISC | Camilla | LVEA | Y | Put up/prep hazard signs | 15:54 |
15:38 | VAC | Jordan | LVEA | Y | Purge air checks | 15:56 |
15:45 | ISC | Keita | LVEA | Y | Open PSL light pipe | 15:49 |
15:54 | FAC | Kim | MidX | N | Tech clean | 17:00 |
15:54 | VAC | Travis | MidX, EndX | N | Turbo monthly checks | 18:48 |
15:54 | FAC | Nellie | MidY | N | Tech clean | 16:58 |
16:11 | FAC | Jim, Mitch, Randy | EndY | N | Wind Fence work | 22:12 |
16:34 | ISC | Camilla, Keita, Elenna | LVEA | Y | HAM1 alignment work, Elenna out 1800UTC | 19:31 |
16:59 | VAC | Jordan | MidY | N | CP3 pump check | 17:17 |
17:01 | FAC | Kim | FCES | N | Tech clean | 17:38 |
17:27 | SAF | Richard | LVEA | Y | Safety checks | 17:44 |
17:48 | ISC | Oli | LVEA | Y | Join HAM1 alignment crew | 19:32 |
18:28 | VAC | Janos | LVEA | N | VAC checks | 19:09 |
18:49 | FIT | Ibrahim | Yarm | N | Walking | 19:42 |
20:32 | CAL | Tony | PCAL lab | LOCAL | Switch spheres | 21:47 |
20:35 | ISC | Camilla, Keita | LVEA | Y | HAM1 alignment | Ongoing |
20:38 | ISC | Oli | LVEA | Y | HAM1 work | Ongoing |
21:49 | VAC | Gerardo, Jordan | LVEA | Y | HAM6 gauge power cycle | 21:56 |
22:31 | VAC | Gerardo, Jordan | LVEA | Y | Trace a cable for a HAM6 gauge | 22:56 |
22:37 | CAL | Tony | PCAL Lab | LOCAL | Sphere swap, measurement | 23:11 |
22:56 | VAC | Jordan | MidY | N | CP3 pump check | 23:29 |
22:55 | OPS | TJ | Garb room | N | Grab something | 22:57 |
RM troubleshooting alog84204
EY wind fence continues
HAM1 alignment continues
Vacuum gauge work by HAM6
Following the work from yesterday post, 2 questions came up immediately. One, how much does the sensing function change with input power? We can plot it as a function of arms circulating power instead. Second, if the detuning is the same, but at different mode mismatches, do we get the same sensing function?
We can see the answer to the first question in this plot. These sensing functions are normalized to 100 Hz value. The ratio between the highest power and the lowest power sensing functions is plotted (dashed line) as well.
Before answering the second question, let’s look at the following scenario.
We lock the interferometer, get SRCL.DC to be -90.4643, then we change that detuning while locking. What happens to the PDH signal and the sensing function now?
Here I plotted the error signals as I change SRCL.DC detuning by ± 0.5 deg
And the DARM sensing at different detuning looks like this
So, we see that the sensing function significantly changes with detuning at a constant mismatch.
So, from here, let’s answer the 2nd question. What we will do is to change the mismatch then manually offset the detuning to be the same in both cases.
For that I look at 2 cases. The first case is the default case where there is a mismatch between SRC and ARM cavities with SRCL.DC = -90.4643 and I plot the sensing function. Now, when I change the radii of curvature of ITMX and ITMY - I get almost a perfect mode matching - SRCL.DC becomes ~ -90.004. Again, the question is, if I add an offset to make SRCL.DC = -90.4643, would I get the same sensing function as the first case, where SRCL.DC is -90.4643 due to the mismatch.
The answer turns out to be not entirely, but also it depends on the power as well.
So, I looked at 2 cases, the first with input power of 1W, in which both sensing functions are very similar to each other in behaviour (not magnitude). The normalized plot shows that, in addition it shows the ratio between both of them. This is shown in here
The 2nd case is with an input power of 60W. In this case, they are not as similar to each other anymore, though not so different either.
This is shown in here
To conclude the 2nd question: the sensing function is almost the same (depending on the power) at the same detuning regardless of the mismatch (in the low mismatch limit < 2%)
Jim, RyanC
We noticed that the oplev damping values seemed pretty large, so we turned off the output for the OLDAMP. The noise increase started the morning of the 1st which makes sense as it's when the vent started.
WP 12505. Patrick, Gerardo I tried various restarts of the Beckhoff PLC on h0vaclx, but none of them changed the error on the PT110 gauge. I did notice an additional diagnosis of the error, which is that the status of the EtherCAT ports is abnormal, which I think is an indication that something is not right with the connection of the gauge to the h0vaclx EtherCAT network. Gerardo went out to reseat the cable and look for anything odd about it. I went through and checked the relay trip point levels for each of the gauges on h0vaclx. I found PT110, PT180 and PT170 set to 1E-5 and changed them to 5E-5. PT132 was already at 5E-5. The other gauges do not have the trip points enabled. PT110 1E-5 -> 5E-5 PT140 not enabled PT180 1E-5 -> 5E-5 PT170 1E-5 -> 5E-5 PT132 5E-5 PT193 not enabled PT192 not enabled PT191 not enabled
I used the vacuum SDF safe.snap file to restore CP2's PID settings. To speed this up in the future I wrote a script to do this, the script should be ran on a machine with write access to the vacuum controls IOCs.
/ligo/home/vacuum/burt_restore_h0vaclx.bsh
cp /opt/rtcds/userapps/release/cds/h1/burtfiles/h1vacuumsdf/h1vacuumsdf_safe.snap /tmp/h1vacuumsdf_safe.snap
cat /tmp/h1vacuumsdf_safe.snap|grep "^H0:VAC-LX_"|awk '{print "caput ",$1,$3}' > /tmp/h0vaclx
while read -r i;do
${i}
done < /tmp/h0vaclx
Error is fixed, all we had to do was connect the Ethernet cable to correct port, yes somehow I managed to connect it on the wrong port, but the odd part is that we had a valid pressure signal, except for the error noted by Patrick.
For future reference, specifically, the correct port (in vs. out) on the gauge itself.
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.
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