Displaying reports 821-840 of 88367.Go to page Start 38 39 40 41 42 43 44 45 46 End
Reports until 15:33, Tuesday 05 May 2026
LHO VE (VE)
jordan.vanosky@LIGO.ORG - posted 15:33, Tuesday 05 May 2026 (90128)
HAM6 RGA Maintenance

The HAM6 RGA tree had a known leak coming from the needle valve on the calibrated leak, so the calibrated leaks were removed from the system and the tree now only consists of the RGA, 10 l/s Ion Pump and a pump out port.

The tree was re-wrapped with heat tape and is currently baking at high temp using an aux cart and 80 l/s turbopump. Caution tape has been installed around the -Y door of HAM6, please avoid the area.

Images attached to this report
H1 CDS
david.barker@LIGO.ORG - posted 14:59, Tuesday 05 May 2026 - last comment - 15:21, Tuesday 05 May 2026(90125)
CDS Maintenance Summary: Tuesday 5th May 2026

WP13221 Add BBSS Fast Channels to DAQ

Tom, Oli, Erik, Dave:

18 BBSS_OSEMINF (SUM, X, Y) DQ channels were added to the DAQ, all at 256Hz. DAQ retstart was required.

WP13223 Add PT100A VACSTAT slow channels to DAQ

Dave:

A new H1EPICS_VACSTAT.ini was generated adding PT100A. An EDC+DAQ restart was required.

WP13228 Add FW2 slow channels to DAQ

Erik, Jonathan, Dave:

Puppet was changed to add three channels unique to FW2 (STATE_0, STATE_1, NUM_WRITERS). An EDC+DAQ restart was required.

WP13235 h1sush6 IO Chassis Install

Fil, Dave:

Fil moved the IO Chassis for h1sush6 from its temporary location in an adjacent rack into the SUSH6 rack on the MER. h1sush6 front end was powered down for the duration of this work.

DAQ Restart

Erik, Jonathan, Dave:

The DAQ and EDC were restarted.

FW2 stopped at the time puppet was upgraded due to a file creation race condition.

For the DAQ restart itself, the main issue was two spontaneous restarts of FW1, both after running for 10 minutes but not synced to the writing of the second trend frame files.

 

Comments related to this report
david.barker@LIGO.ORG - 15:21, Tuesday 05 May 2026 (90127)

11:23:13 h1susb2h34   h1suslo12   <<< New model, add DQ chans to DAQ
11:26:44 h1daqgds0    [DAQ] <<< 0-leg restart, susl012, vacstat, fw2 additions
11:26:48 h1daqfw0     [DAQ]
11:26:48 h1daqtw0     [DAQ]
11:26:49 h1daqnds0    [DAQ]
11:27:39 h1susauxb13 h1edc[DAQ] <<< EDC for vacstat, fw2
11:30:49 h1daqdc1     [DAQ] <<< 1-leg restart
11:30:58 h1daqfw1     [DAQ]
11:31:00 h1daqtw1     [DAQ]
11:31:03 h1daqnds1    [DAQ]
11:31:11 h1daqgds1    [DAQ]
11:32:13 h1daqgds1    [DAQ] <<< gds1 needed a restart


11:40:28 h1sush6      ***REBOOT***  <<< Power up after IO Chassis work
11:41:23 h1daqfw1     [DAQ] <<< First FW1 spontaneous restart, suspiciously close to start of sush6
11:41:30 h1sush6      h1iopsush6  
11:41:43 h1sush6      h1susom0    
11:41:56 h1sush6      h1susobs    
11:42:09 h1sush6      h1susam     
11:42:22 h1sush6      h1susomcab  
11:42:35 h1sush6      h1susom1ab  
11:42:48 h1sush6      h1susom2ab  
11:43:01 h1sush6      h1susom3ab  


11:51:41 h1daqfw1     [DAQ] <<< Second FW1 spontaneous restart, roughly +10mins
12:02:32 h1daqfw1     [DAQ] <<< Third FW1 spontaneous restart, again roughly +10mins
 

