Displaying reports 1701-1720 of 85590.Go to page Start 82 83 84 85 86 87 88 89 90 End
Reports until 18:45, Wednesday 13 August 2025
H1 SQZ (ISC, OpsInfo, SQZ)
ryan.short@LIGO.ORG - posted 18:45, Wednesday 13 August 2025 - last comment - 12:09, Thursday 14 August 2025(86356)
Removed NO_SQUEEZING Requests from ISC_LOCK and Added "ignore_SQZ" Flag

In consultation with Sheila, I've added a new flag in lscparams.py called "ignore_sqz" (currently set to False) which when True, removes SQZ_MANAGER from ISC_LOCK's managed nodes list and sets up ISC_LOCK such that no requests are made of SQZ_MANAGER. I've additionally removed all instances of ISC_LOCK requesting SQZ_MANAGER to 'NO_SQUEEZING.'

The motivation for this stems from an issue encountered earlier this week (alluded to in Monday's shift summary) where after H1 dropped observing from the SQZ PMC having to relock, SQZ_MANAGER eventually stalled (which is not unexpected) and ISC_LOCK then requested it to 'NO_SQUEEZING' for a then-not-well-understood reason. After looking into the frequently used "unstall nodes" decorator in ISC_LOCK, I learned that the revive function it calls simply requests the stalled subordinate node to whatever its last requested state was. The catch here is that the last requested state refers only to what the manager's last request was to the subordinate, not whatever request a user, other node, or standalone script may have made, as the manager node has no way of knowing about requests outside of its own. A discrepancy between a manager node's last request to a subordinate and a different request to that subordinate can be seen with a notification on the manager saying the subordinate's request changed.

My understanding of the sequence of events that led to the confusion on Monday is that commissioners had been working with the squeezer and wanted its Guardian manager node to remain in 'NO_SQUEEZING' while H1 was relocking following their work. In its design at the time, in a few different states such as 'INJECT_SQUEEZING', ISC_LOCK would check the status of SQZ_MANAGER, and if it was in 'NO_SQUEEZING', move on with the state and re-request SQZ_MANAGER to 'NO_SQUEEZING'. This makes SQZ_MANAGER's manager's last request 'NO_SQUEEZING', so when SQZ_MANAGER later stalled, it was requested back to 'NO_SQUEEZING' even though a user had set SQZ_MANAGER to its nominal state sometime later. This is why I've removed requests to 'NO_SQUEEZING' in ISC_LOCK; I believe it's a sound assumption that if SQZ_MANAGER is in 'NO_SQUEEZING', someone wants it there and Guardian should just move on. Further, this makes it so that the only request ISC_LOCK ever makes to SQZ_MANAGER is its nominal state (except in 'DOWN', of course, which would then later get updated to the nominal), meaning there should be no confusion as to what its last request was.

Changes have been saved and committed to svn, but ISC_LOCK has not yet been loaded. This should be done at the next drop from observing.

Comments related to this report
thomas.shaffer@LIGO.ORG - 12:09, Thursday 14 August 2025 (86367)OpsInfo

We loaded this and tested going to and from ISC_LOCK's Inject_Squeezing state with the SQZ manager in No_Squeezing and FREQ_DEP_SQZ. All worked well.

If we ever need to go to observing without squeezing, we should keep this in mind as I'm not 100% confident we won't get some manager confusion depending on when we do the transition. We'll cross that bridge when we get to it though.

H1 General (DetChar)
oli.patane@LIGO.ORG - posted 16:38, Wednesday 13 August 2025 (86355)
Ops Day Shift End

TITLE: 08/13 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Observing at 151 Mpc and have been Locked for over 9 hours. Nothing really happened today besides the calibration commissioning from earlier.

We don't think it affected anything, but at 20:48 UTC, we had a staff member in a car drive up to the LVEA receiving door, idle there for 5 minutes, and then drive away at 20:53UTC, so I'm tagging detchar in case we see anything weird in the data during that time.
LOG:

14:30UTC Just got to NOMINAL_LOW_NOISE
    14:32 Observing
    15:30 Out of Observing for calibration measurements
    15:30 NLN_CAL_MEAS
    16:01 NOMINAL_LOW_NOISE
    16:12 NLN_CAL_MEAS
    16:43 NOMINAL_LOW_NOISE
    17:41 NLN_CAL_MEAS
    18:12 NOMINAL_LOW_NOISE
    18:20 NLN_CAL_MEAS
    18:30 NOMINAL_LOW_NOISE
    18:31 Observing
    20:48 Staff member in car driving up to receiving and idling
    20:53 Car drove away from receiving

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    

Start Time System Name Location Lazer_Haz Task Time End
  LASER LVEA is LASER HAZARD LVEA YES LVEA IS LASER HAZARD  
16:10 VAC Travis MY n Checking on pump status 17:16
16:46   Christina, Nichole MY n 3IFO inventorying 20:10
17:16 VAC Travis, Anna MY n Leak checking 18:30
21:02 SPI Tony PCAL Lab y(local) SPIing 22:32
21:57 FAC Tyler MX, EX n Inventory 23:27
23:32   Betsy OpticsLab n   23:47
LHO General
ryan.short@LIGO.ORG - posted 16:00, Wednesday 13 August 2025 (86353)
Ops Eve Shift Start

TITLE: 08/13 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 22mph Gusts, 11mph 3min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY: Windy, smokey, and hot afternoon on site, but so far H1 has been locked for 8.5 hours following commissioning time this morning.

X1 SUS (SUS)
rahul.kumar@LIGO.ORG - posted 15:44, Wednesday 13 August 2025 (86347)
PSAMS (for HxDS with a Piezo-SAMS payload) assembly and characterization at CIT for O5

Camille Makarem (CIT), Rahul

Last week at CIT we assembled and tested four units of PSAMS (Piezo-SAMS payload - Piezo-deformable Mirrors for Active Mode Matching). These four fully assembled PSAMS are shown in attachment01 and attachment02 and they will be shipped to LLO for O5 HPDS assembly and installation in HAM6. Given below are the test results of the PSAMS payload - PZT actuation and the desired radius of curvature of the mirror at 100V.

1. Optic  E2100053, Type A2, s/n - 02 - PZT voltage tested from 0 to 200V, Pre-load set to 32 in. lbs at 100V DC, RoC = 2.42 m

2. Optic E2100053, Type A1, s/n - 01 - PZT voltage tested from 0 to 200V, Pre-load set to 32 in. lbs at 100V DC, RoC = 5.76 m

3. Optic E2100053, Type B2, s/n - 01 - PZT voltage tested from 0 to 200V, Pre-load set to 30 in. lbs at 100V DC, RoC = 2.41 m

4. Optic E2100053, Type B1, s/n - 03 - PZT voltage tested from 0 to 200V, Pre-load set to 28 in. lbs at 100V DC, RoC = 5.63 m

The Strain gauge readout results will be posted later on. 

PSAMS assembly details and issues (faced) are discussed below,

a.  Attachment03 shows the PZT with five lead wires. We looked into the vendor data to identify + HV PZT (the side which has been marked with dots) and PZT ground (non dotted side). The other 3 leads belong to the Strain Gauge (SG). We crimped pins to all five leads - as shown in attachment04. The wire pins were then pushed into the 7 pin Glenair might mouse connector (MM 803-003-02M6-7PN-598A) - as shown in attachment05. We also used a PEEK zip tie to secure the wires on the PZT stack. We followed D2000383 for the wiring chain diagram.  

b. During the assembly we did not have vendor data to identify the leads for the strain gauge, hence we connected the wires based on the spare units at CIT (which lead to some confusion as the two spare units internal wiring contradicted each other). As per D2000382, the bridge excitation should be connected to pin 1 on the might mouse connector and GND should be at pin 3, strain signal on pin 6. In reality we connected the GND to pin1, strain signal to pin6 and +V bridge excitation to pin 3 (basically pin 1 and pin 3 are inverted).  Later (post assembly), Camille acquired the vendor data for identifying the leads for the strain gauge, which is shown here. After discussing this with Jeff Kissel and Daniel, we concluded that this should not affect the working of the SG - however for future assembly we should use the latest vendor data.

c. The PZTs, washers and the deformable mirror were all stacked vertically (as per T2400260) and torqued as per specification - see pictures for reference here - attachment05, attachment06, attachment07attachment08 and full assembly shown in attachment09.

d. Electrical testing - we followed E2100371 to confirm the electrical connections for the PZT voltage and strain gauge readout - test set up shown in attachment10 and attachment11.

e. RoC measurement on ZYGO interferometer - after successfully testing and confirming the working of the PZT actuation we started measuring the Radius of Curvature (RoC) of the optic on the ZYGO interferometer - see attachment12, attachment13 and attachment14 for details of the setup - fringes observed as shown here, as an example. The final numbers (pre-load and the RoC for each mirror) are posted above.

We wanted to capture few things which we faced during the assembly and testing and this will help for assembling future units. These are listed below,

1. Tangless helicoils for mirror mounting - we used tanged helicoils for mirror mounting, however breaking the tang after the assembly was very unsafe for the mirror. Hence, we had to unmount the mirror from the flexure mirror holder, break the tangs and then re-mount the mirror (which involves heating and cooling them). Hence, we would recommend to use tangless helicoils only.

2. We struggled to attach D1900097 to D1900123 since the threads were bad on D1900097. Don got us a 1''-32 size tap from McMaster to chase the threads, however I could only chase a few of them - enough to assemble four units. The threads on the other 6 units (D1900097) at CIT were extremely difficult to chase hence we included it in our future to-do list of things (might have to be made dirty again for proper chasing).

3. PEEK zip tie for wire lacing inside the PSAMS - the old PSAMS used viton ring to lace the PZT electrical leads, this has now been replaced with PEEK zip tie. We were not very convinced with this, as the viton ring felt easier to use and more secure for the wires.

4.  We spent a lot of time trying to understand and interpret the correct wiring diagram - initially Fabrice's FDR and Luis's document contradicted each other. To add to the confusion, the already built unit at CIT (two spare psams, with two different cables and might mouse connections) wiring also contradicted each other. However (long story short), after talking to Fil and Marc at LHO we were able to sort it. We had to change the 18V power supply to the PZT driver D2000555, since the exciting one was faulty. Also, Dean (at CIT) made some quick checks on the PZT driver to confirm that it was healthy. However the most important thing to note over here is as follows - the two spare units at CIT, ZM2 and ZM5 (from the previous build) have wiring diagrams different from the design (I think for ZM2), hence this needs to be checked before future use. 

Camille as noted down the serial number of the parts used during this assembly and they are listed here.

Images attached to this report
H1 ISC
anthony.sanchez@LIGO.ORG - posted 15:05, Wednesday 13 August 2025 (86349)
DRMI locking histograms Pre & Post ReflAir changes

5 day increments.
I chose 5 days before June 16th because on June 16th there was a ReflAir Phase change, and 5 days later there was another change to ReflAir phasing.
So given a window of 5 days in between 2 changes I chose 5 days before, 5 days between changes, and DRMI after the last change for 5 days.

Images attached to this report
H1 SQZ
camilla.compton@LIGO.ORG - posted 14:49, Wednesday 13 August 2025 (86352)
ZM4 Strain Gauge Minimum Value Slightly Drifting

Leo, Camilla

Leo noticed when comparing the data we took in July 85917 to last years OMC scans with different ZM curvature settings 80010, that the minimum value ZM4 can reach has changed. Over ~ an hour or so, the strain gauge can drift around 0.1V, their total ranges are 7.7V so maybe these changes of 0.2/7.7=2.5% are not too surprising.

H1 PEM
ryan.crouch@LIGO.ORG - posted 12:58, Wednesday 13 August 2025 (86348)
H1 dust monitor Month-Long Trends FAMIS

Closes FAMIS37255, last checked in alog85779

Everything looks as expected, LVEA5 is off during observing.

Images attached to this report
H1 PSL
ryan.crouch@LIGO.ORG - posted 12:05, Wednesday 13 August 2025 (86343)
H1 PSL Status Report Weekly FAMIS

Closes FAMIS26544, last checked in alog86165
Laser Status:
    NPRO output power is 1.86W
    AMP1 output power is 70.07W
    AMP2 output power is 140.6W
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 1 days, 2 hr 21 minutes
    Reflected power = 23.57W
    Transmitted power = 105.3W
    PowerSum = 128.9W

FSS:
    It has been locked for 0 days 5 hr and 47 min
    TPD[V] = 0.8582V

ISS:
    The diffracted power is around 4.1%
    Last saturation event was 0 days 5 hours and 48 minutes ago


Possible Issues:
    PMC reflected power continues to be high, we can see a drop during the Tuesday incursion work, but it has risen a bit since then.

Images attached to this report
H1 CAL (ISC)
elenna.capote@LIGO.ORG - posted 11:50, Wednesday 13 August 2025 - last comment - 16:42, Wednesday 13 August 2025(86344)
Calibration measurements at three ESD biases

Today, we measured the calibration at three different ESD biases. First, we measured at the current bias of 269 V, and then our O4 standard bias of 136 V. Then, I stepped up to a higher bias of 409 V.

ESDAMON value Bias Offset L3 Drivealign gain Calibration report Notes
269 V 6.0542453 88.28457

alog: 86337

report: 20250813T153848Z

only 1 hour thermalized at measurement time

current operating bias

136 V 3.25 198.6643

alog: 86339

report: 20250813T162026Z

nominal O4 bias, calibration model fit at this bias
409 V 8.89 57.587

alog: 86341

report: 20250813T174921Z

ESD saturation warnings while at this bias

Took 5 minutes of quiet time, cal lines on, at this new bias

start: 18:12:54 UTC

end: 18:18:00 UTC

The attached plot compares the three broadband measurements at each ESD bias. It seems like the overall systematic error decreases as we increase the ESD bias.

To step up the ESD bias, I used guardian code that Sheila attached to this alog. Another relevant alog comparing simulines results at different biases is here.

Images attached to this report
Comments related to this report
francisco.llamas@LIGO.ORG - 14:25, Wednesday 13 August 2025 (86346)

Attaching figures comparing the sensing function, the actuation function, and the open loop gain (olg). All the figures are formatted in the same way, where the left side shows the bode plot from each report and the right shows the bode plot from of each measurement ratio to a reference. I used the latest exported calibration measurement "20250719T225835Z" as a reference. From 10 Hz to 1 kHz the sensing and the actuation function residuals are within 5%. The OLG is within 10% with one outlier at 410 Hz.

Images attached to this comment
elenna.capote@LIGO.ORG - 16:42, Wednesday 13 August 2025 (86354)

We are trying to understand how the systematic error is changing at each bias voltage, even though we think we are correcting the drivealign gain to account for the actuation change.

Francisco and I made some plots of how the modeled error changes. First, we pulled the model from the 20250719T225835Z report, since that is our current calibration model. Then, we pulled the kappas at the time of the lowest bias voltage measurement, since that is the bias voltage that our model is based on. We applied the kappas from that measurement time, and then calculated a new response function assuming an additional TST actuation change, ranging from no change (0%) to 1.5% change. Then, we compared each of these response functions to the kappa-corrected model.

To be clear, we are calculating the new response function as:

R = 1/C_model + (error_factor*TST_model + PUM_model + UIM_model) * D_model

The "model" in this case also has the kappa-corrected values applied, which are:

{'c': 0.98335475,
 'f_c': 447.65558,
 'uim': 1.0052187,
 'pum': 1.0012773,
 'tst': 1.0183398}

Looking at our results side-by-side with the broadband pcal measurement, we see some similarites. However, it's not exactly the same, since the frequency dependence appears slightly different in the measurement than the model.

There are some other comparisons to be made, but we can start with these. The script I used to make this plot is saved in /ligo/groups/cal/H1/ifo/scripts/compare_models_tst_err.py

Images attached to this comment
LHO VE (DetChar, VE)
travis.sadecki@LIGO.ORG - posted 11:50, Wednesday 13 August 2025 - last comment - 10:16, Thursday 28 August 2025(86345)
BTRP adapter flange and GV installed at MY

Similar to alog 86227, the BTRP adapter flange and GV were installed on Tuesday at the MY station.  Leak checking was completed today with no signal seen above the ~e-12 torrL/s background of the leak detector.  

Pumping on this volume will continue until next Tuesday, so some additional noise may be seen by DetChar.  This volume is valved out of the main volume, so the pressure readings from the PT-243 gauges can be ignored until further notice.  

Comments related to this report
anna.iudintseva@LIGO.ORG - 14:04, Wednesday 13 August 2025 (86351)
Here are the first and the last pictures of the leak detector values.
The max was 3.5 * 10-12. 90% of the time it stayed at <1 *10-12.
Images attached to this comment
travis.sadecki@LIGO.ORG - 13:30, Tuesday 19 August 2025 (86453)

As of Tuesday, August 19, the pumps have been shut off and removed from this system, and the gauge tree valved back in to the main volume.  Noise/vibration and pressure monitoring at MY should be back to nominal.

janos.csizmazia@LIGO.ORG - 15:33, Tuesday 19 August 2025 (86462)
The pumping cart was switched off, and the dead volume was valved back in to the main volume. The pressure dropped rapidly to ~5E-9 within a few minutes, and it continues to drop.

Also, we (Travis & Janos) added some more parts (an 8" CF to 6" CF tee; CF to ISO adapters, and an ISO valve) to the assembly, and also added a Unistrut support to the tee; see attached photo. Next step is to add the booster pump itself, and anchor it to the ground.
Images attached to this comment
janos.csizmazia@LIGO.ORG - 08:27, Thursday 28 August 2025 (86606)
LOTO was applied now both to the handlers of the hand angle valve and the hand Gate Valve.
Images attached to this comment
H1 CAL
oli.patane@LIGO.ORG - posted 11:19, Wednesday 13 August 2025 (86341)
Calibration Measurement August 13, 2025 17:42 UTC

At the time of starting these measurements, we had been Locked for over 3 hours, so we were fully thermalized
CALIBRATION_MONITOR screen and pydarm report are attached

Broadband
2025-08-13 17:42:30 - 17:47:47 UTC
/ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250813T174237Z.xml

Simulines
2025-08-13 17:48:52 - 18:12:09 UTC
/ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250813T174853Z.hdf5
/ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250813T174853Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250813T174853Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250813T174853Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20250813T174853Z.hdf5

Images attached to this report
Non-image files attached to this report
LHO VE
david.barker@LIGO.ORG - posted 10:30, Wednesday 13 August 2025 (86340)
Wed CP1 Fill

Wed Aug 13 10:07:22 2025 INFO: Fill completed in 7min 18secs

Gerardo confirmed a good fill curbside.

Images attached to this report
H1 CAL
oli.patane@LIGO.ORG - posted 09:53, Wednesday 13 August 2025 (86339)
Calibration Measurement August 13, 2025 16:13 UTC

At the time of starting these measurements, we had only been Locked for 1.5 hours, so we were not fully thermalized
CALIBRATION_MONITOR screen and pydarm report are attached

Broadband
2025-08-13 16:13:34 - 16:18:45 UTC
/ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250813T161334Z.xml

Simulines
2025-08-13 16:19:57 - 16:43:04 UTC
/ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250813T161958Z.hdf5
/ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250813T161958Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250813T161958Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250813T161958Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20250813T161958Z.hdf5

Images attached to this report
Non-image files attached to this report
H1 CAL
oli.patane@LIGO.ORG - posted 09:09, Wednesday 13 August 2025 (86337)
Calibration Measurement August 13, 2025 15:30 UTC

At the time of starting these measurements, we had only been Locked for 1 hour (1hr10min since MAX_POWER), so we were not fully thermalized
CALIBRATION_MONITOR screen and pydarm report are attached

Broadband
2025-08-13 15:31:30 - 15:37:02 UTC
/ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250813T153151Z.xml

Simulines
2025-08-13 15:38:19 - 16:01:22 UTC
/ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250813T153820Z.hdf5
/ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250813T153820Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250813T153820Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250813T153820Z.hdf5
/ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20250813T153820Z.hdf5

Images attached to this report
Non-image files attached to this report
H1 General
oli.patane@LIGO.ORG - posted 07:40, Wednesday 13 August 2025 - last comment - 08:25, Wednesday 13 August 2025(86334)
Ops Day Shift Start

TITLE: 08/13 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 151Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 0mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.12 μm/s
QUICK SUMMARY:

Currently Observing at 153 Mpc and have been Locked for 10 minutes

Comments related to this report
oli.patane@LIGO.ORG - 08:25, Wednesday 13 August 2025 (86336)Lockloss

Last night's lockloss at 2025-08-13 12:59UTC has no obvious cause, but I did notice that the dumped power into HAM6 is an interesting shape, with two bumps instead of the usual one. However, I did find a lockloss from 2025-07-28 03:13UTC whose power has the same shape, so it's probably just an alignment thing, especially since the last lockloss was positioned in such a way that the fast shutter didn't even need to fire (86325).

Images attached to this comment
LHO VE (DetChar, VE)
travis.sadecki@LIGO.ORG - posted 13:51, Wednesday 06 August 2025 - last comment - 08:30, Thursday 28 August 2025(86227)
BTRP adapter flange and GV installed at MX

Yesterday, we installed the BTRP (Beam Tube Roughing Pump) adapter flange on the 13.25" gate valve just to the -X side of GV13.  This included installing a 8" GV onto the roughing pump port of the adapter, moving the existing gauge tree onto the new adapter, and installing a 2.75" blank on an unused port.  All of the new CF joints were helium leak tested and no signal was seen above the ~9e-11 torrL/s background of the leak detector. 

The assembly is currently valved out of the BT vacuum volume via the 13.25" GV, and is being pumped down via small turbo and aux cart.  Therefore, the PT-343 gauge reading is only reporting on the BTRP assembly pressure, not the main BT pressure, so it can be ignored until further notice of it being vavled back in.  This system has been pumping via aux cart or leak detector since ~2pm yesterday, and will continue to be pumped until it is in the pressure range of the BT volume.  The aux cart is isolated by foam under the wheels, but some noise may be noticed by DetChar folks, hence the DetChar tag on this report.

Comments related to this report
janos.csizmazia@LIGO.ORG - 16:08, Wednesday 06 August 2025 (86230)
A before - after pair of photos.
As the conductance is very bad in this complex volume, we're aiming to pump it until next Tuesday. The estimated pressure rise of the main volume after valving in this small volume next Tuesday is less than E-12 Torr (after equalizing) - in other words, negligible.
Images attached to this comment
anna.iudintseva@LIGO.ORG - 16:20, Wednesday 06 August 2025 (86231)
Some backstage snapshots of the great teamwork of Travis, Janos, and me on installing these: Pic. 1 - "before"; 2,3 - 90% complete.
Images attached to this comment
travis.sadecki@LIGO.ORG - 09:39, Wednesday 13 August 2025 (86338)

As of Tuesday, August 12, the pumps have been shut off and removed from this system, and the gauge tree valved back in to the main volume.  Noise/vibration and pressure monitoring at MX should be back to nominal.

janos.csizmazia@LIGO.ORG - 08:30, Thursday 28 August 2025 (86607)
LOTO was applied now both to the handlers of the hand angle valve and the hand Gate Valve.
Also, components have been added to the header, only 1 piece away from the booster pump.
Images attached to this comment
X1 SEI (ISC, SEI)
jeffrey.kissel@LIGO.ORG - posted 10:15, Monday 16 June 2025 - last comment - 11:40, Wednesday 13 August 2025(84825)
Optical Setup and Results of first tuning of SPI In-vac SuK Fiber Collimator Lens Position
J. Kissel

Executive Summary
I've tuned the lens position and measured the projected beam profile of one of three trial fiber collimators to be used for the SPI. The intent is to do this measurement before vs. after a vacuum bake like done for previous collimators (Section 3.3 of E1500384), to see if the bake will cause any negative impact on the performance of the collimator. It also helped clear out a few "rookie mistake" bugs in my data analysis, though there's still a bit of inconsequential confusion in post-processing the fit of the beam profile.

Full Context
The SPI intends to use supposedly vacuum compatible Schaefter + Kirchhoff (SuK) fiber collimators (D2500094, 60FC-0-A11-03-Ti) in order to launch its two measurement (MEAS) and reference (REF) beams from their fiber optical patchcords attached to feedthroughs (D2500175) in to free-space and throughout the ISIK transceiver / interferometer (D2400107). However, unlike their (more expensive) stainless steel counterparts from MicroSense / LightPath used by the SQZ team, SuK doesn't have the facilities to specify a temperature at which they believe the titanium + D-ZK3 glass lens + CuBe & Ti lens retaining ring assembly will fail (see E2300454). As such, we're going to run one SuK collimator through the same baking procedure as the MicroSense / LightPath (see Section 3.3 of E1500384) -- slow 6 [hr] ramp up to 85 [deg C], hold for 24 hours, similar slow ramp down -- and see if it survives.

A catastrophic "if it survived" result would be that the lens cracks under the stress of differential heating between the titanium, CuBe, and glass. 
As we don't expect this type of failure, in order to characterize "if it still functions," we want a quantitative "before" vs "after" metric. 
Since I have to learn how to "collimate" this type of collimator anyways (where "collimate" = mechanically tune the lens position such that emanating beam's waist is positioned as close to the lens as possible), I figure we use a 2D beam profile as our quantitative metric. We expect the symptom of a "failed" fiber collimator to be that "before bake it projects a lovely, symmetric, tunable, Gaussian beam, and after bake the profile looks asymmetric / astigmatic or the lens position is no longer consistently/freely adjustable."

The SPI design requires a beam whose waist (1/e^2) radius is w0 = 1.050 mm +/- 0.1 mm. That puts the Rayleigh range at zR = pi (w0^2) / lambda =  3.25 [m], so in order to get a good fit on where the waist lies, we need a least one or two data points beyond the Rayleigh range. So that means projecting the beam over a large distance, say at least ~5-6 [m].

Measurement Details
2025-06-03_SPIFC_OpticalSetup.pdf shows the optical setup. 

Pretty simple; just consuming a lot of optical table space (which we thankfully have at the moment). The "back" optical table (in IFO coordinates the "-X table (with the long direction oriented in the Y direction") already has a pre-existing fiber coupled, 1064 nm, laser capable of delivering variable power of least 100 [mW] so I started with that. It's output has an FC/APC "angled physical contact" connector, where as the SuK fiber collimators have an FC/PC (flat) "physical contact" connector. I thus used a ThorLabs P5-980PM-FC-2 APC to PC fiber patch cord to couple to the SuK fiber collimator, assembled with a (12 mm)-to-(1 inch) optic mount adapter (AD12NT) and mounted in a standard 1" mirror mount, set at 5 inch beam height. Ensuring I positioned the free-space face of the collimator at the 0 [in] position, I projected to beam down the width of the optical table, placed steering mirrors at 9 [ft] 9 [in] (the maximum +Y grid holes), separated by 6 [in] in order to return the beam down the table. Along this beam, I marked out grid-hole positions to measure the beam profile with a NanoScan head at 
    z = [0.508 0.991 1.499 2.007 3.251 4.496 5.41] [m] 
These are roughly even half-meter points that one gets from "finding 1 inch hole position that gets you close to 0.5 [m] increments", i.e. 
    z = [1'8", 3'3", 4'11", 6'7", 10'8", 14'9", and 17'9"].

Using the SuK proprietary tooling, I then loosened the set-screws that had secured the lens in position with the 1.2 mm flat-head (9D-12), and adjusted the position of the lens with their short eccentric key (60EX-4), per their user manual (T2500062 == Adjustment_60FC.pdf), with the NanoScan was positioned at the 5.41 [m] position.
At the 5.41 [m] position, we expect the beam radii to be w(z=5.41 m) = w0 * sqrt(1 + (z/zR)^2) = 2.036 [mm], or a beam diameter of d(z=5.41 m) = 4.072 [mm].

Regretfully, I made the rookie mistake of interpreting the NanoScan's beam widths (diameters) as radii on the fly, and "could not get a beam 'radii' lower than 3.0 [mm]," at the z = 5.41 position, as adjustments to the eccentric key / lens position approached a "just breath near it and it'll get larger" level at that beam size. This will be totally fine for "the real collimation" process, as beam widths (diameters) of 4.0 [mm] required much less a delicate touch and where quite repeatable (I found, while struggling to achieve 3.0 [mm] width).

Regardless, once I said "good enough" at the lens position, I re-secured the set screws holding the lens in place. That produced a d = 3.4 [mm] beam diameter, or 1.7 [mm] radius, at the z = 5.41 [m]. I then moved the NanoScan head to the remaining locations (aligning the beam into the head at each position, as needed, with either the steering mirrors or the fiber collimator itself) to measure the rest of the beam profile as a function of distance.

2025-06-03_SPIFC_BeamScans_vs_Position.pdf shows the NanoScan head position and raw data at each z position after I tuned the lens position at z = 5.41 [m].
Having understood during the data analysis that the NanoScan software returns either 1/e^2 or D4sigma beam *diameters*, I followed modern convention and used the mean D4sigma values, and converted to radii with the factor of 2, w(z) = d(z) / 2. One can see from the raw data that the beam profile at each point is quite near ''excellently Gaussian,'' which is what we hope will remain true *after* the bake.

Results

2025-06-03_spifc_S0272502_prebake_beamprofile_fit.pdf shows the output of the attached script spifc_beamprofile_S0272502_prebake_20250603.m, which uses Sheila's copy of a la mode to fit the profile of the beam.

Discussion
The data show a pretty darn symmetric beam in X (parallel to the table) and Y (perpendicular to the table), reflecting what had already been seen in the raw profiles.
The fit predicts a waist w0 of 
        (w0x, w0y) = (0.89576, 0.90912) [mm] 
at position 
        (z0x, z0y) = (1.4017, 1.3469) [m] 
away, downstream from the lens. Makes total sense that the z position of the waist is *not* at the lens position, given that I tried to get the beam as small a *diameter* possible at the 5.41 [mm] position, rather than what I should have done which is to tune the lens position / beam diameter to be the desired 4.072 [mm].

What doesn't make sense to me, is that -- in trying to validate the fit and/or show that the beam behaves as an ideal Gaussian beam would -- I also plot the predicted beam radius at the Rayleigh range, 
    w(zR) [model] = w0 * sqrt(1 + (zR/zR)^2) = w0 * sqrt(2),
or 
         (wzRx, wzRy) [model] = (1.2668,1.2857) [mm]
which is much larger than the fit predicts,
         (wzRx, wzRy) [fit] = (0.9677,0.9958) [mm]
at a Rayleigh range,
    zR = pi * w0^2 / lambda
of 
         (zRx,zRy) [from fit w0] = (2.3691, 2.4404) [m]

Similarly confusing, if I plot a line from the waist position (z0x, z0y) to the end of the position vector (6 [m]), whose angle from the x-axis is the divergence angle
    theta_R = lambda / (pi * w0)
i.e. a predicting a waist radius at zEnd = 6 [m] of 
    w(zEnd) = (zEnd - z0) * atan(theta_R)
this results in a beam waist at xEnd much smaller than the fit. Most demo plots, e.g. from wikipedia:Rayleigh_length or wikipedia:Beam_divergence, show that slope of the line should start to match the beam profile just after the Rayleigh range. To be fair, these demos never have quantitative axes, but still. At least the slope seems to match, even though the line is quite offset from the measured / fit z > 6 [m] asymtote.

Conclusion
Though I did not adjust the lens position to place the beam waist at desired position, I now have a good measurement setup and data processing regime to do so for the "production" pair of fiber collimators. For this collimator, since we're just looking at "before" vs. "after" bake data, this data set is good enough.

Let's bake!
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 11:40, Wednesday 13 August 2025 (86342)
I took a moment to revisit the "cross checks" of the fit -- namely why the waist at the Rayleigh range (w(zR)) and Divergence angle's (\theta_{R}) prediction of what the waist should be in the "far field," (w(zEnd)), and solved the "mysteries."

(1) For the the prediction of the waist radius at the Rayleigh range: all the above math was correct, it's merely that I did not properly offset the z position w.r.t. where the origin of the plot lie (at the fiber collimator). If I adjust the z position for that offset
    (zRx,zRy) [from fit w0] = (z0x+zRx, z0y+zRy) [from fiber collimator, i.e. z = 0 [m]] 
                            = (1.4017, 1.3469) + (2.3691, 2.4404) [m]
                            = (3.7708, 3.7899) [m]
then the waist radius (w0 * sqrt(2)) lands bang-on the fit and measurement.

(2) For why the simplistic model of divergence angle doesn't appear to match the divergence of the measurements or model: this is merely a question of what really is "near" and "far" field. Turns out if you just expand the z range what I would call "way" out -- from 6 [m] to 20 [m] -- you see convergence between the two models.

The pdf attached here is a new version of the plots showing the same data and model above, but with the simplistic models fixed. I now show two pages, page one with the original zoom from z = 0 to 6 [m] aka the "Near" field demonstrating (1), and page two zoomed out from z = 0 to 20 [m] demonstrating (2).

I also attach the updated version of the code, spifc_beamprofile_S0272502_prebake_20250603.m.
Non-image files attached to this comment
Displaying reports 1701-1720 of 85590.Go to page Start 82 83 84 85 86 87 88 89 90 End