Jenne D,  Jennie W

Jenne noticed that our AS_A_YAW offset was on in the current state (PREP_FOR_LOCKING). We don't want this offset on currently as we are moving to a different spot on the OFI for which we need the picomotors, therefore we my need to rethink AS_A and B alignment offsets.

We turned this offset and the other AS_A and AS_B oiffsets off.

This is the only one I could find set in the ISC_LOCK guardian so I commented this line out.

        elif self.counter==9 and self.timer['LoopShapeRamp']:
            #ezca['ASC-AS_A_DC_YAW_OFFSET'] = -0.15 J Wright commented this out on 6th June 2024.
            ezca.switch('ASC-AS_A_DC_YAW', 'OFFSET', 'ON')

I reloaded the ISC_LOCK guardian.

Thu Jun 06 10:09:03 2024 INFO: Fill completed in 9min 0secs

Gerardo confirmed a good fill curbside.

P. Baxi , J. Kissel 

Finished characterizing (Channels 1 to 4) of the new 524KHz Analog OMC Anti-Alias Chassis - S2300162

• Bode plot for the system include the Transfer function and Phase of each individual Channels (1 to 4) and their (Channel 2 to 4) respective ratio with Channel 1 for comparision. The system was characterised from Start Frequency of 1KHz to a Stop Frequency of 102.4KHz with 100 steps.

                       BodePlot_Channel_1_4_freq_start_102.4KHz_Freq_stop_1KHz_Steps_100.pdf  (raw data - available in DCC S2300162)

              - We see the frequency response has minimal phase impact in the gravitational wave band, with deg of phase loss at 1000 Hz.

• Noise Measurements for Channels 1 to 4 with reference to the noise of SR785 is shown in the plots below. To achieve the maximum frequency range we incorporate and merge three frequency spans: 4Hz to 3.2 KHz, 32 Hz to 25.6 KHz, and 128Hz to 102.4KHz.

                       ASD_SR785_Channel_1_4_Freq_span_4to32K_32to256K_128to1024K.pdf  (raw data - available in DCC S2300162)

              - We see the noise of each of these 4 representative ADC channels is around ~20 nV/rtHz

• Python scripts to regenrate the plots. (Bode plot and ASD plots) 
• Measurement notes to reproduce the above raw data.  (Bode plot and ASD plots) 

TITLE: 06/06 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 4mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.26 μm/s
QUICK SUMMARY: H1 has been unlocked since 10:21 UTC this morning. It's been able to relock up to PREP_DC_READOUT_TRANSITION, but the OMC is not locked; OMC_LOCK is stuck in the SET_WHITENING state with a notification reading "DCPD gains not equal after whitening switch -- yikes!" (I've not seen this before; will start troubleshooting)

• Wind is low
• Microseism is trending downwards

Ibrahim, Ryan S, Jenne, Sheila, TJ

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

IFO is in NLN and OBSERVING (after a 24 hour outage) as of 07:59 UTC (cutting it real close H1...)

For the majority of the shift, I was unable to lock - here’s why:

1. DARM_OFFSET: 

   • Issue: IFO loses lock at DARM offset at which point PR Gain oscillates very vigorously and plummets. If we can manually turn the offset off in time, it recovers and we don’t lose lock.
   • Fix: ASC Loops were not fully converged at the time of the PRG plummet and so we moved the states around (Ryan S, Jenne, Ibrahim) and put ENGAGE_SOFT_LOOPS and ASC states before DARM_OFFSET, which seemed to have fix the issue owing to the less noisy IFO. However, this means that the OMC locks sequentially instead of simultaneously, adding time to lock
   • Cause: Largely unknown but seemingly related to an alignment issue that Jenne thinks has to do with ASC Yaw.
   • Other Troubleshooting/Relevant Alogs: We have seen that DHARD_Y gets spiky and oscillates in the seconds leading up to SRC1_Y and SRC2_Y engaging right before the lockloss. Alog 78251, Alog 78258, Alog 78259, Alog 78265, Alog 78267

