The Transition from LASER HAZARD to LASER SAFE  by Besty Work permit # 13705 or 13706
 

TITLE: 10/20 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 4mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.25 μm/s 
QUICK SUMMARY:
Seems relatively calm in the control room. CDS screen is mostly green, which is good.

Work listed on the Trello board today:

• Transition LVEA to SAFE
• CDS - Update Safe and Observe snap files  - adding channels
• CDSHW - Terminate CHETA field cabeling in TCS-R1 & R2 racks. Laser interlock will be connected. 
• CHETA X Table install
• CHETA - Beckhoff work for the X table
• PSL - Laser issues
• VAC - Rogers here for Kobelco work
• Safety Walkthru, visitors onsite
• VAC - pumps on at EY, MY, maintenace
• Jenne - Install seismometers under ITMY and ETMY chambers
• PMC ref cav tune up
• Any Other shennaninanigains
  
   

The attempt to revert to last Thursday's alignment has not gone well so far. Ryan Crouch and I were not successful in getting through initial alignment after he reset the green references (qpd & camera offsets). First there were issues with the input align steps of align_ifo. I later learned that we've apparently been having issues with this step for a few days now and have been able to just skip it (?). Ryan C. and I tried going to MICH dark but the guardian was pulling the BS off into space and saturating the BS suspensions. 

- I tried sitting in PREP_FOR_MICH and aligning the BS by hand while it was swinging. This did not seem to help & also we aren't getting anywhere the level of fringes on AS_A RF45Q as we were when Tony went through PREP_FOR_MICH on Monday morning. I'm not sure what changed.

- Sheila logged in & noticed poor alignment on AS_A RF45Q. 
- I ran AS_CENTERING_OFFLOADED & that helped. 
- Unlocked IMC to check dark offsets on AS_A. AS_A RF45Q was not hitting zero at all so we reset the dark offsets for I & Q (sdf.png).
- After this we still had trouble getting to MICH DARK LOCKED. maybe a gain thing ... but an EQ rolled in so we decided to call it a night.

=== 

I'm also attaching some ndscope screenshots of AS_A DC and AS_A RF45Q during PREP_FOR_MICH taken on Monday evening before checking the centering on AS_A and after. The delta on AS_A_DC increased from about 100 to 4200 counts. Sheila made the point that we might consider re-thinking about how we do initial alignment and whether we should bake in some centering checks along the way as the centering clearly has an impact on the MICH error signal.

TITLE: 10/20 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:
LOG:        

I reset the GREEN references to what they were on Thursday, I then reran initial alignment, I was not able to get through input_align as the IMC would keep unlocking in ACQURE, usually right after the IMC_MCL gain is lowered to zero. I then went through PRX, PRC without an issue, but MICH_DARK was clearly bad. The BS M2 stage was saturated and the camera looked like MICH_BRIGHT. We then realized I had forgotten to revert the alignments of PR2 and IM4 which I then did to 10/15 21:05 UTC, bottom and top mass osems on PR2 both agreed. We went down and I did that, and tried input align again, but to no avail.

Today, while we were locked on analog carm, I was able to walk the alignments to a decent place and I got references before a lockloss. These aren't the *best* alignments, since the ADS loops were pretty far off, but CHARD/PRC2/INP1 were at zero and the SRM was in a decent place.

Just wanted to make sure these are recorded, since we *know* we can lock with this alignment. It's not the best alignment, but it gets us to prep full ifo asc.

They are currently SDFed, but it sounds like Louis may try the best alignment from last week later tonight.

I was finally able to engage the MICH ASC loops on RF36. The gains are much lower than they have been in the past.

As a reminder, I have previously walked the beamsplitter to confirm that the RF36 error signals cross zero when the buildups are maximized, and I have checked the overall relative phase between MICH on RF45 and RF36. Nothing should nominally be wrong, and I was able to measure a 2 Hz MICH P loop in PRMI on RF45, but raising the gain on RF36 seems to cause a lockloss.

The ISC_LOCK guardian usually engages the MICH ASC on RF36 in OFFLOAD DRMI ASC after the RF45 MICH loops are offloaded. First the loops are engaged, then a -20 dB gain is switched off when the MICH loop integrators come on. There are two integrators, one in the loop design and one on the suspension.

I engaged the loops with their usual or slightly lower epics gain, and I commented out the disengagement of FM1, which is the -20 dB gain filter.

