Displaying reports 1-20 of 88684.Go to page 1 2 3 4 5 6 7 8 9 10 End
Reports until 20:27, Wednesday 29 July 2026
H1 ISC
madison.simmonds@LIGO.ORG - posted 20:27, Wednesday 29 July 2026 (91306)
ALS-X Mode-mismatch investigation

Madi

I've been reviewing data from 2024 to quantify the ALSX mode-mismatch, with the hope of comparing the mode-mismatch from the cavity scan to the mode-mismatch observed from the return ALS beam, measured 90370. The cavity scans were recorded in 80077 , and follow on from the ALSY cavity scans 80065. I pulled the historical data into ndscope, so I was able to get direct numbers for the relevant data. 

There were two scans performed - one with an 'okay' alignment, and one with 'better' alignment. The 'better' alignment scan does not swing through a full FSR, so the mode frequencies could not be measured, however the magnitude distribution ratio could still be calculated to determine the mode-mismatch. 

The 'okay' alignment had a 2.19% mode-mismatch, while the 'better' alignment had a 1.78% mode-mismatch.

 

Images attached to this report
H1 CDS
anthony.sanchez@LIGO.ORG - posted 19:22, Wednesday 29 July 2026 (91320)
Wednesday Ops Eve* Shift Coverage report.

We noticed that H1ISIBS had gone down and check the dmesg logs to find this: 
[29807.260951] h1iopseib2: WARN - Missed an expected DAC sample, DAC card: 1, chan 13, time_sec: 1469407411, cycle: 32769
[29808.620352] h1isibs: ERROR - Waiting for ADC cycle 32737, live read is 53217, mm: 0, ioMemCtr: 4065
[29808.620529] h1isibs: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
[31724.338050] perf: interrupt took too long (3129 > 3127), lowering kernel.perf_event_max_sample_rate to 63750 

Jonathan restarted the model ~ around 2:15 UTC -ish. 

 

H1 CDS
jonathan.hanks@LIGO.ORG - posted 18:53, Wednesday 29 July 2026 (91319)
WP13457 CDS Ethernet IPC/RCG Upgrade status

EJ, Erik, Jonathan, Tony, Dan M,

This morning EJ and Jonathan started models on the systems and did a daqd restart as rcg5.6 adds a few new channels.  We found that there were install problems with h1suslo12 and h1susauxh6.  EJ looked into those and fixed some permission issues and was able to re-install the models.

We had problems with lsc, seib2, seih23

* LSC - EJ noted that the LSC system had a correctable pci error yesterday around 5:25pm localtime.  We were not controlling anything at this point.  The LSC models would not stay running.  EJ fixed some BIOS setting errors (the c-state settings were not locked to c0/c1 state) and enhanced fault state was not disabled.  EJ traced this down to spikes in the model run time to over 400ms!  We when through and tried a real time processing benchmark with no add in IO cards, the new ethernet NIC, the adnico cards (w/o fibers plugged in), the adnico cards with fibers, and then variations on which fibers.  In the end we have left the 4th adnaco disconnected.  We suspect the fiber got dirty as it was working.  There are no io cards in that chassis on that card.

* seib2 did not see any of its binary io cards.  Rebooting was sufficient to fix that.

* seih23 did not see any IO cards, a reboot fixed that.

After fixing the lsc model Erik and Tony took a spare computer out to end-X to look at seiex.  They were unable to get the computer to see the new ethernet card.  They ended up putting the spare computer in.  Once that was done seiex worked.

After seiex was running, EJ looked at the global IPC state.  We had to restart the ethernet controller and models on cdsh8, as it was erroring out on all its ipcs.  The h1omcpi was having a steady IPC error rate of about 20 errors a second.  The errors are coming from the h1ioplsc0 model.  This is a problem with the fast adc logic just taking a lot of time.  The IPCs where coming in late for the omcpi model.  EJ was able to adjust how it waited for the IPCs to clear the errors.  The base assumption on the IPCS timings is against models that are running with some headroom, the lsc iop mode is running at almost the max time that it can which gives a small window for the IPC.

We restarted h1build and h1ecatmon0 to have them booting from the new bootserver.

Dan Moraru and Jonathan looked at the cdsfs systems.  Dan was able to fix a race condition which prevented the system from doing high availability fail over for the /ligo filesystem.  Now we can move which server is serving /ligo between cfdsf2 and cdsfs3.  Migrating the /ligo filesystem causes access to the filesystem by the control room systems to pause for a few minutes.   We tested this transition a few times, and then tested it by applying system updates and reboots on cdsfs2 and cdsfs3.

Dan also put the same configuration fixes into cdsfs4 and cdsfs5.  These are designed to hold /opt/rtcds (though they are not yet).  We will continue to work on these systems as the cdsfs4 & cdsfs5 have not come back properly from updates.

 

H1 SEI
jenne.driggers@LIGO.ORG - posted 18:06, Wednesday 29 July 2026 (91317)
Distributed acoustic sensing (DAS) setup, day 3; the end stations

Gizem K, Wanda V, Jenne, Fil

Since yesterday (alog 91299) and Monday (alog 91271) we saw lots of back-reflection from the end of the fibers, today we went to the ends to terminate the fibers with what is essentially a fiber beam dump.

