https://ldas-jobs.ligo-wa.caltech.edu/~lockloss/index.cgi?event=1400438280

We've had some difficulty with turning off the mad hatter boost (DARM1 FM2) in the new DARM state, 77640 and this is probably also the problem Tony was encountering in 77956. 

This is a boost that was turned on in the DARM_OFFSET state and then turned off again in LOWNOISE_ESD_ETMX.  Today I commented out the boost turning on, since it may not be necessary.

We locked in fairly windy conditions like this, with wind speeds up to 25mph.

The first attachment shows how H1's range has degraded over the last week, with the first incident of poor range happening before we started to move PR3.

It seems that there are mulitple issues.  The squeezer seems to be intermittently adding low frequency noise, see 77969 and 77888.  This morning I repeated the squeezer on / off test and see that the low frequency noise is worse than May 8th now but isn't from the squeezer.  The low frequency noise could be explained by the PRCL coherence, which is higher than either SRCL or MICH coherence.   (Similar to what Camilla saw last night 77976). 

Looking at the trend of the range with PR3 alignment, it does seem that the nonstationarity is present when we have PR3 moved, and mostly gone when it is in the original position.  There was one incident of low range right before the move, which seemed related to anthropogenic ground motion.  The range dips at times when PR3 is moved do not seem related to the ground motion. 

This morning I made an attempt to move the squeezer alignment to see if this would help with the low frequency noise.  I put a length excitation on ZM5, and increased the amplitude until I saw fringe wrapping in DARM.  This template is saved in useraps/sqz/h1/Templates/dtt/DARM_scatter_bad.xml  I moved ZM5 - 47urad in yaw, and saw that this reduced the amplitude of the scatter shelf (screenshot).  Once I ran the SCAN_ALIGNMENT script which adjusted ZM4+6 to reoptimize the squeezing, the shelf height was mostly back to it's original.  I've left the squeezer in this new alignment, but I'm not sure it's worth pursuing this until a time when the intermittent squeezer problem is happening.

Wed May 22 10:08:52 2024 INFO: Fill completed in 8min 48secs
Gerardo confirmed a good fill curbside.

TITLE: 05/22 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 21mph Gusts, 17mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.14 μm/s
QUICK SUMMARY:

• 14:20 UTC lockloss, likely from the wind
• The wind is starting to pick up

Bruco ran from May 22, 2024 06:06UTC, where we'd been in observing at 150MPc for ~3 hours.

Can see coherence with PRCL 13-40Hz, CHARDY <25Hz and some MICH 20-30Hz.

TITLE: 05/22 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Two locklosses with currently unknown causes this shift, otherwise relatively quiet. H1 is currently relocking up to START_TR_CARM.

• 23:53 - Reached NLN
• 23:55 - Starting no-SQZ time
• 00:08 - End of no-SQZ time; starting observing
• 01:38 - Lockloss (alog77971)
• 02:57 - Reached NLN
  • Needed to adjust BS and PRM during DRMI, otherwise straightforward acquisition
  • Noticed BNS range was higher this lock by ~5Mpc
• 03:00 - Started observing
• 07:49 - Lockloss (alog77974)
  • 08:02 - Adjusted ISS RefSignal to bring diffracted power to ~2.3%

LOG:

No log for this shift.

Lockloss @ 07:49 UTC - link to online lockloss tool

No obvious cause; much like last time, LSC-DARM saw the first motion.

FAMIS 20029

No major events of note this week; PMC REFL continues to rise as it has been.

I did some additional trending to look a bit closer at what else possibly lines up with the PMC REFL increase, but so far those have proved inconclusive, providing further evidence that there's some on-table alignment shift happening.

Lockloss @ 01:38 UTC - link to online lockloss tool

No obvious cause; LSC-DARM saw the first motion.

[Sheila, Jenne, Betsy, TJ]

Today we had a saga of trying to move even closer to center on PR2, however we were struggling to lock DRMI when relocking, so we've reverted to the alignment situation we were in for our long lock last night.  Since that work took longer than anticipated, we still have not yet remeasured our position on PR2 and PRM, so we plan to do that next time we're commissioning.

• We extrapolated from alog 77870 that we needed to move the PR3 yaw slider to a value of -234 urad, which is a further 159 urad more than we had moved so far.  This comes from our measurement noted in that alog that having moved the PR3 slider by 64 urad moved the spot on PR2 by 2.5 mm, and we wanted to move a total of 15mm from our original position. 
• Since we were unlocked anyway from maintenance day, we got the green arms locked (so that we could see the ALS COMM and DIFF beatnotes), and then manual-ed ISC_LOCK to PR2_spot_move.  
  • Aside: later in the day it was noticed by some GDS folks that using this state with index 900 (which is greater than 409) meant that the range was being calculated, but was returning a nonsensical value, because the IFO wasn't actually locked.  TJ changed the index of this state to be -11 so that the range won't be calculated when we're in that state.
