Displaying reports 1-20 of 88131.Go to page 1 2 3 4 5 6 7 8 9 10 End
Reports until 13:15, Wednesday 24 June 2026
H1 SUS
thomas.roocke@LIGO.ORG - posted 13:15, Wednesday 24 June 2026 (90743)
BBSS M1 QOSEM Drive Transfer Function

To aid in testing the BBSS M1 QOSEM coils for issues related to the cross coupling (see LHO alog 90665), below is the DC tranfer function from DAC counts (16 bit) to the voltage across the QOSEM coils. This assumes a coil resisatnce of 35ohms, which is the nominal spec, but they can vary by ~10%.

DAC drive to voltage across the coil = 3.18e-5 V/cts

H1 SUS
oli.patane@LIGO.ORG - posted 12:35, Wednesday 24 June 2026 (90741)
BBSS TF comparison: Teststand BOSEMs vs QOSEMs vs Chamber QOSEMs

I've made plots comparing three sets of transfer functions.

  1. 2026/05/26: On the LVEA Teststand with BOSEMs (90356) (individual results)
  2. 2026/06/01: On the LVEA Teststand with QOSEMs (90440) (individual results)
  3. 2026/06/10: In Chamber with QOSEMs (90590) (individual results)

Here are the comparison plots between the three. The most important plots right now are the P2Y and Y2P plots. They can be found in /ligo/svncommon/SusSVN/sus/trunk/BBSS/Common/Results/allbbss_2026_teststand_vs_chamber_BOSEMs_vs_QOSEMs/ and have been committed as r13043.

Side note: Since Arnaud and I realized our calibration DAC compensation mistake yesterday (90720), I have reanalyzed the last few measurements, including the three being compared here, using /ligo/svncommon/SusSVN/sus/trunk/BBSS/Common/MatlabTools/plotBBSS_dtttfs_M1.m. These are three measurements that had been taken with the 28bit DAC compensation gain in the COILOUTF filter set to gain(4096) = gain(2^12), which is the correct compensation when accounting for the difference in DAC counts between a 28bit and 16bit DAC. This compensation means that the calibration factor in plotBBSS_dtttfs_M1.m should've just accounted for the 16-bit DAC (since the rest was already accounted for), but it had been set to 18-bit DAC, so I reran them. The measurements that had been reanalyzed were 2026-05-26_1700, 2026-06-01_1700, and 2026-06-10_1700, committed as r13041.

Note: All three of these measurements were taken before the sign swap was implemented in the COILOUTF filter banks.

Non-image files attached to this report
H1 SUS
arnaud.pele@LIGO.ORG - posted 12:11, Wednesday 24 June 2026 (90739)
BBSS top mass drive calibration

Following up from 90723 we (roughly) calculated the BS top mass drive (cts) to bottom mass motion (urad) measured by the oplev. This will allow to (re)calibrate the top mass sliders in physical units. The screenshot attached show the ndscope used for this calculation. The data was taken before the sign convention was corrected (90725), so the signs were flipped from the ndscope in the table below: 

+0.15 [P_urad/P_cts] +0.35 [Y_urad/P_cts]
+0.1 [P_urad/Y_cts] +1.65 [Y_urad/Y_cts]

The slider calibrations to implement (at next opportunity) in the gain of the slider filterbanks are : 

P calibration = 1/0.15 = 6.6 [P_cts/P_urad] 
Y calibration = 1/0.35 = 0.6 [Y_cts/Y_urad] 

Images attached to this report
H1 ISC
camilla.compton@LIGO.ORG - posted 11:23, Wednesday 24 June 2026 - last comment - 12:00, Wednesday 24 June 2026(90738)
ITMX taken back to DRMI top mass OSEMs, BS Alignment adjusted to compensate

Follow on from 90719. Jennie, Keita, Betsy, Sheila, Camilla, Ryan S, Oli,  Arnaud

Before doing any more mechanical BS offloading, we decide to put ITMX back too it's March DRMI top mass osems values, as described in alog90708, we expected we'd need to move ITMY to compensate for this, but did not.