First, Fil went to each end, and connected a jumper fiber cable to the junction box panel at the end of each of our fibers (recall we're using #24 on each arm).  Then we went, and Gizem spliced in to that jumper fiber a cladding-only "fiber", that will absorb the light since there isn't a core to this fiber.  This termination fiber is laid inside of a pvc pipe, which is then laying on the floor, taped closed to be light-tight as well as secured to the floor using UltraTape.  

Unfortunately, the data looks more noisy now than it did earlier in the week.  Gizem and Wanda ran an OTDR test on the newly terminated fibers, and indeed the ends of the fibers seem to be absorbing the light as desired.  However the connection point between the LIGO fiber and the jumper fiber seems to have lots of reflection.  

Folks will look at the data further to help decide whether we should keep the termination fibers, or just remove them and live with the slightly-noisy data that we had earlier in the week rather than the very noisy data we have today.

Attached are some action shots of Gizem splicing, Wanda watching, and the pvc pipes we have the termination fibers in.

Images attached to this report
LHO VE (VE)
jordan.vanosky@LIGO.ORG - posted 17:10, Wednesday 29 July 2026 (91314)
Seal Replacement on GV6 Air Cylinder

Travis, Gerardo, Jordan

During the closing of GV6 back in May, we noticed that there was some blow-by in the pneumatic system when trying to hard close the valve, see alog 90093

We were able to hard close the valve eventually but as preventative maintenance we wanted to replace the air cylinder seals, similar to GV7.

Prior to disassembly we measured the locations of the reed switches from the top surface of the bottom plate to the bottom surface of the reed switches:

Bottom Switch: 1 1/8"

Top Switch: 49 1/4"

We then disassembled the air cylinder and replaced the seals following procedure/notes collected during the GV7 repair. During cleaning of the old grease on the piston head, we noticed there were two burrs on the top of the piston, we did not notice any damage to the inside of the cylinder, but as a precaution we used a small flat file to remove the burrs. We also chased the threads on the four threaded rods with a die to aid with reinstallation. After cleaning and inspection of the cylinder tube, we found no issues or damage so we decided to continue to use that cylinder and keep the new one as a spare.

No other issues encountered, we removed the old seals, cleaned the grooves, added copious amounts of the supplied grease to the o-rings, seals and the inside of the air cylinder, and then re-assembled the cylinder tube. Pictures posted below and a final procedure is in progress and will be posted to the DCC.

We did not get a chance to cycle the valve after the seal replacement, so we will continue tomorrow with cycling the valve.

 

Images attached to this report
H1 General (CDS, SEI, SUS)
anthony.sanchez@LIGO.ORG - posted 17:07, Wednesday 29 July 2026 - last comment - 18:43, Wednesday 29 July 2026(91315)
Wednesday Ops Eve* Shift Coverage.

TITLE: 07/29 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 10mph Gusts, 5mph 3min avg
    Primary useism: 0.71 μm/s
    Secondary useism: 0.12 μm/s 
QUICK SUMMARY:

Dan, Jonathan, & Erik are still working on the file server.  OPS-Overview is still all red.
But Jonathan just walked in and said I can start recovering the IFO. 
So i will start taking the SEI and the SUS back to Damped and aligned.

Comments related to this report
anthony.sanchez@LIGO.ORG - 17:13, Wednesday 29 July 2026 (91316)

PSL team said that they have relockedthe PMC and i may drift in the next 24 hours.

anthony.sanchez@LIGO.ORG - 18:43, Wednesday 29 July 2026 (91318)SEI

The HEPI, ISI, and Optics have been recovered.
All SEI Guardians for all chambers has been set to ISI Damped HEPI Offline , Except HAM7 and BS. BS ISI watchdogs are tripping for some reason. 
All Optics are set to Aligned.

 

Images attached to this comment
H1 SQZ (SUS)
camilla.compton@LIGO.ORG - posted 16:55, Wednesday 29 July 2026 (91310)
DIAG_MAIN checks of PSAMS Strain Gauge vs Target

Ryan S and I added a check in DIAG_MAIN called PSAMS() which checks that the PSAMS Strain Gauge for ZM2, ZM4 and ZM5 is within 0.1V of the target. If not, gives the message "PSAMS not at Target Voltage". This should let us know if anything goes wrong with the chassis or servo as in FRS 31062. We reloaded DIAG_MAIN and it worked as expected. 

H1 General
oli.patane@LIGO.ORG - posted 16:35, Wednesday 29 July 2026 (91313)
Ops DAY Shift End

TITLE: 07/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Tony
SHIFT SUMMARY: CDS team is still working on getting everything back up from the rcg upgrade, but we (currently) have access to /ligo back. Slow day since many systems were down because of the upgrade. All suspensions and seismic models are up and running, but we are leaving them all in safe/tripped until the upgrade is done. 
LOG:                                                                                                                                                                                                                                                                                                                               

Start Time System Name Location Lazer_Haz Task Time End
14:50 FAC Kim, Dawn LVEA n Tech clean 15:39
15:11 FAC Randy LVEA n WB cleanroom work 16:30
16:11 TCS Camilla LVEA n Replacing ITMY camera viewport 16:23
16:12 FAC Kim LVEA n Tech clean 16:54
16:33 VAC Jordan, Gerardo LVEA n GV6 repair 23:31
16:54 FAC Randy LVEA n More cleanroom work in WB 18:26
16:55 FAC Kim EY n Trash and garb 18:29
17:21 PEM Robert, Carlos, Shrey, Miranda YARM n Measurements along arm 19:31
17:24 EE RyanS, Fil, Richard, Marc LVEA n Testing EStop button (Richard out 17:33) 17:43
17:28   Betsy LVEA n Cleanroom measurements 18:31
17:45   Jim LVEA n Finding Betsy 18:22
18:17 EE RyanS, Fil LVEA n More EStop testing 18:29
18:31 VAC Travis LVEA n GV6 repair 23:31
18:33 EE Fil, Tony EY, EX, FCES n Estop/PCAL EE work 19:29
18:42 EE RyanS LVEA n Watching relay lights turn on and off 18:52
19:12 EE RyanS LVEA n Checking relay lights for fun 19:12
19:21 EE RyanS LVEA n Watching relay lights twinkling 19:24
19:33 CDS Erik, Tony EX n Fixing h1seiex 20:24
19:40 FAC Randy LVEA n Even more WB cleanroom work 21:47
19:52 EE Fil EX, EY n Connecting cable for DAS 20:48
20:02 SEI Jim LVEA n Fixing BSC2 T240s 22:24
20:07 SEI Jenne, Wanda, Gizem EX, EY n Connecting terminator to cable for DAS 22:28
20:45   Tony CER n Putting laptop back 20:50
20:50 EE Fil CER n SEI AI chassis work 22:20
21:06 PEM Robert, Carlos YARM n Taking measurements along arm 23:06
21:32 CDS Erik EY n Turning on AI chassis 23:02
21:33 CDS Jonathan, Dan MSR n Moving over everything and trying not to break everything ongoing
22:33 TCS Camilla PrepLab n CHETA work ongoing
H1 CDS (SYS)
filiberto.clara@LIGO.ORG - posted 15:40, Wednesday 29 July 2026 (91312)
CRS and SPI Fibers

WP 13462

Labels “Class 4 Laser” were installed every 10ft on the fiber runs for both SPI and CRS.

H1 AOS (CDS, Laser Safety)
patrick.thomas@LIGO.ORG - posted 14:29, Wednesday 29 July 2026 - last comment - 15:33, Wednesday 29 July 2026(91308)
updated laser safety interlock PLC code
P. Thomas, F. Clara, R. Short, T. Sanchez, R. McCarthy

WP 13441.

The laser safety interlock code is now running (temporarily) on the CX2040-0155 machine labeled 'testing' in the MSR at IP address 10.105.0.113. It is using commit 86f4fb088fbed6ce3c0e47afcdfc756547e70416 on the branch labeled 'scripting' in the lho-laser-safety gitlab repository: https://git.ligo.org/cds/ifo/beckhoff/lho-laser-safety/-/commit/86f4fb088fbed6ce3c0e47afcdfc756547e70416

The original intention was to use the machine that was already running the previous version of the code, a C5210-0020 in the MSR labeled h1safety0 at IP address 10.105.0.10. However, after reimaging this machine with the Beckhoff service tool using the IN-0406-0112-03-0-2021-21-0002H_1.TIB, IN-0406-0112-03-0-2021-21-0002H_2.TIB, and IN-0406-0112-03-0-2021-21-0002H_3.TIB images, the computer went into a cycle where it showed the Windows square with a spinning busy indicator, then went blank and restarted again and again. I then tried using the IN-0303-0010-03-0-2020-11-0001V_1.TIB, IN-0303-0010-03-0-2020-11-0001V_2.TIB, IN-0303-0010-03-0-2020-11-0001V_3.TIB, and IN-0303-0010-03-0-2020-11-0001V_4.TIB images. This started off more promising, but then went to a completely black and unresponsive screen. I contacted Beckhoff technical support and they said these were the wrong images for this machine. They sent me IN-0406-0112-03-0-2024-00-00043_1.TIB, IN-0406-0112-03-0-2024-00-00043_2.TIB, and IN-0406-0112-03-0-2024-00-00043_3.TIB. I tried these but they sent the computer into a boot cycle like the first images. They then suggested updating the code on the service tool. At this point it was getting late in the day, so the decision was made to use the test machine to get things back up and running.
I reimaged the test machine with the CX1800-0511-1009v2.4a_1.TIB, CX1800-0511-1009v2.4a_2.TIB, and CX1800-0511-1009v2.4a_3.TIB images and proceeded with the rest of the work permit.

Filiberto, Ryan, Tony and I verified the following:
IOT1 doors, LVEA Exit ESTOP, LVEA Entrance ESTOP, ISCT1 doors, IOT2 doors, PSL ESTOP, TCSY doors, TCSY ESTOP, CHETAY ESTOP, SQZ ESTOP, SQZT7 doors, SQZT0 doors, SQZ Table ESTOP, HWS doors, HWS ESTOP, TCSX doors, TCSX ESTOP, HIGH BAY Exit ESTOP, HIGH BAY Entrance ESTOP, CHETAX ESTOP, EY VEA Entrance ESTOP, EY VEA Exit ESTOP, EY ALS ESTOP, EY ALS doors, EY PCAL Enclosure, EX VEA Entrance ESTOP, EY VEA Exit ESTOP, EX ALS ESTOP, EX ALS doors, EX PCAL Enclosure, FCES ESTOP, FCES doors.
The EX PCAL enclosure only trips off the EX and EY PCAL lasers. The EY PCAL enclosure only trips off the EX and EY PCAL lasers. The CHETA doors tripped off all of the lasers, which turned out to be the wrong thing to do. Filiberto made a hardware change so that this wouldn't happen, but the code needs to be eventually changed to fix this.
Comments related to this report
patrick.thomas@LIGO.ORG - 15:10, Wednesday 29 July 2026 (91309)
For reference, the Beckhoff restore tool reads:
USB Image C9900-I901 v2.1.9.47
Computer Name: BST-000f7zrg

filiberto.clara@LIGO.ORG - 15:33, Wednesday 29 July 2026 (91311)

WP 13459

The outputs of the EP1957-0022 terminal are used to enable the CHETAY, CHETAX, and the CRS lasers. The CHETA enclosures are not installed. This required the inputs to the EP1957 for the panel/doors to be shorted. Verified enable outputs were present when system was nominal. Verified enable outputs went to 0V when an e-stop was pushed. Same was done for the CRS.

To clear the error on the EL2904, a phoenix safety relay was installed. This satisfied the minimum required load.

H1 General
oli.patane@LIGO.ORG - posted 07:36, Wednesday 29 July 2026 (91304)
Ops DAY Shift Start

TITLE: 07/29 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
QUICK SUMMARY: More work to be done for the rcg update today

H1 AOS (PSL)
matthew.heintze@LIGO.ORG - posted 06:15, Wednesday 29 July 2026 (91303)
PSL amplifier/laser diode run hours

[Matt, Jason O, Maik F (remote)]

We wanted to see the run hours on the PSL systems at both sites to check on the health of everything (and as an easy kickoff on the FCA review of the detector itself....see slide 10 of G2610464). The chillers we swap out regularly to get refurbished so we have no concerns there, but the PSL laser diode lifetimes are the point of interest here. 

 

LLO

LLO finished the O4 upgrade of the PSL circa November 2022.

LLO appear in very good shape. The run hours LLO have are:

AMP1: 30,427 hours

AMP2: 30,399 hours

From Maik "The diodes have the standard specifications of 20,000h but the vendor typically says that they will do more than 30,000h which you proved !"!

The diode currents for the laser diodes at LLO has not been changed from its initial set points at install.

Note: The laser diode current has to be changed as the laser diodes start to die to maintain the same output power from the diode itself and retain the thermal lens profile of the crystals inside the amplifier. 

 

LHO

LHO finished their O4 upgrade of the PSL circa February 2022. 

LHO are in a bit more of a concerning shape than LLO. The run hours LHO have are:

Amp1: 38,512

Amp2: 38,365

More concerningly from LHO's point of view, LHO HAVE had to start adjusting their laser diode currents to maintain output form their laser diodes. From Jason "We’ve been able to keep output power good by increasing the injection currents, but our PMC reflected power has more than doubled since install (~12 W -> ~28 W).  I can’t get it lower with injection current increases, further increases only increase PMC Refl; at this point we’d have to redo the mode matching to the PMC to restore our original power available to the IFO"

 

Summary

Both sites laser diodes are beyond the manufacturers specifications for runtime. 

LHO have around a year of extra runtime on their laser diodes and the LHO diodes have started to degrade in terms of performance. 

Each site does have a complete set of spare diode boxes that can be swapped in. LLO's have hours on them as they are part of the T&T lab setup, but LHO's should still be brand new (other than burn in time). However we do need to starting thinking/planning about refurbishing (or buying new), laser diodes for the PSL system. So at this point in time both sites should be fine for the IR1 run (however laser diodes typically degrade at a non-linear rate and so LHO will have to keep an eye on their performance and make a judgment call on if they think they need to swap theirs at some stage). However for O5 (or even the upgrades/commissioning before them), both sites are going to have to swap out to fresh laser diodes. 

Images attached to this report
H1 CDS
jonathan.hanks@LIGO.ORG - posted 19:08, Tuesday 28 July 2026 (91302)
WP13457 CDS Ethernet IPC/RCG Upgrade status

Jonathan, Dave, Erik, Tony, Cory, EJ,

As per WP 13457 we started the dolphin to ethernet transition today.

We broke into two groups, Dave and Tony when to the end stations.  Erik, Jonathan, and Cory worked in the corner station.  EJ provided remote support.

Current status:

Issues that we have hit

We have shown the ability to pass some IPC traffic between a few nodes.  We are doing a fresh build and install of the models to fix an issue with the target/install folder location being incorrect.  We plan on starting the models tomorrow morning.

The seis ai chassis are on in the end stations, and off in the corner station.

H1 ISC
camilla.compton@LIGO.ORG - posted 16:44, Tuesday 28 July 2026 - last comment - 09:25, Wednesday 29 July 2026(91293)
Reworked ITMX Camera can re-attached to X-arm adapter plate

TJ, Camilla, Tyler. WP 13451

The ITMX camera that was removed from A-1C VP4 in 90949 has now been reattached to A-1C VP5. The camera can extender needed to be reduced in thickness, Tyler did this. Camera can D970211-014, camera Balser, lens Rainbow H20X15M  and adjustable post Giotto MH1303, are originally from ITMY, swapped so height would work better. CDS camera was down so we could not yet check and adjust pointing. 

The ITMY reworked camera can is still too wide to for between the VP and Oplev Pier 91160, will now re-work the newer D1300705 type instead which will be more convenient with side access. 

Edits: Originally wrote this as if we installed ITMY camera, we did not, this is ITMX. 

Comments related to this report
camilla.compton@LIGO.ORG - 09:25, Wednesday 29 July 2026 (91305)

After speaking with Richard I re-inserted the guillotine as I think the the camera came loose it's currently in a location where it could fall forward and hit the VP. 

H1 SQZ
eric.oelker@LIGO.ORG - posted 11:21, Wednesday 01 July 2026 - last comment - 14:32, Wednesday 29 July 2026(90845)
Determining the ROC for ZM4 and ZM5

[Sheila, Camilla, Ryan, Eric]

We would like to verify that our recent mode measurements after ZM5 ( 90783) and before ZM4 (90815 ) make sense by connecting the two.  We decided to use the q value from the measurement at the nominal ZM2 strain in 90815 (ZM2 strain = 3.15V) and propagate that mode through the path containing ZM4 and ZM5 and calculate the overlap with the q values from 90783 measured at different strain settings for ZM4/ZM5.  The goals here are as follows:

  1. Improve our model of the ZM4 - to - SEC path and verify that we're interpreting our mode measurements (with M^2 > 1) correctly.  
  2. Determine the ROC for ZM4 and ZM5 as a function of the strain gauge voltage.  This is particularly important since we are going to replace ZM5 and Camille would like to know what ROC to shoot for with the pre-stressing procedure.

 

First, I address item 1.

Mode Measurements with M2 > 1:

Our system seems to be adding some higher order abberations to the beam.  As a result, our mode measurements indicate that we have an M^2 number significantly above 1 (between 1.2 - 1.5 depending on the PSAM settings).  When M^2 is > 1, the presence of HOM content in the beam prevents one from focusing down to as tight of a waist, for the same divergence angle, the beam radius at the waist will be larger by a factor of M.  The thorlabs beam profiler accounts for this by fitting the data to the following formula (which we confirmed by doing our own independent fit):

w(z)2 = wM2[1 +(z - z0)2 (pi*wM2/(M2*lambda))2]

Where wM2 = M2*w02  Is the waist for a beam with M2>1, and w0 is the waist for the TEM00 component of the beam (ie for M2 = 1). 

The q parameter ends up the same as before:

q(z) = (z-z0) + i*zR

where zR = pi*w02/lambda = pi*wM2/(lambda* M2)

Knowing that M2 > 1 tells us that our beam is a mixture of TEM00 and some higher order mode content.  However, from the M2 value alone we don't know which higher order modes are excited (in principle one might be able to make some rough projections using the surface abberation measurements of the PSAMs from Caltech, but that sounds tricky and is beyond the scope of today's post).  If we want to do mode matching calculations, the only thing we can do at the moment is back propagate the TEM00 component and do all mode calculations for TEM00.  