When I measured the MICH P OLG, the loop gain is definitely very low, but any attempt to raise the gain seems to cause a lockloss.

PREP_ASC_FOR_FULL_IFO would bump up these gains, but I commented that out until we can determine if we are happy with the gains.

We now have some understanding of the FE to daqd data transmission problems.  The quick fix that we did was to restart the cps_recv processes on the dc0 and dc1 machines.

The root problem was a truncation of a gps time used as a key value interacting with logic that was put in to protect the system from slow (or dead) consumer processes that where pinning messages in memory.  The main issue is the system was looking for the next message by key value and due to truncation would not generate a key that was larger (due to the truncation).  It is an easy fix.  We will need to push out at least new advligorts-transport-pubsub packages to the front ends and the daqd systems.  This is best to do at one of the next daqd restarts.  We have a large window of time until this causes issues again, so there is time to test, it should updated prior to IR1.

Last Tuesday, Jennie and I did some quick measurements running HAM2-3 SPI DIFF length in loop on HAM2 during maintenance. We tested 2 configurations of the ISI SPI supersensor, one used the blend filter I posted the week before, the other was using the normal 250mhz blend filter, but using the SPI for the low pass and the GS13 for the high frequency sensor. After we realized that the SPI need a minus sign in the blend, each of the SPI blends was stable, the IMC was able to stay locked and the HAM2 ISI X control stayed at least reasonable for the short time we tested these blends. 

Attached images are asds of 3 configurations, with HAM2 in the nominal CPS/GS13 blend, HAM2 using the 3 part CPS/SPI/GS13 blend and HAM2 using the 250mhz SPI/GS13 blend. HAM3 stayed in it's nominal state, CPS diff was turned off at HAM2, sensor correction was off. For each plot, red is the HAM2 nominal state, blue is with the 3 part blend, green is the 250mhz SPI/GS13 blend. First image is IMC F OUT, second image is the HAM2-3 differential GS13s, the third image is the HAM2 GS13s and the fourth image is the SPI DIFF length channel.

