Plot of 3 months of Bit switching.
There are certainly bits switching on all of the channels.
Marked nad noticable increase in bit switching on May 22nd for ETMY which I believe is a known issue.

J. Kissel

I'm are trying to figure out the best metrics for showing off the improvements to the OSEM PD's satellite amplifier's whitening improvements.
Thus far, Oli's been using the input to the damping loops as the metric, using a regression of the corresponding ISI's GS13s to subract out a fit of how much of that sensor signal is seismic noise, and dividing out the loop suppression -- see LHO:86149 for the most recent examples comparing before vs. after the sat amp upgrade. 
Without the presence of any other noise or control signals, that should be a fair comparison of the OSEM PD's sensor noise improvement.
However, for a lot of these comparisons ISC control signals are complicating the comparison -- usually at low frequency where ISC control is typically distributed to the top masses.

I use this aLOG as an example of how to better understand this contribution breakdown for a relatively simple suspension -- H1SUSMC1 -- which only has P and Y ISC control from the IMC WFS. (Longitudinal control for IMC L is fed to MC2). This will also be interesting in the future 
    :: in the context of how SPI and other sensors may improve the cavity motion, 
    :: in terms of what DOFs and loop's worth of control drive at which frequencies -- important for discussions along the lines of "DOF [blah] is dominating the control signal, and the actuator cross-coupling for M1 drive of DOF [blah] to M3 optic DOF [blorp] is large, so let's reduce the DOF [blah] drive," and
    :: in terms of whether/where implementing ISI GS13 estimator feedforward will improve things.

To understand how much of the damping loop *error* signal is composed of ISC *control* signal, I look compare the 
    - the ISC control signal,
    - the DAMP *control* signal, against the
    - the MASTER total control request,
all calibrated to the same point in the control system -- where the control output is summed and in the OSEM basis; just down-stream of the EUL2OSEM matrix, and just upstream of the COILOUTF filters which compensate for the coil driver frequency response (uninteresting for this study).

Pitch -- the T1T2T3 actuators
    (3) Attachment 3 Pitch Noise Comparison excerpt from Oli's LHO:86149. These are times when the IMC was LOCKED, so there should be ISC control. But, see the expected factors of 2x-to3x improvement in the OSEM noise below ~5 Hz. So, maybe the ISC control is so low in bandwidth that its affect isn't impacting this study. But, we can see that there's clearly some other loop suppression that has not been accounted for, so maybe it *is* high bandwidth? Let's find out.
    (1) Attachment 1 Comparison of ISC pitch, DAMP pitch, as well as the other DAMP DOFs that use the T1, T2, and T3 actuators -- Vertical and Roll -- control signals.
    Here, we can clearly see that the damping loops are dominating the T2 (and thus T3) control signal above ~ 0.5 Hz, or conversely, the IMC WFS DC coupled control is dominating below 0.5 Hz.
    (2) Attachment 2 shows that the T2 and T3 sensors receive identical request (mostly an out-of-phase combination of Pitch and Roll damping request, as expected from the EUL2OSEM matrix), and T1 drives mostly Roll damping request. The vertical drive request is subdominant at all frequencies.
    (3) Attachment 4 shows the open loop gain and loop suppression TF magnitudes for pitch. The loop suppression here looks very much like the inverse of the shape of the ASD left in the pitch regression, making me worried that Oli's automated regime for removing the loop suppression isn't perfect... I'll ask.

Yaw -- the LFRT actuators
    (7) Attachment 7 The before vs. after comparison of OSEM noise
    (5) Attachment 5 Similar comparison of ISC vs. relevant DAMP control -- showing IMC WFS control dominating only below ~0.2 Hz.
    (6) Attachment 6 As expected from the EUL2OSEM matrix, the LF and RT actuators receive the same control.
    (8) Attachment 8 Shows the open loop gain and loop suppression TF magnitudes for the Yaw damping loop.

1438365262

No obvious cause yet. Commissioning was going on at that time, but no activity seems suspect.

FAMIS 31097

Looks like only things happening this past week are the FSS TPD signal is dropping, so the RefCav may need some alignment touchup soon, and the mysterious jumps in the TPD signal I first saw a couple weeks ago seem to have stopped as of last Tuesday. Looking at some IMC signals (final screenshot), these show the same behavior of calming down last Tuesday, however, I can't explain what would have changed that day to affect the feedback from the IMC to the FSS.

Sheila, Camilla

