Kiwamu I, Jeff K, Darkhan T,
Overview
Today we looked at the calibration line coherence values calculated in the front end. We discovered that in the front-end model with the currently used averaging parameters the coherence value is updated once every 10 seconds (first 1.5 minutes in Fig. 1).
We propose modifying the averaging code to improve coherence calculation and avoid potential aliasing (see details).
Details
A front-end model that calculates coherence uses N data points taken every Scycles computational cycles to calculate cross-spectral density of the signals. Scycles is controlled by an EPICS record $(IFO):CAL-CS_TDEP_COH_STRIDE (or simply STRIDE): Scycles = FE_RATE * STRIDE. There are drawbacks associated with this approach:
-
New coherence value will appear every
STRIDE seconds;
-
Skipping data points will produce aliasing.
We can deal with the first problem listed above by reducing STRIDE. On Fig. 1 we show coherence values for N = 10 and STRIDE set to 10, 5, 1, 1/16 and again 1. Notice that this test was done when the IFO was not locked, thus we do not expect a coherence of ~1. When STRIDE is set to 1/16, we can see that the number of averages must be increased in order to include actual fluctuations in the signals (in the last 2.5 minutes N = 120).
Fig. 1
Several minutes later IFO locked (at t = -5 in Fig. 2) and the coherence became ~0.8. After we set the line amplitude to its nominal value we got coherence of ~1.
Fig. 2
Next, to avoid aliasing we should use all data points (equivalent to setting STRIDE = 1/FE_RATE in the current code) and increase N accordingly. Thus to integrate over 10 seconds and avoid aliasing the current code will require O(FE_RATE * 10) = O(160k) operations per cycle and a buffer for 160k values, which is unnecessary expensive.
A following minor modification of the averaging code can solve the issue described above. Instead of adding every Scycles'th data point into the averaging buffer, we could insert an average of Scycles values. E.g. buffer_and_average() can be modified as follows:
...
static int mini_sum = 0;
...
//Increment cycle count
mini_sum += data;
cycle_counter++;
if (cycle_counter >= cycles_between_data) {
buffer[current_pointer] = mini_sum / ((double) cycles_between_data);
current_pointer++;
cycle_counter = 0;
mini_sum = 0;
}
...
With this modification and N = 160, STRIDE = 1/16 (Scycles = 1024), the coherence will be calculated with 10 second integration and will require O(160) operations per cycle, and the coherence value will be updated every 1/16 of a second.
J. Kissel, S. Dwyer First attachment -- a screen cap the currently functional Bounce and Roll mode damping settings that work as Jenne describes above. One potential cause Shiela and I explored: we're using DARM_CTRL as our error signal for the bounce mode damping. We've always assumed that the DARM open loop gain is large enough that the open loop gain of the bounce mode damping loop is unaffected by changes in the DARM filter, D, or the DARM plant, or sensing function, C. Given recent, uncompensated issues with SRC cavity detuning cause optical spring changes in the plant, the DARM open loop gain near 10 [Hz] has been questionably low. We've been struggling with interferometric SRC alignment signal, and therefore leaving SRC angular control essentially off recently. This implies the SRC detuning can be changing from lock-stretch to lock-stretch, which means the DARM optical plant is changing from lock-stretch to lock-stretch. And if the overall DARM open loop gain is low enough, then the phase impacts of this change in optical plant will change the phase necessary to damp the bounce modes. The second attachment compares Kiwamu's DARM OLG TFs taken on 2016-09-16 vs 2016-09-21, and indeed, the open loop gain magnitude is only ~4 to 5 at 10 [Hz], and once can clearly see substantial phase differences between the two measurements. The third attachment shows the loop math to aide the following proof of how the two loops are coupled: C = DARM IFO plant, or sensing function D = DARM filter bank A = ISC L to TST L DARM super-actuator TF V = Bounce mode damping filter alpha = TOP V to TST L actuation function xi = coupling from TST L to DARM Delta L_{res} = Delta L_{V} + Delta L_{ctrl} = Delta L_{V} + A D C Delta L_{res} d_{ctrl} = D C Delta L_{res} --> Delta L_{res} = d_{ctrl} / (D C) d_{ctrl} / (D C) = Delta L_{V} + A D C d_{ctrl} / (D C) d_{ctrl} = D C Delta L_{V} + A D C d_{ctrl} G_{darm} = - A D C (1 + G_{darm}) d_{ctrl} = D C Delta L_{V} d_{ctrl} / Delta L_{V} = D C / (1 + G_{darm}) --> G_{V} = alpha xi beta D C / (1 + G_{darm}) --> IF G_{darm} << 1, then G_{V} ~ alpha xi beta D C and we have dependence on the changes in the optical plant of DARM. --> IF G_{darm} >> 1, then G_{V} ~ alpha xi beta D C / G = alpha xi beta / A and we have the scenario we have always assumed was happening. Now that Jenne's just restored old damping, this is less of a suspicion, but I wanted to write it down so that we keep this sort of loop inter-dependence in mind.