Used the SQZ beam. Mis-aligned ITMY. Moved ITMX towards correct Pit value. Compensated with BS Pitch and Yaw to keep beam on AS AIR. Moved PR3 to keep beam on ISCT1 REFL camera.  We did not fine tune fringing. Keita opened PSL light pipe an further tuned PR3 to get PSL beams both on cameras. Ending sliders here. Ndscope of the fringing on AS_A/B here.

BS pitch is now close enough we will do no further mechanical pitch offloading now, it will be Yaw offloaded SEI system.  Arnaud checked the oplevs to known that for the -1500 counts of BS yaw slider, this is ~ 2.5mrad.

Both ITMX and ITMY are now at their March  DRMI top mass osems locations (11:02 PDT 19 March 2026). 

 
Starting today
After ITMX moved back to DRMI M0 OSEMs
ITMX
P -280, Y +94
P -96, Y +104
BS
P +520, Y -1677
P +115, Y -1557
PR3
P -247, Y -245
P -195, -242
Images attached to this report
Comments related to this report
arnaud.pele@LIGO.ORG - 12:00, Wednesday 24 June 2026 (90740)

Given this calibration the newest BS offsets (P +115, Y -1557) [cts] corresponds to the calibrated offsets (P +17.25, Y -2569) [urad at M3] when only considering the P2P and Y2Y calibration. When taking into account the cross coupling those offsets are (P -138, Y -2529) [urad at M3].

This defines the amount of yaw motion (and direction) to offload this offset with HEPI : Rotate HEPI ~2.5mrad clockwise

H1 CDS
jonathan.hanks@LIGO.ORG - posted 10:49, Wednesday 24 June 2026 (90737)
WP 13208 cdswiki OS upgraded

As per WP 13208 the cdswiki was down yesterday for an OS upgrade.

H1 CDS
david.barker@LIGO.ORG - posted 08:39, Wednesday 24 June 2026 (90734)
Earthquake has tripped ETMX Hardware Watchdog

Corey, Dave:

An EQ quickly tripped the ETMX SEI SWWD. I bypassed the SWWD and tried to drive the ISI to prevent the HWWD from tripping, but to no avail. HWWD tripped 08:36 and will need manual reset when the EQ has passed.

LHO General
corey.gray@LIGO.ORG - posted 07:42, Wednesday 24 June 2026 (90732)
Wed DAY Ops Transition

TITLE: 06/24 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: 5mph Gusts, 2mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.07 μm/s 
QUICK SUMMARY:

BBSS, SPI, CRS, and baffling work continue, with planning for possible laser safe time for BBSS actuator work.

H1 CDS
david.barker@LIGO.ORG - posted 07:12, Wednesday 24 June 2026 (90731)
More 20bit-DAC testing on H1 production front ends

Erik, Jonathan, EJ, Dave:

On Monday 21jun2026 we did some more investigation of the General Standards 20bit-DACs in h1iscex and h1susb2h34.

h1iscex:

Following my successful loop-back testing of this 20bit-DAC to the PEM ADC, EJ confirmed that this 20bit-DAC passed the Monday tests. This card is still a bit of mystery as to why it is working with a MPS=256B. It is a unique 20bit-DAC, older than all the others (it is 2015, all the others 2019 or later). It has a 4th region (Region1) on the lspci -vv scan missing in the other DACs.

h1susb2h34:

Monday's testing showed that both of the 20bit-DACs on this frontend are non-operational. The first because it shares an Adnaco with the Timing-Card, the second because it shares an Adnaco with the LIGO-DACs. In both cases the LIGO card is forcing MPS=256B which causes the 20bit-DACs to drive no output voltage (constant FIFO=empty).

My original SUSAUX testing was faulty, I was looking at the stop stages of PR2, SR2 but the 20bit-DAC drives M2,M3 for these suspensions. I was able to verify that these lower stages have not been driven since the January 2026 upgrade.

h1sush12:

