Displaying reports 1261-1280 of 84513.Go to page Start 60 61 62 63 64 65 66 67 68 End
Reports until 17:36, Friday 11 July 2025
H1 SUS
oli.patane@LIGO.ORG - posted 17:36, Friday 11 July 2025 (85699)
Satamp swap OSEM noise part 2 (ITMX, ITMY, SR2)

I ran my damp_regression_compare script (85369) on the suspensions that we swapped the satellite amplifiers for today, BS, PRM, PR3, SRM, and SR3. The results show a decrease in the OSEM noise of at least 2x!

Part of what the script does is save the channel data as a .mat file so it's quicker to run next time, so I'll post that as well as the results.

On Tuesday Fil swapped the sat amps for ITMX, ITMY, and SR2 (85619). Like I did for the first set of satamp swaps (85485), I've used my damp_regression_compare script found in sustrunk to compare the noise performance (85369).

ITMX
M0
Results: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/SAGM0/Results/allDampRegressCompare_H1SUSITMX_M0_NoiseComparison_1435482383vs1436080373-1200.pdf
         r12442
Data: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/SAGM0/Data/dampRegress_H1SUSITMX_M0_1435482383_1200.mat
      /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/SAGM0/Data/dampRegress_H1SUSITMX_M0_1436080373_1200.mat
      r12442
R0
Results: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/SAGR0/Results/allDampRegressCompare_H1SUSITMX_R0_NoiseComparison_1435482383vs1436080373-1200.pdf
         r12443
Data: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/SAGR0/Data/dampRegress_H1SUSITMX_R0_1435482383_1200.mat
      /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMX/SAGR0/Data/dampRegress_H1SUSITMX_R0_1436080373_1200.mat
      r12443

ITMY
M0
Results: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGM0/Results/allDampRegressCompare_H1SUSITMY_M0_NoiseComparison_1435482383vs1436080373-1200.pdf
         r12444
Data: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGM0/Data/dampRegress_H1SUSITMY_M0_1435482383_1200.mat
      /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGM0/Data/dampRegress_H1SUSITMY_M0_1436080373_1200.mat
      r12444
R0
Results: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGR0/Results/allDampRegressCompare_H1SUSITMY_R0_NoiseComparison_1435482383vs1436080373-1200.pdf
         r12445
Data: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGR0/Data/dampRegress_H1SUSITMY_R0_1435482383_1200.mat
      /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ITMY/SAGR0/Data/dampRegress_H1SUSITMY_R0_1436080373_1200.mat
      r12445

SR2
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SR2/SAGM1/Results/allDampRegressCompare_H1SUSSR2_M1_NoiseComparison_1435482383vs1436080373-1200.pdf
         r12446
Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SR2/SAGM1/Data/dampRegress_H1SUSSR2_M1_1435482383_1200.mat
      /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SR2/SAGM1/Data/dampRegress_H1SUSSR2_M1_1436080373_1200.mat
      r12446

Non-image files attached to this report
H1 General (Lockloss)
ryan.crouch@LIGO.ORG - posted 16:59, Friday 11 July 2025 - last comment - 18:28, Friday 11 July 2025(85704)
23:57 UTC lockloss

23:57 UTC lockloss

Comments related to this report
ryan.crouch@LIGO.ORG - 18:28, Friday 11 July 2025 (85706)

01:27 UTC Observing

LHO General
ryan.short@LIGO.ORG - posted 16:28, Friday 11 July 2025 (85701)
Ops Day Shift Summary

TITLE: 07/11 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Two locklosses this shift, but recovery so far has been straightforward. H1 is currently relocking and up to MAX_POWER.

LOG:

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
18:26 ISC Keita OptLab N ISS array work 19:20
20:16 FAC Randy MY N Plug in forklift 20:31
20:17 ISC Jennie OptLab Local ISS array work 20:54
21:50 PEM RyanC VacPrepLab N Testing dust monitors 22:24
23:03 ISC Keita OptLab N ISS array work Ongoing
H1 General
ryan.crouch@LIGO.ORG - posted 16:01, Friday 11 July 2025 - last comment - 16:43, Friday 11 July 2025(85700)
OPS Friday EVE shift start

TITLE: 07/11 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 10mph Gusts, 6mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

Comments related to this report
ryan.crouch@LIGO.ORG - 16:43, Friday 11 July 2025 (85703)

23:43 UTC Observing

H1 General (Lockloss)
ryan.short@LIGO.ORG - posted 15:36, Friday 11 July 2025 - last comment - 16:43, Friday 11 July 2025(85697)
Lockloss @ 22:23 UTC

Lockloss @ 22:23 UTC after 4.5 hours locked - link to lockloss tool

No obvious cause, but ETMX starts moving strangely about a half a second before the lockloss.

Images attached to this report
Comments related to this report
ryan.crouch@LIGO.ORG - 16:43, Friday 11 July 2025 (85702)

23:43 UTC Observing

H1 SUS (SUS)
edgard.bonilla@LIGO.ORG - posted 15:12, Friday 11 July 2025 (85695)
SR3 M1 to M1 transfer functions with calibrated OSEMs

