J. Kissel, C. Vorvick

This morning, during repair of an infrasound microphone in the PEM stay-clear zone the corner station sensor correction STS got an impulse.  Unfortunately sensor correction to the corner-station SEI was not turned off, because it was unclear to those present that these two things would be interrelated. As such, this impulse was sent to the SEI systems and tripped a large fraction of their watchdogs (see LHO aLOG 31735). 

This includes the HAM2 ISI, on which the IMs are suspended. Whenever the HAM2 ISI trips or goes offline, the IMs all move to a new position, regardless of their requested alignment slider values.

This is merely another instance of the on-going issue with the IMs, as reported in
Integration Issue 4698
(note that as of this aLOG I've cleaned up the long and confusing digital paper trail associated with this bug.)

Sadly, we must wait until WHENVENT HAM2 before we can resolve this issue.

Here's how much the IMs moved:

      dP [urad]     dY [urad]
IM1      0.2          0.8             
IM2      31           5
IM3      6            0.5        
IM4      0.5          1
I've attached a 24-hour trend of the position to show this as a function of time. The black vertical line on each plot indicates the time of HAM2 ISI trip. 

Notes:
- From Cheryl's experience, a "large" jump that we need to correct for is 1 [urad] and 5 [urad] for IM1 and IM2/IM3 respectively, thus I've bolded the values in the table that are a large jump. I put "large" in quotes, because to-date, these numbers have just been empirically determined from commissioning experience. Cheryl is working on an analytical quantitative method for determining what is a large move based on metrics of the input faraday like the alignment's impact on the IFI's extinction ratio, etc.

- IM2 and IM3 are those SUS that typically move. IM4 never moves appreciably (so its typically not reported), and indeed that has been a defining bit of evidence in the study as to why IM2/IM3 move.

We've restored their alignment to the most recent out of lock positions as reported by their M1_DAMP_P/Y_IN1_DQ channels (or whatever EPICs versions of those channels you prefer). These must be restored to an out of lock alignment, because IM4 is globally controlled for alignment to follow the IFO when locked, which is decidedly the wrong alignment for lock acquisition.