2. ACQUIRE_DRMI_1F:

   • Issue: IFO loses lock here due to very poor pop19 and pop90 flashes, not even making it past PRMI or MICH_FRINGES at times. 
   • Fix: Turning on an 0.6 Offset in SRC1_Y seems to help get past this state but interestingly, this was not required during the last lock attempt post-initial alignment so maybe just initial alignment?
   • Cause: Unknown but thought to be due to more SRC alignment issues.
   • Other Troubleshooting/Relevant Alogs: Alog 78267, Alog 78265

3. LOCKING_ARMS_GREEN: 

   • Issue: IFO cannot lock green arms for longer than 5 minutes. ALSX is the problem here, where it gets extremely fuzzy and oscillates with a huge amplitude (between 1.2 and 0.8 on its scale). The fuzziness is indicative of a weird comb interference. During this time, it usually loses lock but in the times that it doesn’t, TRX degrades slowly and randomly and then recovers slightly. While this is happening, PLL and PDH fault alarms go up and the state prompts me to “check crystal frequency”
   • Fix: With Jenne, we went into the ALSX Crystal Polarization screen and found that the number was 15 when it is usually supposed to be below 9. Playing with it manually, we were able to get it to 11 by playing with the sliders, which allowed us to get past ALS. I don’t know if this mattered though because after our most recent initial alignment, the value read: 9.
   • Cause: Unknown
   • Other Troubleshooting/Relevant Alogs: None

4. VIOLINS:

   • Issue: Violins are extremely high, to the point that the primary is occulted by the DARM legend on Nuc30
   • Fix: Damp them violins.
   • Cause: All the above, though it’s interesting that they maintained their magnitude despite initial alignments and hours of non-movement during non-violin exciting periods.
   • Other Troubleshooting/Relevant Alogs: There was a lockloss when violins got sufficiently damp to go to OMC_WHITENING but when there is no wind, there is still pain - and we lost lock minutes before that happened.

On top of these, we have also had a few totally spontaneous lock losses which do not have tracks as egregious as the three above. Moreover, running INITIAL_ALIGNMENT seems to randomize what issue I face in that I either will be acquainted with a totally new problem or face no problems.

A summary of controls moved (with permission):

• PRM
• PR2
• SRM
• SR2
• SR3 (don’t panic - moving it back to nominal after it got moved earlier)
• SRC1_Y Offset
• DARM1 Offset
• ALSX Polarization Frequency

SDF Diffs Attached (All Seismic Related)

LOG:

None

IFO is still LOCKING (I know)

While violins were damping to turn on whitening (pretty steadily too), we lost lock unexpectedly. DRMI could not lock - PRMI could not lock and MICH Fringes could not lock PRMI. So now I'm doing an initial alignment.

Attaching a set of slides summarizing the on-going efforts to reproduce the beam path from SR3 through the OFI. Two sets of the beam spot position measurement on SR2 and SR3 were used to "calibrate" the slider moves and to simulate the beam position for other alignment configurations using Zemax. The slides are posted to the dcc https://dcc.ligo.org/E2400189-x0
The aLogs with the beam spot position measurements:
beam spot 1 measurement  aLog77443 
beam spot 2 measurement aLog78119

[Jenne, Sheila, Jennie, RyanS, Ibrahim]

The interferometer has remained fussy all day.  I suspect we may have some alignment issue somewhere, since the AS_AIR camera looks a little bit lobe-y and wrong in yaw.  Twice now, if we've gotten past the DARM_OFFSET state and convinced the OMC to lock (which it will do with the autolocker once the darm offset is at the full value of 9e-5), we're able to at least start powering up. 