As an aside, I took a look at the MPS for h1sush12. This has no 20bit-DACs, it is all LIGO-DAC. This is a W3323 computer, the additional cores were needed for the large number of models. Strangely this machine is running with MPS=128B on all cards, even though it could run at 256B, presumably resulting is a loss of DAC performance. We will investigate this on the test stand's W3323.

H1 SUS
thomas.roocke@LIGO.ORG - posted 00:22, Wednesday 24 June 2026 (90729)
QOSEM Readout Sign Convention Checks

To verify that the QOSEM readout has the expected sign convention, as detailed in D2500284, I injected a longtidual offset into the BBSS M1, via the QOSEM coils, and monitored M1, M2, M3 OSEMs. The QOSEM readout sign should be consistent with the BOSEMs and AOSEMs.

Figure 1 plots M1 F1x, M2 LL, M3 UR and the test L injection into M1. Due to the location of these OSEMs they should all readout with the same sign. Here we see that the sign is consistent between the QOSEM, BOSEM and AOSEM for this given longitudal offset, verifying that the QOSEM sign convention is indeed as documented.

 

Images attached to this report
H1 SEI (SEI)
shoshana.apple@LIGO.ORG - posted 18:25, Tuesday 23 June 2026 - last comment - 18:34, Tuesday 23 June 2026(90715)
CRS Chamber Side Testing Continues

[Arnaud, Michael, Jim, Fil, Shoshana]

As mentioned in 90702, one of the readouts for the CRS HoQI amplifier wasn't working, after investigating we figured out that it was an issue with a broken op-amp in a transimpedance amplifier (HoQI B, channel E/COS). Fil switched out the op-amp so we now have a working chassis. Our best guess is that the op-amp failed after plugging it into the rack.

The HoQI on the left side of the CRS (SN01-005, currently HoQI2) had much lower fringe visibility than the other one (SN02-007) since yesterday. We figured out that the laser collimator was positioned in a way where the beam wasn't hitting the center of the photodiodes. The laser collimator was re-aligned and we were able to greatly increase the fringe visibility so the HoQIs now match.

HoQI 1 (SN02-007), SIN: 86.7%, COS: 79.4%, MCOS: 84.9%

HoQI 2 (SN01-005), SIN: 81.4%, COS: 82.7%, MCOS: 80.1%

CRS was balanced, currently has a estimated resonance frequency of 15.7mHz, but we will re-check it in the morning. We are leaving the laser on over night hoping to get some noise measurements, both due to the air currents in the clean room, and the fact that we didn't ground the damping capacitors, it looks unlikely that it will damp down overnight.

Arnaud got the ellipse fitting working, the python script is in /opt/rtcds/userapps/trunk/isi/h1/scripts/write_ellipse_values3.py

We added a gain 0.0847 um/cnt (1064 nm/4pi) to the HoQI Dist filter banks to calibrate the HoQIs into distance. We also changed the CRSRY_PHI_SUM matrix elements to 2.75 to put the RY channels into urad.

 

An unrelated mystery: HoQI1 and HoQI2 are switched, we aren't sure where in the chain they get flipped, but right now we are guessing it's at one of the cables to the chassis

 

Comments related to this report
michael.ross@LIGO.ORG - 18:34, Tuesday 23 June 2026 (90727)

We took a quick spectrum to check the HoQI performance. The CRS is very rung up so this noise floor is not indicative of the final performance. Yet the noise floor already looks good.

Images attached to this comment
H1 SUS
oli.patane@LIGO.ORG - posted 18:12, Tuesday 23 June 2026 - last comment - 00:43, Wednesday 24 June 2026(90725)
BS Sign Convention fixed throughout signal path

Previously (90441), Tom, Ibrahim, and I had found out that the QOSEM coil drivers were wired opposite as compared to other OSEMs. To compensate for this at the time (since we were attempting to use damping), we had swapped the signs of the damping gains. But we had only swapped those gains, meaning that other actuation coming through the TEST or OPTICALIGN filter banks was still pushing the coil drivers the opposite way from expected. Today we finally decided to fix it to reduce confusion wrt the direction the BS was moving when offsets were put in (offsets were moving the BS in the opposite direction than expected). 

