Just adding a note:

As of the end of the day, Sheila and I have left the sidebands OFF, and the HAM6 high voltage ON (per WP #12545).

See Elenna's comment on her previous measurement where this saturation happened.

Turn off the sidebands - instructions in this alog.

Sheila and I ran one more OMC scan with sidebands off after OM2 heated up. Attached is the screenshot with scans off both ITMX and ITMY, data is saved in [userapp]/omc/h1/templates/OMC_scan_single_bounce_sidebands_off.xml

 

I also ran two OMC scans, single bounce off ITMY, 10 W input, with the sidebands ON. One measurement I ran with the sidebands set to 23 dBm and 27 dBm (9 and 45 MHz) and another set to 20 dBm and 21 dBm (9 and 45 MHz). I will use these measurements to calibrate the modulation depth. Data saved in /opt/rtcds/userapps/release/omc/h1/templates/OMC_scan_single_bounce_RF_cal.xml

SR3 heater was on for this measurement but it should have little effect on my results.

Looked closer at these HWS signals during SR3 heater heat up and cool down. In all these plots, the two t-cursors are used as the reference and shown HWS live image.

• Heat up plot attached
• Cool down plot attached (ITMX was misaligned so there's no HWS data)

Some strange things:

• ITMX heat up ndscope spherical power looks the opposite direction of ITMY, this isn't physical. Looking at the HWS Live plot, this isn't really want's happening, it appears that the SR3 signal just appears if the edge of ITMX is heating up so the center that the calculations are made from isn't correct, making the calculated spherical power wrong.
• In both the heat up and cool down of the ITMY signal, there appears to be two steps with a flat region in the middle. Looking at the the flat region only, attached, it appears that the spherical power is continuing to change in the expected direction, unsure why this change isn't shown in the calculated spherical power.

Finally got round to fitting the two single bounce mode scans done with SR3 hot and OM2 cold. The first we had ITMX aligned, the second we switched to ITMY aligned.

These can currently be processed using OMCscan.py in the /dev branch for the labutils/omcscan repository at /ligo/gitcommon/labutils/omc_scan, you need to have activated the labutils conda environment to do so.

The call statements for the data processing are:

python OMCscan.py 1431449762 130 "1st 1431449762 - SR3 hot, 10W PSL, ITMY mis-aligned" "single bounce" -s -v -o 2 -m 

python OMCscan.py 1431450536 140 "2nd 1431450536 - SR3 hot, 10W PSL, ITMX mis-aligned" "single bounce" -s --verbose -m -o 2

For each measurement the tag -s specifices that the sidebands were not on and so in order to calibrate the PZT the code uses the two TM00 modes and then you have to tell it in what height order the 10 and 20 modes appear relative to the highest peak which will be one of the 00 modes.

def identify_C02(self):

"""If in single bounce configuration, and with sidebands off,

identify 10 and 20 modes in order to improve fit.

Assumes that

OMCscan.identify_peaks()

and

OMCscan.identify_carrier_00_peaks()

have already been run.

 

Output:

-------

self.peak_dict: dictionary

first set of keys are carrier, 45 upper, 45 lower

second set of keys are TEM mode, e.g. "00", "01", "20", etc.

third set of keys is the fsr number

"""

 

# Create temporary dictionary to combine into self.peak_dict

peak_dict = {}

peak_dict["carrier"] = {"10": {}, "20": {}}

#print(peak_dict)

nn = [2, 1]

mm = 0

#freq_diff = np.empty(np.size(self.peak_frequencies)) not sure why this line here.

#set frequency to be that of third largest peak.

first_order = np.argsort(self.peak_heights)[-4]#-4 for second meas.

second_order = np.argsort(self.peak_heights)[-3]#change index to match where 20 is in terfirst meas if measuring from start of scan.ms of peak height.

#print(third_larg)

for ii, peak_freq in enumerate(self.peak_frequencies):

if peak_freq == self.peak_frequencies[second_order]:

#print("found C02")

#print(f"List fields in IFO {self.fields_MHz}")

#print(type(self.fields_MHz))

#print(f"OMC HOM spacing {self.omc_hom} MHz")

#print(type(self.omc_hom))

field = f"carrier"

#print(f"mode {field}{nn[0]}{mm}")

peak_dict[field]["20"][-1] = {

"height": self.peak_heights[ii],

"voltage": self.peak_pzt_voltages[ii],

"frequency": self.peak_frequencies[ii],

"true_frequency": np.mod((self.fields_MHz - (nn[0] + mm) * self.omc_hom), self.omc_fsr),

"label": r"$c_{20}$",

}

self.peak_ided[ii] = 1

elif peak_freq == self.peak_frequencies[first_order]:

field = f"carrier"

peak_dict[field]["10"][-1] = {

"height": self.peak_heights[ii],

"voltage": self.peak_pzt_voltages[ii],

"frequency": self.peak_frequencies[ii],

"true_frequency": np.mod((self.fields_MHz - (nn[1] + mm) * self.omc_hom), self.omc_fsr),

"label": r"$c_{10}$",

}

self.peak_ided[ii] = 1

else:

continue

# Merge dictionaries

#if not "20" in peak_dict["carrier"].keys():

self.peak_dict["carrier"] = {**self.peak_dict["carrier"], **peak_dict["carrier"]}

#print(self.peak_dict)

#print(self.peak_ided)

return

 

For both measurements I only took slightly over 1 FSR of the data, this is because in order to fit a polynomial to the known peaks (allowing us to calculate the PZT non-linearity), the code assumes the 1st order is the 3rd highest and 2nd order is the 4th highest.  In the code above you need to change the indexes in the below lines to match the height order of the peaks (ie. and index of -4 is fourth highest peak).

first_order = np.argsort(self.peak_heights)[-4]

second_order = np.argsort(self.peak_heights)[-3]

When the mode-matching is bad this may not be true, also if there are multiple FSRs in the scan this also may not be true.

 

First measurement 1st order mode is fifth highest, 2nd order mode is third highest. The scan is here. I took 130 s of data. The PZT fit is here.

Second measurement the 1st order mode was the 4th highest, 2nd order mode was the third highest. The scan is here. I took 140s of the scan data. The PZT fit is here.

 

First measurement has 

1.69/(1.69+15.86) = 9.63 % mode mis-match.

 

Second measurement has 

1.25*100/(1.25 + 16.46) = 7.06 % mode mis-match

 

I also analysed the single bounce measurements Elenna and Sheila made after OM2 was heated up. So these have both SR3 and OM2 hot.

For both these measurements C02 was the third highest mode and C01 was the fourth highest. I took 120s starting 45s into the scan.

 

Measurement 1: 23:40:38 UTC on 2025/05/16 with ITMX aligned and ITMY mis-aligned.

See the spectrum with labelled peaks here.

And the PZT calibration here.

Mode mis-match is: 

0.93/( 0.93 + 17.29 ) = 5.10 %

 

Measurement 2: 23:46:48 UTC on 2025/05/16 with ITMY aligned and ITMX mis-aligned.

See the spectrum with labelled peaks here.

And the PZT calibration here.

100 * 0.56/( 0.56 + 17.62 ) = 3.08 %

Bear in mind that this is assuming that there is no astigmatism in the OMC (since there is but we cannot resolve 02 vs 20 modes). This requires some careful analysis of uncertainties to get useful info about how we should tune for better mode-matching. Watch this space.

Last night RM2 was left in DAMPED with the damping loops on, whereas RM1 asnd PM1 were also in DAMPED but their damping loops had been turned off. The loops on RM2 excited the suspension until it was causing overflows. This continued all night. It seems strange that the loops that were damping well two days ago are now not damping (ndscope1). I noticed that turning off only the L damping solved the issue of the MASTER_OUTs slowly increasing.

Doing some tests (starting in SAFE and then going to DAMPED), it looks like damping is fine for the first few minutes, after which it very quickly starts exciting instead of damping (ndscope2, ndscope3), and the voltmons start going crazy. I did this test a few times with the same result every time.

Doing the same test but immediately switching L damping off as soon as it turns on, we stay just damping P and Y and have no issues with oscillations or saturations (ndscope4).

I am not sure if this means that the issue is specifically with the Length damping? I am putting RM2 in SAFE for now and I'm going to try the same tests on RM1 and PM1 to see if the same issue exists there.

[Shoshana, Michael]

We've managed to get all of the hardware/parts installed in and we've closed up the BRS chamber. We had to add an inch of shims beneath to motor mount in order to get it to fit/align properly, but otherwise there were only minor complications during installation. We've tested the pico-motor and the mass adjuster using the pico-motor driver that we brought from UW and both seem to work fine. 
For in air balancing, we left the new mass adjuster centered to increase range for future adjustments for when the BRS is pumped down and running, and tried to just stick to moving masses that are inaccessible when the BRS chamber is pumped down. We unfortunately reached the maximum range with the internal masses and had to slightly move the manual mass adjustment system (what is currently used to adjust the center of mass) from center, but that might be returned to center after we re-balance it when it's pumped down. Right now the resonance frequency looks to be around ~7mHz (around 130 second period) which is about the same as it was before Mass Adjuster installation, but we'll check again after the chamber has been pumped down.
Tomorrow we'll finish all of the wiring and electronics to hook up the pico-motor to the LIGO system. The plan is to pump down the BRS chamber tomorrow and re-balance and test the pico-motor some more.

The reference pattern has a higher intensity than expected and we aren't sure why. Right now our best guess is that the light source drifted slightly, and we'll look into it more tomorrow.

EPO tag for BRS pics

[Shoshana, Michael]

Pumped down the BRS chamber overnight and started the ion pump this morning and got it down to 1.9e-6 Torr before we left end End-X. We also wired up the picomotor to the LIGO picomotor controller system. It is hooked up to the 7th channel X-direction and we tested it out and were able to hear it spinning for both directions. The BRS's thermal insulation was reapplied the box closed and the temperature sensors and heating plate were all re-attached and plugged back in. The reference beam's intensity has gone down to be closer to normal somehow, so it doesn't seem to be anything to worry about
We might go back to End-Y one more time tomorrow to clean up the wiring and do a final check of the vacuum pressure.
We waited for the temperature to equilibrate a bit before balancing  because we were hoping that as the temperature rises it would drift back to center, but we ended up using the mass adjuster to try and balance it.
It looks like the + - wires for the damping were switched, meaning when the damping was on it would ring up the BRS. Fixed by changing a line in the BRS code[IF H1_ISI_GND_BRS_ETMY_CAPDRIVE>=0] by switching the [>=0] to [<=0] and switching [H1_ISI_GND_BRS_ETMY_CAPOUTL] and [H1_ISI_GND_BRS_ETMY_CAPOUTR], and [H1_ISI_GND_BRS_ETMY_RELAYL] and [H1_ISI_GND_BRS_ETMY_RELAYR]


FROM THE END-X INSTALL:
Coupling/decoupling move: 1.25k steps
Maximum: +-140k steps
Be careful: +-100k steps

NOTE: MOVING PICOMOTOR +(POSITIVE) DIRECTION TRANSLATES TO MOVING THE BRS UP

TOTAL MOVEMENT TODAY:+21k steps

Centered both ETMY and ETMX BRSs.
For ETMX net movement was +2200 steps, for ETMY net movement was -3200 steps.
For ETMX we saw that the DRIFTMON was moved by about ~3.27 counts per step, and ~2.3 counts per step for ETMY

Cleaned everything up for the ETMY BRS and relabeled all the wires. The final reading that we saw for the ion pump was 9.9e-7 Torr (186uA, 6950V) which seems about right. We left some extra mass adjuster parts with Jim just in case. 

Shoshana, Michael

We took tilt subtraction spectra as a final life check of the BRSs. Both BRSs appear to be in good working order and doing their jobs well.

Jennie, Sheila, and I ran OMC scans this morning and realized that the proper way to slow down the scan to avoid weird saturation effects is to reduce the excitation frequency in the template. The nominal templates have excitation frequencies of 0.01 Hz, so sweeping over 200 seconds just sweeps at the same speed twice. To sweep once, slower, you have to increase the sweep time to 200 seconds AND reduce the sweep frequency to 0.005 Hz.

Sheila and I want to note some things that are "obvious" but easily forgotten:

• high voltage must be on
• sensor correction must be on