H1 CDS (SUS)
filiberto.clara@LIGO.ORG - posted 14:28, Tuesday 05 May 2026 (90124)
O5 HAM6 SUS Racks - SUS-M2 / SEI-M1 / SUS-R7

WP 13235
WP 13169
Drawing O5 SUS HAM6 (sush6) System Wiring Diagrams - D2300379

The O5 SUS HAM6 electronics and in-rack cabling installation in the MER is complete. System wiring diagrams D2300379 will need to be updated to show no IO h1susauxh6 was installed. New ADC cards (SUS AUX) were installed in the h1seih7 IO chassis.

IO chassis h1sush6 and h1sush7 share a 24V power supply. A dual Kepco power supply was installed to power the ±18V for SUS-M2. New electronics except the h1sush6 IO chassis were left powered off.

Status of the SUS-R7 rack is ongoing. All electronics installed. All long cables from MER and CER pulled and dressed. Rack requires ±18V and 200V for PSAMS. Depending on loads, plan is to use the SUS-R4 power supplies for the ±18V. The HV power supply will need to be placed on the HAM6 vacuum gauge interlock.

Images attached to this report
H1 AOS
david.barker@LIGO.ORG - posted 10:09, Tuesday 05 May 2026 (90123)
h1sush6 powered down for IO Chassis move

Fil, Erik, Dave:

we have powered down h1sush6 front end in preparation for Fil's move of the IO Chassis into the SUSH6 rack on the MER. Reminder that this front end is not connected to the Dolphin switch, so there is no risk of a corner station Dolphin glitch.

H1 SUS
betsy.weaver@LIGO.ORG - posted 08:14, Tuesday 05 May 2026 - last comment - 10:35, Friday 08 May 2026(90103)
BSC2 Cartridge pictures and time lapse movie

Pictures and the timelapse video from the BSC2 Cartridge (alog 90021) last week are attached and/or at https://caltech.box.com/s/4ahvfvdnaev8iiz3ktgda8g00srpvv1x

 

 

Images attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 10:35, Friday 08 May 2026 (90176)EPO

tagging for photos.

LHO General
ryan.short@LIGO.ORG - posted 07:41, Tuesday 05 May 2026 (90120)
Ops Day Shift Start

TITLE: 05/05 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: 14mph Gusts, 10mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.11 μm/s 
QUICK SUMMARY: Surveying on the BS at the test stand in the LVEA continues today, along with RGA work at HAM6 and CP1 regen near the Y-manifold. HAM2 doors are also likely to come off today.

LHO General
ryan.short@LIGO.ORG - posted 07:38, Tuesday 05 May 2026 (90110)
Ops Day Shift Summary

TITLE: 05/05 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY: Work continued with the BS on the test stand, preparations were made for HAM2 doors to come off later this week, and baffle installation in HAM3 all took place today.

I neglected to post this yesterday afternoon and unfortunately did not save the log.

H1 CDS (CDS)
erik.vonreis@LIGO.ORG - posted 06:35, Tuesday 05 May 2026 (90119)
Workstations updated

Workstations were updated and rebooted.  This was an OS packages update.  Conda packages were not updated.

H1 CDS
david.barker@LIGO.ORG - posted 21:15, Monday 04 May 2026 - last comment - 08:49, Tuesday 05 May 2026(90116)
CP1 Regen Alarms

Gerardo, Jordan, Jonathan, Dave:

PT114 has started to rise rapidly. At 16:50 I changed its alarm high from 2.0e-08 to 5.0e-04.

Later PT114B's VACSTAT continued to trip due to the large delta-P. After clearing the alarms I have disabled PT114B in VACSTAT (but its level alarms remain active).

 

Images attached to this report
Comments related to this report
david.barker@LIGO.ORG - 21:28, Monday 04 May 2026 (90118)

