Reports until 11:39, Tuesday 11 July 2023
H1 ISC
jenne.driggers@LIGO.ORG - posted 11:39, Tuesday 11 July 2023 - last comment - 12:20, Tuesday 11 July 2023(71229)
Plans for MICH initial alignment

[Daniel, Keita, Sheila, Jenne]

After checking when we do / don't offload the OM suspensions, we only offload them in the MICH and SRY initial alignment states, after they have completed successfully.  We do not offload them in DRMI ASC. 

Also, from Ibrahim's alog 71183, we haven't succeeded with MICH or SRY initial alignment since *before* we turned on the OM2 heater.  So, probably we're just in a situation where OM2 needs to be moved by hand to compensate for some different alignment due to its being warmer to get the beam more centered on the AS, and then things will be fine.  MICH will lock and align during the initial alignment sequence, and then OM1 and OM2 will be offloaded.  We will probably also need to help OM2 by hand again after we turn off the heater.

If this is not sufficient to ameliorate most of our problems, then we should engage and offload some AS WFS centering before attempting to lock MICH.  There are two ways we could do this, either add AS WFS centering and offloading to the Input Align (or PRX) states, or we could insert the AS_Single_bounce alignment and offloading states after PRX and before PREP_for_MICH.  Since these options are before the BS is aligned (which happens after MICH is locked), we'd be offloading OM1 and OM2 under the assumption that the BS alignment is 'close' (and OM1 and OM2 will get re-offloaded again after the BS is fully aligned, so it doesn't matter at these states if they're not perfect).  Also though, the BS has to be quite close for the Yarm green initial alignment to have succeeded, so the assumption that the BS is 'close' is probably fine. 

For now, I'm not going to make any changes to the guardian, and we'll see how initial alignment goes after hand-aligning OM2. 

Comments related to this report
jenne.driggers@LIGO.ORG - 12:04, Tuesday 11 July 2023 (71230)

Okay, even worse. 

We *do* use the AS WFS for the Xarm input (which I hadn't checked earlier), and the DC alignment of the AS WFS works, and pushes the OMs around.  However, the offloading state (which is what I had checked) for the Input_Align was only offloading the RMs (which weren't in use, so were probably "offloading" zeros).  I have added OM1 and OM2 to the Input align offload states (for both Xarm and Yarm).  We're giving it a try now.  The Input align certainly moved OM2, but since it wasn't offloaded, it went back to where it came from.

Okay - Input align offloaded now correctly offloads OM1 and OM2.  This should be much better now.

jenne.driggers@LIGO.ORG - 12:13, Tuesday 11 July 2023 (71231)

This seems to have worked nicely.  MICH alignment worked automatically without any further intervention. 

Daniel also notes that the demod phase seems much more reasonable now, and most of the signal is correctly in the Q phase.  So, the apparent mis-phasing was likely due to the very poor alignment. 

keita.kawabe@LIGO.ORG - 12:20, Tuesday 11 July 2023 (71232)

Attached shows that the demod phases are OK.

Images attached to this comment