jeffrey.kissel@LIGO.ORG - posted 17:26, Monday 30 August 2021 - last comment - 14:16, Tuesday 31 August 2021(59772)
Resolved Tidal and QUAD M0 Tracking Front-end Model Discrepancies Between Sites for ETMs, ITMs, and TMTSs
J. Kissel (after consult with S. Aston and J. Driggers) WP #9901 In O3, we implemented "R0 tracking" -- where the L/P/Y displacement of PUM (L2) stage, measured by that stage's OSEMs, of each QUAD is digitally, internally sent to a filter bank whos output controls the respective reaction chain top mass (R0) such that the main and reaction chain doesn't drift from each other and create scattered light fringes from the differential motion. In fact, L1 went a step further and sent the main chain TOP mass (M0) L displacement of the ETMs over to SHMEM IPC to the top mass of the respective TMTS. In the middle of the run circa Jan 2020, when H1 decided to try out some of this scattered light mitigation, Jenne and Rahul were selective about what they installed. To do so, they had to fracture the ETMs and ITMs top-level front-end models from using the common library, and created new H1-only-used "library" parts (see E2000011 / 51436 and the TMTS addition, ECR E2000186 / LLO:53224 which includes changes to all top-level models involved, /opt/rtcds/userapps/release/sus/h1/models/ h1susetmx.mdl h1sustmsx.mdl h1susetmy.mdl h1sustmsy.mdl h1susitmx.mdl h1susitmy.mdl which mostly was "easily" done by updating the common library parts, /opt/rtcds/userapps/release/sus/h1/models/ FOUROSEM_DAMPED_STAGE_MASTER_WITH_DAMP_MODE.mdl << Library part used for the PUM (L2) stage, which changes to grab and send up/out the L/P/Y OSEM displacement signals TMTS_MASTER.mdl << Changes to receive the M0 L OSEM displacement signals at the TOP (M1) stage for control QUAD_MASTER.mdl << Maps the signals from the PUM (L2) in to the R0 stage for damping, and brings the M0 L OSEM displacement up to the top QUAD_ITM_MASTER.mdl << Same as above -- and in fact the only difference between the library and what Jenne/Rahul implemented was the DAQ channel list, storing the R0 tracking channels SIXOSEM_F_STAGE_MASTER.mdl << Library part used for the Main Chain TOP (M0), which changes to grab and send up/out the M0 L OSEM displacement. In addition to all this, I've also made several changes to the ETM top level models that follow generalizing the tidal infrastructure, and in passing incorporate ECR E1900374, which serves L1's method of implementing tidal. I will say, the way tidal is done between sights is still *wildly* different. They are still quite independent in and through the QUAD_MASTER model, but I've now implemented a top-level change that both preserves the QUAD's role in the H1 method, but also completely allows for the L1 method, if we want to try it. More importantly for extensibility, now the *top* level of the model is capable of doing both methods at H1, so at least H1 can demonstrate if any one way is different / better than the other and or deciding if we can integrate the best of both methods. I'll put more details in the comments (because describing both methods request a diagram that spans *many* control models and library parts), but for now I'll just say that H1 can now deploy both methods. I've compiled all 6 of the above mentioned models against RCG 4.01, in prep for tomorrow's RCG upgrade. The plan / hope is that these upgrades will be installed once the RCG upgrade to 4.20 is complete. As far as I can tell, there are no incoming MEDM screen updates to support these upgrades. I don't understand this, but it may be that L1 hasn't committed their MEDM screens, explicitly *because* they are common and H1 hadn't incorporated these changes. But, we'll have to sort that out after L1 staff is confirmed safe after Hurricane Ida, and the site regains power. Also -- once the upgrade is installed, we'll need to reconfigure some of the settings of the new Tidal filters, such that we restore the same effective functionality as before (which, really, is just making sure the new L1-capable infrastructure at the top-level output to HEPI is configured as a pass-through for H1.)
Further (Graphical) Explanation of Tidal Changes Following up with more graphical details of changes made on the tidal path, and how I was able to combine the different methods of tidal paths through the ETMs. Attached are the two top level models for L1SUSETMX and H1SUSETMX *before* any changes were made. To "quickly" summarize the path for L1: (0) The CARM common mode board, filtering the IFO REFL PDs in analog, has the traditional "slow" and "fast" control outputs. (1) The "fast" control of the CARM common mode board is sent to the IMC common mode board, which also has "slow" and "fast" control outputs. (2) The "fast" control is both sent to the PSL's VCO driving the REF CAV frequency stabilization servo, as well as being digitized by an IO chassis down sampled to 16 kHz in the l1lsc.mdl. (3) Inside userapps/lsc/l1/l1lsc.mdl, this "IMC_F" (F for frequency at this point), is filtered (IMC-F), then fed in to c-code which may apply an offset and a gain, turning it into a "tidal" signal IMC_F_CTRL. (4) This IMC_F_CTRL signal, is then shipped to l1omc.mdl via shared memory (SHMEM) as "L1:LSC-OMC_IMC_F" (5) Inside userapps/omc/l1/l1omc.mdl, "L1:LSC-OMC_IMC_F" is multiplied by a simulink hard-coded gain of 1.0, then split into two RFM senders, one for each arm: "L1:OMC-MCF_TIDAL_SUSETMX" (or ETMY). (6) Now's where the top-level userapps/sus/l1/models/l1susetmx.mdl model, shown in 2021-08-30_l1susetmx_toplevel_TIDALFOCUS_labeled.png, comes in: here -- this IMC_F_CTRL, L1:LSC-OMC_IMC_F, now L1:OMC-MCF_TIDAL_SUSETMX, signal is piped in to the QUAD_MASTER library part, via the port TIDAL_IMCF_in, down in to the main chain top-mass M0 stage into a M0_TIDAL filter bank. (7) The output of M0_TIDAL is both added to the DARM L control that (only L1) applies to its top mass, and also, now, newly as of ECR E1900374, picked off and sent all the way back up and out to the top level. (8) Now back at the top level, again as of ECR E1900374, all of these possible tidal control (error?) signals are fed into a matrix, ETMX_TIDAL_MTRX, in the order: - L1:OMC-MCF_TIDAL_SUSETMX (direct IMC_F) - The UIM (L1) DARM CTRL LOCK L filterbank output - The TOP (M0) DARM CTRL LOCK L filterbank output - The TOP (M0) TIDAL CTRL L filterbank output (9) The single output of this matrix, is the longitudinal control nominally offloaded to the ISI and HEPI, fed through a final filter here in the SUS land, TIDAL_DOWNSAMPLING, and shipped out over a PCIE channel "L1:SUS-ETMX_TIDAL_X". (10) L1:SUS-ETMX_TIDAL_X is picked up by the userapps/hpi/l1/models/l1hpietmx.mdl, and only the *signal* output of the block is fed in to the ISC_L input of the hpi/common/models/hepitemplate.mdl model block, where it's fed through the ISCINF filterbank, then the LPY to XYRZHPZRXRYVP matrix, filtered *again* in an ISCMON block, then added into the output of the blends before going into the ISO block. (11) L1:SUS-ETMX_TIDAL_X is also picked up by the isi/l1/models/l1isietmx.mdl, but both outputs of the block are terminated at the top level. The "quick" summary for H1, prior to yesterday's upgrade: (1) - (4) Are / were / remain the same as L1, ending with IMC_F_CTRL channel send via PCIE on a "channel" called "H1:LSC-OMC_IMC_F." (5) Inside userapps/omc/h1/h1omc.mdl, "H1:LSC-OMC_IMC_F" is split and passed directly into two RFM senders, one for each arm: "H1:OMC-ALSEX_COMM_TIDAL" (or ALSEY). From here, the tidal control follows the topology T1400733: (6) H1:OMC-ALSEX_COMM_TIDAL gets picked up by userapps/als/h1/alsex.mdl (ey) model, and fed in to a top_names LSC block, which then fed into the "Comm_in" port of a broken link to an "X" ("Y") instantiation of the library part LSC_END_TIDAL in the upserapps/als/common/models/ALS_END.mdl model. (7) Comm_in (still IMC_F_CTRL with a gain and offset at this point) gets filtered by the COMM_ERR bank, then sent into the COMM_CTRL "integrator filter module" (described in section 6 of T1400733) popping out as a tag "COMMOUT." (8) In parallel, the requested longitudinal control from ALS -- informed by the "slow" control analog output of the ALS EX (EY) green laser's Common Mode board, filtered by the REFL_SLOW filterbank in the ALS block of the same userapps/als/h1/alsex.mdl model -- is sent in to the "Slow_in" port, filtered by ARM_ERR filterbank, and passed into an integrator filter model ARM_CTRL popping out as a tag "SLOWOUT." (9) SLOWOUT (REFL_SLOW ALS arm control) is added to COMMOUT (IMC_F_CTRL) and filtered a final time in the bank ARM_DRIVE before popping out up to the top level and sent out over PCIE IPC as "H1:ALS-X_ARM_SUSETMX_IPC" (ALS-Y_ARM_SUSETMY). (10) H1:ALS-X_ARM_SUSETMX_IPC is then received at the top level of userapps/sus/h1/models/h1susetmx.mdl as shown in 2021-08-30_h1susetmx_toplevel_before_TIDALFOCUS_labeled.png. From here, this sum of what was originally IMC_F_CTRL_OUT and REFL_SLOW_OUT is piped down into the UIM (L1) stage, via the "TIDAL_IMCF_PLUS_ISCEND_In" port, and then itself summed into the output of the DARM control UIM LOCK L stage directly, with a simple sum. (11) Post summing, this IMC_F_CTRL + ALS_REFL_SLOW + DARM LOCK UIM L is brought up to the top level, and piped directly into a PCIE IPC "H1:SUS-ETMX_TIDAL_ISCX_IPC" (ETMY_TIDAL_ISCY). (12) This gets picked up *back* in the userapps/als/h1/alsex.mdl (ey) model, back down in to the LSC_X (LSC_Y) block and gets another filterbank and integrator filter module treatment (TIDAL_ERR and TIDAL_CTRL, respectively). (13) The output of the integrator, a tag TIDALOUT, is then *multiplied by a hard-coded simulink constant of 1000, before getting shipped up/out with one more PCIE IPC "H1:LSC-X_TIDAL_HEPIETMX_IPC" (-Y_TIDAL_HEPIETMY). (14) H1:LSC-X_TIDAL_HEPIETMX_IPC is then picked up by hpi/h1/h1hpietmx.mdl (etmy), and fed in through HEPI as is done step 10 of L1's process. *phew* See? Like I said, "the way tidal is done between sights is still *wildly* different" as one can "clearly" "see" comparing steps at L1 (5) through (9) against H1 steps (5) through (13). And I can't trace out the frequency response of what's installed in any of these filter banks / integrators because at H1, the RCG is getting upgraded, and L1's power still remains down from Hurricane Ida. Anyways -- now, I finally can bring you up-to-date with that I've installed in this upgrade of userapps/sus/h1/models/h1susetmx.mdl and userapps/sus/h1/models/h1susetmy.mdl (see example, as shown in 2021-08-30_h1susetmx_toplevel_after_TIDALFOCUS_labeled.png). (1) Since I've svn updated the library parts QUAD_MASTER.mdl, and re-installed it in the top level of userapps/sus/h1/models/h1susetmx.mdl (etmy), that means we inherit ECR E1900374's change to bring the M0_TIDAL filter up / out to the top level. (The M0_TIDAL filter already existed, and had been available and a part of H1's infrastructure even though it never got used). This is the only change related to tidal in the library parts. Just for the record: - 2021-08-30_h1susetmx_QUAD_MASTER_TIDALFOCUS_labeled.png shows the first layer down inside QUAD_MASTER, - 2021-08-30_h1susetmx_QUAD_MASTER_M0_TIDALFOCUS_labeled.png shows the M0 stage (notably *not* a SIXOSEM_F_STAGE_MASTER.mdl), and - 2021-08-30_h1susetmx_QUAD_MASTER_L1_TIDALFOCUS_labeled.png shows the L1 stage (no change related to tidal). At the top level userapps/sus/h1/models/h1susetmx.mdl (etmy), again 2021-08-30_h1susetmx_toplevel_after_TIDALFOCUS_labeled.png, here's where I've created a scheme that allows for *both* observatories configuration. (2) On the left, I've now brought in the RFM receiver for H1:OMC-ALSEX_COMM_TIDAL, which remember is IMC_F_CTRL, equivalent to L1's L1:OMC-MCF_TIDAL_SUSETMX. As such, this IMC_F_CTRL is now fed directly in to the TIDAL_IMCF_In port to meet up with the M0_TIDAL bank as with L1 step (6). Of course, I've also kept the IMC_F_CTRL + REFL_SLOW_OUT "ALS-X_ARM_SUSETMX_IPC" channel, and fed that into the TIDAL_IMCF_PLUS_ISCEND_In as with H1 step (10). (3) Then, since all the signals are filtered / controlled in the same way at both sites now, I then take advantage of the new ETMX_TIDAL_MTRX matrix, feeding it inputs in the same order, - H1:OMC-ALSEX_COMM_TIDAL (direct IMC_F) - The UIM (L1) DARM CTRL LOCK L filterbank output - The TOP (M0) DARM CTRL LOCK L filterbank output - The TOP (M0) TIDAL CTRL L filterbank output And, rather than messy direct wire connections, I've employed tags with the following respective names: - IMCFCTRL_2_QUAD - L1LOCKTIDAL_OUT_2_HPI - M0LOCKONLY_OUT_2_HPI - M0TIDALONLY_OUT_2_HPI (4) Then, as with L1, I've hooked up the single output of the matrix to a (for H1 new) filterbank ETMX_TIDAL_DOWNSAMPLING, and then output of *that* goes into the pre-existing connection to HEPI (without changing it's "channel" name), H1:SUS-ETMX_TIDAL_ISCX_IPC. So, hopefully, when all models are back up and running, H1 should be able to replicate it's former scheme as described above by - entering a 1.0 in the second-row (column?) of the 4x1 ETMX_TIDAL_MTRX - making sure the ETMX_TIDAL_DOWNSAMPLING filterbank is a "pass-through" with its inputs and outputs ON, with a gain of 1.0, and filter modules all OFF and/or empty. Again, with both IFO's infrastructure in place, H1 can try both, to see if there's a benefit to using any part of the L1's methods or some other mixture of it all. Smells like a graduate student's thesis worth of work though... But at least now the guts of the ETM QUAD models are now the same again, which makes them extensible for all the *other* pending ECRs that we've built up and put off until "sometime in between O3 and O4" -- aka now.Further Explanation of Main Chain Tracking via PUM (L2) OSEMs Here, I show the source and sink of the two paths that implement some sort of tracking of the QUAD's main chain with either the R0 reaction chain (informed by the main-chain PUM [L2] OSEM displacement) and the TMTS M1 chain tracking of the main chain Top Mass M0 L (informed by the main-chain TOP [M0] OSEM displacement). Going in order of attachments: (1) The source of the reaction chain tracking the main chain -- the new(ish) outputs of the L2_WIT bank which house the calibrated PUM (L2) OSEMs in L, P, and Y and now get sent up to the QUAD_MASTER level, (2) The L2 OSEMs coming out of the L2 block at the QUAD_MASTER level (3) The L2 OSEMs as they go in to the R0 block at the QUAD_MASTER level (4) Inside the R0 stage, where the L2DAMP filters filter the displacement and turn it into a tracking force, and add it in to the L, P, Y, and R DOFS of the R0 actuators. (5) The source of the TMTS tracking of the main chain, inside the QUAD_MASTER M0 stage -- the new pickoff of the EUL2OSEM matrix which grabs the calibrated M0 L OSEM displacement. (6) The M0 L OSEM signal coming up and out of the M0 block at the QUAD_MASTER level (7) The M0 L OSEM signal coming up and out of the QUAD_MASTER block at the top level, and then the map to the new IPC "channel", called H1:SUSETMX_2_SUSTMSX_M0_L_SHMEM (8) The M0 L OSEM signal imported in the top level of the h1sustmsx (tmsy) model, and mapped over to the TMTS_MASTER block, (9) The M0 L OSEM signal as is drills down in to the M1 block at the TMTS_MASTER level, and finally, (10) The M0 L OSEM signal as it lands in the FF_L bank of the M1 stage of the TMTS_MASTER, and summed in with the other ISC longitudinal control. For the record, the h1susitmx.mdl and h1susitmy.mdl top-level models, which use the QUAD_ITM_MASTER part only has the L2 to R0 tracking, since there's corresponding TMS-like suspension to track them. And again, I've not yet received any MEDM screen updates for these, so we'll have to check back in with LLO once they get power back up.