D. Davis, E. Capote, O. Patane

There was a discussion recently in the Detchar tools channel about how to interpret the cumulative range plots generated on the summary pages, such as today's cumulative range plot. Specifically, it seems incorrect that we could accumulate 30% of our range below 30 Hz.

Derek has pointed out that this is so misleading because the calculation of cumulative range in this manner is actually performed somewhat incorrectly. In short, range can be thought as analogous to SNR, which is a quantity that must be added in quadrature. Therefore, the order matters when calculating a cumulative range, i.e. the range acquired from 10-20 Hz, then 10-30 Hz, 10-40 Hz, etc. Therefore, the total cumulative range number, as in the one we think about all the time (160 Mpc, for example) is correct, but determining the range over a subset of the band (such as 10-30 Hz) needs to be done more carefully so it is not misleading.

Once we started discussing this, I pointed out that this means that the way we compare ranges is also misleading, as in when we run our DARM integral comparison scripts, we are subtracting the cumulative range of two different DARM PSDs, but we subtract it in amplitude (Mpc) and not in quadrature (Mpc^2).

Derek has created an improved way to calculate cumulative range, which they have coined to be the "cumulative normalized range". To get right to the point: it is better to normalize the cumulative range squared by the total range. This is an example plot showing how these two differ. This plot shows that for a given DARM PSD, the cumulative normalized range better estimates the sensitivity gained over a particular range of frequency. The low frequency portion is still very important (this results from the f^(-7/3) dependence in the range calculation), but indeed we gain very little sensitivity between 10-20 Hz, for example. You can also see that, when using the normalized method, the curve where you integrate up in frequency and the curve where you integrate down in frequency intersect at about 50% of the range, which is what you would expect.

In equation form, this image attachment defines the total cumulative range, and this image attachment shows our defintion of the normalized cumulative range.

In order to more sensibly compare two sensitivities by frequency, we have also derived a way to calculate the cumulative normalized range difference. The derivation is slightly more complicated, but the result is that you subtract the two cumulative normalized quantities, and then normalize by the sum of the two ranges.

This image attachment shows the equation form of this.

To make sense of why this method is better than the method we use now, you can imagine that we have two PSDs, one with 100 Mpc of range, and one that is exactly the same, except that between 10-20 Hz there is an additional gain of 20 Mpc, such that the total range is now 120 Mpc. If you compare these two bizarre PSDs, you would expect that the cumulative range difference between the two from 10-20 Hz is 20 Mpc, and then zero thereafter. This is an example plot showing how the cumulative range difference would appear, using the method where you subtract the two cumulative ranges, and then the method where you apply this normalized range method. The normalized range calculation behaves as expected, while the method that straightforwardly subtracts the two cumulative ranges overshoots the range gain from 10-20 Hz, and then misleadingly indicates the range is decreasing above 20 Hz to make up for it.

There is a lot of information to grasp here, and Derek and I will be posting a document to the DCC soon with a fuller explanation and full derivations. Oli has taken the time to implement these new methods in our DARM comparison scripts, and they will follow up here with more information about that.

Because of drift issues that we've been seeing in the BBSS, we've been looking into center of mass issues, and we are now looking at the lowest stage, M3, and the possibility that the stainless steel center insert (which was installed upside down) is causing pitch issues.

We wanted to go through and verify what the physical d4 value, aka the physical location of the prism-clamp breakoff point, is in our latest set of measurements we took at the end of October. We wanted to verify this just because when we were messing around with d4 back in early 2024 (75947, 76071), we never checked any measurements where we changed around d4 with the stage2 parameter correctly on, meaning that those d4 comparisons all plotted changes in the effective d's instead of the physical d's.

I've plotted a few parameter sets where the stage2 parameter is on so we can more properly compare them.

I've plotted:

• the current default parameter set, which has d4 = FDR = 0.5mm, as well as having d1 = FDR - 2.5mm
  • this parameter set had been decided by us to be the new default a while ago
