jeffrey.kissel@LIGO.ORG - posted 17:32, Wednesday 26 July 2023 - last comment - 14:49, Thursday 07 September 2023(71746)
Adding More Oscillators to PCAL, New Oscillators to DARM to Create Infrastructure for More, Permanent, CAL Lines
J. Kissel We now have heard from search groups that they don't (yet, definitively) mind having more calibration lines -- as long as they're subtracted. Further, we've re-found the need to make continuous measures of the low-frequency end of the sensing and response function. Finally, we want to use an excitation solution that is more robust than awg (which is what the recently re-started CAL_AWG_LINES guardian uses). As such, I propose the following changes: (1) In the PCAL models' library part: expand the same solution that's already in use -- front-end, synchronized oscillators whose parameters are controllable by EPICs -- piped into the same "LINE_SUM" channels that already exist and stored into frames. Since we always seem to find more uses for PCAL lines, I've added 20 more beyond the 10 that are already there, for a total of 30 at each end station. There're no new fast channels / test points needed, since we only monitor the SUM of all the oscillators, and that sum is already stored in the frames. (2) In the h1omc model's LSC block*** which contains the DARM control filters -- add front-end, synchronized oscillators 10 in total -- and sum them in to the error point of the loop, just down stream of DARM_ERR, just like the actual excitation point, DARM1_EXC. We'll only store the sum of the oscillators in the frames, like in the PCAL system using the pre-existing channel stored in the frames -- LSC_CAL_LINE_SUM -- so no new data storage burden there. However, because we're using these DARM calibration lines as measures of the open loop gain, loop suppression, and closed loop gain, we need to store the test point immediately *downstream* of the summation point, which, in H1's case is DARM1_IN1. (We'd already stored DARM1_IN2 as the test point just downstream of awg-style excitations -- which is still needed for swept sine and broadband excitations). (***the LSC block is intentionally *not* a library part, since L1's LSC control needs are different that H1's). So -- this proposal's impact on data storage is (20 PCALX + 20 PCALY + 10 DARM) oscillators * (5 EPICs records per OSC) = 250 new EPICs records at 16 Hz, and ONE new test point stored at 16 kHz. I attach screenshots of "before" vs "after" changes in the comments below. I'll now use this documentation to write the ECR to install, hopefully next Tuesday (7/31/2023).
PCAL library part, before vs. after. I took the opportunity to re-organize other parts visually for clarity as well, but there's no functional change other than the 20 new oscillators. Also, as a minor simulink detail -- the individual OSC blocks *had* been a library part with-in a library part bug since the beginning of time (someone copied and pasted the block, but forgot the annoying feature of library sub-blocks that if you copy a block within a model that's already a library, it stays linked to the original thing you copied. One needs to explicitly "disable link" and "break link" if you don't want that sub-block to reference the other). Instead, I *actually* made a new library part, since I new I wanted to copy the same thing to the LSC model. Thus, the PCAL_MASTER.mdl library now relies on a new library part, /opt/rtcds/userapps/release/cal/common/models CAL_OSC_MASTER.mdl which is manifested in the PCAL model as the oscillators "PCALOSC1," "PCALOSC2," ... "PCALOSC30". 2023-07-26_PCAL_MASTER_PCAL_OSCfocus_before.png shows the impacted parts of the PCAL_MASTER.mdl library part before the changes. 2023-07-26_PCAL_MASTER_PCAL_OSCfocus_after.png shows the impacted PCAL_MASTER after the changes. 2023-07-26_CAL_OSC_MASTER.png shows the new CAL_OSC_MASTER library block, and 2023-07-26_CAL_OSC_MASTER_inside.png shows the innards.And here's the LSC block before and after the changes. Here, again, I took the opportunity to aesthetically clean up the garbled mess that was all the things that have been stapled on and around the DARM bank over the years. But, the only functional changes are (a) the new oscillators, (b) the move of the CAL_LINES summation point from into DARM_CTRL to into DARM_ERR, (c) the DARMOSC_SUM test point and epics monitor, and (d) the storage of DARM1_IN1 in the frames. The changes (b) and (d) are "interesting." For old iLIGO reasons that I don't remember, the "DARM" calibration lines were summed in down stream of the DARM bank, i.e. into DARM_CTRL. Even though the infrastructure is there (I personally installed it circa 2012-2013), we haven't used these DARM calibration lines *at all* in the advanced LIGO era. This is because we quickly realized that we need such a "CTRL" excitation at each stage of QUAD's DARM actuation if we want to track the actuation strength of each stage of the QUAD separately like we do now. Now, we want to re-invoke the "DARM" calibration lines to constantly measure the DARM open loop gain, G, or more specifically the loop suppression, 1/(1+G), so we can divide it *out* of an adjacent PCAL line measure of the response function, C/(1+G). But, as always, we need two test points surrounding it, the so-called "IN1" (just up stream of the excitation) and "IN2" (just down stream of the excitation) points. Of course, when measuring live, it doesn't matter where in the loop this trifecta of IN1+EXC=IN2 system of channels are; you'll get the same answer whether it's up or down stream of the DARM banks. BUT, while we already store DARM_ERR and DARM_OUT in the frames, which could both equally be the "IN1" channel, - there was no convenient test point to store after the DARM OUT, - I wanted the calibration lines to mimic the location of where the awg input DARM1_EXC was injected in the loop -- i.e. in between DARM1_IN1 and DARM1_IN2, and - I figure the DARM1_IN1 test point (which comes by default with the DARM1 standard filter module) is already there and has a more natural name. So, I moved the summation point. So, when we analyze these calibration lines offline, we'll be taking the transfer function between the following channels to get the following equivalent loop characterizations: H1:LSC-DARM_ERR_DQ / H1:LSC-DARM1_IN1_DQ == "IN1/IN2" == G H1:LSC-DARM1_IN1_DQ / H1:LSC-CAL_LINE_SUM_DQ == "IN2/EXC" = 1/(1 + G) H1:LSC-DARM_ERR_DQ / H1:LSC-CAL_LINE_SUM_DQ == "IN1/EXC" = G/(1 + G) To the ECR process!