We grabbed the measurement data that Oli generated on [LHO: 85288] which was taken using the calibrated OSEMINF gains that we obtained by driving the ISI an looking at the OSEM response at high frequencies [see LHO: 84367].

The TL;DR is that the calibration works:

The .pdf attached can be found in

https://svn.ligo.caltech.edu/svn/sus/trunk/HLTS/H1/SR3/SAGM1/Results/2025-06-24_1900_H1SUSSR3_M1_ALL_TFs.pdf

We can see that the diagonal M1 to M1 modeled and measured transfer functions actually match one another much better than before (for an example uncalibrated plot, click here to see April 2025). This happens even though the calibration did not involve M1 to M1 transfer functions.

 

We can assess the impact that the calibration had on the M1 to M1 cross-couplings by plotting a normalized version of the cross-coupled transfer functions. For example, the Length-Pitch normalized transfer function will be (L2P)norm=(L2P)/sqrt(P2P*L2L).

This way we can get rid of the overall scaling factors that come from the OSEM calibration and focus on the cross-coupling. The result is shown in the second attachment. The columns correspond to M1 drives, and the rows are OSEM displacements, all plots are dimensionless. The blue trace is after OSEM calibration, and red is before OSEM calibration, and from 2024/08/08 to avoid the gains that were in the yaw and pitch TEST drive paths in the more recent data [see LHO: 84259].

The cross-couplings of=n this last plot can be broken down into 4 general types of cross-couplings:

1) Things that don't change much (L2T, L2P, etc)- Nothing to say.

2) Cross couplings that improve quite a bit with the calibration. [V2R, V2P R2V, and R2P]. This were what we expected from the original calibration procedure. Especially cross-couplings involving the Roll degree of freedom were expected to improve.

3) Cross couplings that got a bit worse, but were expected [Y2R, Y2V, L2V, and L2R]. These are related to the fact that the average calibration for the LF and RT OSEMs is very different for the three osems atop the suspension T1, T2, and T3. The cross-coupling is not higher, it's just a normalization quirk.

4) Cross-coupling that got worse and was unexpected. Only P2R fits this category. The calibration should make the plant more symmetric, so it is at least good that P2R and R2P seem more similar now. Since the coupling that's changing is going to Roll, we believe this is actually more accurate to the underlying Pitch-Roll plant compared to the results from before.

The next steps for this work are to semi-automate the calibration process, and to methodically deploy the calibration to other suspensions now that the SatAmp work has been done.

Images attached to this report
Non-image files attached to this report
X1 SUS
oli.patane@LIGO.ORG - posted 12:31, Friday 11 July 2025 (85674)
bbssopt parameter set updated

We have finally confirmed that the current BBSS build is stable for both LHO and LLO, and we have figured out the model parameter set that matches the builds, so I've finally gone ahead and merged the parameter changes from the parameter set we had been using as the default for a while, bbssopt_2025_d0plus3p0_l1mins3p0_m2plus0p3_FDRd1plus3p5.m, into bbssopt.m (r12435). The differences between the original FDR parameter set (from T2000599-v1) and this hopefully final set are as follows:

I have used my compareallbbss_tfs.m script (CSWG:11252) to make comparison plots between the BSFM, the original FDR parameter set from T2000599-v1, and this parameter set. This parameter set has been uploaded to T2000599 as -v4.

H1 General (DetChar, INJ)
geoffrey.mo@LIGO.ORG - posted 12:16, Friday 11 July 2025 (85694)
Latest safety results from November 2024 injections

Here are the latest H1 safety results from the November 2024 injections (sorry for the very long delay): https://drive.google.com/drive/folders/1CgwhWlKpG9CFnaiLvHnF2bWZVyHMN4gz?usp=sharing. It'd be great if folks could take a quick scroll through this spreadsheet (sorted by statistically most unsafe at the top) and see if there are any channels which have been determined to be unsafe (column F) which shouldn't be, or if there are any that should be added to the channel lists. Thanks!

LHO VE
david.barker@LIGO.ORG - posted 11:29, Friday 11 July 2025 (85692)
Fri CP1 Fill

Fri Jul 11 10:07:27 2025 INFO: Fill completed in 7min 24secs

Jordan confirmed a good fill curbside.

Images attached to this report
H1 TCS
oli.patane@LIGO.ORG - posted 11:05, Friday 11 July 2025 (85690)
TCS Monthly Trends FAMIS

Closes FAMIS#28462 , last checked 84837

CO2 Trends (ndscope1)

Everything is looking good

HWS Trends (ndscope2)

Everything is generally looking good, with both ITMX and ITMY SLEDPOWERMON slowly going down, which they tend to do. The only possible concern I can see would be that zooming out to almost a year ago (ndscope3), it looks like the level that ITMX SLEDPOWERMON is at now is a lower value than it has been in the past year.

Images attached to this report
H1 ISC (Lockloss)
elenna.capote@LIGO.ORG - posted 10:45, Friday 11 July 2025 (85688)
PIMON running on CR computer