To do this all I did was put the M1 DAMP filter gains back (before, after) to being negative and then swapped the signs of the gains in M1 COILOUTF (before, after). To put the beamsplitter back with the OPTICALIGN offsets that it had before, I then swapped the sign of each offset. 

I will update the SUS Sign Conventions document to mention that the QOSEMs require the opposite COILOUTF signs from nominal.

So now EVERY BBSS OPTICALIGN slider offset from before 2026/06/24 00:50 UTC requires the opposite sign to be recreated.

Images attached to this report
Comments related to this report
arnaud.pele@LIGO.ORG - 00:43, Wednesday 24 June 2026 (90728)

Following this sign change, we verified the following conventions for the M1 actuation : 

Positive offset on the coil ouptut filterbanks corresponds to positive qosem signal on M1(figure 1)
Positive offset on the cartesian basis (test filterbanks) corresponds to positive cartesian signal on M1 (figure 3)

Figure 2 and Figure 4  show the dc cross couplings for the local and cartesian basis drive, as as reference for the on-going xcoupling investigation.

The two scripts to make those plots were saved in the svn under /opt/rtcds/userapps/trunk/sus/h1/scripts

push_pull_bs.py
push_pull_bs_cartesian.py
 

Images attached to this comment
H1 CDS
erik.vonreis@LIGO.ORG - posted 17:27, Tuesday 23 June 2026 (90722)
new trace color system for ndscope

Ndscope has a new system for picking trace colors that tries to maintain a high contrast between the trace and the background.

You can test the new system by running "ndscope-test" instead of ndscope on any workstation, laptop, or login portal.  Give it a try and let me know what you think.

H1 SUS
oli.patane@LIGO.ORG - posted 17:24, Tuesday 23 June 2026 (90720)
BBSS Model M1 to M3 TFs and DC values

Arnaud, Oli

As part of our BBSS alignment and investigation, I used /ligo/svncommon/SusSVN/sus/trunk/BBSScomparetripleparams.m to look at the DC values of our current model when actuating at M1 and reading out at M3. 

I made a few edits to comparetripleparams.m in order to allow me to do this easily, and I've committed those changes as r13039.

The plots (P, Y) show that the DC value for M1 P to M3 P is 0.029 rad/Nm and M1 Y to M3 Y is 0.129 rad/Nm. These plots can be found in /ligo/svncommon/SusSVN/sus/trunk/BBSS/Common/Results/comparetripleparams/comparetripleparams/2026-06-23_M1toM3Model/triplemodelcomp_2026-06-23_M1toM3Model_M1toM3.pdf r13040.

We then converted into cts/N using (1e-6)*(1/DACdrive)*(1/coilDriver)*(1/forceCoeff).

For this we used DACDrive = 20/2^16 cts/V, forceCoefficient = 1.694 N/A, and coilDriverTransconductance = 0.011919 A/V. The reason why DACDrive = 20/2^16 cts/V and not 20/2^28 is because we already compensate for the difference between a 16-bit DAC and a 28-bit DAC in the COILOUTF filter bank so we don't need to put that into our calibration.

This gives us:

   Calibration factor [cts/N] = (1e-6)*(1/(20/2^16[cts/V]))*(1/0.011919 [A/V])*(1/1.694 [N/A])

     = 1.623e5 [cts/N]

Then multiplying this calibration factor by our earlier fractional values for P and Y gives us:

   Pitch slider calibration : 4.7e-3 cts[M1]/urad[M3]

   Yaw slider calibration: 20.9e-3 cts [M1]/urad[M3]

Images attached to this report
H1 SUS (ISC)
ryan.short@LIGO.ORG - posted 17:14, Tuesday 23 June 2026 - last comment - 07:11, Wednesday 24 June 2026(90719)
BS Pitch Pointing Offloaded

B. Weaver, C. Compton, R. Short