As mentioned by Gerardo CP1's outside discharge line pipe is now completely free of ice (Nov 2025 image added for comparison).

Images attached to this comment
ryan.short@LIGO.ORG - 08:49, Tuesday 05 May 2026 (90122)OpsInfo

The pressure at PT114 has continued to rise this morning and mostly leveled out, but it's bouncing around the channel's low-level alarm threshold at 1e-5 Torr. This is triggering Verbal Alarms and the CR alarm handler computer every time the pressure goes above 1e-5 Torr, which is on average a few times per minute.

I've commented out PT114 from the Verbal Alarms vacuum channel list to reduce redundant alarms and will look into modifying the thresholds somehow for the alarm handler.

Images attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 18:34, Monday 04 May 2026 - last comment - 21:10, Monday 04 May 2026(90113)
DAQ DC0 crash 18:35 Mon 04may2026

h1daqdc0 stopped running around the time I restarted vacstat_ioc on cdsioc0 to clear an alarm. DC0 is pingable, but we cannot ssh onto it. Jonathan is taking a look, we may have to power cycle it via IPMI.

Comments related to this report
david.barker@LIGO.ORG - 21:10, Monday 04 May 2026 (90115)

DC0 was power cycled at 18:52 PDT. After that we did a clean 0-leg restart to resync the other nodes to the DC.

H1 General
camilla.compton@LIGO.ORG - posted 17:12, Monday 04 May 2026 (90112)
ALS X Laser on

Turn ALS X laser back back on, we used it to take some ALS return beam beam profiles. It's been off since the interlock was worked on. It is now shuttered. 

H1 SUS (SUS)
ibrahim.abouelfettouh@LIGO.ORG - posted 17:06, Monday 04 May 2026 (90111)
BS/FM In-Vac Cables Replaced, Gold BS Baffles Removed, BBS Magnet Gluing Staged

Ibrahim, Betsy

Today we:

  1. Replaced the in-vac cables with the new QOSEM ones, maintaining their positions in the cable clamps
  2. Wrestled the gold BS baffles loose to make way for clearer alignment sighting
  3. Unpacked and set-up the magnet gluing set-up in prep for BBS01 arrival tomorrow.
H1 SUS (SUS)
thomas.roocke@LIGO.ORG - posted 18:04, Sunday 03 May 2026 - last comment - 19:06, Monday 04 May 2026(90097)
QOSEM Calibration Rig Setup

On Friday I setup the QOSEM calibration rig in the triple lab, in the staging building. It consists of a motorored translation stage (open loop picomotor), which drives the QOSEM flag into and out of the QOSEM body, while the sum and difference voltages produced by the sat amp are monitored. The position of the stage, and hence flag is readout by a Mach-Zender interferometer (SmarAct PicoScale). This is all controlled by a laptop running a python script.

The purpose of setting up this rig again is to better calibrate each QOSEM going on to the BBSS M1, by taking calibration data with the exact sat amp and flag that each QOSEM will use.

Comments related to this report
thomas.roocke@LIGO.ORG - 19:06, Monday 04 May 2026 (90114)

Today I finished setting up the QOSEM calibration rig in the triples lab. I grabbed the LHO production QOSEM sat amp from SUS-R2 for use in this calibration, and will match the flag and QOSEM pair to what they will be on the BBSS, such that the calibration is as valid as possible. The rig is all ready to go for calibration runs tomorrow.

 

Images attached to this comment
H1 AOS (SUS)
thomas.roocke@LIGO.ORG - posted 17:45, Thursday 30 April 2026 - last comment - 15:04, Tuesday 05 May 2026(90079)
QOSEM Signal Chain Testing

[Tom Roocke, Oli]

Summary: The 6 QOSEMs and their signal chain for the BBSS are operational with the final sat amp, CER wiring, CDS mapping, in vac DB25 extension cables. All that remains to test before SUS installation is the duopus cables, which are in C&B currently.