• variations on the FDR parameter set, with d4 being the FDR d4 value shifted by +/- 0.5, 1.0, or 1.5mm. For these parameter sets, d1 is left as its original FDR value
• Our most recent measurements from October 31st, which was after all the M1 blade heights had been changed

Here are the plots. The zoomed L and P plots are the best for seeing the differences between the different parameters.

The Oct31 measurement seems to match best somewhere between d4 - 1.0mm and d4 - 0.5mm, so the value of  d4 that we have in our current set seems to still match pretty well.

It is interesting to see though the difference between the dark red and the yellow traces as compared to our latest measurement, since the only difference between those two is the d1 value. It looks like somewhere along while messing with the blade heights, we also moved away from the d1 = FDR - 2.5mm value and closer to the d1 value given in the FDR.

TITLE: 01/06 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 9mph Gusts, 5mph 3min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.48 μm/s
QUICK SUMMARY:

• We've been locked for about 13.5 hours
• 2ndary microseism seems to have leveled out, just over the 90th percentile

This is a plot to show that the squeezing performance has been nice and consistent since work in October, including the crystal move, and getting both the ASC and SQZ angle servos working together.  This seems to be helping our range to be more consistent over the last few months as well.

Sheila, Camilla. Last done in 80451, followed those instructions.

Before translating the crystal, we reduced the green H1:SQZ-SHG_LAUNCH_DC_POWERMON power from 30mW down to 6mW. After we finished, we brought this up to 15mW and still could lock the OPO with 80uW on H1:SQZ-OPO_TRANS_LF_OUTPUT and around 6 on the ISS controlmon. Meaning our losses reduced significantly.

We moved from the 3rd spot from the left photo to the 4th spot from the left photo ( 34 x steps of 50 to the right and then 19 x steps of 10 to the right).  We have previously used the 2nd, 3rd, and 5th spots from the left, there is 6 spots in total.

Measured NLG to be 8.8 (0.0787/0.00892, 76542). This is lower than what we usually run with 11 to 17 so means that this new spot has less losses but a worse NLG.

FDS is the same but ASQZ lower. Shiela said that this good and is expected with lower losses and mean there can be less mis-rotated ASQZ injected. Plot attached.

Tagging OpsInfo: This change will mean that for the next week or so we'll need to more regularly adjust the OPO TEC temperature, instructions are in 80461. Should be done pro-actively when relocking and if range is low in observing.  If you adjust while in Observing, please tag Detchar in your alog.

Mon Jan 06 10:14:22 2025 INFO: Fill completed in 14min 19secs

Gerardo confirmed a good fill curbside.

TCtrip = -50C, TCmins [-82C, -27C]. OAT (3C, 38F)

Famis 28386
Last weeks's In-Lock SUS Charge Measurements:  Injections were not made on Tuesday Dec 31st 2024.

TITLE: 01/06 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 8mph Gusts, 6mph 3min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.68 μm/s
QUICK SUMMARY:

Observing and have been Locked for over 5 hours. Secondary microseism looks like it's been creeping up.

TITLE: 01/06 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 165Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Quiet night, we stayed locked the whole shift, 10.5 hours as of 06:00 UTC. 2ndary microseism has risen rapidly over the past 3 hours.
LOG: No log.

TITLE: 01/06 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 160Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Currently Observing and have been locked for 5 hours. One lockloss today due to an EQ, but relocking was easy. The only problem I ran into was during initial alignment SRY couldn't catch, but I just had us go through SR2 align again and then we were fine. No other intervention was needed from me.
LOG:

15:30 Relocking and at LOCKING_ARMS_GREEN
16:34 NOMINAL_LOW_NOISE
16:38 Observing

17:37 Lockloss due to earthquake
    - Ran an initial alignment
        - Was having trouble with SRY so I reran SR2 and that worked
19:30 NOMINAL_LOW_NOISE
19:32 Observing

TITLE: 01/06 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 159Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 2mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.35 μm/s
QUICK SUMMARY:

• We've been locked for 4.5 hours
• Low wind but the 2ndary microseism is rising

Sun Jan 05 10:13:05 2025 INFO: Fill completed in 13min 2secs

