Displaying report 1-1 of 1.
Reports until 01:14, Thursday 06 June 2024
LHO General
ibrahim.abouelfettouh@LIGO.ORG - posted 01:14, Thursday 06 June 2024 (78273)
OPS Eve Shift Summary

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):

SDF Diffs Attached (All Seismic Related)

LOG:

None

Images attached to this report
Displaying report 1-1 of 1.