In continuation from yesterday, we are testing out the QOSEM signal chain prior to installation of the BBSS. Yesterday we verified the sat amp was still functional and the readouts were showing up in CDS appropriately. See LHO:90072. Today we checked both the DB25 to DB25 extension cables, and the QOSEMs. To come is testing of the duopus cables, which are still in C&B.

DB25 Extension Testing:
Using a known functional Duopus cable (S2600215), and inair DB25, we tested the three DB25 extension cables by reading for the QOSEM coil resistance and diode drops at the in air DB25, where it connects to the sat amp. See the signal continuity test section in T2600170 for more information on this. All 3 cables are functional.

S2001548: DB25 working
S2100358: DB25 working
S2100410: DB25 working

QOSEM CDS Readout Testing:

Using a known functional Duopus Cable (S2600215), DB25 Extension (S2100410) and in air DB25, we checked for the open sum voltage in the CDS readout. This is the voltage seen on the sum channel of the QPD with no lens installed. Seeing a nonzero voltage here indicates that the QOSEM LED, QPD and signal chain are functional, but will be far lower than the operational sum level when the lens flag is appropriately focusing light onto the QPD. We tested the open sum voltage for all 6 QOSEMs designated for the BBSS. All QOSEMs and there signal chain are functional.

S2600008: working with open sum of 13910
S2600009: working with open sum of 14755
S2600010: working with open sum of 15550
S2600011: working with open sum of 15470
S2600012: working with open sum of 15348
S2600013: working with Open Sum of 14380

Images attached to this report
Comments related to this report
thomas.roocke@LIGO.ORG - 15:04, Tuesday 05 May 2026 (90126)

Today the QOSEM Duopus cable finished C&B, so I unbagged and tested them in the triples lab. I checked for continuty and any shorted pins with a multimeter, and all 4 cables passed. With this all parts of the QOSEM signal chain have been tested and ready to go for on suspension testing

H1 SYS
betsy.weaver@LIGO.ORG - posted 14:05, Monday 27 April 2026 - last comment - 10:38, Friday 08 May 2026(90021)
BSC2 Cartridge on the Test Stand
The BSC2 cartridge was removed from the BSC2 chamber today and placed on the Test Stand in the West Bay (+Y bay).  The lift took 3 "test lifts" to make very minor adjustments to the CG prior to lift out of the chamber - on the 4th lift, we were very well balanced so embarked on the flight.
Like LLO, the BS had it's "Stay Leg" assemblies and Vibration Absorber Assemblies removed for the flight.  This means it was probably lighter than the 2013 time (alog 5689) when we did this which had the weight slightly heavier.  The cartridge plus 3-point lift fixture and load cell together all weighed 9380 lbs.  It was rotated 90deg Counterclockwise per the procedures and landed on the threaded rod in the test stand with little issue other than careful craning and spotting.
All went as expected and according to the procedures E1200433-v3, E1200971-v4 and associated docs.

Mitchell, Travis, Tyler, Randy (on crane) all up on the platform
Jim and Tony inside of BSC2
Gerardo, Jordan on the eMod as Support
TJ on the camera
Betsy soaking it all in (support)

A pre-lift meeting was held to go over the teams and maneuver details (again) at 9am prior to work starting.

Particle counts up at the dome level were all 0,0 before starting.
More photos and videos will be posted when those folks have them available.

Covers used - A BS/QUAD SUS tube cover up underneath, an ISI cover up on the ISI, the BSC Cartridge sock which encased the whole thing, dropped down to Jim and Tony once the lift was up a couple feet.  

The bulk of the work was from ~10:30am-1pm.  Most of the time before was getting folks in headsets and gear and getting equipment on.


Images attached to this report
Comments related to this report
jenne.driggers@LIGO.ORG - 20:36, Monday 27 April 2026 (90028)

Going over the details during the 9am pre-lift meeting. Congratulations, all, on a smooth operation!