Carrying on from alog90708 posted at lunch, Betsy, Camilla, and I offloaded the BS pitch sliders mechanically at the suspension.  This was a tad tricky since we were looking at the beam(s) at HAM3 in front of PR2, so we had to work out blocking 1 ITM beam in order to not be confused by both beams crossing each other after the long PR chain of optics.  In the end, we worked out the process to bring the BS PIT slider from +1000 to 0 which meant pitching the BS optic HR "up" (PUM roll bar "in").  Unblocking the other ITM, we got both beams overlapping onto each other with a little more slider to see how much better we could get them and see flashes in the AS_AIR camera (PIT = -300, YAW +1560).

Once back in the control room, Keita scanned BS alignment to find the SQZ beam reflected by ITMX as well as ITMY in AS camera as well as ISCT1 camera, ending with BS PIT = -520, YAW = 1677. With this alignment, IMC flashes reflected by ITMX as well as ITMY were visible in both of the cameras. Though SQZ beam and IMC flashes are not coaligned,  the corner alignment is already pretty good as of now.

At this point we want to:

1) Recenter the OPLEV

2) Go in and physically calibrate which way the sliders go as seen on the oplev and at the HAM3 PR Beams since there is confusion around the sliders (direction, calibration, cross coupling)

3) Based on 2) Potentially make a request for HEPI YAW correction tomorrow when they resume HEPI "fine" alignment and actuator reattachment (TBD convo with SEI/IAS)

4) Get on with landing HEPI/actuator attachment, etc.

5) Final round of BS PIT SUS mechanical Offloading 

Comments related to this report
jason.oberling@LIGO.ORG - 17:21, Tuesday 23 June 2026 (90721)

The BBS OpLev has been recentered.  I had to yaw the beam onto the QPD, as it was not on it.  Once recentered, the SUM counts were around 2400, which is much lower than for the old BS, which was up around 20k.  I checked the Output Configuration Switch on the BBS OpLev chassis in the biergarten and it has not changed, the amount of gain is still 0 dB.  The other explanations are the coating on the BBS (OpLev beam is at 635 nm, which is not a design wavelength for the coating, so the %R at 635 nm for the BBS could be very different than the old BS) and a failing OpLev laser.  I'll check the power output from the laser to see how it's doing (likely tomorrow).

ryan.short@LIGO.ORG - 17:46, Tuesday 23 June 2026 (90723)

Keita's note: After Jason recentered BS oplev, we changed the BS sliders to see the sign of the sliders (we knew that they were flipped) and how bad the pit to yaw coupling was.

Sign of the H1:SUS-BS_M1_OPTICALIGN_P_OFFSET and H1:SUS-BS_M1_OPTICALIGN_P_OFFSET are systematically wrong.

Positive PIT (right column top) in the slider consistently makes negative PIT on oplev, M2 OSEM and M1 OSEM, i.e. positive PIT tilts the BS up when positive offset is added to the pit slider.

Same story for YAW, negative PIT (left column top) in the slider consistently makes positive YAW for all sensors available, i.e. positive YAW rotates the BS clockwise when viewed from the top.

Arnaud and the gang will fix the sign issue.

PIT to YAW coupling is about 2 YAW per 1 PIT (i.e. PIT actuation make BS move more in YAW). YAW to PIT is not bad.

Positive PIT of 50 counts (uncalibrated) made negative 10urad in PIT and negative 20urad in YAW according to oplev. This agrees with our experience of observing how the beam spot moved in chamber as well as on the AS and ICST1 cameras when trying to move BS in PIT using the slider.

Interestingly, P2Y coupling seems to be OK for M1 (1:0.17 if we trust the QOSEMs), bad (about 1:0.7) for M2 and absolutely terrible (1:2) for M3 oplev.

Negative YAW of 20 counts made positive YAW of about 30urad and almost unmeasurable amount of PIT according to oplev.

Images attached to this comment
timothy.ohanlon@LIGO.ORG - 07:11, Wednesday 24 June 2026 (90730)

LLO also saw a drop in power output on the BS oplev. The current sum is around 12 percent of what the sum was before the vent which matches the drop in LHO BS oplev power.

