J. Driggers, J. Kissel
Philosophical discussion -- for ISC-related models, we only are really using safe.snaps when things are going wrong. And when things are going wrong, we kind of want to know that every single setting is in the same good state that's ready for the guardian to take over. This is true for ISC-related computers and Beckhoff systems (e.g. ASC, LSC, OMC, TCS, SQZ, EX/EY/CS_ECAT_PLCs), and the ever-blurry suspension systems. We worry -- when it comes to unmonitoring individual filter banks that are currently controlled by guardian that at some point in the future we may take them out of guardian. Seismic and PSL systems are different. CAL, IOP and AUX monitor computers are different still. We didn't resolve this today, but this is a constant debate.
Further, it seems that some suspension alignment offsets have been monitored, and some has not. This, again, depends on the person reconciling, the philosophy they're adhering to, and how they feel that day. How I felt today is indicated below -- but I ended up unmonitoring 4 of these suspensions, which mankes them now all consistent.
We've taken the following action on safe.snaps:
SUSITMX -- accepted and *unmonitored* OPTICALIGN_OFFSETS
SUSBS -- accepted and *unmonitored* OPTICALIGN_OFFSETS
SUSITMY -- accepted and *unmonitored* OPTICALIGN_OFFSETS
SUSETMX -- accepted and *unmonitored* OPTICALIGN_OFFSETS
H1:SUS-${OPTIC}_${ISOSTAGE}_OPTICALIGN_${DOF}_OFFSET
(OPTIC = [ITMX, BS, ITMY, ETMX], ISOSTAGE = [M0, M1], DOF = [P,Y])
See philosophical discussions above -- today, my philosophy is that suspensions that regularly touched during alignment of the IFO should not have their optic align offsets monitored.
SUSITMX, SUSITMY
-- Accepted new spot position A2L gains on ITMs (as per "finalized" gains mentioned in LHO aLOG 50972; ETMs had already been accepted).
H1:SUS-ITMX_L2_DRIVEALIGN_P2L_SPOT_GAIN
H1:SUS-ITMX_L2_DRIVEALIGN_Y2L_SPOT_GAIN
H1:SUS-ITMY_L2_DRIVEALIGN_P2L_SPOT_GAIN
H1:SUS-ITMY_L2_DRIVEALIGN_Y2L_SPOT_GAIN
-- Accepted A2L TRAMPS on ITMs to be 3.0 sec since it doesn't matter, and OBSERVE.snap wants it to be 3.0.
SUSETMY
-- accepted L2_COILOUTF_LL TRAMP as 3.0 -- it was the only one set to 10. Don't underdstand why.
SUSSRM
-- accepted (but not unmonitored) M2 LOCK_L TRAMP and GAINs in such a way the ISC_DRMI likes in the DOWN state
SUSPRM
-- M3 coil output filter state accepted to match the coil driver state request (2.0). The state request is in the correct configuration, so there's no reason that the filter banks should be accepted differently since they're front-end forced controlled to be correct given a state request number.
SUSIM (specifically IM4)
-- accepted (but not unmonitored) the INPUTs to the M1_LOCK_P/Y filter banks as OFF, as requested by the ISC_DRMI in DOWN state.
SUSBS
-- M1 LOCK L gain value accepted (but not unonitored) -- confirmd to be in ISC_DRMI in DOWN state.
-- M1 OPTICALIGN TRAMPS accepted
SUSETMYPI
-- now defunked for observation, but used for testing occasionally -- channels related to identification of ETMY drumhead mode used last on June 26 by Jenne / Georgia (see LHO aLOG 50213):
H1:SUS-ETMY_PI_DOWNCONV_DC8_SIG_SWSTAT
H1:SUS-ETMY_PI_DOWNCONV_IN_MTRX_8_2
H1:SUS-ETMY_PI_DOWNCONV_IN_MTRX_8_4
H1:SUS-ETMY_PI_UPCONV_OUT_MTRX_2_8
accepted current settings (already accepted in OBSERVE.snap).
ASC major work here
-- WITH THE "MONITOR SELECT" MASK ON
accepted ASC LOCKIN OSC1 channels in the OFF configuration; used for occasional testing but irrelevant for observation / lock acquisition:
H1:ASC-LOCKIN_OSC1_MTRX_1_6
H1:ASC-LOCKIN_OSC1_MTRX_2_4
H1:ASC-LOCKIN_OSC1_MTRX_3_7
H1:ASC-LOCKIN_OSC1_MTRX_4_8
H1:ASC-LOCKIN_OSC1_DEMOD1_SIG
H1:ASC-LOCKIN_OSC1_FREQ
Accepted or reverted the following channels such that in safe, the start off as ZERO / OFF.
ASC-[PRC / SRC / INP]_P/Y_SMOOTH_ENABLE channels confirmed to be in PREP_FOR_LOCKING of ISC_LOCK guardian. Accepted -- but NOT unmonitored.
ASC-[C/D]SOFT_P/Y_SMOOTH_ENABLE -- reverted.
Accepting ADS PIT/YAW 10 oscillators to be consistent with MICH BRIGHT ALIGN (initial alignment state, only used occasionally).
Accepting ASD PIT/YAW Sensing, Output, and Oscillator Matrix "10" values used in MICH_BRIGHT_ALIGN, in the state that the guardian expects
Now all going to be ZERO -- OFF.
Reverted (but not unmonitored) ASC-PRC1_P filter setting -20dB gain as OFF. See discussion LHO aLOG 51044. Will need to fix this issue with DRMI ASC later in guardian, but for now accepting as though "last night didn't happen."
Accepted (but not unmonitored) the SRC1 Y offset as ON, because we confirmed that the entire filterbank is controlled by guardian. Note that the *value* is currently ZERO, as per
Accepted (but not unmonitored) SRC2 P/Y SMOOTH limits as is, because we confirm they're controlled/set by guardian.
-- WITH THE "MONITOR SELECT" MASK OFF -- checking DIFFs between the 606 unmonitored channels (there were only ~50 or so)
TRAMPS are still there.
Everything else has been accepted to match what guardian wants.
LSC
-- 5 diffs reduced to 2, the diffs made consistent with what ISC_LOCK guardian wants in PREP_FOR_LOCKING
OMC
-- accepted new OMC QPD offsets, for better optical gain (LHO aLOG 50973) -- though note that these might change due to excess glitching (see LHO aLOG 51034)
H1:OMC-ASC_QPD_A_PIT_OFFSET
H1:OMC-ASC_QPD_A_YAW_OFFSET
H1:OMC-ASC_QPD_B_PIT_OFFSET
H1:OMC-ASC_QPD_B_YAW_OFFSET
Accept (but not unomnitored) ADS YAW 5 and ADS PIT 3 in current filter states as is -- confirmed to be consistent with what guardian wants/ controls
ECAT_PLC_2
-- accepted LSC_REFL SERVO things that are consitent with ALS_COMM down state.
ECAT_PLC_4
-- accepted the LO_SERVO_COMBOOST as 0.0, and LO_SERVO_IN1EN as "off" (or 0.0) because it is set as such in the SQZ_LO_LR guardian in its DOWN state.
-- accepted the SQZ_VCO_CONTROLS_ENABLE as 1.0 or "on" because it is set as such in the SQZ_LO_LR guardian in its DOWN state.
SQZWFS
-- accepted SQZ-ASC_WFS_SWTCH as OFF (0.0), because this is requested in the SQZ_MANAGER DOWN state, and via the sub-function called turn_off_sqz.
LSC
-- H1:IMC-MCL_FM_TRIG_TRESH_ON and OFF. These have been problematic for a while. Here's why:
These trigger thresholds are set by the ISC_LOCK guardian depending on what the power is going in to the IMC we when the IMC_LOCK goes through its DOWN state. Occasionally, when the IFO loses lock -- including the IMC
-- we'll still be ramping down the power from 37W. So the thresholds will be set for the higher power that's not 2W. Right now the guardian is setting these thresholds by checking the current power. One option to fix this would be to check the requested power instead of the measured power. Another option is to just leave at the 2W value.
Jenne will post a separate aLOG about this.
CALINJ
-- Unmonitored the H1:CAL-INJ_TINJ_OUTCOME. This is readback channel written to by the TINJ guardian.
-- Accepted H1:CAL-INJ_TRANSIENT_TRAMP and H1:CAL-INJ_TRANSIENT_GAIN as 2.0 sec and 0.0 respectively. They've been this way for the entire run, save for brief stints around July 23 and 25 when the power failed.