Closes FAMIS37255, last checked in alog85779

Everything looks as expected, LVEA5 is off during observing.

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.

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.

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.

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.  

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

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

Gerardo confirmed a good fill curbside.

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

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

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

TITLE: 08/13 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY:

Nice shift with H1 locked 6hrs15min.  We did have 3 drop-outs due to TCS ITMy CO2 (all quick and automatic recoveries).  ~45min after the 3rd drop, ther was superevent S250813k.  Ended the night checking out peak Perseids just before the moon was rising.
LOG:

• 0032 Turned off turbo at MY (janos)
• Observing DROPs:  TCSy Laser unlocked, but found a new locking point and came back automatically.
  • 0048-0050
  • 0055-0056
  • 0135-0136
• 0212 S250813k
• 0426-0452 Drove out to the Y-arm +1km spot to look at Perseids (saw 6 meteors [and 6 satellites]).  Moon was barely rising (about 3-diameters) as I drove back to the Control Room. 

Just had a couple of drops from Observing due to TCS_ITMY_CO2 guardian saying laser is unlocked and needed to find a new locking point.  (Attached are the two occurrences thus far).

TITLE: 08/12 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 143Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Currently Observing at 145 Mpc and have been Locked for 50 minutes. Relocking went pretty well today with the only concern being the fast shutter not firing during the last lockloss (86324), but luckily it seems like we were okay and that was expected in that situation.
LOG:

14:30UTC Locked for 5.5 hours and running magnetic injections
    14:40 Back into Observing
    14:45 Out of Observing for SUS charge measurements
14:57 Lockloss
19:18 Started relocking
    - Initial alignment - BS ADS convergence took 16+ minutes (86320)
20:47 NOMINAL_LOW_NOISE
    20:55 Observing
21:12 Lockloss
22:44 NOMINAL_LOW_NOISE
    22:46 Observing                                                                                                                                                                                                                                                                                                    

TITLE: 08/12 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 144Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 8mph 3min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.17 μm/s
QUICK SUMMARY:

Got the hand-off from OIi which was standard other than their mention of the Fast Shutter note after a lockloss they had from their first locking attempt post-Maintenance.  H1 has currently been locked for almost an hour. 

(oh and Oli did also mention on leaving that they & Elenna noticed there was a Verbal Alarm for a PR3 saturation which happened about 20min after being in observing---they mentioned this is an odd thing for PR3.)

Operator Checksheet NOTES:

• FOM wall scan: 
  • CDS Overview has: 
    • (1) CDS Server Room Environment is YELLOW for MY due to Light Level being at ~65% (vs sub-5%),
    • (2) CDS ALARM box is red due to an MY VAC pressure signal (was also red yesterday) and looking at the screen for this, I'm guessing texts have already been sent to "system's engineers"
  • Calibration ndscope (nuc26):  Elenna noted it looked odd (all signals were flat), and she logged in to see it was paused, so she hit the Start Online button to bring it back.
  • Ran the "check_dust_monitors_are_working" script and have had the usual notifications for LVEA5 & LAB2 dust monitors.
• Access System "flashing doors" at:  VPW LDAS entry, VPW dirty shop entry, & EY mechanical room person door.
• Control Room Screenshots:  "H1 Glitches" (nuc27) not updating (has trouble screen for browser, which has been case for a while)

Ivey, Edgard, and Brian have created new estimator fits (86233) and blend filters (86265) for the SR3 Y estimator, and we have new rate channels (86080), so we were excited to be able to take new estimator measurements (last time 85615).

Unfortunately, there were issues with installing the new filters, so I had to make do with the old filters: for the for the estimator filters, I used the fits from fits_H1SR3_2025-06-30.mat, and the blend filters are from Estimator_blend_doublenotch_SR3yaw.m, aka the DBL_notch filter and not the new skinny notch. These are the same filters used in the testing from 85615.

So the only difference between the last estimator test and this one is that the last test had the generic satamp compensation filters (85471), and this measurement has the more precise 'best possible' compensation filters (85746). Good for us to see how much of a difference the generic vs best possible compensation filters make.

Unfortunately, due to the filter installation issues as well as still trying to re set up the estimator channels following the channel name changes, I also didn't have much time to run the tests, resulting in the actual test with the estimator being only 5 minutes. Hopefully this is okay enough for at least a preliminary view of how it's working and then next week we can run a full test with the more recent filters. Like last time, the transition between the OSEM damping and the estimator damping was very smooth and the noise out of the estimator was visibly smaller than with the regular damping (ndscope1).

Measurement times
SR3 Y damp -0.1
2025-08-12 18:28:00 - 18:44:00 UTC

SR3 Y damp -0.1, OSEM damp -0.4
2025-08-12 18:46:46 - 19:03:41 UTC

SR3 Y damp -0.1, Estimator damp -0.4
2025-08-12 19:09:00 - 19:16:51 UTC

Oli told me that the TCS CO2Y Chassis Tripped off during Maintenance this morning. This is not surprising as there was alot of craning work going on near that rack and the CO2 chassis are known to be fussy, see FRS 6639.

When I went to untrip it both indicator lights were red on it but after key-ing off/on, it turned on with no issues. 

WP12746 h1omc0 Low Noise ADC Autocal Test

EJ, Jonathan, Dave:

For a first test we restarted h1iopomc0 three times to run an autocal on the low-noise ADC -- each time the autocal Failed. Next test will be to power cycle existing card leading to possible replacement.

WP12755 TW1 Raw Minute Trend Offload

Dave:

h1daqtw1 was configured to write it raw minutes into a new local directory to isolate the last 6 months of data from the running system. The NDS service on h1daqnds1 was restarted to serve these data from this location while the file transfer progresses.

Restarts

Tue12Aug2025
LOC TIME HOSTNAME     MODEL/REBOOT
09:06:26 h1omc0       h1iopomc0   <<< three ADC AUTOCAL tests
09:08:12 h1omc0       h1iopomc0   
09:08:58 h1omc0       h1iopomc0   
09:09:12 h1omc0       h1omc       <<< start user models
09:09:26 h1omc0       h1omcpi     
11:51:19 h1daqnds1    [DAQ] <<< reconfigure for TW1 offload
 

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.

3:47:39 UTC unknown Lockloss  

 

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!