TITLE: 06/06 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

The detector is in DOWN for the night and there is a test running right now for Matt for the IMC. The HAM1 cleanroom is on and will be on all night to prep for the +Y door coming off tomorrow morning. Craig and I had turned it on earlier, but then I got worried that it was causing locklosses so I went out and turned it back off, and just now went and turned it back on for the night. It looks like the temperature in that zone (zone 5) was really affected by the cleanroom being turned on (and off) (ndscope1), but the locklosses that we had after it was turned on and back off I don't think should be related to the temperature of the input arm.

After the lockloss earlier in the day during the calibration simulines measurement, we really wanted to get back up and at least check that simulines was running fine and had not caused the lockloss (it didn't look like it did 84836, but still). Unfortunately we weren't able to get back up, as the ifo hasn't really liked me much lately and we had constant locklosses from different places:

• We had a couple locklosses from ENGAGE_ASC_FOR_FULL_IFO, and Elenna figured out it was due to the DC6 centering loops not being able to keep up with the movements. Elenna upped the gain and this looked like it basically? fixed the issue (84843). However, we do get a pretty large glitch in the PR gain during that time, and we did have a lockloss after that in the same spot one other time afterwards.
• Later on, we were getting PRC2 P ringups at 0.28 Hz during MOVE_SPOTS  (ndscope2). The first time it happened we lost lock from it, and the next time it started happening, I lowered the ASC PRC2 P gain from 500 to 400, and that saved us! Later on, Elenna and I were looking at the ISC_LOCK code, and Elenna saw that earlier when she had been uncommenting some other lines for 84843, she had accidently uncommented a line that raised the PRC2 P gain up to 500! She commented it back out and reloaded ISC_LOCK, and we didn't encounter that issue again.
• We also had a lockloss from TRANSITION_FROM_ETMX due to a 1 Hz oscillation in DHARD P and PRC2 P (ndscope3)(84844). Elenna said this was an issue from LOWNOISE_ASC, so I prepped to turn off the DHARD P FM4 and FM8 filters in case we saw the oscillation on the next lock. Additionally, Elenna added 60s timers to multiple chunks of the LOWNOISE_ASC code, to hopefully step everything up nicely and slowly. Unfortunately, on the next lock, we started seeing the oscillation again. I turned off the two DHARD P filters at the same time using the interactive guardian shell, but the oscillation didn't stop. In a futile attempt to save the lock, Elenna and I teamed up to revert the filters and gain for CHARD P at the same time, but alas our noble attempt failed and we lost lock, either from the oscillation, or from trying to save the lock.

LOG:

23:00UTC in NLN_CAL_MEAS
23:14 Started calibration measurement
23:16 Lockloss during calibration measurement, cause unknown
    - Lockloss from ENGAGE_ASC_FOR_FULL_IFO
    - Lockloss from ENGAGE_ASC_FOR_FULL_IFO (from same location)
        - Figured out it was due to the DC6 centering signals not being able to keep up with the movements. Elenna upped the gain for the DC6 loops and this fixed the issue (84843)
    - Lockloss during MOVE_SPOTS due to Craig and me turning on the HAM1 cleanroom
    - Lockloss from MOVE_SPOTS due to a PRC1/2 P ringup at 0.27 Hz
    - Lockloss from ENGAGE_ASC_FOR_FULL_IFO due to 84843
    - I turned the HAM1 cleanroom back off in case it was affecting our ability to lock
    - Lockloss from TRANSITION_FROM_ETMX due to 1 Hz oscillation in DHARD P and PRC2 P from ringup (84844)