Images attached to this comment
betsy.weaver@LIGO.ORG - 08:15, Tuesday 05 May 2026 (90121)

More photos posted at alog 90103.

corey.gray@LIGO.ORG - 10:38, Friday 08 May 2026 (90177)EPO

tagging for photos.

H1 ISC
jennifer.wright@LIGO.ORG - posted 10:33, Friday 16 May 2025 - last comment - 16:42, Monday 04 May 2026(84432)
OMC scans with SR3 heater on

Jennie W, Sheila, Elenna

 

In order to get data for mode-matching and for Elenna to get data to calibrate sideband heights we ran some mode scans after the SR3 heater was turned on last night.

16:55:24 UTC Carried out single bounce OMC scan at 10W PSL input with sensor correction on HAM6 on, high voltage on for PZT driver in HAM6, sidebands off , SRM mis-aligned, ITMY mis-aligned, DC 3 and 4 on, OMC ASC on.

Excitation freq changed to 0.005 Hz as the top peak of the TM00 mode looked squint so could have been saturating. Lowering this frequency prevented this.

Ref 15-17 corresponds to dcpd data, pzt exc signal, pzt2 dc monitor.

 

Then mis-aligned ITMX and aligned ITMY (Sheila had to re-align SR2 to centre on ASC-AS_C).

Measurement starts at 17:08:18 UTC.

Ref 18-20 corresponds to dcpd data, pzt exc signal, pzt2 dc monitor.

 

Traces saved in 20250516_OMC_scan.xml. The top left plot is the first scan bouncing beam off ITMX, the second scan is the bottom right bouncing off ITMY.

The top right is the two plots of the PZT2 DC voltage monitor. That is, the current voltage applied to the PZT. The bottom left is the plot of the voltage ramp applied to the PZT2 on the OMC for this measurement.

 

The ndscope attached shows the power in mA transmitted through the OMC on the top, then the PZT used for the scan DC voltage underneath, then the input PZT voltage underneath that, then the reflected power from the OMC in mW, then at the bottom the SR3 heater element temperature in degrees.

 

Elenna did two more scans in single bounce with sidebands back on and different modulations depths in each.

Images attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 10:38, Friday 16 May 2025 (84433)

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

Turn off the sidebands - instructions in this alog.

elenna.capote@LIGO.ORG - 16:51, Friday 16 May 2025 (84441)

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

 

Images attached to this comment
elenna.capote@LIGO.ORG - 17:02, Friday 16 May 2025 (84442)

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.

camilla.compton@LIGO.ORG - 11:40, Tuesday 03 June 2025 (84749)

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.
Images attached to this comment
jennifer.wright@LIGO.ORG - 12:09, Thursday 10 July 2025 (85661)

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.

 

Non-image files attached to this comment
jennifer.wright@LIGO.ORG - 11:52, Friday 11 July 2025 (85693)

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

 

jennifer.wright@LIGO.ORG - 15:56, Friday 11 July 2025 (85698)

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.

Non-image files attached to this comment
sheila.dwyer@LIGO.ORG - 08:58, Wednesday 15 April 2026 (89897)

In these scans the SR3 heater request (POWER_SET) was 2W, the readback power monitor reports 1.9W. 

craig.cahillane@LIGO.ORG - 16:42, Monday 04 May 2026 (90109)
Using the data from Elenna's scans with the sidebands on, I added a function calculate_modulation_depths() to the OMCscan.py code.
I then used it to find the modulation depths for the 9 and 45 MHz from those scans:

PDH measurement data for two GPS timestamps

Parameter GPS 1431450833 GPS 1431451160
Slider 9 MHz 23.4 dBm 20.4 dBm
Slider 45 MHz 27.0 dBm 21.0 dBm
Modulation depth 9 MHz 0.215 rad 0.165 rad
Modulation depth 45 MHz 0.277 rad 0.145 rad
Displaying reports 821-840 of 88367.Go to page Start 38 39 40 41 42 43 44 45 46 End