TCtrip -50C, TCmins [-64, -34] OAT (4C, 38F).

Est. TCA-min was -62.

Lockloss @ 01/05 17:37 UTC due to earthquake

Waiting for earth to calm down before trying to relock.

TITLE: 01/05 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 2mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.38 μm/s
QUICK SUMMARY:

Currently relocking and at FIND_IR. We had been locked for 14.5 hours before having a lockloss a bit ago at 01/05 15:17UTC

TITLE: 01/05 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: We've been locked for over 5 hours.
LOG: No log

"pump fiber rej power in ham7 high, align fiber pol on sqt0" notification on SQZ_OPO_LR

00:46 UTC observing

This alog follows up LHO:81769 where I calibrated the ASC drives to test mass motion for all eight arm ASC control loops. Now, I have taken the noise budget injections that we run to measure the ASC coupling to DARM, and used that to calibrate an angle-to-length coupling function in mm/rad. I have only done this for the HARD loops because the SOFT loops do not couple very strongly to DARM (notable exception to CSOFT P, which I will follow up on).

The noise budget code uses an excess power projection to DARM, but instead I chose to measure the linear transfer function. The coherence is just ok, so I think a good follow up is to remeasure the coupling again and drive a bit harder/average longer (these are 60 second measurements). This plot shows the noise budget injection into calibrated DARM/ASC PUM drive [m/Nm] transfer function, and the coherence of the measurement.

I followed a similar calibration procedure to my previous alog:

• Go from "H1:ASC-[DOF]_[P/Y]_OUT_DQ"  to Nm of PUM torque using G1100968
  • I made sure that I corrected by an erroneous factor of two that I found previously
  • Some of these injections were done after the ETMX DAC change. However, Daniel noted this alog for me, 80023, so the calibration for the ASC should not change significantly.
•  transform this N*m PUM drive to radians of test mass motion using the PUM-TST state space suspension model transfer function, which is calibrated into real units (radian/Nm)
  • I did all of this in python, so I used Kevin's exported quad state space model, found here: T2300299
  • I used the damped model which applies the ETMX top mass damping filters
• Multiply by 1e3 to convert to mm/rad

I did not apply the drive matrix here, so the calibration is into ETM motion only (factor of +/-1), whereas the calibration into ITM motion would have an additional +/- 0.74 (+/- 0.72 for yaw) applied.

HARD Pitch Angle to Length coupling plot

HARD Yaw Angle to Length coupling plot

Overall, the best-measured DOF here is CHARD Y. In both CHARD Y and DHARD Y, there seem to be two clear coupling regions: one fairly flat region above 20 Hz in CHARD Y and above 30 Hz in DHARD Y, reaching between 20-30 mm/rad. Below, there is a steep coupling. This is reminiscient of the coupling that Gabriele, Louis, and I measured back in March and tried to mitigate with A2L and WFS offset. We found that we could reduce the flatter coupling in DHARD Y by adjusting the A2L gain, and the steeper coupling by applying a small offset in AS WFS A yaw DC. We are currently not running with that WFS offset. The yaw coupling suggests that we have some sort of miscentering on both the REFL and AS WFS which causes a steep low frequency coupling which is less sensitive to beam centering on the test mass (as shown by the A2L tests); meanwhile, the flat coupling is sensitive to beam miscentering on the test mass, which is expected (see e.g. T0900511).

The pitch coupling has the worst coherence here, but the coupling is certainly not flat. It appears to be rising with about f^4 at high frequency. I have a hard time understanding what could cause that. There is also possibly a similar steep coupling at low frequency like the yaw coupling, but the coherence is so poor it's hard to see.

Assuming that I have my calibration factors correct here (please don't assume this! check my work!), this suggests that the beam miscentering is higher than 1 mm everywhere and possibly up to 30 mm on the ETMs (remember this would be ~25% lower on the ITMs). This seems very large, so I'm hoping that there is another errant factor of two or something somewhere.

My code for both the calibrated motion and calibrated coupling is in a git repo here: https://git.ligo.org/ecapote/ASC_calibration