The operator team has been having a lot of issues with the SQZ FC locking recently, e.g. 86153. We hoped this was due to incorrect SEI settings 86120, but this didn't solve the issue.

The issue isn't with green locking as green locking can stay for ~minutes. It appears to be when we get to state FC_ASC_ON, although the ASC is not the issue (Oli had tried keeping it off). Comparing an unsuccessful to successful time, both the green and IR powers are lower when we are unsuccessful, as well as the FC_WFS_A_SUM Q_OUT channel, both the WFS and the IR signal get noisy with a growing ~15Hz oscillation before the lockloss plot, which happens before the ASC is turned on.

Sheila notes that this means that the FC IR LSC loop was probably unstable. We measured the crossover and could see it was very close to unstable at 15Hz, see plot. We increased the gain in at the FC LSC input matrix a factor of 1.3, H1:SQZ-FC_LSC_INMTRX_RAMPING_2_7 via sqzparams.py (fc_wfs_a_ir_gain) from -0.86 to -1.12.  This brought the crossover back to the reference with 50deg of phase margin. Ideally we would compleatly redesign this loop but it was hard to design originally 66092.

To get FC to lock successfully, Sheila did had to trend and revert FC2 and ZM3 alignments. It seems that while the FC locking is struggling, the fC ASC can pull these away from nominal.

Interestingly the successful lock, as the ASC comes on, the green light decreases as the IR light increases, maybe this si a sign that green and IR aren't well co-aligned. There is picos in the green FC path, but we don't want to touch these as it's more likely that different OPO crystal voltages or spots change the alignment.

Other things that have changed over the past ~month:

• FC launch power is lower and correlated to the FC_TRANS green power being lower, plot. We were having FC issues at the end of June when this was low as well. We can't increase this without taking power from the green pump.
• FC IR power is degrading quickly throughout a lock, the operators adjusting the OPO temperature brings this up again, plot, but this only sometimes fixes issues with FC locking, e.g.  86153.

Hopefully this has fixed our issues, but if this happens again, steps operators should take are (added to wiki):