Since we had a few PI-caused locklosses last week, we realized that the PI monitor (PIMON) didn't seem to be running properly and saving the data 524 kHz DCPD data at the end of the lock. TJ has been trying to debug the issue. In the meantime, I have left PIMON running on a control room computer that I am logged into, and the lockloss data is being saved into /ligo/gitcommon/labutils/PIMON/locklosses and the script plot_locklosses.py in /ligo/gitcommon/labutils/PIMON can be used to plot the data from the locklosses.

Fortunately, we haven't had any PI locklosses that we know of since last week. Whenever control room computers are rebooted, we need to restart the script.

H1 General (Lockloss)
ryan.short@LIGO.ORG - posted 08:52, Friday 11 July 2025 - last comment - 11:24, Friday 11 July 2025(85685)
Lockloss @ 15:41 UTC

Lockloss @ 15:41 UTC after 18 hours locked - link to lockloss tool

No obvious cause that I can see.

Comments related to this report
ryan.short@LIGO.ORG - 11:02, Friday 11 July 2025 (85689)

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.

elenna.capote@LIGO.ORG - 11:24, Friday 11 July 2025 (85691)

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.

Images attached to this comment
H1 SUS
oli.patane@LIGO.ORG - posted 16:37, Tuesday 01 July 2025 - last comment - 15:34, Friday 11 July 2025(85485)
Satamp swap OSEM noise first looks

I ran my damp_regression_compare script (85369) on the suspensions that we swapped the satellite amplifiers for today, BS, PRM, PR3, SRM, and SR3. The results show a decrease in the OSEM noise of at least 2x!

Part of what the script does is save the channel data as a .mat file so it's quicker to run next time, so I'll post that as well as the results.

BS
Results: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Results/allDampRegressCompare_H1SUSBS_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
      r12374

Data: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1BS_M1_1435348334_1200.mat
     /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1BS_M1_1435435046_1200.mat
    r12373

PRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Results/allDampRegressCompare_H1SUSPRM_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
      r12376

Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1PRM_M1_1435435046_1200.mat
     /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1PRM_M1_1435348334_1200.mat
     r12375

PR3
Results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Results/allDampRegressCompare_H1SUSPR3_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
      r12380

Data: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/dampRegress_H1PR3_M1_1435348334_1200.mat
     /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/dampRegress_H1PR3_M1_1435435046_1200.mat
     r12379

SRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Results/allDampRegressCompare_H1SUSSRM_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
      r12378

Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SRM_M1_1435435046_1200.mat
    /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SRM_M1_1435348334_1200.mat
    r12377

SR3
Results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Results/allDampRegressCompare_H1SUSSR3_M1_NoiseComparison_1435348334vs1435435046-1200.pdf
      r12382

Data: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/dampRegress_H1SR3_M1_1435348334_1200.mat
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/dampRegress_H1SR3_M1_1435435046_1200.mat
    r12381

Non-image files attached to this report
Comments related to this report
oli.patane@LIGO.ORG - 15:34, Friday 11 July 2025 (85696)

Since a few of the before times I picked for some of the suspensions were during times where they had ISC control on, I've rerun them with a better starting time where there was no ISC control

BS
Results: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Results/allDampRegressCompare_H1SUSBS_M1_NoiseComparison_1435154988vs1435435038-1200.pdf
      r12436

Data: /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1SUSBS_M1_1435154988_1200.mat
     /ligo/svncommon/SusSVN/sus/trunk/BSFM/H1/BS/SAGM1/Data/dampRegress_H1SUSBS_M1_1435435038_1200.mat
     r12437

PRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Results/allDampRegressCompare_H1SUSPRM_M1_NoiseComparison_1435154988vs1435435046-1200.pdf
      r12438
Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1SUSPRM_M1_1435435046_1200.mat
     /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/dampRegress_H1SUSPRM_M1_1435154988_1200.mat

     r12438

SRM
Results: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Results/allDampRegressCompare_H1SUSSRM_M1_NoiseComparison_1435154988vs1435435046-1200.pdf
      r12441
Data: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SUSSRM_M1_1435435046_1200.mat
    /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data/dampRegress_H1SUSSRM_M1_1435154988_1200.mat

    r12441

Non-image files attached to this comment
H1 ISC (SQZ)
jennifer.wright@LIGO.ORG - posted 13:07, Monday 30 June 2025 - last comment - 09:45, Friday 11 July 2025(85434)
DARM Offset Steps while changing CO2s

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.

 

Images attached to this report
Non-image files attached to this report
Comments related to this report
jennifer.wright@LIGO.ORG - 09:45, Friday 11 July 2025 (85687)

Camilla pointed out its annular heating we are changing with the C02s here, not central.

H1 ISC
jennifer.wright@LIGO.ORG - posted 10:33, Friday 16 May 2025 - last comment - 15:56, Friday 11 July 2025(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
Displaying reports 1261-1280 of 84513.Go to page Start 60 61 62 63 64 65 66 67 68 End