• One time, as RyanS mentioned, we succeeded by slowly stepping the DARM offset up to the value of 9e-5, after all ASC for full IFO (Including SOFT) loops had converged. I'm not sure why we lost lock on this one, but it's possible that we're more sensitive to motion on the LVEA floor, and Robert was out taking photos.
• One time, that wasn't enough, and we were more successful with an offset of +0.6 in place in the SRC1 yaw loop both during DRMI ASC and re-engaging it during full IFO ASC.  This current lock, with that technique, once the OMC was locked I slowly set that offset back to its nominal value of zero, and we're powering up okay.  More specifics on what I did:
  • With the ISC_LOCK at CHECK_DRMI_ASC, I turned on an offset of +0.6 in SRC1 yaw.  I then let the ASC converge and set ISC_LOCK to PREP_ASC_FOR_FULL_IFO, which turned off the offset (during a time when SRC1 was not engaged).
  • I set ISC_LOCK to ENGAGE_ASC_FOR_FULL_IFO, and it was clear that the alignment was getting a bit worse with the SRC1 yaw offset off, so I re-turned it on again to +0.6. 
  • I set ISC_LOCK to PREP_DC_READOUT_TRANSITION, and the OMC was able to lock, we didn't lose lots of PRG, everything seemed overall fine.
  • I ramped the SRC1Y offset back to 0, and then requested NomLowNoise.  The alignment definitely saw the move, but it didn't seem terribly dramatic, so it seems fine.
• I am hopeful that this was a fluke, and we don't need to actually have a SRC1 yaw offset.

My hypothesis of why we might be needing this alignment offset, is that increasing the DARM offset is letting more carrier light go to the AS port, and the the AS WFS loops are seeing that and responding poorly.  So, this alignment offset helps kepe them in the right spot.  That's not a very satisfying story though.

Earlier, I had tried moving SR3 by +/- 1urad on the slider in yaw (reverting afterward to the previous slider val), but that didn't really help.  I also tried offsets in AS_C and AS_A pointing, but neither of those had the same improvement in the AS camera or POP90.  They would improve momentarily, but after the rest of the ASC caught up, we still had the lobe-y look on the AS camera.

Jennie also noted earlier (and it happened at least both of these last two power ups) that we're saturating the OMC suspension when we power up (before moving spots).  But, after all the ASCs catch up, it's no longer saturated.  So, we're close to the edge of what the OMC suspension can do, but it seems surviveable.

Attached are screenshots at CHECK_DRMI_ASC of the AS air camera, without and then with my hokey offset of 0.6 in SRC1 yaw.  You can see that with the offset in place, the camera image is much more centered and nice looking.

For posterity, here are the mattermost versions of the notes, starting with this message:

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.

Wind was brutal today, so I was messing with the controls on the BSCs to try to help. Mostly just running RX/RY sensor correction from St1 to St2 on the BSCs. Sensor correction is focused on improving the ~.4hz motion and doesn't really affect the motion outside that. I don't think this really helped, winds calmed down after I left at 5:30 and Ryan is almost all the way NLN now, so I will leave the extra sensor correction running for tonight. I'll accept SDFs for tonight, then turn it back of during maintenance tomorrow.

Wind and lock losses make a comparison challenging, but the blrms trends show the (log scale) improvement ETMY sees when it's turned on over .3-1hz. Top trace is the St2 RX GS13 blrms, middle trace is the gain for the sensor correction, sc is on when it's 1, off at 0. Bottom trace are the .3-1hz ground blrms. For the las 3-ish hours the St2 RX motion is lower with the sensor correction on even when the ground is moving more in this frequency band.

With the difficulties locking, I tried changing some of the CPS diff filters to get the end station ISI to follow the corner ISI. The CPS diff uses a band pass filter to reduce the differential motion between the ISI, but this filter can inject motion at the microseism. Microseism is low, I'm guessing the arms are struggling more with the below .1hz motion. In the attached image the filters we had been using, are the red trace, blue is what I switched to. It kind of seemed to help, but I think we lost lock after I left the room. I'll leave this running for now, going to try a couple other things.

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.