TITLE: 03/24 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY: H1 was locked this morning following the windstorm of last night, but lost lock during commissioning time. Relocking after that was simple, but after again losing lock about an hour later, H1 has not been able to relock since then.

I'll write up a separate and more detailed entry later, but most of the struggle with relocking stemmed from an issue I started noticing with ALS-Y that would cause spontaneous locklosses at states after LOCKING_ARMS_GREEN. At seemingly random intervals, the ALS-Y PLL would jump from its Locked state into Ramp Gain, which flags the PLL as "not okay," causing Guardian to assume a lockloss. Since I don't know what causes this state transition, I'm not sure what the underlying issue might be, but so far when this happens the first thing I can see changing is this FIBR_LOCK_STATE. Eventually, these glitches stopped late in the afternoon. An example of one of these instances (in this case during FIND_IR) is shown in the ndscope screenshot attached.

• 15:30 - Dropped observing for commissioning
• 17:09 - Lockloss from commissioning activities
• 18:44 - Observing; straightforward relock without an alignment
• 19:54 - Lockloss - alog83533
  • ALS-Y issues begin, locking proves impossible
• 20:57 - Jim power cycling HAM3 CPS rack to address noise - alog83528
• 22:52 - ALS-Y issues seem to have stopped, but can't lock DRMI, so starting initial alignment
• 23:13 - IA finished

LOG:

TITLE: 03/24 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 18mph Gusts, 11mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.27 μm/s
QUICK SUMMARY:

H1's been down and Ryan S shared issues he was observing (see what he says about ALSy  in an upcoming alog).  He was running an Initial Alignment during our shift handoff.  Arm locking was fine, but DRMI looked pretty bad.  Went through PRMI a couple times (was successfully completed) as well as a round of CHECK MICH FRINGES---DRMI still looked bad.  Now running through a 2nd consecutive alilgnment.

Winds are much calmer (under 20mph) than last night and microseism.

I'm starting to look at the nice data set Camilla took with different non linear gains in the interferometer,  83370.  A few weeks ago we took a similar dataset on the homodyne, see 83040.

OPO threshold and NLG measurements by both methods now make sense:

Based on the important realization in 83032 that we previously had pump depletion while we were measuring NLG by injecting a seed beam, we reduced the seed power for these two more recent datasets.  This means that we can rely on the NLG measurements to fit the OPO threshold, and not have the OPO threshold as a free parameter in this dataset.  (In the homodyne dataset, I had the OPO threshold as a free parameter, and it fit the NLG data well.  With the IFO data, we want to fit more parameters so it's nice to be able to fit the threshold independently.). The first attachment shows a plot of nonlinear gain measured two ways, from Camilla's table in 83370.  The first method of NLG calculation is the one we normally use at LHO, where we measure the amplified seed while scanning the seed PZT, and then block the green and scan the OPO to measure the unamplified seed level (blue dots in 1st attachment).  The second method is to measure the amplified and deamplified seed while the seed PZT is scanning, (max and min), and nlg = {[1+sqrt(amplified./deamplified)]/2}^2 (orange pluses in attached plot).  The fit amplified/ unamplified method gives a threshold of 158.1uW OPO transmitted power in this case, while the amplified/ deamplified method gives 157/5uW. 

Mean squeezing lump and estimate of eta:

The second attachment here shows all the spectra that Camilla saved in 83370.  As she mentioned there, there is something strange happening in the mean squeezing spectra from 300-400 Hz, which is probably due to the ADF at 322Hz was on while the LO loop was unlocked.  In the future it would be nice to turn off the ADF when we do mean squeezing so that we don't see this. This could also be adding noise at low frequencies, making the mean squeezing measurement confusing.

Mean squeezing is injecting squeezing with the LO loop unlocked, which means that it averages over the squeezing angles, and if we know the nonlinear gain (the generated squeezing) the mean squeezing level is determined only by the total efficiency.  With x = sqrt(P/P_thresh)

Lockloss @ 19:54 UTC - link to lockloss tool

Possibly due to wind; lockloss tool has 'WINDY' tag and gusts have reached almost up to 30mph in the past hour.

I've added some code to the OPLEV charge measurement scripts to export the plotted data (weighted and unweighted mean charge with their associated STD and VAR), it ended up being ~10 years of measurements for each ETM. The analysis scripts both live at /ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/Scripts. The saved mat files will be in the same directory as the scripts, named 'ETMX_OPLEV_CHRG.mat' & 'ETMY_OPLEV_CHRG.mat'. The data is also attached to this alog.

The data is formatted as a matlab table with each variable labeled, **it's important to note that each column (4 per variable for ETMX, 3 for ETMY) of each variable coresponds to a quadrant in the following order UL LL UR LR. Also ETMY does not have LR**

For ETMX the data range is 11/04/14 to present. The analysis script for this quad is "Long_Trend.mat"

For ETMY the data range is 01/06/15 to present. The analysis script for this quad is "Long_Trend_ETMY_LHO.mat"

If someone wants to rerun this at a later time with new measurements, you'd just have to adjust the time range at the top of the script to what you want, then go to the end of the script and change the "export_data" variable from 0 to 1.

We started to see noise peaking up again at EX so we swapped Fans to see if this is the coupling mechanism.

H1 back to observing at 18:44 UTC after a commissioning-induced lockloss and a straightforward relock.

Before observing, I accepted a few SQZ ADF servo-related SDF diffs (the servo remains off); see attached.

Noted that there was a out of nominal rise on the Y-Arm pressure plot (see first attachment), handy tool, so I started looking into it.  Noted that the temperature in the VEA for the Y mid station has gone up from an nice oscillation of 63~65 °F up to a rising temperature, currently at 68 °F, maybe we are adding heat to the Y-Mid??, all pressure gauges, including the annuli ones noted the pressure rise.  No attention required, but it would be nice if the temperature stopped at a nominal value.

RyanS reported getting HAM3 CPS noise notifications on DIAG_MAIN. Looking at the log, there have been several periods where the blrms noise monitors have been going over threshold. Digging in to HAM3's performance this morning, CPS noise seems to be affection mostly RZ, but the other horizontal dofs are affected. as well. First attached image, is comparision with HAM2. Top asds are the rotational dofs, bottom are the X/Y/Z dofs. HAM3 RX/RY/Z vertical dofs are all mostly similar to HAM2, but the cyan trace vs the pink trace on the top plot shows HAM3 RZ is moving much more that HAM2 RZ.

Second image shows asds of the individual sensors, the blue trace on the top plot is H2 CPS, which has a higher noise floor than the other sensors, so I suspect this sensor is the root cause of the HAM3s problems. All of the other senors seem more or less healthy. If I get a chance or the ISI becomes unstable, I would like to go to the floor or CER to power cycle some stuff. Otherwise, I can wait till tomorrow.

Jennie W, Camilla

Today during commissioning at 16:29:41 UTC I ran the SCAN_SQZANG_FDS guardian state and it changed the squeeze angle from 170.94 degrees to 163.08 degrees.

Then Camilla and I changed the filter cavity detuning from the nominal value of -32 Hz, measured DARM between 20 to 30 Hz atr each step. This was following this entry by Vicky and Camilla. The lowest value we tried was -44 Hz and the highest was -26 Hz. The optimal seemed to be between -38 Hz and -32 Hz, eventually we chose -36 Hz as it was better 30 and 46 Hz, and among the best between 60 and 70 Hz. Above 70 Hz it is hard to see the difference between traces.

We accepted the new value for H1:IOP-LSC0_RLF_FREQ_OFS in the OBSERVE.snap file in sdf.

Mon Mar 24 10:10:42 2025 INFO: Fill completed in 10min 38secs

Gerardo confirmed a good fill curbside, audio only, no line to sight due to tumbleweed.

J. Kissel

One step closer to driving an analog signal into the OMC DCPD test chain at ~10 kHz (see other prep aLOG discussion in LHO:83466 and LHO:83468), I set up the SR785, SR785 accessory box, and at the necessary cabling by ISC-R5 rack on the -Y side of the -Y side of HAM6, tucked up against the mini clean room that's there. Other commissioning activities broke the lock just as I was about to plug the setup into the wall and power on. So -- we'll try again Thursday 03/27.
All in-rack cabling is the same as is typically is for all of O4, I hadn't gotten to disconnecting the ISC_444 injection port cable yet.

Was in the LVEA for a mere 6 minutes from 2025-03-24 17:07 UTC to 17:13 UTC.

Attached is a picture of the unplugged and powered off equipment as I left it.

This morning at 09:04:42 Mon 24mar2025 we had a BSC3 sensor gitch, which VACSTAT normally logs as a single gauge event and does not send alarms. Today however many LVEA gauges also tripped and alarms were sent to the Vacuum Team.

The reason is that on 13mar2025 we had a lock-loss due to an LVEA vacuum event which was below VACSTAT's nominal trip level. To counter this some LVEA slope trip levels were reduced from 1.0e-10 to 3.0e-12 (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=83366)

Fast forward to today and the sequence was:

09:04:42 standard BSC3 sensor glitch, num_glitched = 1, all other gauges set to sensitive mode, meaning 3.0e-13 for most LVEA gauges

09:05:03 2nd LVEA sensor glitched on noise while in sensitive mode, num_glitched = 2, Alarms sent to Vacuum Team

09:11:07 3rd LVEA sensor glitched on noise while in sensitive mode

09:12:37 4th LVEA sensor glitched on noise while in sensitive mode

09:18:35 5th LVEA sensor glitched on noise while in sensitive mode

J. Kissel

Oli and I are beginning the process for designing damping loops for the A+ O5 BBSS. We're running through the same process that I've been running through for over a decade designing suspension damping loops, in which I build up a noise budget for the optic displacement in all DOFs using input noises for seismic noise, DAC noise, and OSEM sensor noise filtered through said damping loops, all propagated thru the matlab dynamical model of the suspension.
 
The first step along that journey is revisiting all the input noise sources, and making sure we have good model for those. 
OSEM noise and DAC noise models have recently been validated and updated when I revisited the HLTS damping loop design (see LHO:65687).
However, I haven't worked on damping loops for suspensions suspended from a BSC-ISI since 2013, see G1300537 for the QUAD, G1300561 for the BSFM, and G1300621 for the TMTS.
In those, I used the 2015 update to the 2005 requirement curve from T1500122 as the input motion.
Now, after a decade worth of commissioning and improvements, I figure it's time to show that work here and use it in modeling future SUS damping loops where the SUS is mounted from a BSC-ISI.

One of the biggest things we've learned over the decades is that the seismic noise input to the suspension at its "Suspension Point" motion for a given suspension can be the (quadrature) sum of many of the ISI's cartesian degrees of freedom, and depends on where and in what orientation it is on the optical table (see T1100617). As such, we installed front-end infrastructure to calculate the calibrate the lowest stage sensors -- the GS13 inertial sensors -- into both the Cartesian and Euler basis (see E1600028). In this aLOG, I do as I did for the HAM-ISI LHO:65639, I show the Cartesian contributions to each of the Beam Splitter's SUS point motion, by multiplying the Cartesian channels by the coefficients in the CART2EUL matrix for the beam splitter.

The time I used for this performance of the H1 ISI BS was 0.01 Hz binwidth (128 sec FFT), 10 average, 50% overlap data set starting at 2025-03-19 14:00 UTC.
    - This was a late night local set, with no wind and 0.1 [um_BLRMS] level microseism (between 0.1-0.3 Hz)
    - GND to ST1 Sensor correction is ON, including the DIFF and COMM inputs.
        - Here at H1, the corner station does NOT have beam rotation sensors to improve the GND T240 sensor correction signal. But, both end stations have a BRS.
        - The wind was low at this measurement time, but it's worth saying that each end-stations wind fences are in dis-repair at the moment, too be fixed soon.
    - ST1 Z drive to ST1 RZ T240 decoupling is ON with a "pele_rz" filter
    - Off diagonal ST1 dispalign matrices are in play, 
         X to RX & RY = -1e-4 & 1e-4, 
         Y to RX = -7e-4, 
         Z to RX & RY = 3.5e-3 & 2.5e-3 
    - ST1 Blend Filters:
        - X & Y = nol4cQuite_250
        - Z = 45mHz_cps
        - RX & RY = Quite_250_cps
        - RZ = nol4cQuite_250.
    - As far as I can tell, there's NO ST1 to ST2 sensor correction on the ST2 CPS, nor is there and ST1 to ST2 FF to the ST2 actuators.
    - ST2 Blend Filters:
        - X & Y = 250mhz
        - Z = 250mhz
        - RX & RY = tilt_800b
        - RZ = 250mhz

These will be used to make updates to 
    /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/
        seisBSC.m or 
        seisBSC2.m
which are toy models of the BSC-ISI performance, used so you don't have to carry around some giant .mat file of performance and you can per-interpolate on to an arbitrary frequency vector, much like I did for seisHAM.m in CSWG:11236.

I've committed the .xmls and .pngs in the following SeiSVN directory:
/ligo/svncommon/SeiSVN/seismic/BSC-ISI/H1/BS/Data/Spectra/Isolated/ASD_20250319/

I'm looking again at the OSEM estimator we want to try on PR3 - see https://dcc.ligo.org/LIGO-G2402303 for description of that idea.

We want to make a yaw estimator, because that should be the easiest one for which we have a hope of seeing some difference (vertical is probably easier, but you can't measure it). One thing which makes this hard is that the cross coupling from L drive to Y readout is large.

But - a quick comparison (first figure) shows that the L to Y coupling (yellow) does not match the Y to L coupling (purple). If this were a drive from the OSEMs, then this should match. This is actuatually a drive from the ISI, so it is not actually reciprocal - but the ideas are still relevant. For an OSEM drive - we know that mechanical systems are reciprocal, so, to the extent that yellow doesn't match purple, this coupling can not be in the mechanics.

Never-the-less, the similarity of the Length to Length and the Length to Yaw indicates that there is likely a great deal of cross-coupling in the OSEM sensors. We see that the Y response shows a bunch of the L resonances (L to L is the red TF); you drive L, and you see L in the Y signal. This smells of a coupling where the Y sensors see L motion. This is quite plausible if the two L OSEMs on the top mass are not calibrated correctly - because they are very close together, even a small scale-factor error will result in pretty big Y response to L motion.

Next - I did a quick fit (figure 2). I took the Y<-L TF (yellow, measured back in LHO alog 80863) and fit the L<-L TF to it (red), and then subtracted the L<-L component. The fit coefficient which gives the smallest response at the 1.59 Hz peak is about -0.85 rad/meter. 

In figure 3, you can see the result in green, which is generally much better. The big peak at 1.59 Hz is much smaller, and the peak at 0.64 is reduced. There is more from the peak at 0.75 (this is related to pitch. Why should the Yaw osems see Pitch motion? maybe transverse motion of the little flags? I don't know, and it's going to be a headache).

The improved Y<-L (green) and the original L<-Y (purple) still don't match, even though they are much closer than the original yellow/purple pair. Hence there is more which could be gained by someone with more cleverness and time than I have right now.

figure 4 - I've plotted just the Y<-Y and Y<-L improved.

Note - The units are wrong - the drive units are all meters or radians not forces and torques, and we know, because of the d-offset in the mounting of the top wires from the suspoint to the top mass, that a L drive of the ISI has first order L and P forces and torques on the top mass. I still need to calculate how much pitch motion we expect to see in the yaw reponse for the mode at 0.75 Hz.

In the meantime - this argues that the yaw motion of PR3 could be reduced quite a bit with a simple update to the SUS large triple model, I suggest a matrix similar to the CPS align in the ISI. I happen to have the PR3 model open right now because I'm trying to add the OSEM estimator parts to it. Look for an ECR in a day or two...

This is run from the code {SUS_SVN}/HLTS/Common/MatlabTools/plotHLTS_ISI_dtttfs_M1_remove_xcouple'

-Brian