We use the same beam propagation matricies as always to back propagate the TEM00 component to determine what the TEM00 mode looks like in HAM 7.  

Determination of the ZM4 and ZM5 ROCs

I then took the q value (for the nominal ZM2 = 3.15V) from the measurement before ZM4, back propagated it to ZM4 using our length measurements.  I then propagated the q through ZM4 and ZM5 and calculated the overlap with the q values measured after ZM5 for various values of the ZM4/ZM5 strain gauge settings in ( 90783)

Then, the ROCs for ZM4 and ZM5 were chosen for each strain gauge settings to maximize the overlap.  The overlap is => 98% over the entire 2D grid of ZM4/ZM5 strain gauge values, which gives us some confidence that the ROC values are accurate.  One thing that gives us pause is that the change in ROC for ZM5 doesn't appear to change linearly in diopters with the strain gauge reading.  ZM4, on the other hand is roughly consistant with a 5 mD/V change though because the beam spot is quite small on ZM4, we are relatively insensitive to its ROC value.

ZM4 Strain (V) ZM4 ROC (m)
2.0 -12
4.0 -11
6.0 -10
8.0 -9

 

ZM5 Strain(V) ZM5 ROC (m)
-4.5 3.8
-2.0 4.05
0.0 4.4
2.0 4.55

 

