To allow for the longer acquisition times we've been seeing to catch D/PRMI despite good-looking alignment and buildups, I've doubled the timers in ISC_LOCK for DRMI to try PRMI and PRMI to try MICH_FRINGES from 10 minutes to 20 minutes each. Changes have been loaded and committed to SVN.
Lockloss @ 15:41 UTC after 18 hours locked - link to lockloss tool
No obvious cause that I can see.
FAMIS 26430
Laser Status:
NPRO output power is 1.853W
AMP1 output power is 70.03W
AMP2 output power is 140.2W
NPRO watchdog is GREEN
AMP1 watchdog is GREEN
AMP2 watchdog is GREEN
PDWD watchdog is GREEN
PMC:
It has been locked 23 days, 22 hr 6 minutes
Reflected power = 23.42W
Transmitted power = 105.4W
PowerSum = 128.8W
FSS:
It has been locked for 0 days 18 hr and 23 min
TPD[V] = 0.7448V
ISS:
The diffracted power is around 3.7%
Last saturation event was 0 days 21 hours and 23 minutes ago
Possible Issues:
PMC reflected power is high
TITLE: 07/11 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 16mph Gusts, 10mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY: H1 has been locked and observing for 17 hours.
TITLE: 07/11 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY:
IFO is in NLN and OBSERVING since 21:43 UTC (7 hr lock!)
Extremely quiet shift in which there were no saturations, no SQZ drops and 1 Superevent!
Nothing else to report
LOG:
None
TITLE: 07/10 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 144Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Currently Observing at 145Mpc and have been Locked for 2 hours. Wind seems to be coming down.
Lots of struggles relocking today after the 17:54 lockloss due to increase of winds and gusts as well as issues with treh ALSX crystal frequency. Eventually made it up.
LOG:
14:30UTC Observing and Locked for 11 hours
15:00 Out of Observing for Commissioning
17:54 Lockloss
- Issues with ALSX crystal frequency
- Issues with wind
- Ran IA
- Many lower level locklosses from wind and ALSX crystal frequency
- Lockloss from TRANSITION_FROM_ETMX due to wind
21:43 NOMINAL_LOW_NOISE
21:48 Observing
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 22:56 | LASER | LVEA | LVEA | YES | LVEA IS LASER HAZARD \u0d26\u0d3f(\u239a_\u239a) | 14:34 |
| 14:35 | FAC | Randy | EX | n | Pump alignment (14:30) | 16:40 |
| 14:36 | FAC | Chris, Eric | XARM | n | Beam tube sealing | 15:43 |
| 15:05 | PEM | Robert | LVEA | YES | Checking if measurement is working | 16:13 |
| 15:48 | FAC | Tyler | X1, XARM | n | Looking at box and joints | 16:48 |
| 16:32 | FAC | Nellie | OpticsLab | n | Tech clean | 16:36 |
| 17:23 | PEM | Robert, Sam | LVEA | YES | Measurement setup | 18:06 |
| 17:37 | EPO | Jonathan, EJ | Roof | n | Tour? | 17:42 |
| 17:58 | Jennie | LVEA | YES | Telling PEM team about lockloss | 18:06 | |
| 22:55 | ISC | Keita | OpticsLab | y(local) | ISS array | 00:25 |
TITLE: 07/10 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 26mph Gusts, 9mph 3min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.05 μm/s
QUICK SUMMARY:
IFO is in NLN and OBSERVING as of 21:43 UTC
Conditions look great except for slightly high winds (same as yesterday). Have been in the control room for about an hour and there have been no SQZ locklosses!
There appears to be an instability when locking ALS. The X arm green build up and ASC signals begin to shake as the DARM gain is ramped to 40 and then 400. This caused multiple locklosses until we held at green arms for a longer convergence time before going to locking ALS. I have attached a screenshot of the successful lock but the oscillation still occurred. Maybe the extra WFS convergence time ensures the green controls are more robust against the darm gain change. We should look into this.
Jennie, Elenna, Camilla, Matt
DTT saved as camilla.compton/Documents/sqz/templates/dtt/20250710_SQZdata.xml and screenshot attached.
Starting angle at 141deg
| Type | Time (UTC) | Angle | DTT Ref | Notes |
| No SQZ | 17:21:30 - 17:31:30 | N/A | ref 0 | |
| FIS Mean SQZ (no ADF) | 17:40:00 - 17:43:00 | N/A | ref 1 | |
| FIS Mid SQZ +50deg | 17:49:00 - 17:52:00 | (-) 191 | ref 2 | |
| Scatter shelf and Lockloss |
| OPO Setpoint | Amplified Max | Amplified Min | UnAmp | Dark | NLG | OPO Gain | Note |
| 80uW | 0.0518 | 0.007026 | -1.35e-5 | 7.35 | -8 | Before changing OPO temp, to match Kevins data | |
| 80uW | 0.083055 | 0.0023519 | 0.007026 | -1.35e-5 | 11.8 | -8 | With changing OPO temp |
Sheila and Matt found that we get different temperature optimizations when optimizing the SEED beam or the RF6 with OPO locked. We tested this out again by checking the NLG again before and after using Sheila's new 85532 SCAN_OPOTEMP OPO GRD state, with a silightly increased range (0.015 rather than 0.01 and 180s rather than 120s), see plot in exports/SQZ/GRD/OPOTEMP_SCAN/. It adjusted temp -0.002deg, the NLG did not change, stayed at ~11.8.
I ran a script that pulls the full 524 kHz OMC DCPD A and B channels during the no squeezing time. The data that was saved was 10 minutes of no squeezing data. I saved the data into .gwf files at the full rate, and another downsampled to 64 kHz.
The data is saved in /ligo/home/elenna.capote/OMC_DCPD/251007-102149_xcorr_data as OMC_DCPD_{A,B}_{524,64}.gwf which can be easily read by gwpy. Unfortunately I can't upload them here because the alog doesn't accept this file format, but I can pass it along to you as necessary if you don't have control room access.
Looks like the ITMY R0 alignment tramp was accepted in SDF at 300seconds from its usual 30sec back in June 16. This has been accpeted at 30sec now.
Lockloss July 07, 2025 17:54 UTC during commissioning due to commissioner error after over 14 hours locked (LL website not loading)
Randy moved the 3IFO ISS PD array (S1202968) crate from MY storage to the OSB yesterday (WP). I opened the crate, moved the transport/storage container to the vacuum lab and optics lab to inspect. It was in a good shape except that some upgrade parts weren't there. Since I'm already forgetting what happened to other units, here's the summary.
First about parts.
Next, the summary per unit.
Here's the thing about the PD array plate D1300322 (see attached). The updated version has a wider 100deg conical bore for larger beam clearance because it was found at some point (ECR E1400231) that the clearance was too small for the original bore and the reflection of some PDs will hit the bore wall at an glazing angle instead of hitting the beam dump. It's also easy to imagine that if you fiddle with the alignment for the production unit in chamber, INPUT light on some PDs will hit the bore wall first before hitting the PD surface.
We have the blue glass beam dumps for the S1202966 unit, they just need cleaned - location is sitting on top of the unit in the Optics lab.
Camilla, TJ, Dave:
Last Thursday 26th June 2025 alog85373 I restarted the HWS camera control code. We hoped this would improve the 2Hz noise comb in DARM. Initial results for F-Scan (observing) suggest it has not made much, if any difference.
Attached F-Scans show the spectra on sun22jun2025 and mon30jun2025. The 2Hz comb (blue squares) look unchanged.
More investigation is needed to verfiy we are indeed disabling the frame aquisition on all HWS cameras when H1 is in observation.
Looking at the HWS camera data, Dave's code was successfully stopping the HWS camera dueing NLN from 27th June, as expected 85373.
However, looking at the f-scans from the last week, the 2Hz comb was there until 3rd July but was gone on 4th July and hasn't returned since.
Nothing HWS related should have changed on the 3rd July (ops shift log 85519).
Excellent, thank you Camilla and Dave! This is very helpful.
Jennie W, Sheila, Ryan C, Ibrahim, Corey
Over the last 3 weeks three DARM offstep measurements (where we change the DARM offset to look at the fraction of the light from the differential mode which makes it past the OMC) have been taken.
This is so we can get data points to compare to my model of ARM to OMC mode-matching. These were done at three different CO2 X power levels.
Measurement 1: 2025/06/18 20:44:55 UTC
CO2 central heating on ITMX: 1.698W
CO2 central heating on ITMY: 1.694 W
The test is run with /ligo/gitcommon/labutils/darm_offset_step/auto_darm_offset.py . The data is processed with plot_darm_optical_gain_vs_dcpd_sum.py .
Graphs of the power after the OMC vs. optical gain are in the first plot, optical gain vs. offset and anti-symmetric port power vs. power out of the omc are in this document.
The average contrast defect is 1.07 mW, the junk light is 679 mW, the transmission of the differential mode light at the AS port by the OMC is 1/1.217 = 82.2%.
Measurement 2: 2025/06/20 15:11:46 UTC
CO2 central heating on ITMX: 1.698 W
CO2 central heating on ITMY: 1.711 W
The test is run with /ligo/gitcommon/labutils/darm_offset_step/auto_darm_offset.py . The data is processed with plot_darm_optical_gain_vs_dcpd_sum.py .
Graphs of the power after the OMC vs. optical gain are in the first plot, optical gain vs. offset and anti-symmetric port power vs. power out of the omc are in this document.
The avergae contrast defect is 1.03 mW, the junk light is 677 mW, the transmission of the differential mode light at the AS port by the OMC is 1/1.212= 82.5%.
Measurement 3: 2025/06/30 15:06:50 UTC
CO2 central heating on ITMX: 1.698 W
CO2 central heating on ITMY: 1.721 W
The test is run with /ligo/gitcommon/labutils/darm_offset_step/auto_darm_offset.py . The data is processed with plot_darm_optical_gain_vs_dcpd_sum.py .
Graphs of the power after the OMC vs. optical gain are in the first plot, optical gain vs. offset and anti-symmetric port power vs. power out of the omc are in this document.
The avergae contrast defect is 1.09 mW, the junk light is 694 mW, the transmission of the differential mode light at the AS port by the OMC is 1/1.212= 82.5%.
This is not a very good test for our purposes as I think we want a larger change in mode-matching from thermal tuning to inform our simulations of Arm->OMC mode-mis-match.
Each time we have stepped the CO2Y down (all these darm offset measurements were meant to be repeated after decreasing the CO2 power) for this test (measurement 2 on the 20th June, alog 85238 shows attempt from 23rd June, alog 85335 shows attempt from the 25th June, alog 85429 is measurement 3) we have lost lock, so we might not be able to repeat this measurement with a larger CO2 step.
Camilla pointed out its annular heating we are changing with the C02s here, not central.
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.
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.
Some strange things:
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.
Sheila, Camilla
Data to take and how each data is used in the model:
Edited instruction for:
Back to observing at 18:00 UTC.
BS and PRM needed adjustment during DRMI locking, but no initial alignment was run. Also had an unknown lockloss during LOWNOISE_ASC, so acquisition took a bit longer this time.
For the lockloss from lownoise ASC, there appears to be some glitch in the suspension channels about 30 seconds before the lockloss, and it appears in all four test mass L2 channels and not in EX L3, suggesting it is coming from the ASC. However, I don't see any glitch in the ASC channels themselves. I also don't know if this caused the lockloss, or is just random. Pointing out in case we see it again.