After lots more digging and checking of calculations, I discovered that the problem with kappa_UIM from yesterday (see alog 48129) was just that the EPICS record for the calculation of that kappa wasn't actually written to the front end system properly. The summary is that with the fix of the time slip of the replica oscillators, and pushing the updated EPICS values, all of our kappas should come out sensible starting with our next lock. If needed, one could re-create our kappa_UIM for yesterday's locks using the correct epics value from the .txt file that is created when the write was attempted.
In the attached screenshot you can see the real and imaginary parts of this epics record, and several steps when we've been updating the calibration epics records over the last few weeks. However, you can see that when we pushed things again yesterday, the real part of this one changed, but the matching imaginary part did not see a matching step change.
I have now added a checking functionality to the writeEPICS function that is used to actually set these epics values in the front end. After it has tried to do the epics write, it sleeps for 1 second, then reads each epics value and compares that to the value it wanted to write. If the ratio of those values is not equal to 1, it will print an error to the terminal.
If I use the correct value that should have been in there yesterday and hand-calculate kappa_UIM, I get a value of 1.03, which is a perfectly sensible value (especially since the other 2 stages have kappas around 1.05). If the GDS pipeline reads the reference values from the .txt file that is saved, they would have gotten the correct value, and should have calculated the correct values for the kappas. However if GDS reads from the front end epics values, they would have picked up the wrong value and would also have seen poor calculated values for kappa_UIM at LHO.
As for this few percent discrepancy, one thing we've been wondering is why the actuator strengths are different from the reference values (i.e., why are the kappas not all unity?). Earlier today I calculated the kappa values for the actuator assuming that the sensing function and open loop gain are time-independent (not a valid assumption, but was part of finding the epics write error). By making this assumption, I only need to use the measured data from the suspension demodulation line, and don't use the measured data from the Pcal demodulation line. When doing this, I calculate kappa values of 1.005, 1.002, and 0.98 for tst, pum, and uim, respectively. So, that must mean that some of the extra discrepancy from the reference time (reported values of 1.05 rather than 1.005, for example with the test mass) must be coming in from the pcal demodulation measurement.
There are 2 assumptions that we make when calculating these kappa values: That the actuation function of the photon calibrator does not change with time, and that the slope of the response function also does not change with time. This second assumption probably is less important if the pcal and sus lines are close in frequency (as they are for LHO's test mass, and as they are for all of LLO's lines), but our PUM and UIM suspension lines are ~20 Hz lower than the Pcal line. We should check both of these assumptions to see how they may have changed since the reference time.