These values give the following overlaps for the x and y direction (our mode measurements indicate we have non-negligible asitgmatism on this path) for propagating the nominal q value from (90815 where ZM2 strain = 3.15) to the q vales from ( 90783) .

ZM4 \ ZM5 -4.5 -2.0 0.0 2.0
2.0 x = .994, y = .995 x = .998, y = .997 x = .990, y = .995 x = .9874, y = .993
4.0 x =.996, y = .997 x = .994, y = .995 x = .986, y = .992 x = .983, y = .991
6.0 x =.995, y = .997 x =.992, y = .993 x =.983, y = .989 x =.980, y = .984
8.0 x =.993, y = .995 x =.990, y = .992 x =.980, y = .984 x =.977, y = .980

The fact that this set of ROC values gives good overlap over the entire 2D grid suggests that these ROCs are a resonable model for ZM4 and ZM5 at these strain gauge settings.

 

Attached is an a la mode file for doing the beam propagation.  One could do some more intellegent fitting of the data to extract the best ROC estimates; I'm just sorta hand fitting it at the moment.

Non-image files attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 15:08, Wednesday 01 July 2026 (90859)

We have ZM5 SN4 installed now. Original data before we changed the preloading (E2100297) had the ROC range 3.0m to 3.9m. With at 0V applied 667mD optical power, with 200V applied 508mD.

