J. Kissel, J. Driggers, J. Betzwieser

on Mar 08 2022, Joe was at LHO, here, installing the new cross-correlation system (see LHO:62102). After this change, both the top level calibration model,
     h1calcs.mdl 
and the library part it uses, 
     CAL_CS_MASTER.mdl 
were fine.

On May 31 2022, Jenne installed a new IPC sender at the top level of the h1calcs.mdl (see post-install aLOG on June 03 LHO:63445). During this top-level only change, h1calcs.mdl compiled just fine.

On Jun 02 2022, I was debugging some missing channels from the PCAL system with Dripta & Francisco from my office, and accidentally ran an svn up command in the 
    /opt/rtcds/userapps/release/cal/common/models/
directory. This caused a conflict to appear between the local copy of the CAL_CS_MASTER.mdl. I was under the impression that day that I had chosen the "post-pone" command, to deal with the conflict later and thus leaving the local, functional version untouched. But, I didn't verify that this was the case, and promptly went back to what I was doing, already 3 layers deep into distraction land.

On Jun 07 2022, Jenne was trying to review her May 31st work in order to commit it to the svn repo, and found that the top level model was broken, because the bottom most, quite old, calibrated PRCL_CTRL, SRCL_CTRL, and MICH_CTRL IPC senders were no longer receiving their input from inside the CAL_CS_MASTER.mdl library part, because they no longer existed (see screenshot from Attachment 1). Trying to investigate further, we opened up the current local version of the CAL_CS_MASTER.mdl and found a very scary hot mess (see screenshot from Attachment #2).

Today, I've reconciled the issue:
    (1) "Simulink vs. how svn handles version conflict." Remember, a Matlab Simulink model is just a text file with a bunch of formatting such that it can be loaded into the Matlab Simulink GUI. Since svn was built for text-file-style code comparison, when you hit "postpone" means that it shoves in half-and-half of both conflicting versions, with lots of junk lines in the text file that are supposed to help show you where the conflict is. But, when you only look at this in the GUI, it manifests as a complete garbled mess. This is what we saw, and I now understand.

    (2) I spoke with Jenne and Joe to get a better understanding of the relatively simple changes that have been made since Mar 08 2022.

    (3) In parallel, and in addition, to (2) I went through all of the above svn committed history in terms of revisions of the CAL_CS_MASTER.mdl library part committed to the repo, and found that really the only problem was that
        (a) L1 doesn't have / use the output of the quite old PRCL_CTRL, SRCL_CTRL, and MICH_CTRL IPC paths, hence Joe's comment at the bottom of his LHO:62102,
            "L1 will need to pull and terminate 3 NOWHITEN outputs at the top level."
        (b) When he landed back at LLO, something got mixed up and instead of importing the work we did at H1, he copied over his CAL_CS_MASTER work by hand -- I think because there was an unrelated difference that L1 does *not* have a few channels (XARM, XARM_ERR, XARM_CTRL, YARM, YARM_ERR, YARM_CTRL) that had been stored in the frames for H1. Or something like that. 
        (c) Upon recommitting a change to re-include those channels, while we retained the new cross-correlation, we *didn't* retain the DAQ channel list.
        (d) When I requested the blanket svn up, that caused a conflict between Jenne's as-of-yet uncommitted May 31 2022 work, and Joe's commit of his work without the XARM / YARM channels. This is what broke the visual representation of the CAL_CS_MASTER model.
        (e) After talking with Joe and Jenne today, we all agree that we don't need this XARM and YARM calibrated channels stored in the frames, so we like that L1 change of removing those channels from the DAQ channel list from the frames.

    (4) All of this was relatively easy to reconcile once I understood (3):
        (a) Inside the top-most level CAL_CS_MASTER library block, re-install tags of LSC_MICH and LSC_SRCL that come in from the top level.
        (b) Send those tags both in to the SUM_MICH and SUM_SRCL blocks for calibration into displacement, but also into the XCORR block.
        (c) Re-install the tags as pick-offs of the calibrated control (CTRL) output of the SUM_MICH, SUM_PRCL, and SUM_SRCL blocks
        (d) Re-install the sending of those CTRL tags to output ports that go up-and-out to the top level.
        (e) Accept the L1 suggestion and removed (XARM, XARM_ERR, XARM_CTRL, YARM, YARM_ERR, YARM_CTRL) from the DAQ channel list.

After doing step (4), I then looked at h1calcs.mdl and confirmed that the top-level model required no change -- even to the point of not needing any graphical alignment -- a very good indicator that all has been restored well.

I've now compiled this version of h1calcs.mdl and it compiles successfully.

This reconciled version of CAL_CS_MASTER.mdl has now been committed to the svn as revision r23293.
Again, no changes were required for h1calcs.mdl I've taken no action there, and it remains committed at revision r23170, last changed by Jenne for the May 31 2022 activity described above.

Now that the model has been reconciled -- and making it just as functional as it was before Jun 02 2022 with no further changes -- we can proceed with WP 10553 / ECR E2200291 which addresses IIET Ticket 12638 by adding a 16 kHz version of the reference PCAL channel to the corner station.