None of these plots show a clear win for SPI, but we didn't really have time to try any changes and there's clearly some evidence of anthropogenic noise in some of the spectra. I hope to get some time in the evenings when commissioning is done to do some more testing, particularly doing things like using the CRS on HAM3, sensor correction on, different blends on HAM3. Sina has also shared some better X blends, and blends for the other dofs (for HAM2, using SPI QPDB for pitch(RY) and yaw(RZ).

Times for the configs tested:

Oct 13 2026 17:50:36 utc HAM2 nominal blends, no sensor correction or cps diff

Oct 13 2026 17:45:51 utc HAM2 3 part SPI blends, no sensor correction or cps diff

Oct 13 2026 18:22:06 utc HAM2 250mhz SPI/GS13 blend, no sensor correction or cps diff

TITLE: 10/19 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Ryan C. 
SHIFT SUMMARY:
The Site wide CDS issue was resolved by the CDS team before 11. Since I don't see an alog this is what I heard from a tiny little bird.... one of the CDS team memebers got back to me just before the end of my shift and told be it turned out to be a mini hexadecimal Y2K type event but for Oct 18th 2026 2:43:10 PDT becuase that GPS time 1476395008 is 
apparently  = '0x58000000' in Hexadecimal. I hope I didn't spoil the plot of an awesome future CDS alog. 

The Commisioners have been locking the IFO to Prep ASC to Full IFO and we still haven't gotten got much further than that.  

Note I spent some amount of time troubleshooting the lockloss tool. I was able to get it to run by emptying the contents of extra_LL_plots into:
/opt/rtcds/userapps/release/sys/h1/templates/locklossplots
as the the script was looking for yaml files and choking on the directory named extra_LL_plots. Removing that worked for both Ryan C and my self.
The web analysis still is not completing though. 

. 

LOG:
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            

TITLE: 10/19 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 4mph Gusts, 2mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.27 μm/s 
QUICK SUMMARY:

• More attempts to commission at PREP_ASC but we're having some trouble both in getting and staying there

Louis and I had left the CARM comcomp boost off since last Wednesday (10/14) at 16:32 local time, because we thought it was causing a lockloss. However, that must have been a fluke. Now carm_to_analog will engage it, as usual.

Putting this here in case we can link this lack of boost was causing some of our fast locklosses.

In other news, we had multiple locklosses from start_tr_carm today, and Sheila noticed the order of the steps in the run state didn't make sense. She reordered the run state logic, and we have now successfully ran the state twice.

Closes FAMIS85359 , last checked in alog92122

• TCSx Chiller:  Had level of 30.2 cm.  Added 100mL for 30.5cm.
• TCSy Chiller:  Had level of 10.4 cm.  Added 60mL for 10.5cm.
• There was no water in the leak dectector cup

Using the cavity parameters from LIGO-T1700104-v2 (VOPO final design) and the ABCD matrix from M. Stefszky, Sec. 6.1.2, I calculated the eigenmodes of the OPO cavity in vacuum and in air.

Method

• Round-trip ABCD matrix starting and ending at the crystal center (Stefszky eq. 6.6 and DCC T1700104 eq. 16), using the propagation, interface and curved-mirror matrices.
• Calculated the eigenmode of the round-trip matrix, eigenvalues, and checked the cavity's stability.
• Parameters: taken and calculated from LIGO-T1700104-v2
• Air: n_air = 1.000274 (1064 nm), 1.000278 (532 nm) ~ 1.0003 

Vacuum (n_vac = 1.0):

Air (n_air = 1.000274 at 1064 nm, 1.000278 at 532 nm)

Overlap (air vs vacuum)
I calculated the overlap between the vacuum and air eigenmodes at the crystal center, separately for each plane, using the finesse overlap function.
 

Summary

• The cavity is stable in both planes at both wavelengths, in vacuum and in air (no suprise, but good check anyways). The vacuum results agree with Table 1 of T1700104 (w₀ = 30.0/29.9 µm at 1064 nm and 21.1/21.1 µm at 532 nm, sagittal/tangential)
• Going from vacuum to air shrinks the waist by only about 1-2 nm (about 1 part in 10⁴), and the g factor and Gouy phase change in the fourth decimal place.
• The air and vacuum eigenmodes show a strong overlap at both wavelengths, so the change in refractive index on pump-down could have a negligible effect on the mode.

J. Kissel, J. Oberling [for -- we think -- R. Short]

I was just browsing the SPI signals this morning, catching up after being out on leave and I noticed that the SUM on the SPI QPDs was a bit lower that when I last looked closely on Oct 6 2026 (after we intentionally throttled the SPI input power; see 92192). 

On Oct 15 2026 at 23:45 UTC (4:45p PDT), someone manually increased the ISS REF Signal (H1:PSL-ISS_REFSIGNAL), the set-point for how much power is diffracted from the PSL ISS AOM (AOM01 at coordinates [X,Y] = [61,20] in the H1 PSL as-built layout D1300348-v9), which then increased the percentage of power that's diffracted by the AOM per H1:PSL-ISS_DIFFRACTION_AVG. We think this is Ryan short making good on his Oct 12 2026 promise to adjust the diffracted power in LHO:92278 at the start of his Eve shift (which explains the odd time to make this change; normally done on a Tuesday morning during maintenance).

This, understandably dropped the transmitted power from the PMC -- from ~105 [W] to 104 [W]. This power drop, of course, then trickled down to all things downstream of the PMC, including the ALS / SQZ / SPI pick-off path. The only monitor that's calibrated input optical power units is the on-PSL-table PD (H1:ALS-C_FIBR_EXTERNAL_DC_POWERMON; the Thorlabs SM1PD1A at [X,Y]=[149,38] per D1300348-v9), and that shows a mere 0.33 [mW] drop in power from reported 38.85 ["mW"] that it's been since we adjusted the SPI pickoff path power to 38.52 ["mW"] after ISS ref signal adjustment.

From power meter measurements within the PSL reported in LHO:92192, we know 
- the 38.85 ["mW"] of power reported on this PD is proportional to the power-meter measured power of 68.4 [mW] going into the ALS/SQZ fiber collimator, with proportionality 1.761 [mW/"mW"]. Thus the power in the ALS/SQZ portion of the pick-off dropped to 38.52 ["mW"] *  1.761 [mW/"mW"] = 67.83 [mW], or a 0.57 [mW] drop.
- the optical power ratio between the ALS/SQZ fiber collimator and the input to the SPI path is R:T = (268.3 / 329):(68.4 / 329) = 0.815:0.207. So the total ALS/SQZ/SPI path's power dropped from 329 to 67.83 [mW] * (329 / 68.4) = 326.26 [mW] (or a 2.74 [mW] drop).
- from that, the SPI path's available power dropped from 268.3 [mW] to 326.26 [mW] * (268.3 / 329) = 266.06 [mW] (or a 2.24 [mW]) drop.
- thus, the power injected into the SPI pick-off's fiber collimator has dropped by the same amount, from 190.6 [mW] to 188.36 [mW]. 

No action required, just more "operational information," as adjusting the ISS diffracted power is a relatively frequent thing that's done by the PSL team.

Seems like we are suddenly having problems in DRMI locking when the beamsplitter oplev damping is ramped off and when the BS ISI stage 2 boost is engaged. I say "sudden" because these have no been a problem at all with this despite frequent DRMI locking over the past few weeks.

Looking into this, I noticed that if we have DRMI lockloss, that is, we lose DRMI but not ALS, we return to ACQUIRE DRMI 1F, but the stage2 boost does not get disengaged, which is why this usually causes us to lose lock once, and then it is fine the second time as long as we don't lose ALS.

I don't understand why there is a problem when we ramp down BS oplev damping and then ramp on MICH ASC, but to get around this I will just have it ramp damping off first and then MICH ASC. I changed the order in ISC_DRMI guardian with the oplev damping ramp wait=TRUE. I have tested this twice and it works.

Jim has looked at the trends when we lock DRMI and he recommends that we can keep the ST2 boost on all the time now since, it appears the BBSS is not kicking the ISI as much as it used to when acquiring DRMI/PRMI. I will work on taking that bit out of the guardian.

Camilla, Sheila, Ryan Crouch

Attached are three screenshots of fast locklosses from last night and this morning (here, here, here) and one more normal lockloss for comparison.  These seem a lot like the locklosses that plauged us in October and Nov of 2024, because AS power drops down before it goes up, and the IMC looses lock at exactly the same time as the light disappears at the AS port. 

Here are some useful alogs to reference the previous problems: 81371 (Vicky also has a comment to this with a useful summary of investigations done)

Ryan Crouch had the IFO in down, with the IMC locked, for an hour (16:53 -17:53 UTC). Screenshot of the hour trends and zoomed in on the biggest glitch seen here. He also had the IMC offline for 1 hour, from 17:55 UTC to 18:55 UTC, trends here.  These can be compared to similar trends from last Nov, for example 81356.  The size of the glitches in the PMC PZT is similar to then, but other signals like PMC mixer mon and FSS fast mon are not glitching now. 

(Will add more info later, posting now so Camilla can add her plots in comments).

Summary: ADC noise is very close to, if not limiting the QOSEM signals. It doesn't seem to be enough to explain the elevated QOSEM noisefloor seen, but whitening gain should not be lowered any futher than it already is.

This is one in a series of posts investigating the excess noise seen on the BBSS M1 QOSEMs. In short, at both LHO and LLO, the noisefloor of the QOSEMs appears to be around 8pm/rtHz at 100Hz, quickly increasing to 50pm/rtHz by 1Hz; where we expect the noisefloor to be flat at ~5pm/rtHz across this bandwidth. See more details in LHO alog 91466. 

At both LHO and LLO, changes have been made to the QOSEM sat amp to reduce the whitening gain (see LHO:91853 and LLO:82137), in response to long saturation periods when the BBSS is rung up. In the figures below we plot noise budgets of the LHO BBSS, now including the new whitened ADC noise floor. The expected noisefloor of the GS 16 Bit ADC was taken from T1000322. Keep in mind that the true ADC noise floor often varies from channel to channel and unit to unit. Informally, I've heard they can vary by as much as factors or 2-3, especially towards the lower frequencies, however I dont have any solid reference for this.

Figure 1 shows the raw voltage noise of the QOSEM signals (Sum, XDiff, YDiff) after dewhitening, along with expected shot noise level and ADC noise. During this section of data, the BBSS damping loop was off, and the QOSEM LED sum feedback was turned off (see LHO:92011 for details). Here we see that the ADC noise is very close, if not limiting the QOSEM XDiff and YDiff signals, particularly if we consider true ADC could vary higher than shown. Certainly, whitening gain should not be reduced any futher. 

Figure 2 shows an open loop noise budget of the BBSS M1, now with the whitened ADC noise propagated in. Again we see that the ADC noise is very close to, if not limiting, particularly at the high frequencies. 

With this said, I'm not convinced we can blame ADC noise for this excess QOSEM noise we've been seeing. In prior budgets (such as LHO:91871), LHO QOSEMs were running with about 10x more whitening gain and the QOSEM noise floor was not sigificantly different. With that said whitening should certainly not be lowered any further.