J. Kissel, N. Kijbunchoo We've tried several more times to reacquire lock after the damping the rung up violin modes (LHO aLOG 18153), a slow but steady increase in wind up to the current 30-35 [mph] (see 1st attachment), the PSL tripping (LHO aLOG 18159), a mysterious guardian failure (LHO aLOG 18162), and now a rigorous trip of the ETMX seismic isolation because of what I think is my user error. We've run out of steam, and I don't think there's a point in continuing to battle the IFO under these terribly windy conditions. We'll start again tomorrow morning. Some details from the few lock acquisition attempts after the Guardian failure: Attempt 1: Just let the guardian try and do it's thing. Lost lock at the start of TRANSITION_TO_QPDs (but didn't realize it) Attempt 2: Noticed the recycling gain (as measured by ASAIR) was low, lost lock again Because I'd heard Kiwamu talking about low recycling gain vs. high recycling gain causing a sign flip in the ASC loops, I suspected the low recycling gain was the problem. So I had Nusinee play with the alignment of PR3, and the ITMs to try and get the ASAIR signal back up into the 600s (where is was in the 500s). She found that PR3 YAW was most effective (and the recycling gain has stayed in the 600s since she touched it up) -- we still lost lock on the TRANSITION TO QPDS. Attempt 3: After relocking, the recycling gain came up awesomely with out having to touch anything. Still lost lock at the same point. Attempt 4: This time, requested DRMI_LOCKED, such that we could go manually through each of the steps leading up to SWITCH_TO_QPDs. We got as far as the step right before -- REDUCE_CARM_OFFSET -- which completed. I was *just* about to hit go on the TRANSISTION_TO_QPDS when we lost lock. Then Nutsinee noticed that the ETMX SEI isolation system had tripped. After chasing down a bunch of WD trip and lock loss tools, we found the lock loss in the following order: HEPI 03:54:12 UTC (Actuators) IFO 03:54:13 UTC ISI 03:54:19 UTC (ST1 Actuators) TMSX 03:54:24 UTC Now, because I was messing around with the ISC_LOCK guardian in manual, I have a feeling it was me somehow sending a huge Tidal impulse to HEPI that took down the chamber but I can't be sure. Looking at the plot of the lock loss, it's certainly a huge impulsive spike that kicks the chamber, not like some slow shove from the wind or as if the Tidal was huge (again because of wind) and it suddenly hit the edge of the range. Anyways, I don't think there's something systematically wrong with HEPI that we need to freak out about, this was one lock loss of MANY over the past day, and my gut feeling tells me that the problem right now is that the TRANSITION_TO_QPDs fails while it's servoing the ALS-C_DIFF_PLL_CTRL_OFFSET and even during the REDUCE_CARM_OFFSET, because there's too much uncontrolled arm angular motion (from wind) for the CARM reduction to happen. According to the guardian logs, this servo seems to stress and eventually break the IMC lock, but I'm not sure if it's a cause or effect. We're gunna try to lock one more time, because getting to DRMI_LOCKED is incredibly robust, even in these high winds. BUT, we're not gunna log the result if negative and just go home.
Oh -- one more thing: we found something suspicious in the ISC_LOCK guardian, exactly in the TRANSITION TO QPDs's state definition: (Line 714) "ezca['LSC-TR_CARM_OFFSET'] = -3.3 #reduced from -3.3 when recylcing gain went from 29 to 40"" Seems strange that this OFFSET value would be the same as what the comment says it was reduced *from*. BUT -- this Guardian code hadn't changed since the ~3 hour lock stretch this morning, so I'm not sure if it's a problem. The lock losses happen during the only other thing of substance in this state, the self.servo of ALS-C_DIFF_PLL_CTRL_OFFSET using LSC-ASAIR_A_RF45_Q_NORM_MON as the readback channel.
Jeff switching from Manual to Exec (03:54:19) does not explain HEPI tripped (03:54:12). However, it does correspond to ISI tripped (03:54:19) which probably caused the TMSX tripped (03:54:24). Thus the kick on HEPI that caused a lock loss right before REDUCE_CARM_OFFSET is still a mystery...