jeffrey.kissel@LIGO.ORG - posted 09:23, Tuesday 14 January 2020 (54492)
Reconciling SDFs
J. Kissel
I've "finished up" the SDF reconciliation from last week, in which we had a couple of outstanding models that we didn't want to reconcile until we had a "fresh" lock loss (i.e. having not run initial alignment like had been done last week). I report the results below in the form of Dave's ever useful /ligo/cds/userscripts/sdf_files_report script.
model_name: | safe | down | OBSERVE
h1susitmx: | ->down | 14-Jan-2020 | 12-Jan-2020
- accepted new violin mode damping filter bank configuration for MODE3 (see LHO aLOG 54382).
h1susetmy: | ->down | 07-Jan-2020 | 06-Jan-2020
- Accepted new configurations of violin mode damping filter bank for MODE18 and 20 (see LHO aLOG 54382)
- unmonitored ETMY TEST_{P,Y}_OFFSET, as per philosophical discussion last week (see LHO aLOG 54339): if the OFFSETS are touched by ALIGN_IFO (for initial alignment), ALS_XARM/YARM (for INCREASE_FLASHES), ISC_LOCK (for CSOFT spot position moves), then unmonitor the M0 TEST OFFFSETs.
h1ascimc: | ->down | 07-Jan-2020 | 10-Jan-2020
- accepted 2e-17 difference from H1:IMC-WFS_GAIN of 0.04 to ... 0.04.
- accepted H1:IMC-PZT_PIT_OFFSET and H1:IMC-PZT_YAW_OFFSET in there new position
- these were moved during last week's IMC WFS centering (see LHO aLOG 54340)
- ... we should have a philosophical discussion *** about this.
h1calcs: | 14-Jan-2020 | none | ->safe
- accepted the new model values at calibration line frequencies. These are going to continue to show up every time the sdf snap comparison file "switches" from safe to OBSERVE until the calibration team modifies their script to round off these EPICS values before writing.
h1lsc: | ->down | 10-Dec-2019 | 25-Nov-2019
- unmonitored the H1:IMC-MCL_FM_TRIG_THRESH_ON and H1:IMC-MCL_FM_TRIG_THRESH_OFF thresholds. These are set by the ISC_LOCK guardian.
h1susprm: | ->down | 29-Oct-2019 | 17-Sep-2019
h1sussrm: | ->down | 10-Dec-2019 | 01-Nov-2019
- For both these SUS, like ETMY last week (LHO aLOG 54343) have coil driver analog switching that's regularly touched by the global controlling guardians. Also, like SR2 and PR2, the coil driver state is switched in three different guardians -- ISC_LOCK, ISC_DRMI, and ALIGN_IFO -- and they each want a different state. It still puzzles me that the H1:SUS-SRM_BIO_M3_??_STATEREQ channels are in the state we want, but the actual filter banks H1:SUS-SRM_M2_COILOUTF_?? show up as diffs. I think what's happening is that the coild don't get switched back to a given state until somewhere in the middle of the acquisitions (e.g. the ISC_DRMI guardian is in charge during the lock acquisition sequence, and just like SR2 and PR2, the coil driver state configuration was moved from the DOWN state to the PREP_FOR state), so they don't get exercised after a lock loss until trying again. So, the configuration that appears depends on the last lock loss, and whether we lost it before or after they've been exercised. The message: the STATEREQ is controlled by guardian, and the COILOUTF are *forced* to match the state request by the front-end, so I'm unmonitoring FM1 FM2 FM6 FM7 of the COILOUTF banks -- the filters are front-end controlled.
h1seiproc: | 03-Dec-2019 | none | 04-Jan-2020
- umonitored the H1:ISI-DIFF_CONTROL_BIT and H1:ISI-DIFF_${OPTIC}_CPS_[X,Y]_GAIN where ${OPTIC} = HAM3, HAM4, ETMX , ETMY, and BS. This is controlled by the CPS DIFF guardian, and is the CPS DIFF ON/OFF switch. In safe, we want the CPS DIFF OFF, and it is saved in OFF in that snap. However, CPS DIFF is now a part of the seismic configuration that is regularly manipulated either ON or OFF, and done so with guardian.
h1sysecatc1plc4:
- unmonitored
H1:SQZ-LO_SERVO_COMBOOST
H1:SQZ-LO_SERVO_IN1EN
H1:SQZ-VCO_CONTROLS_ENABLE
since these are controlled by the SQZ guardian.
Though -- if we don't have one already, we should probably create a "DOWN" and an "OBSERVE" snap for this model.
Currently this "model" (it's really beckhoff, of course) is not included in Dave's awesome new sdf_files_report script, so I don't know what files exist and who points to whom.
*** The philosophical debate regarding the IMC-PZT sliders:
- The whole point of safe.snaps are to make sure that, upon computer reboot, the the values are returned to a functional value.
- BUT these IMC-PZTs are known to be *very* hysteretic, such that if the power to the PZTs goes down, there's no guarantee at all that the PZT will come back to the same physical location given the identical slider values.
- The secondary reason we like to cite for keeping the safe.snaps up to date for the OPTICALIGN-like sliders is "we wanna make sure that no one's changing them" or "well, we want to make sure we're at least in the right ball park," but
- changes to them will show up in the OBSERVE.snap and the IMC usually doesn't work well at all when these PZTs are misaligned, and
- even if the values are "out-of-date" resetting to them upon a computer crash / power failure just won't get you any where (you'd need to nudge the value ~100 cts one way and then bring it back, and even when we *do* do that, the physical location ends up "good enough," not actually in the same location, and the IMC WFS take up the rest.).
So... do we just "occasionally accept them when we see a difference" (which seems pointless) or do we "unmonitor them" to avoid alarm noise...
