Reports until 15:28, Friday 24 January 2020
H1 SUS
jenne.driggers@LIGO.ORG - posted 15:28, Friday 24 January 2020 - last comment - 14:07, Monday 27 January 2020(54706)
BS and PR3 wire heating filters are 25 min, not 4 min

[Corey, Jenne]

We've found that when the BS has integrated up a lot of ASC signal, but then we lose lock, it can take a long time for the flashes on the AS air camera to look symmetric again.  While looking at a series of locklosses from TR_CARM, Corey and I found that the let-the-integrator-decay filters in the M1 stage of the BS (which are labeled as 4min) are actually having the pitch output of the BS decay to zero over 25 (!) minutes.  Recall that these decay filters are to help with alignment issues due to wire heating, but that wire heating issues should mostly have been ameliorated by the wire baffles.  Even if we need these decay filters when we lose lock from NomLowNoise and high power, we shouldn't need them when we're losing lock from a cold IFO (eg. DRMI states).  Identical filters with long decay times are installed in PR3, but we don't use that optic for angular control, so it never needs to do any decaying.

The decay filters have names that say 4min, but the poles is at 6.6315e-4 Hz, which gives a ~1500 second decay time.  The pole frequency is at a surprisingly precise frequency, which if you include a 2*pi, makes it look like the decay time would be 240 seconds, or 4 min.  I suspect that the designer of these filters got mixed up and thought the values in Foton were in units of radians/sec, rather than 1/sec.

I don't know that this is what has been causing problems with locking, but it probably hasn't been helping.  I suppose that since we turn on MICH ASC once DRMI is locked, and before we start the carm offset reduction sequence, this residual BS offset shouldn't be a problem for TR_CARM (since it will be taken away by the MICH ASC).  It might have been causing problems with FIND IR for DIFF/Yarm, since the Yarm bounces off the BS to get out to its transmission PD.  

We should probably change the logic so that if we've lost lock from an early acquisition state, we just clear the BS pit history.  We can still use these decay filters for NomLowNoise locklosses, if they seem necessary.

Comments related to this report
jenne.driggers@LIGO.ORG - 16:27, Friday 24 January 2020 (54709)

After talking to Sheila and Jim, we all agree that we can probably get rid of these wire heating decay filters, since the new BS baffle was put in pre-O3 to further protect the wires from seeing any heating.  

In the first attached figure, we lose lock around 1300 seconds from a TR_CARM lockloss (so no power buildup). Very quickly, we have a transient that get through to the BS_M2_LOCK_P output, and so gets integrated in with the M1 Lock input.  But, since we've just lost lock, the ASC output isn't sent to the coils (because the lockloss trigger is stopping the signal), but after ~100 seconds the lockloss trigger is reset in the guardian, so we allow the decaying ASC signal back to the coils, and see a jump in the BS oplev signal.  The salient point is that as the coil output filter changes over 20 min, the BS oplev is also changing.  If the decay filter were compensating for wire heating, then the oplev should be more constant and flat.  Since it's not, we're pushing unneccessarily.

In the second attached figure, we lose lock from a 2 hour long Nominal Low Noise lock around 20 seconds.  No major transient in the M2 filter that gets sent to the M1 output, although the lockloss trigger again takes away the coil output for about a minute, during which time the optic swings a bit.  But, once the ASC outputs are again sent to the coils, we see the BS move as the coil output is changed.  I suspect that we'd be okay here also without having the long decay filters.  

Since we would only even potentially need the heating decay filters when losing lock from nominal low noise, it's a bit hard to do chopping tests with and without the filter, so probably we'll just try removing it entirely, and making the pitch filter banks operate the same way the yaws do (without any decay, just normal ramp-down).

Images attached to this comment
jenne.driggers@LIGO.ORG - 16:58, Friday 24 January 2020 (54712)OpsInfo

I have just changed ISC_DRMI to treat BS and PR3 pitch the same as yaw (as is done for all other suspensions) when clearing the ASC history in the DOWN state.  Next time we're out of Observing, we'll reload the ISC_DRMI guardian, so that we can (hopefully) see an improvement in some lock acqusition cases. If BS pointing is a real problem over the weekend, we can revert the DRMI guardian and reload it.

Still to be seen (fair game for an operator to look at over the weekend, otherwise I'll look next week) is whether the MICH BS ASC is in fact undoing / taking care of any leftover decay filter offset when we go through DRMI ASC, or whether this decay filter output has been causing trouble for us during the TR_CARM states.  I think that it's probably true that the MICH ASC is doing its job and pushing the BS where it needs to go (we do see improvements in buildups afterall), and that the TR_CARM locklosses are from something different. 

Even if the TR_CARM locklosses are unrelated to the BS pitch decay filters, it is still interesting that the TR_CARM locklosses seem to go away so easily after initial alignment.  Maybe something to check is where the optics were pointing when attempting and failing TR_CARM earlier in the afternoon before initial alignment, versus where the optics were pointing after initial alignment when we successfully got through TR_CARM.

jenne.driggers@LIGO.ORG - 16:58, Friday 24 January 2020 (54713)OpsInfo

I have just changed ISC_DRMI to treat BS and PR3 pitch the same as yaw (as is done for all other suspensions) when clearing the ASC history in the DOWN state.  Next time we're out of Observing, we'll reload the ISC_DRMI guardian, so that we can (hopefully) see an improvement in some lock acqusition cases. If BS pointing is a real problem over the weekend, we can revert the DRMI guardian and reload it.

Still to be seen (fair game for an operator to look at over the weekend, otherwise I'll look next week) is whether the MICH BS ASC is in fact undoing / taking care of any leftover decay filter offset when we go through DRMI ASC, or whether this decay filter output has been causing trouble for us during the TR_CARM states.  I think that it's probably true that the MICH ASC is doing its job and pushing the BS where it needs to go (we do see improvements in buildups afterall), and that the TR_CARM locklosses are from something different. 

Even if the TR_CARM locklosses are unrelated to the BS pitch decay filters, it is still interesting that the TR_CARM locklosses seem to go away so easily after initial alignment.  Maybe something to check is where the optics were pointing when attempting and failing TR_CARM earlier in the afternoon before initial alignment, versus where the optics were pointing after initial alignment when we successfully got through TR_CARM.

jenne.driggers@LIGO.ORG - 14:07, Monday 27 January 2020 (54758)

When doing this work on Friday, I had forgotten to ensure that the pitch gains get set back to their nonzero values in the guardian.  Corey fixed this, see thread in alog 54746.