• When almost all the way on the PR3 slider to our goal position, verbal alarms warned us that we were saturating IM4.  This is because the PR2_spot_move state watches how much you move the PR3 slider, and applies a scaled change to PR2, PRM, and IM4 sliders. 
  • My plan for mitigating this was to move IM3 to relieve IM4, but since we had fallen off of ASC_POP_A basically as soon as we started moving PR3, we had to walk all the way back in PR3 slider to where we started, in order to see beam on ASC_POP_A.  However, moving just IM3 gives a pretty significant angle change, so in the end I moved a combination of IMs 1-3 to keep in roughly the same place on IM4_trans and POP_A, while relieving the IM4 yaw slider. 
• Went back to moving PR3
• I think around here is when I realized that we had no light on the AS_AIR camera, and also that we had again fallen off of POP_A. 
• Re-reverted about halfway to last nights alignment situation, to get onto POP_A.
• Went 'forward' with PR3 a little bit, moving IMs 1-3 to keep on POP_A and IM4_trans.  Didn't go very far though, since it was getting late in the day.
• When trying to relock, saw that the ALS COMM beatnote was too low, and could not be improved by either moving PR3 or by pico-ing.
  • Went to ISCT1 and touched up the COMM beatnote alignment, and brought it up from -20dBm to about 0dBm.
• We went through an initial alignment and were trying to relock, but it was very nearly impossible to get DRMI to catch lock.  I could get it to catch and hold for 1-2 seconds or so, but only a very few times. 
• In the end, we went back to green arms locked, and I manual-ed again to the PR2_spot_move state, and I moved the PR3 yaw slider back to about where it had been last night.
  • Re-did the IR parts of initial alignment, and saw that the comm beatnote was still good, so no need to go back to ISCT1. 
  • This time we were able to get locked on basically the first attempt.
• I'm not so sure that the attached screenshot is very helpful, but at least it gives a timescale so we can go back and look at some things in more detail later if need be. Also, the y-cursors, if set, are at the value at the end of the long lock that ended just before maintenance today, so you can see that alignment-wise we're pretty similar to where we were last night.

H1 is now back to observing as of 00:09 UTC following input alignment changes and other maintenance today.

After we reached low noise, I took 10 minutes of no-SQZ time from 23:55 to 00:05 UTC.

MinhyoK, FranciscoL, [Remote: DriptaB]

After one week of moving the inner beam 5 mm to the right of the Rx (see alog 77840), we moved the beam to the center. This will help to evaluate the reproducibility of this procedure and the risks from moving the beam at the ETM.

Attachment 'BothBeamsBefore' shows the beams before making any changes. (image taken before step (1))

The pdf 'EndStationLog.pdf' lists the voltage values after each significant step of procedure T2400163. The steps are represent writing down a voltage value after a particular change of the system:

• 'Pre' - Nothing has changed, reading voltmeter after plugging it to "Rx PD Mon".
• (1) Alignment of the target.
• (2) Only inner beam at Rx detector. (see image 'InnerBeamOffCenter')
• (3) Finalized beam movement. (see image'InnerBeamCentered')
• (4) Both beams at Rx detector, target still on (see image 'BothBeamsAfter')
• (8) Target off.
• 'Final' - Measuring after placing enclosures.

The initial measurement (done on step 'Pre') agree with the last voltage measurement from the previous movement, done on May 14 (see alog 77840), by a factor of 3 HOPs.

The changes we saw from making the movement of last week will be reported as a comment to alog 77840. In summary, our values disagree by a relative difference (measured/expected -1) of 15%.

With the movement made today, we expect that the X/Y comparison will return to a value of 1 in the upcoming week.

TITLE: 05/21 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Maintenance activities were light, but the was some work to try and get the PR2 spot moved closer to the center that had some alignment consequences. We have been trying to recover the IFO since the moves but unable so far. Right now Jenne is working to revert us back to our configuration we were in last night and then we can try with that.
LOG:

We need to reduce the DHARD rms to make our SRCL to darm coupling more stationary, (77729 77666) I ran a noise injection to measure the DHARD P loop this morning.

Elenna measured the hard loops and compared them to a model while we had 430kW in the arms in 69597, today's measurement is with 375kW. I used a template I found in userapps/h1/asc/templates/DHARD/DHARD_P_broadband_excitation.xml, which I think is the one that Elenna tuned in 69597.

Attached is a very simple script that uses dttxml to get the transfer function data from an xml file, getting the IN2/exc/IN1/exc unbiased transfer function.  I also plotted uncertainties based on 10506, calculating an uncertainty for magnitude and phase from in1/exc and in2/exc separately and adding them in quadrature (this is not the correct way to add these uncertainties).

It seems like we have room to add a boost to this loop.