TITLE: 06/05 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: It's been a busy shift of troubleshooting. See alogs 78251, 78258, and 78259 for summaries of the first half of the day's events. Since then, we had trouble locking DRMI where buildups looked very unstable and there were several locklosses at different places in the DRMI acquisition steps. Eventually DRMI was able to lock (Jim reverted some sensor correction-like changes he put in Monday, but unsure if this had any effect) and we made it up to engaging ASC. Sheila had moved the DARM_OFFSET state to between the ENGAGE_ASC and SOFT_LOOPS states, but we found that increasing the DARM offset again caused the PRG to drop as we had been seeing in the morning. I wasn't fast enough to lower the DARM offset, so we lost lock. On the next attempt, we ran through both ENGAGE_ASC and SOFT_LOOPS before running DARM_OFFSET, but we still saw the drop in PRG as before. I was able to turn off the DARM offset in time, then Jenne started to step it up slowly to see where things became unstable. When she reaced the nominal value of 9e-5, things still looked okay and the OMC was able to lock, so we proceeded to DC readout and powered up to 25W. At this point, Robert went into the LVEA to take pictures through a HAM2 viewport, and sometime around then, we lost lock (unsure exactly if he was the cause). We've since relocked and continue to troubleshoot why we canot turn on the DARM offset reliably.

Handing off to Ibrahim as troubleshooting is ongoing.

LOG:

Andrei, Sheila, Naoki

We've observed that the reduction of the observable range is accompanied by the presence of "whistles", high-magnitude frequency-modulated signals in the spectrum in SQZ FC WFC.

Sheila created several plot overlays to demonstrate this dependence. Specifically, we selected the Lock : Range : DMT-SNSL_EFFECTIVE_RANGE_MPC and SQZ : Subsystems : SQZ FC WFC plots and overlaid them to highlight the relation between them.

• overlayjune2.png shows no “whistles,” and the range does not undergo any significant decreases.
• overlayMay18.png, overlayMay21.png and overlaymay30.png datasets exhibit the presence if "whistles" and a corresponding range decrease.
• overlayMay22.png, overlayMay23.png datasets dont have the visible "whistles", but the 10-20 Hz low-frequency noise band increases during the range decrease.

DARM_comparison.png plot contains the 18th of May 2024 DARM during the “whistle” and during its absence. ≈0.5 dB difference is observed.

TITLE: 06/05 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 11mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.38 μm/s
QUICK SUMMARY:

IFO is LOCKING at DARM_OFFSET

We're experiencing issues with the Power Recycling Gain. Jenne, Sheila and Ryan S are troubleshooting it currently. This is preventing us from locking.

Naoki, Sheila

To estimate the FC backscatter noise, we excited the FC IR error signal. The attached figure shows the FC IR error signal and DARM with (red)/without (blue) exciation. Although the FC IR error signal is excited by a factor of more than 30 between 10-100 Hz, the excess noise in DARM is small so the FC backscatter noise should be much smaller than DARM.

Jennie W, Jenne D, Sheila

The other day I designed a new notch to get rid of a bump we had been seeing at 17.75Hz. We think this is the bounce mode of the BS coupling into the MICH loop. The notch for this in LSC-MICH has not been updated since the BRDs were installed I think, and there is no notch for this mode in the ASC-MICH_P and ASC_MICH_Y loops.

Changes made to ISC_DRMI.py

Added Bounce-roll notch (FM8) to MICH2 (line 457) in DRMI_LOCKED state and took out line turning on notch at 15Hz (line 456).

#ezca.get_LIGOFilter('LSC-MICH2').switch_on('FM10') # Turn on the BounceRoll FM10 in LSC FM

ezca.get_LIGOFilter('LSC-MICH2').switch_on('FM8') # Turn on the BounceRoll FM8 in LSC FM 05/06/2024 J Wright

Added bounce-roll notch to PREP_PRMI_ASC in FM MICH_P and MICH_Y in FM9. These were added to lines 690 and 692.

Added these same filters in PREP_DRMI_ASC state in FM MICH_P and MICH_Y in FM9 in lines 920 and 922.

After much time diagnosing locking issues this morning (see alogs 78251 and 78258 for the main events), we eventually reached NLN after damping violin modes in OMC_WHITENING for 40 minutes. Almost two minutes after reaching NLN, Robert attempted to ramp the bias on ITMY, but accidentally changed it immediately, which unlocked the IFO at 19:38 UTC.

H1 is currently relocking. We're scheduled for commissioning time until 22:00 UTC, so if we can get back to low noise, we'll spend time commissioning until then.

