Displaying report 1-1 of 1.
Reports until 13:12, Tuesday 07 May 2024
H1 ISC
jenne.driggers@LIGO.ORG - posted 13:12, Tuesday 07 May 2024 - last comment - 10:51, Friday 10 May 2024(77690)
SR2 alignment when beam centered on AS_C, before vs after SR3 shift

Sheila asked a good question the other day of, Did SR2 alignment change between the beginning of O4b (when things were still good) and when we had the bad losses through the OFI (when things were bad, before the big shift).  The answer: no, I don't think SR2 moved very much (according to its top mass osems) when the the losses through the OFI showed up. It did move about 10 urad in yaw (see table below), which I plan to look into further.

I looked at several times throughout the last few weeks when ALIGN_IFO guardian had just finished up state 58, SR2_ALIGN at 10 W, which it now does every time initial alignment is automatically run.  These should all be single bounce off of ITMY, with the beam centered on AS_C by adjusting the SR2 sliders, for some given SR3 slider position (nothing automatic touches the SR3 sliders). 

In the table, I summarize the SR3 and SR2 top mass osems.  I've got 3 categories of times for the IFO situation:

Note that this table is not chronological, since I've grouped rows by IFO situation rather than time.  The SR2 and SR3 osem values that are in bold are the ones to compare amongst each other.  There does seem to be a 10 urad shift in SR2 yaw between the April 21st and April 23rd times.  There are no other run-throughs of the SR2_ALIGN state of ALIGN_IFO between these times to check.  This SR2 yaw shift (which is consistent even when we revert sliders to the 'pre shift' values and run SR2_ALIGN) is notable, but not nearly as large as what we ended up using for steering around the spot in the OFI.

IFO 'situation' Date / time [UTC] AS_C NSUM value SR3 Pit [M1_DAMP_P_INMON] SR3 Yaw [M1_DAMP_Y_INMON] SR2 Pit [M1_DAMP_P_INMON] SR2 Yaw [M1_DAMP_Y_INMON]
(1) before EQ, before loss, before alignment shift 17 Apr 2024 00:19:00 0.0227 -281.5 -612.2 569.8 35.3
(1) after EQ, before loss, before alignment shift 21 Apr 2024 20:08:30 0.0227 -281.5 -611.9 571.9 35.3
(2) after EQ, after loss, before alignment shift 23 Apr 2024 23:10:00 0.0193 -281.9 -612.2 572.7 26.7
(2) after EQ, after loss, shift temporarily reverted to check 7 May 2024 18:10:00 0.0187 -282.3 -616.0 558.5 23.2
(3) after EQ, after loss, after alignment shift 25 Apr 2024 12:18:20 0.0226 -291.7 -411.1 599.6 1150.0
(3) after EQ, after loss, after alignment shift 7 May 2024 19:11:15 0.0226 -292.4 -408.8 597.6 1149.9

 

Comments related to this report
jenne.driggers@LIGO.ORG - 14:08, Tuesday 07 May 2024 (77693)

After a quick re-look, that 10 urad move in SR2 yaw seems to have come during maintenance, or sometime later than the time that the loss showed up. 

In the attachment, the vertical t-cursors are at the times from the table in the parent comment on April 21st and 23rd.  The top row is SR2 pitch and yaw, and the bottom row is SR3.  The middle row shows our guardian state (i.e. when we were locked), and kappa_c which is indiciative of when we started to see loss.  In particular, there are 3 locks right after the first t-cursor, and they all have quite similar OSEM values for SR2 yaw (also the times between locks are similar-ish).  Those three locks are the last one with no loss, one with middling-bad loss, and one with the full loss.  So, it wasn't until after we had our full amount of loss that SR2 moved in yaw.  I haven't double-checked sliders yet, but probably this is a move that happened during maintenance day.

Images attached to this comment
sheila.dwyer@LIGO.ORG - 10:51, Friday 10 May 2024 (77762)

I'm using Jenne's times above to do a similar check, but looking at times when ALIGN_IFO was in state 65 (SRY align) because in that state the AS WFS centering servos are on.  This state is run shortly after state 58, so I'll reuse Jenne's numbers to refer to times and the IFO situation.

This table indicates that changes in AS power are consistent between AS_C and the AS WFS, so the beam transmitted by OM1 and reflected by OM1 see similar losses.  This makes it seem less likely that a bad spot on OM1 is the problem (and points to probably being an issue with the OFI), although it's not impossible that a loss on OM1 is seen in the same way for transmission and reflection.

    AS_C sum AS_C normalized to first row AS_A sum AS_A normalized to first row AS_B sum AS_B normalized to first row
1 April 17 00:20:15 UTC 0.0626 1 5264   5104  
1 April 21 20:09:43 UTC 0.0629 1.005 5283 1.004 5114 1.002
2 April 23 23:34:15 UTC 0.0534 0.853 4595 0.873 4359 0.854
2 AS centering was not run this time            
3 April 25 12:19:36 UTC 0.0622 0.993 5209 0.989 5083 0.996
3 May 7 19:12:30 UTC 0.0624 0.997 5241 0.996 5118 1.003

 

Displaying report 1-1 of 1.