FranciscoL, TonyS, MattT, RickS

On Tuesday, March 25, we reverted the PCALX lower beam to its nominal center. We expect to see a change of 4 HOPs in \chi_XY -- returning to the value it was two week ago.

Target was placed with a 33 degree offset as seen on the first attachment (TARGET_ON -- featuring a responsible scientist, wearing laser goggles). Each individual beam voltage values, as found, were very similar to the values recorded at the end of the move done last week.

The following table shows the voltage values as read by the Keithley voltmeter we use during the procedure

The IFO has not regain lock at the time of writing this alog which limits further observations from this move.

WP 12393

The FE and IO chassis for h1seih16 were powered down for in-rack cabling of the ISI electronics. All cables are now routed and dressed. The long field cables were left disconnected, will wait until they are in connected at the flange.
The AI chassis on U38 was removed. AA chassis from U39 was moved down. This matches LLO's rack configuration, alog 75328.

CDS Team

RyanC, TJ

I wrote a new decorator in ISC_library (@ISC_library.bring_unlocked_imc_2w_decorator(nodes)) for the specific scenario of the IMC losing lock while we're at 10Ws which would give it trouble relocking - alog82436. The decorator looks for the IMC being unlocked with a power above 2Ws and if the rotation stage is stationary it requests the LASER_PWR GRD to 2Ws.

We sprinkled the decorator into ALIGN_IFO,  INIT_ALIGN, into the MICH, SRC and AS_CENTERING states, I also added it to CHECK_MICH_FRINGES and MICH_OFFLOADED in ISC_LOCK.  We successfully tested it today during an initial alignment by breaking the IMC lock during these states.

Tue Mar 25 10:12:47 2025 INFO: Fill completed in 12min 43secs

TITLE: 03/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 3mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.25 μm/s
QUICK SUMMARY: H1 is currently relocking up to MOVE_SPOTS. Looks like H1 was able to lock twice last night and most recently lost lock about an hour ago. Maintenance day today, but I'll let H1 continue until those activities begin.

• Diode room dust monitor reports dust counts have not changed
• Wind low, microseism steady around 75th percentile

Workstations were updated and rebooted.  Os packages were updated, and conda packages were also updated.

In the CDS conda environment, gwpy was upgraded to version 3.0.12.  Among other improvements, this version fixes an issue that could cause matplotlib to lock up while creating pltos after importing gwpy.

IFO is in LOCKING at FIND_IR

I got called at 03:11 AM because ALSY Guardian went into fault during initial alignment and stayed there for an hour at which point IFO Notify was triggered to call the OWL Ops. I couldn't see anything immediately wrong with Y-ARM other than it got itself into a weird state. Long story short, the ALSY IR DC Power is low, and around the threshold for ALSY guardian faulting.

I went into init to try another initial alignment but ALSY got into the same state. Upon further investigaiton, this was due to the ALS Guardian detecting an error in the locking relating to the ALS_Y_LASER_IR_DC. I noticed that ALSY would only fault if the power went below 4.5 mW, which I later realized to be on the boarder, fluctuating between "too low" and over 4.5. I set the threshold on the same page (attached pic) to 4.48 (lower by 0.02mW), which seems to have fixed the issue. I waited until ALS Locked in both INITIAL_ALIGNMENT and LOCKING_ARMS_GREEN to ensure that the fix worked. I waited a bit more and can confirm we can lock DRMI (we lost lock a few minutes thereafter though).

I have accepted and screenshoted the SDF corresponding to the power change in SAFE.SNAP just in case we lose lock on the way to NLN (since this gets reset with each LL). I will likely get called again and need to accept the SDF in OBSERVE later, though that may be during DAY OPS time. Other screenshots have been attached, including the screen where I made the power threshold change. I've re-set my OWL and will stay logged in to expect a call for potential SDF confirmation.

TITLE: 03/24 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:

Rough shift with DRMI locking all of a sudden being VERY finicky.  Hoping POPAIR gain change helps with locking (after the end-of-shift-alignment).
LOG:

• ISS Array work (myank, jennie)
  • 2323 ISS Array Jennie out
  • 0056 ISS Array work is done for the day as Myank leaves optics lab
• 2252-2313 Initial Alignment during ops handoff
  • ALS locking was fine, but DRMI did not look good (even with PRMI & CHECK MICH FRINGES)
• 2323-2351 sorting parts (matt, camilla)
• 2358-0004 pcal measurement checks (tony)
• 2351-0007 Initial Alignment Round2
  • Summary of locking notes below was in alog earlier, but here was the running log of locking notes:
  • ALS locking was fine, but DRMI did not look good (even with PRMI & CHECK MICH FRINGES)
  • Once again, ALS locking was fine, but DRMI did not look good (even with PRMI & CHECK MICH FRINGES)
  • Called Sheila (next on Call List) to let her know of the status.  She suggested, instead of running a 3rd Initial Alignment, run PRMI again and then do a MANUAL Initial Alignment for SRC OFFLOADED.
    • I should say, I let PRMI complete, then took ISC LOCK to DOWN; selected MANUAL INITIAL ALIGNMENT; then for ALIGN IFO, selected SRC ALIGN OFFLOADED.
      • This actually took (2) attempts, the first one went to DOWN (not sure why).
      • After the 2nd attempt was successful, started over with locking!
  • DRMi locking once again looked the same.  Symptoms:  hard to see misalignment in flashes, POP90+18 look ok (NOT seeing anything for SRCL (or MICH) TRIG MON FAST---it is zero).  POP90+18 do start with what looks like a lock, but then they slowly drift back down to 0 within 1-second.
  • Going to try another MANUAL INITIAL ALIGNMENT, but this time doing trying:  (1) AS CENTERING OFFLOADED, then (2) SRC ALIGN OFFLOADED.
    • Once again see that for OFFLOAD SRC, ASC signals were not very far off at all
    • 2nd time in a row 1st attempt at SRC ALIGN OFFLOADED went down due to AS_A_DC slowly drifting down.
  • Although SRC looks like it's decently aligned, I can assume it's bad and misalign SRM, and then do tweaks of SR2 to center on the PD AS_AS_C.  then realigned SRM and tweaked it to make highs higher/lows lower for ASC-AS_C_NSUM_OUT16.
    • Then ran through an AS_CENTERING_OFFLOADED + SRC ALIGN_OFFLOADED
    • for a 3rd time in a row, the first attempt of SRC ALIGN OFFLOADED might have 
  • Since the above did not improve DRMI locking, Sheila then suggested a change from 3weeks ago (alog 83182)