H1 AOS
camilla.compton@LIGO.ORG - posted 12:50, Tuesday 23 June 2026 - last comment - 17:57, Tuesday 23 June 2026(90708)
BS Alignment with SQZ Beam, got MICH fringes with SQZ and IFO beam

Continued from 90691. Betsy, Keita, Sheila, Oli, Eric, Camilla, Ryan S, Jenne

First thing, we went back to alignment we had ITMX SQZ  the "flashes" and "fly-bys" yesterday, put the same size oscillation on the BS, but saw no flashes of fly bys. Betsy took a video of what the two SQZ beams looked like at PR2 at this alignment, they were crossing each other. 

We then rethought the alignments from yesterday, we are leaving:

Once we did this, we had SRY fringes, Betsy and I then adjusted the BS to bring the beams back on top of each other at PR2. This was a change in the BS sliders from (P 1000, Y 1290) to (P 1350, Y 1180).

Keita then wobbled ITMX and found the SQZ beam off ITMX! Aligned ITMX to get MICH flashes at AS_AIR, AS_A/B and ISCT1 REFL. He had to move ITMX from (P -96, Y 104) to (P -280, Y 94). 

He then got the PSL IX and IY reflection in the AS_AIR camera in this alignment. Sliders at this alignment attached

However as we are not sure we trust the ITMY alignment form top mass osems (from 90551), we want this Pitch change to be in ITMY, so ITMX is at it's known DRMI pointing. We could try to walk these, maybe along with SRC which might reduce some of our Pitch differences in SR2 and SRM. This change is so small that we will go ahead with mechanically offloading BS Pitch. The BS YAW will not mechanically changed. 

The OMs are also not currently in their O4 sliders/osems position, attached. We could verify the SQZ beam pointing by putting these back if we thought that was needed.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 17:57, Tuesday 23 June 2026 (90724)

Since IMTX was moved today, I had to move PR3 to compensate in order to regain IMC flashes in the AS camera as well as ISCT1 camera.

H1:SUS-PR3_M1_OPTICALIGN_P_OFFSET is now -247.0 (used to be -140).

H1:SUS-PR3_M1_OPTICALIGN_Y_OFFSET is now -245.0 (used to be -583).

H1 SQZ
begum.kabagoz@LIGO.ORG - posted 17:36, Sunday 14 June 2026 - last comment - 14:06, Wednesday 24 June 2026(90613)
HAM7 - FC path mode matching projections from beam profile data

Below is the analysis for data taken on the FC path: between ZM1 and ZM2 and between ZM2 and ZM3, with Nanoscan, see Camilla's log 90573. As a reminder, ZM1 are flat optics, ZM2 is a PSAM with variable curvature, FC1 HR side is flat, AR side is curved with RoC ~1m. 

The data suggest that the OPO mode is slightly different from O4 OPO, and also strongly suggest a new optimal ZM2 PSAM voltage can be found within the range. 

We measured the beam profile at 5 different points after ZM1 with A:L2 lens at its nominal 0 position (sled that the lens lives on is flush to its translation stage on both front and back edges). At the last point with A:L2 at 0, we realized it would be pertinent to measure beam profiles for the two extremities of the A:L2 translation stage: -13 mm, which is closer to ZM1 by 13 mm and +17 mm, which is 17 mm further from ZM1. We then proceeded to take 5 measurements (again downstream from ZM1) for each of these lens positions. The nanoscan screenshots for each measurement are attached in the .zip folder. 

The attached gif shows the beam waist position estimation extracted from the beam profile scans downstream ZM1, for all three A:L2 positions. The "target" and "O4 x/y" come from Keita's log 59515The overlap plot attached shows the field overlap in percentage for all three A:L2 positions, with target and O4 beam parameters. With A:L2@0, the overlaps are above 99%, which bodes well for the FC mode matching prospects. There could potentially be a better mode matching solution to the "target" or "O4" for A:L2 between 0 pos and -13mm pos. However, the following measurements betwen ZM2 and ZM3 suggest fine-tuning of A:L2 position will not be necessary. 