In alog 75709 we increased the preload from 20 in lb to 47 in lbs. An estimated linear increase of 65mD as according to T2300426, changing the preloading changes the optical power by 2.4mD/in.lb.The preloading should make the magnitude of the optical power larger, so it should be increased to 667mD - 2.4mD/in lb * 27 in lbs = 602mD mD with 0 V on the PZT, 443mD with 200V on the PZT. This is an estimated ROC range of  3.3 to 4.5 meters for strain gauge -5.0 to +2.6V (it's range with 0V and 200V applied). This mostly agrees with Eric's data. 

We have ZM4 SN1 installed now. Original data before we changed the preloading (E2100289) had the ROC range -19.3m to -9.0m. With at 0V applied -104mD optical power, with 200V applied -221mD.

In alog 75677 we increased the preload from 46 in lb to 75 in lb. An estimated linear increase of 70mD.  This should be increased to -104mD - 2.4mD/in lb * 29 in lbs = -174mD mD with 0 V on the PZT, -291mD with 200V on the PZT.  This is an estimated ROC range of -11.5 to -6.9 meters for strain gauge 1.0 to 8.3V. This mostly agrees with Eric's data.

eric.oelker@LIGO.ORG - 09:02, Thursday 02 July 2026 (90873)

I attempted to confirm these values by repeating this exercise with a second dataset from 90827.  This was an additional set of q measurements made directly after ZM4.  The idea here is that this should allow us to fit the ROC values for ZM5 only by taking these measured qs, propagating them through ZM 5 and comparing with the measurements from 90783.  Unfortunately this did not proceed as smoothly.  The fits and mode overlap values are tabulated below.  This isn't too far from the old ROC range, but the agreement between the q values isn't nearly as good as before

 

Rough values for ZM5:

ZM5 Strain (V) ZM5 ROC (m)
-4.5 4.0
-2 4.3
0 4.7
2 4.9

 Mode overlap after propagating through ZM5 assuming the above ROC values.  I was mostly optimizing the y value; the astigmatism seemed to be quite different in this dataset, leading to poor x/y agreement when propagating and comparing with the other data.  

ZM4 \ ZM5 -4.5 -2 0 2
2 x = .975, y = .996 x = .976, y = .990 x = .954, y = .986 x = .948, y = .982
4 x = .981, y = .994 x = .971, y = .986 x = .956, y = .982

x = .947, y = .981

6 x = .974, y = .992 x = .969, y = .990 x = .946, y = .977 x = .937, y = .971
8 x = .969, y = .990 x = .955, y = .980 x = .940, y = .970 x = .930, y = .963

 

Non-image files attached to this comment
sheila.dwyer@LIGO.ORG - 16:46, Monday 06 July 2026 (90909)

Attached is a Sw plot at SRM made using the ROCs Eric logged above, and the measured q at the input of ZM4.

The measurements seem to be systematically different from the prediction based on ROC and the input q.  I reproduced the overlaps that Eric listed above, and they are similarly above 98% for all of these (the overlap between the prediction and the measurement for each strain guage pair).  

I also made a linear estimate of the diopters per strain guage based on the ROCs that Eric listed above, for ZM4 this give -7mD/ strain guage volt (for -11m ROC at 4V SG), for ZM5 -10.5mD/ SG V (for 4.05m ROC with SG at -2V).  This is shown by the orange stars and blue + in the attached plot, there is some discrepancy with the red and brown "predicted" points (based on just the ROCs that Eric listed above and the input q), because of the nonlinearity of Eric's ZM5 ROCs.  

 

Images attached to this comment
sheila.dwyer@LIGO.ORG - 09:38, Tuesday 07 July 2026 (90919)

Continuing from Camilla's accounting of where we want the ZM4 preload to be.  

Eric's ROC values above show the range to be from -12m ROC to -9meters (this is not quite the full range but close to it), which is -170mD to -220 mD, so the range of ZM4 psams seems to be close to 50mD.  In Camille's original charachterization data before the preload change E2100289 the range was 118mD.  

If we make a decision on where we want to move ZM4 based on the OMC matching grid in the attachment to 90804, we would gues that we'd want the lower edge of the ZM4 range to be in the middle of the range.  This means we want to reduce the pre-load by 25mD,  reducing the pre-load by 10 in lbs, to 65 in lbs.  

sheila.dwyer@LIGO.ORG - 15:46, Tuesday 14 July 2026 (91013)

Above, Eric found ROCs for each strain guage value that can predict our measured q's after ZM5 (90783) starting with the measured q before ZM4, where the predicted qs overlapped with the measured qs by more than 98%.  We are aiming for sqz to OMC mode matching of better than 99%, so I wondered if we can get better agreement than this with our measurement technique.  If we want to be able to set ROCs or distances based on these measurements, we want to know if they are repeatable and consistent with a model at a level better than the mode matching that we are trying to acheive.  In O4 we had squeezer to OMC mode mismatch of 2.2%, we would like that to be less than 1%.

I take the q's measured after ZM5, propagate them back to before zm4 using the guesses for ROCs and the AOIs from the finesse .yml file, and calculates the overlap with the measured q before ZM4 for each.  The sum off the mode mismatches is the cost function used to fit either vertical or horizontal ROCs.  In this version of the script, it is fitting either the vertical or horizontal data, I would like in the future to have it include both in the cost function.

These plots (horizontal and vertical) show that this fitting results in overlap between the measured beam and the forward propagated beam using the fit ROCs is better that 99.5% for all the data.  This is true when I use only the horizontal (vertical) data in the fit, and use those ROCs to propagate the vertical (horiztonal) mode.  The worst overlaps are all for points measured where ZM5 strain guage was at -4.5V, which also had the worst values of M^2 (see top left panel).  

Using these fit ROCs and the measured q before ZM4, we can propagate to the usual Sw plot on the AR side of SRM, using either vertical or horizontal data gives us an sw plot that looks a lot closer to the measured data than the guesses above.  I think this means that we can use this kind of fit data to determine what ROC we need to move us to a particular place in Sw space in the future, at least at the level of 0.5% mode matching. 

ZM4 (strain guage voltage) 2 4 6 8
ROC fit with vertical data[m] -8.687 -7.699 -6.923 -6.280
ROC fit with horiztonal data [m] -7.621 -6.886 -6.313 -5.798
ZM5 (strain guage voltage) -4.5 -2 0 2
ROC fit with vertical data [m] 3.600 3.889 4.266 4.351
ROC fit with horizontal data [m] 3.544 3.852 4.190 4.273

The script to make these fots and plots can be found here

 

Images attached to this comment
eric.oelker@LIGO.ORG - 10:01, Wednesday 15 July 2026 (91046)

I was curious to see what Sheila's improved fits imply for our hunt for the source of astigmatism in HAM 7.  Below I've tabluated some calculations for the astigmatism, which I define as the difference in focusing power between the horizontal (X) and vertical (Y) directions for ZM4/5

 

For ZM4

ZM4 SG 2 4 6 8
Rx (m) -7.621 -6.886 -6.313 -5.798
Ry (m) -8.687 -7.699 -6.923 -6.280
Dx - Dy (mD) -32.2 -30.7 -27.9 -26.5
Dx/CosT - Dy*CosT (mD) -50.5 -51.1 -50.4 -51.1

Here T is the angle of incidence (15.5 degrees for ZM4).  The total astigmatism (line 5 in the table) includes both the physical astigmatism (line 4 in the table) due to non-uniformity in the ROC of the PSAM optic as well as the astigmatism resulting from non-normal incidence.  By comparing lines 4 and 5, we see that, for ZM4, the impact of the relatively large angle of incidence is also a significant source of astigmatism.  

 

For ZM5

ZM5 SG -4.5 -2 0 2
Rx (m) 3.544 3.852 4.190 4.273
Ry (m) 3.600 3.889 4.266 4.315
Dx - Dy (mD) 8.8 4.9 8.5 8.4
Dx/CosT - Dy*CosT (mD) 13.0 8.9 12.1 11.9

Here T is the angle of incidence (5 degrees for ZM5)

 

The physical astigmatism (Dx - Dy) of the PSAM optics appear to be typical of the characterization data at Caltech in 2021.  

See this presentation from Lee McCuller:  https://docs.google.com/presentation/d/12UynUfIfyXmggvRKFq-OTcJKO3U0TrhD8XnKnrJE1CA/edit?usp=sharing

And his corresponding calcuations from the raw data:  https://git.ligo.org/wieldphysics/wield-ligo-mcculler/-/tree/main/src/wield/LIGO/mcculler/mirror_maps?ref_type=heads

 

Implications for X/Y overlap in HAM 7:

Note:  I do my best here to calculate the expected impact of the various ZM mirrors on our X/Y mismatch. I'm fairly new to analyzing AWC optics, so take these calculations with a grain of salt.  

 

From this we can calculate the astigmatism-induced mode mismatch between the x and y directions due to reflection off of ZM4 and ZM5.  This can be done using Equation 23 in the following technical document:  https://dcc.ligo.org/LIGO-T1900144

I believe that one wants to take the square root of eqn 23, since we are interested in calculating a 1D overlap integral between X and Y of a single beam rather than a 2D overlap between two separate beams.

 

We use the following paramters in Eqn 23:

 w = beam spot size on ZM4 or ZM5 (roughly 1 mm and 2 mm respectively)

D = difference in defocus between X and Y for either ZM4 or ZM5 (Just the last line of the two tables above)

 

I find roughly that |k00|2 = 0.997  for both ZM4 and ZM5.  The impact is small and, because the astigmatism appears to have the opposite sign for each optic, the effect of ZM4 and ZM5 will probably cancel one another to some degree (this should be straightforward to calculate, I just haven't done it here). This suggests that the impact on our X/Y overlap due to the astigmatism on ZM4 and ZM5 is likely not a significant limit to our squeezing level at present.  I'll take a look at the raw q values later to see if they tell a consistant story, will hopefully confirm that these back-of the envelope calcs using this T-doc are reliable.  

 

However, our measurements on SQZT7 suggest that we do have noticible astigmatism.  ZM2 seems like a more likely culprit due to the larger beam spot size on that optic (w = 2.5 mm).  

 

Rough estimate of the impact of ZM2:

Based on Lee's analysis of the Zygo data for the ZM2, ZM4, and ZM5 PSAMS, it appears that 10-20 mD of astigmatism is typical near the center of a PSAM optic.

For 10-20 mD of astigmatism from ZM2 with w =2.5 mm, the mode overlap between X and Y would lie between:

|k00|4 = 0.9916 to 0.9671  

I dont think that this naive calculation where I square the result for a double-passed optic is correct in general for a retroreflected path, but my intuition is that this should be roughly right in our case because ZM2 actuates mostly on the beam defocus at FC1.  I'm not that confident in my intuition, so I plan to confirm this with some finesse modeling.  

This might account for the astigmatism measured on SQZT7.  Further measurements before/after ZM2 would allow us to confirm this theory.  

 

sheila.dwyer@LIGO.ORG - 14:32, Wednesday 29 July 2026 (91307)

Camilla and Eric realized that the AOIs listed in the ligo-commissoning-modeling repo for the ZM2 were a factor of 2 too large, ie they were the angles between entering and exiting beams.  I've corrected this in the repo, and re-ran the fitting to the ROCs, (and cleaned up the code and plots a little). 

In the plots, all the stars are for vertical qs, all the circles are for horizontal qs.  The first plot shows the measured q before ZM4 compared to the qs measured after ZM5 propagated back to before ZM4.  If the measurements and fitting were perfect these would all line up at the horiozontal and vertical measured qs.  

The next plot shows the qs measured after ZM5, but propagated to SRM, the salmon points are the measured qs.  The dark blue symbols are predictions based on the ROCs that I fit using only vertical q measurements and the measured vertical q before ZM4, the teal symbols are based on fits made using only horizontal qs.  You can see that in the middle of the ZM5 range, the fits do a pretty good job of predicting the measured qs, but at the edges of the range the predictions are not as good.  If you look at the vertical fits, they don't do much of a worse job predicting the horiztonal data than the vertical data, so I think this means that whatever is preventing good fitting there is a larger impact than the astigmatism.  The third plots shows similar information, as a grid of overlaps between the predicted and measured qs: the horizontal fits don't do much worse at explaining the vertical data than the horizontal, and vice versa.  So, I don't have a lot of confidence in this technique as a way of measuring astigmatism,as the fitting is limited by something else. It does re-affirm that our measurement technique should be good enough to get lower than 1% mode mismatch. 

Recreating Eric's tables from above, with the corrected AOIs.  For ZM4, the astigmatism expected based on AOI alone is about 5mD.

ZM4 strain guage (V) 2 4 6 8
ZM4 ROC horizontal fit [m] -7.84 -7.08 -6.49 -5.96
ZM4 ROC vertical fit [m] -8.93 -7.92 -7.12 -6.46
physical astigmatism (Dh-Dv) [mD] -31 -30 -27 -26
total astigmatism Dh/cos(AOI) - Dv*cos(AOI) -36 -35 -33 -32

For ZM5, the astigmatism expected from the AOI alone is about 10mD, we do not seem to need much astigmatism from the optic quality to explain the data.  

ZM5 strain guage (V) -4.5 -2 0 2
ZM5 ROC horizontal fit [m] 3.55 3.86 4.2 4.28
ZM5 ROC vertical fit [m] 3.61 3.90 4.28 4.36
physical astigmatism (Dh-Dv) [mD] 9 5 8 8
total astigmatism Dh/cos(AOI) - Dv*cos(AOI) 10 6 9 9

Utilmately these number's aren't very different from what they are in Eric's tables above after the AOI fix, the main difference is the total astigmatism from ZM5 which was inflated above because of the too large AOI. 

Images attached to this comment
H1 ISC
thomas.shaffer@LIGO.ORG - posted 10:59, Friday 13 September 2024 - last comment - 20:28, Wednesday 29 July 2026(80077)
More checking of ALS higher order mode spacing

After a lock loss this morning Sheila and I spent some time looking further into the mode spacing for ALS (alog80065). We each took an arm and looked at the mode spacing and peak heights at good alignments and some not as good alignments. This exercise didn't yield any major revelations, but did confirm that our Y arm definitely doesn't have perfect mode matching, X arm seems to be better than Y. 

Attachment 1 - ALS Y 00 mode to 2nd order mode spacing. This showed that yesterday Sheila and Ibrahim missed the small 1st order mode between these and Sheila has sinced updated their FSR and FHOM values (alog80076).

Attachment 2 - An example of ALS Y locking below the max flashes, showing that some of our power is in the higher order modes.

Attachment 3 - ALS X comparison of attachment 1

Attachment 4 & attachment 5  - ALS X 1st order peak spacing and height for an okay alignment (4) vs a better alignment (5).

Attachment 6 & attachment 7 - Same as above but for the 2nd order modes.

 

Images attached to this report
Comments related to this report
madison.simmonds@LIGO.ORG - 20:28, Wednesday 29 July 2026 (91321)

Madi

Analysis of this data, including determining the misalignment, and mode-mismatch are captured in 91306 .

Displaying reports 1-20 of 88684.Go to page 1 2 3 4 5 6 7 8 9 10 End