• Change was made per alog 83540
• ~0200utc M6.7 earthquake off New Zealand would cause increase ground motion for next 2hrs.
• 0325 Return to locking, but DRMI & PRMI would not lock.  DRMI did atleast show some triggers, but the flashes were low.
• 0431 Initial Alignment & notified Owl shift operator (Ibrahim) of H1 status.  Hoping H1 is better than last night!
  • 0458---DRMI is flashing and the camera does look better as well, and we finally have triggers...hoping for a DRMI lock!   .....just had a lockloss, but it does look better than earlier in the shift.  

The shift started with Ryan looking into why ALSy was causing grief in the afternoon (it would later clear up on its own), but since the beginning of the EVE shift, DRMI locking has been the issue.

Have went through 2-Initial Alignments, as well as several successful PRMIs and CHECK MICH FRINGES.

DRMI Symptoms:

DRMI would start out the first few seconds with strong flashes seen on the camera and decent flashes on ndscopes, but

Then the behavior would switch to an ugly camera image which would be seen as DRMI looking like it's going to catch, but within 1-sec POP18+90 (and also the camera) would "wobble" back down to zero in a "slow flash". 

(It feels like DRMI has been like this over the weekend as well, but after some of these wobbles to zero after these "slow flashes,"  DRMI would lock.  Not the case tonight---have had zero DRMI locks going on 6+hrs.)

It feels like the alignment is decent, and no environmental issues, but it doesn't seem to trigger or start LSC control when these flashes start (hence their "slow" drop of POP18+90.). 

What's Been Tried:

• Initial Alignments (have gone through 2).
• Manual Alignment:  This was the first suggestion Sheila gave me.  After PRMI completed, took ISC LOCK to DOWN, went to MANUAL Alignment, and then on ALIGN IFO, selected SRC ALIGN OFFLOADED.  Tried this a few times.  Also tried AS CENTERING OFFLOADED followed by SRC ALIGN OFFLOADED.  For all of these ASC was not far off---leading one to think alignment was fine.
• Checked pointing on AS_C photodetector with SR2 (no real change made here) & also used SRM to make highs higher/lows lower (no change here either).
• NEXT Try Improving DRMI triggering:  Increasing gain of H1:LSC-POPAIR_B_RF18_I (&Q) _GAIN from 2 to 4  (see attached screenshot with appropriate screens)
  • Sheila mentioned this helped with a similar issue 3 weeks ago (see alog83182)
  • I went to the POPAIR RF 18 medm and changed the gains for both I & Q gains from 2 to 4 while ISC_LOCK was trying to lock Green Arms.
  • Then opened up the LSC SDF, which had the safe.snap file up (and then did a sort for this substring: H1:LSC-POPAIR_B_RF18_) and then I ACCEPTED this safe.snap with the new gains of 4 for both of these channels.

Now:  We Wait

Just before Sheila and I were going to go with this new gain, a M6.7 EQ rolled through (of course).  Probably have another 30-90 min before the ground calms down, but the hope is we'll have the same luck Elenna, Ibrahim, and Sheila had on March 4th with DRMI locking right up!

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)

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.

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

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

The new clean air supply (compressor, tank, dryer and a series of extra filters), which was received in the end of 2024, was installed in the EX mechanical room as a replacement for the old system. The installation work was carried out in the last few weeks, the last step - the startup by Rogers Machinery - happened today.
This new system has a 69 cfm air delivery operating with 3 pcs. of 7.5 HP motors (in sum 22.5 HP). In comparison, the old system had a 50 cfm air delivery, operating with 5 pcs. of 5 HP motors (in sum 25 HP). Moreover, the new system (unlike the old one) has an automatic dew point monitor, and a complete pair of redundant dryer towers.
So, this new system is a major improvement. The reason for this 69 cfm limit (and not more) is that the cooling of the compressor units in the MER is still feasible, moreover, the filters and the airline do not need any upgrades, they can still accommodate the airflow.
Both the new and old systems are able to produce at least -40 deg F dew point air on paper. During the startup, the new system was however able to produce much better than this - it was ~-70 deg F (and dropping) - as you can see in the attached photo.

Last but not least, a huge congratulations to the Vacuum team for the installation, as this was the first instance, when the installation of a clean air system was carried out by LIGO staff, so this is indeed a huge achievement. Also, big thanks to Chris, who cleaned some parts for the compressor, to Tyler, who helped a lot in the heavy lifting, and to Richard & Ken, who did the electrical wiring.

From next week on, we repeat this same installation at the EY station.