We also measured beam profile between ZM2 and ZM3 for three different points, setting ZM2 PSAM voltage to 4 different values at each point. The "nominal" O4 strain gauge (S.G.) for ZM2 has been 3.15 V, which corresponds to ~ 60 or 90 V pzt supply voltage depending on which direction one scans from. The edges of the psam range are 0 V and 196 V, which corresponds to ~1.2-1.3 V and ~6.04 V S.G. respectively. In the interest of more uniform sampling of the available psam curvatures, we also chose to sample 4.5 V S.G. (~120 V or 150 V). 

This table shows experimental data mapped to radii of curvature of the ZM2 mirror, using Camille's E2100298. The exact PZT strain gauge/ PZT supply voltage that gives a certain RoC is affected by the hysteresis curve i.e. sweep direction.

Strain Gauge (V) PZT Supply Voltage (V) RoC (m) with increasing scan RoC (m) with decreasing scan
1.3 V 0 0.8211 0.82202
6.0x V 196 0.8911 0.89114
3.1x V 60 (d) or 90 (i) V 0.8523 0.85025
4.4x V 120 or 150 V 0.87534 0.87242

Attached gif for propagation between FC1 and ZM2 show esimated beam parameters for all four SG cases: 1.3, 3.1x, 4.4x and 6.0x V. The exact values for the strain gauge varied from one beam profile position to the next, however it should be good enough to tell if we have enough range on ZM2 or not.

The gif switches between different SG values once every 2 second, the lefthand plot is useful in looking at the beam divergence near FC1 while the righthand plot is a zoom-in around the beam waist. Looking at the estimated beam waist position for 1.3 V and 3.1x V cases switching across the "FC x/y waist", "VOPO target waist", ''O4 x/y waist", we can guess there could be a better mode matching solution between these two SG values. "FC x/y waist" comes from the Finesse eigenmode solution for the FC path (thanks Kevin Kuns!), target and O4 values are the same from the above-mentioned Keita log, assuming ZM2 curvature to be 0.85025 m (3.15V SG), and the following distances between the optics: A:M3 --> ZM1: 158.2 mm, ZM1--> ZM2: 1498.625 mm, ZM2 --> ZM3: 1821.497 mm, ZM3--> FC1: 1000.261 mm. Camilla extracted these distance values from D1900365-v1.

Knowing the applied PZT voltage and the corresponding RoC, we can use the measurements at 3.1x V and 1.3 V to estimate the mode matching we would obtain if we swept the RoC between that of these strain gauge values. The attached FC mode matching projection plot is computed by taking beam parameter estimated from the beam size measurements for 3.1x V, propagates the beam back to ZM2, unapplies the estimated RoC (decreasing RoC value was used informed by data, indicated in bold in the above table), then reapplies the RoC between these two values, after the overlap with the FC eigenmode is calculated. This projection suggests that mode-matching points with >99% overlap for both x and y axes are accessible. Clearly, there is varying astigmatism with strain gauge setting, see beam profile plots where 3.1x and 6.0x V shows beams with smaller astig. than the other two points. Since the PSAM characterization data gives only a single RoC number rather than separate x/y effective curvatures, the projection should be interpreted as approximate. In practice, the final optimization should be done empirically.

The effect of the astigmatism is also apparent in this defocus vs beam size at FC1 plot that shows mode matching contours. The calculation is made at the FC1.p2.o plane in Finesse.

 

Images attached to this report
Non-image files attached to this report
Comments related to this report
begum.kabagoz@LIGO.ORG - 14:06, Wednesday 24 June 2026 (90744)

The beam width data kindly tabulated by Camilla, the R(V) data from Camille's dcc E2100298, and the analysis code .py are attached, in the .zip. Fair warning, the analysis code also makes a bunch of plots I find useful to look at but another user may find irritating :)

Non-image files attached to this comment
Displaying reports 1-20 of 88131.Go to page 1 2 3 4 5 6 7 8 9 10 End