Jenne Driggers, Ryan Short, Sheila Dwyer, Jim Warner

In several of the locklosses that TJ and Ryan had early this morning, the PRG would drop before we started to engage ASC, and we would loose lock while the ASC loops came on.  By pausing and going line by line through the guardian we identified that turning on the DARM offset was causing the drop in PRG.  We were able to engage the ASC without issue when the DARM offset was off.  At this point we did a series of OMC scans, attached screenshot, but everything seems normal here.

Our hypothesis is that the DARM offset was too large when the alignment was off (and perhaps some microseism makes things a little less stable), but that things are fine once the ASC is on. 

For this locking attempt I've moved the DARM offset state to after ENGAGE_ASC.  We had initially moved it to before ASC a long time ago to save time by locking the OMC while the ASC was being engaged.  But, if this causes locklosses while we are engaging the ASC this isn't worthwhile, and we can let the OMC lock while we are waiting for the soft loops.  I had a look at the lockloss tool to see how often we've been loosing lock from this state, it say we lost lock from ENGAGE_ASC (429) 8 times since March, but this only includes one lockloss from last night.

I'll leave this guardian change in for now.

While we were looking into this, Jim made changes to sensor correction and CPS DIFF.  This might have been helpful, based on the locking progress it's hard to say because his changes happened as we were understanding that the DARM offset was the issue.

Sheila, Jennie W, Jenne D

Peter F suggested we dither the alignment into the OFI and look at the power fluctuation on our QPDs and diodes in HAM6.

If we are right on top of some trough in OFI throughput thewn we should see a 2*f_dither line in our QPDs and PDs.

If we are on the side we should see f_dither frequency lines, and away from the bad spot on the OFI we should see no modulation at either of these frequencies.

We had trouble finding the centre of the bad spot with this measurement although it did tell us some more information about how steep it edges are.

See the below image for the channels we were monitoring.

We set the sliders to the 'bad spot' ie. our alignment into the OFI that was nominal before April 24th this year shown in the first table column here.

The values we used were:

We turned the dither lines on the third stage down on SR2 (11 Hz for pitch degree of freedom and 13 for yaw).

The channels used were H1:SUS-SR2_M3_TEST_P_EXC and H1:SUS-SR2_M3_TEST_Y_EXC with a sine wave injection of 1000 counts amplitude.

We set the IFO_ALIGN guardian to SR2_ALIGN which feeds back to SR2 on its own to keep the beam centred on AS_C QPD, this means we only had to change the position of DSR3 and SR2 would be stepped by this loop (SRC2).

We also turned on the centering loops, then the OMC ASC, but had to turn the OMC ASC off for some of the measurement period as OMC suspension kept saturating.

17:16:48 UTC went to bad spot mentioned in table and tried dither - did not see 2F modulation in power on all five HAM 6 QPDs or the OMC REFL PD (shown here as dark blue reference).

This time is shown by the position (roughly) of the first cursor in this image.

We eventually saturated the SR2 suspension when driving it in pitch and still don't see 2*f_dither peaks.

Now walking the beam from this position at around 17:34 UTC.

The magenta curve was taken after we had moved in the positive yaw direction to have the SR3 yaw slider at -116 uradians and the SR2 yaw osem to be at155 uradians. It can be seen that the pitch line gets higher and the yaw line lower so this means we are moving away from the centre of the bad spot in yaw and towards it in pitch as we moved the beam in this direction on the OFI.

We ran OMC ASC again to centre on OMC REFL as this dropped but then fully saturated OMC ASC so turned off OMC ASC.

OMC model restarted at 17:52:45 UTC and so the OMC ASC restarted with 0 offsets, since we hadn't cleared history this caused oscillation on QPDs for OMC.

We increased the gain in the SRC2 centering loop by increasing the input matrix sleement in SRC2 loop.

18:45:52 UTC Trying to move to better OFI spot suggested by Alena's calculations but this moves us off AS_C and saturates DC centering so will move us off AS_A and B (if we do this we will need to pico back onto these QPDs).

The light blue curve was taken at our current alignment through the OFI, marked with the second cursor in this image.

The xml file Sheila used for measuring the dither on SR2 is also attached.

Wed Jun 05 10:10:06 2024 INFO: Fill completed in 10min 2secs

Gerardo confirmed a good fill curbside.

I ran a BRUCO (brunt force coherence) from a time segment (400s) starting at GPS 1399898087 when we had high noise in the range BLRMS and this was correlated with high noise on the CO2_ISS_CRTL2 signal, as discussed in this comment by Sheila.