• Check OPO temperature via taking SQZ_OPO_LR guardian to SCAN_OPOTEMP (will take 3 minutes, can watch via !SQZ Scopes > OPO temp) once it's done you can take SQZ_OPO_LR back to LOCKED_CLF_DUAL and  check the OPO temp plot that's in https://lhocds.ligo-wa.caltech.edu/exports/SQZ/GRD/OPOTEMP_SCAN/
• If H1:SQZ-FC_TRANS_C_LF_OUTPUT is a lot lower than 80, should check alignments and revert or optimize of FC2 and ZM3 (explicit instructions in the wiki (under "Issues with SQZ_FC Guardian").

Mon Aug 04 10:07:01 2025 INFO: Fill completed in 6min 57secs

Note that, similar to yesterday, TC-B does not saturate at -200C. Perhaps due to lower OAT (24C, 76F).

FAMIS26054

The script reported ITMY_ST1_CPSINF_H3 is high. This was the same as last time this was ran (alog85969).

TITLE: 08/04 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 8mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.07 μm/s
QUICK SUMMARY: Locked for 6.5 hours after an earthquake took us out 10 hours ago. The DARM FOM is currently not working. Violin modes, most notably ITMY mode 6, are elevated but the DCPD window FOM shows that they are damping.

3:47:39 UTC unknown Lockloss  

 

TITLE: 08/04 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Corey
SHIFT SUMMARY:
H1 was locked for a good 6 hours then had an unknown lockloss.
Relocking was interupted at LOWNOISE_COIL_DRIVERS, due to a 6.2 M  earth_quake whcih took H1 to DOWN.

H1 is currently waiting in Earthquake mode.


LOG:
                                                                                                            

We have many peaks below 40 Hz that couple, at least partly, through input beam jitter. Last summer Sam and Genevieve determined that a wide variety of site equipment produced these peaks, including the office area air handler, mini-splits in the CER, and chiller compressors for the main HVAC (LIGO-G2402140).  The figure shows that there is coherence between DARM and the IMC WFS that might be used to clean these low frequency peaks, but that they are currently not being cleaned.

Eventually, we would rather not have peaks that need cleaning, but instead, reduce the source vibration and/or the vibration coupling to DARM. I think that the best plan is to reduce the source vibration of the largest peaks, but to mainly focus on reducing the coupling, because many of these peaks are just 2-5 times the vibration background at the coupling sites, so even eliminating the vibration of the sources will not be enough to get us to our design sensitivity.

The coupling of relatively low amplitude vibrations at low frequencies seems to be associated with coupling resonances. For example, when one of the frequencies of the office area air handler drifted into the 35Hz peak frequency of one of these coupling resonances, the peak in DARM was huge, but was greatly reduced by changing the operation frequency of the air handler (82986).  Ill try to map out these low frequency coupling resonances during commissioning periods as a step in understanding their cause.  But for now, it would be nice to see how much we can reduce the peaks with cleaning.

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

H1 has been locked for 2 Hours and 20 minutes.
All systems seem to be functioning well.
Hoping for a smooth shift of Observing.

TITLE: 08/03 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Currently Observing at 155Mpc and have been Locked for a little over 2 hours. One lockloss today and after some issues with ALS not wanting to stay locked (partially due to ground motion, partially unknown), after an initial alignment we were able to relock fine. We dropped out of Observing once due to the squeezer unlocking but it was able to fix itself.
LOG:

18:05 Lockloss
    - Lockloss from PRMI/DRMI multiple times due to ALSX or Y unlocking
    - Ran an initial alignment
21:19 NOMINAL_LOW_NOISE
    21:21 Observing
    22:10 Out of Observing due to SQZer unlock
    22:15 Back into Observing

Lockloss at 2025-08-03 18:05UTC after over 7.5 hour locked

Lockloss from NLN 2025-08-02 02:57:54
Looks like maybe it's an ASC excursion?

Lockloss at 2025-08-01 22:02 UTC after 3 minutes in NLN. We couldn't go into Observing because of SPM differences causing SDF diffs in the guardians for ISIHAM2/3/4/5. Last time we had this, I asked Jim what to do and he said to just INIT the guardians, and it caused a glitch, but we did not lose lock, and he said INITing them should not cause glitches or locklosses (85809). Today, I did the same thing and went to INIT the guardians, but when doing it for the first one, ISIHAM2, it caused a glitch and we lost lock from it.

The site has been abuzz as of late. For the past few months, western honeybees have turned LIGO from interferometer to apiary. The first swarm, near the LSB lift station was reported in early May. Since then, Facilities group and others have been combing the site, and some 15 colonies have been captured and extracted with the help of Phillip Johnson from The Bee Team (seen in buzzworthy photos below). 

The bees have been largely indiscriminate about hive habitat selection. To date we have removed them from spools, BTE interiors, irrigation boxes and connexes. It's not clear where the bees came from, or how they got here. The nearest location to site that I could find which would utilize bees, Brainstorm Cellars, is some 6 miles away. This is further than a swarm will migrate. Stranger yet, the habitat between us and the nearest possible location is, to my understanding, not favorable for hive building which would rule out leap frogging to us. Nevertheless, the bees are here and thriving. The queens are prolific egg layers; the forager bees are caked in pollen and the extractions of more established colonies are chalked full with 10's of pounds of delicious, capped honey. Bee temperament is, across the board, very mild. Even during our most invasive extractions they seem largely unbothered. 

All that to say, I hope to see the increase of bees across site taper off strongly, especially as we inch closer to Fall. In the meantime, M. Landry has recently reached out to the WSU Honeybees and Pollinators Program to help us understand how we came to find this abnormal explosion of bees. That meeting has yet to take place. 


C. Soike, M. Robinson, T. Guidry

SEI_CONF transition to EQ.

I actually started this a long time ago, but got swamped with other work and buried by snow. Our seismon code does not seem to give an accurate prediction of ground velocities. Attached plot compares the timeseries .03-.1hz rms ground velocity measured by the ITMY STS in Z (solid blue line) and the seismon predicted ground velocities for 5000 minutes of data from this month. Each dot represents the predicted velocity and arrival time for each earthquake seismon found over this time period (seismon can give up to five active predictions, eq chan 1,2 & 3 are the first 3 predictions, typically the "live" ones if seismon has given us early warning). The numbers by each prediction point are the magnitude and distance in 1000km of the earthquake (so 5.8, 10 is a 5.8 magnitude earthquake 10,000 km away). The earthquake at 4000 minutes actually has a  arrival time prediction , but the predicted velocity is up around 60 micron/s, which made the rest of the plot hard to see, so I cut it off.

I would expect that if seismon was accurately predicting ground velocities, the dots would follow the blue line in some way. If there is a systematic relationship between the dots and the line, I don't see it.

The good new is that for other time periods when there were large earthquakes, seismon usually gave us early warning, which is the primary goal. But it would help deciding what the response to a notification should be if we could get a believable prediction of the velocities.