We know our instances of abrupt drops are correlated with the CO2 ISS array and possibly the squeezer and the purpose of this is to check for any other correlations whoch provide an explanation for our range drops.

The BRUCO was run on GDS-CALIB_STRAIN_NOLINES to avoid finding coherences between the calibration lines and various channels.

The BRUCO can be ran following these instructions from Elenna.

TITLE: 06/05 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 14mph Gusts, 10mph 5min avg
    Primary useism: 0.06 μm/s
    Secondary useism: 0.51 μm/s
QUICK SUMMARY: TJ has been working on locking troubles this morning; sounds like locklosses mostly happening around ENGAGE_ASC and the OMC is consistently locking on the wrong mode. Will start by stepping through ENGAGE_ASC slowly.

• Wind is finally low
• Microsiesm has been on the rise

H1 lost lock at 0807UTC (0107PT) for a reason I can't figure out. Since then there have been numerous lock losses from various states in the locking process. It has made it past full power, but other times it won't make it to DC readout. I've ran another initial alignment just to try something, but I'm having the same results. There was also a small earthquake from mexico to slow this all down.

The useism is getting higher, though not terrible, but I'm beginning to wonder if maybe some of the sensor correction changes that have happened (alog78226) aren't playing well with this ground motion. I've changed the SEI configuration to USEISM since the wind is still low and well see how this goes.

TITLE: 06/05 Eve Shift: 2300-0800 UTC (1600-0100 PST), all times posted in UTC
STATE of H1: Observing at 132Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 06:09 UTC

IFO was in DOWN for the majority of the shift due to 40mph wind gusts that were preventing locking (primarily ALS). At 04:00 UTC, the wind finally dropped below 30mph. This was the locking process:

04:05 UTC - INITIAL ALIGNMENT - I had to get involved to alter the states for ALSY since it was having issues with the WFs (wind was still around 30mph here. This was the bulk of time spent in initial alignment.

04:47 UTC - SRM WD tripped during SRC Align (during the usual many saturations - have never seen a WD trip before during though), prompting untripping intervention

04:55 UTC - Initial alignment complete, moved into full IFO locking

05:42 UTC - NLN Acquired fully automatically and without going into PRMI (Dying wind helped with this I presume). There was some extra time spent in ENGAGE_ASC_FOR_FULL_IFO due to non-converging signals

06:09 UTC - OBSERVING - it took 30 minutes because I accepted SQZ diffs that I thought were preventing us from going into OBSERVING only to realized that we weren't squeezing for whatever reason (and thus not in truly complete NLN). I went into the SQZ screen and requested Freq. Dep. SQZ and a few minutes later, we were in full NLN. I then went back and re-accepted those diffs that I erroneously accepted. For the sake of book-keeping, I've attached both versions of each. I was briefly thrown off by an ISS Pump message telling me to troubleshoot via an alog but this was just a symptom of there not being any squeezing at all. I do not know why IFO didn't automatically go into squeezing as it usually does. This was my only intervension during locking.

Other:

• Wind gusts have drastically reduced over the last 3 hours (starting 4:50 UTC), hovering at around 15 max
• Secondary microseism has steadily increased, crossing the 90% threashold around one hour ago (6:50 UTC)

LOG:

None

FranciscoL, [Remote: RickS]

After one week of moving the inner beam down by 5 mm on the Rx sensor (alog 78107), on June 4, we moved the beam back to center of the target.

The ETM was missaligned during the procedure. It will be interesting to see any effects from this state of the interferometer on making changes to the position of the inner beam.

Attachment 'AlignedTarget' shows the alignment with the beam height gauge. Attachment 'BothBeamsBefore' shows the beams before making any changes. The pdf 'EndStationLog.pdf' lists the voltage values after each significant step of procedure T2400163. The steps represent writing down a voltage value after a particular change to the beam position. Some steps were recorded multiple times after minor changes.

• (2) Only inner beam at Rx detector. (see image 'InnerBeamBefore')
  • The beam voltage was maximized before moving it to center. The first value is before attempting to move anything. The second value comes from attempting to maximize by making a vertical move. There was an increase of about 0.01 V (1.63 %) from this move. The third value is from moving the beam on the horizontal axis. There was no increase from the previous move.
• (3) Finalized beam movement. (see image'InnerBeamAfter')
  • First value after making the beam move to center. Second value from attempting to maximize on both axes.
• (8) Target off. The measurement was recorded after placing the pcal enclosures.

The 'Initial' measurement is *equal* to the last voltage measurement from the previous movement, done on May 21 (alog 78107). The initial and final voltage measuremed during todays procedure decreased by 2 mV (6 HOPs). The digital thermometer had a temperature of 21.1 at the beginning of the procedure and increased by 0.6 C. Will record temperature more carefully on following procedures.

With the movement made today, we expect that the X/Y comparison to return to 1.

IFO is still DOWN due to wind.

However, wind gust speeds have started to come down in the last 30 minutes and I will begin locking shortly.

J. Kissel, D. Barker, E. von Ries, R. McCarthy

Continuing investigations of the OMC0 DuoTone coupling to the ADC0 card (see LHO:77579 and LHO:78218), Erik installed some software this morning (LHO:78237) giving us the ability to turn off the DuoTone signal in the h1omc0 IO chassis in two different ways:
    (1) Change the output of the Timing Card from the standard 960 and 961 Hz DuoTone signal to a constant 2.5 [V].
    (2) Triggering the ADC DuoTone relay in the backplane interface adapter card for the low-noise 524 kHz ADC (D2100491) to turn OFF the DuoTone input to the last channel (H1:IOP-OMC0_MADCO_TP_CH31, or the 32nd channel)

The first attachment is a screen grab of the h1omc0 page of the recently updated as-built drawings of the IO chassis D1301004. This serves as a visual aide for where things are.

As such, I measured the same differentially-shorted channel I had in LHO:78218, H1:IOP-OMC0_MADCO_TP_CH17, in the following three different configurations because (again according to LHO:78218) it sees the DuoTone signal just as loudly as H1:IOP-OMC0_MADCO_TP_CHCH0, one of the channels that informs the average of four, the OMC0-DCPD_A0 gravitational wave channel. This way, we're not confused by the OMC DCPD signal chains' electronics noise.
    (a) BLACK The nominal configuration, with the standard DuoTone signal coming out of the timing card, and the interface card relay set to "ON" allowing the DuoTone into CH31.
    (b) MAGENTA Switching the timing card out to a constant 2.5 V, but leaving the interface card relay set to "ON," and
    (c) RED The standard DuoTone signal coming out of the timing card, but the interface card relay set to "OFF."

Attached is the ASD comparing the three different configurations. 

Both "OFF" configurations show no DuoTone signal. This rules out three of the suspect coupling paths -- 
    (i) direct coupling of the timing card to the ADC channels via the Adneco mother board they both reside on or 
    (ii) the ribbon cable that connects the timing card to the interface card somehow radiating the DuoTone signals to the rest of the chain
    (iii) The backplane itself (D2000297) mixing the timing signal in with interface cards that it houses . 

This differentiates between which two things that LLO did in (LLO:71315) that mitigated the issue. Remember, with the LLO the arrangement of their non-segregated h1lsc0 IO chassis, they both 
    - moved the channels off the card *and* 
    - migrated the card off the same Adneco board as the timing card . 
Because we did NOT see and DuoTone on ACD0 CH17 in configuration (c), with the timing signal ON, but the relay piping it into ADC0 CH32, that means indirect coupling across the Adneco board is ruled out, and moving the monitor channel off the card that was their real solution.

That leaves the following suggested coupling sites:
    (iv) The flat, non-twisted pair ribbon cable that connects the interface card to the ADC (less likely, given that we've proven that the same type ribbon cable from the timing card to the backplane doesn't radiate)
    (v) On the ADC card itself, direct coupling from CH31 to all its other channels

Given that (v) seems most likely, the options forward that seem most promising are:
    (I) Reduce the amplitude of the DuoTone timing signal (hopefully easy software change)
    (II) Trust that the timing system hasn't failed us, and won't fail us again, and turn off the DuoTone signal all together (dubious)
    (III) Do as LLO has done, and move the DuoTone Monitor signal OFF of this ADC by installing another ADC card, and moving the low-noise ADC to another slot on the Adneco board (expensive)

My vote (if it's not clear from my parenthetical assessment of each) is (I) because it's "the easiest." However, the CW and Stochastic groups are in the business of integrating forever, so it'll merely reduce the problem for them rather than eliminate.
The discussion will continue ... 

I've left the system in nominal configuration (a), with the DuoTone ON at it's full 5 [V_pp] amplitude, and the backplane interface card relay ON, allowing that DuoTone signal to flow into ADC0's CH31

LLO noted a 10 Hz comb that was attributed to the IRIG B monitor channel at the end station connected to the PEM chassis. (https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=71217)

LHO has agreed to remove this signal for a week to see how it impacts our DARM signal.

EX and EY cables have been disconnected.