You can follow along in T1500377. Or said more correctly, you'll *need* this document open to help follow along.

We have found actuation strength of the QUAD is varying slowly as a function of time, and we're quite confident that slow, time-dependent, charge on the test mass is changing the test mass actuation strength alone (relative to the upper stages of the quad). As such, and before the PUM / TST crossover is in the gravitational wave band, we need to be able to independently track the ESD strength as a function of time, with respect to the overall actuation strength. We have explored several different methods for potentially compensating the variation that we see (see T1500422 for discussion), and the method that results in the least amount of systematic error in the correction needs new front-end infrastructure. This update is to install said infrastructure.

Some of the details:
(1) New channels stored into science frames for storing each stage of actuation independently. These new channels are stored at 4096 [Hz].
$(IFO):CAL-DELTAL_CTRL_TST_DQ
$(IFO):CAL-DELTAL_CTRL_PUM_DQ
$(IFO):CAL-DELTAL_CTRL_UIM_DQ
Just like the $(IFO):CAL-DELTAL_CTRL_DQ channel, these channels will be whitened to avoid single-precision errors. Note that, for now, I've installed the same whitening filters, i.e.
      zpk([1;1;1],[500;500;500],1,"n)
but we'll need to do the same kind of study that Shivaraj did to make sure they're not limited by precision errors.

Also, in doing so, I've *reduced* the frame rate for $(IFO):CAL-DELTAL_CTRL_DQ also to 4096 [Hz].

Note, for offline analysis, this means one now needs to account for the DAQ down sampling filter between 16 [kHz] and 4 [kHz], which is detailed as the "x4" filter in T1400719.

(2) There are LOTS of new EPICs records to support the calculations defined in Eqs. 9, 11, 12, and 15 of T1500377. While we thought that the GDS calibration pipeline would be able to simply absorb EPICs records that housed the model parameter values (e.g. A_{0}^{tst}, A_{0}^{pu}, C_{0}, G_{0}) at each calibration line frequency, Maddie tested the new code, and found memory issues with all of the calucaltions that were necessary.

As such, now, we not only store the "raw" parameters values, but from those values, the contant / reference / "_{0}" terms in the above mentioned equations are calculated in the front-end. It's a mess of complex analysis, but the new EPICs records, and there associated relation to the above equations are mentioned below. 
for f_{tst} @ ~ 35 [Hz]
    User entered EPICs records:
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_OLG_$(REAL,IMAG)             G_{0}                @ f_{tst}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_D_$(REAL,IMAG)               D                    @ f_{tst}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_C_$(REAL,IMAG)               C_{0}                @ f_{tst}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_C_NOCAVPOLE_$(REAL,IMAG)     C_{res}              @ f_{tst}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_A_TST_$(REAL,IMAG)           A_{0}^{tst}          @ f_{tst}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_A_PUM_$(REAL,IMAG)           A_{0}^{pum}          @ f_{tst}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_A_UIM_$(REAL,IMAG)           A_{0}^{uim}          @ f_{tst}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_A_TOP_$(REAL,IMAG)           A_{0}^{top}          @ f_{tst}

    Calcalulated records:
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_A_TST_MODSQ                  |A_{0}^{tst}|^2      @ f_{tst}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_A_TST_NEGINV_$(REAL,IMAG)    - (1 / A_{0}^{tst})  @ f_{tst}    for Eq. 9
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_A_USUM_$(REAL,IMAG)           A_{0}^{pu}          @ f_{tst}    = A_{0}^{top} + A_{0}^{uim} + A_{0}^{pum}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_A_USUM_MODSQ                 |A_{0}^{pu}|^2       @ f_{tst}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_A_USUM_INV_$(REAL,IMAG)      (1 /  A_{0}^{pu})    @ f_{tst}         
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_C_MODSQ                      |C_{0}|^2            @ f_{tst}
    $(IFO):CAL-CS_TDEP_ESD_LINE1_REF_INVCLG_$(REAL,IMAG)          (1 + G_{0}) / C_{0}  @ f_{tst}    for Eq. 9

for f_{pcal} @ ~ 35 [Hz] (which are currently running on PCALY)
    User entered EPICs records:
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_OLG_$(REAL,IMAG)           G_{0}                @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_D_$(REAL,IMAG)             D                    @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_C_$(REAL,IMAG)             C_{0}                @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_C_NOCAVPOLE_$(REAL,IMAG)   C_{res}              @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_A_TST_$(REAL,IMAG)         A_{0}^{tst}          @ f_{pcal}    
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_A_PUM_$(REAL,IMAG)         A_{0}^{pum}          @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_A_UIM_$(REAL,IMAG)         A_{0}^{uim}          @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_A_TOP_$(REAL,IMAG)         A_{0}^{top}          @ f_{pcal}
    
    Calcalulated records:
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_A_USUM_$(REAL,IMAG)        A_{0}^{pu}           @ f_{pcal}    = A_{0}^{top} + A_{0}^{uim} + A_{0}^{pum}
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_G_MODSQ                    |G_{0}|^{2}          @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_G_TWICEREAL                2 Re{G_{0}}          @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_ONEPLUSG_MODSQ             |1+G_{0}|^2          @ f_{pcal}    
    $(IFO):CAL-CS_TDEP_PCALY_LINE1_REF_CLG0_$(REAL,IMAG)          C_{0} / (1 + G_{0})  @ f_{pcal}    for Eq. 9 and Eq. 11

for f_{ctrl} @ ~ 35 [Hz]
    User entered EPICs records:
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_OLG_$(REAL,IMAG)            G_{0}                @ f_{ctrl}
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_D_$(REAL,IMAG)              D                    @ f_{ctrl}
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_C_$(REAL,IMAG)              C_{0}                @ f_{ctrl}
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_C_NOCAVPOLE_$(REAL,IMAG)    C_{res}              @ f_{ctrl}
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_A_TST_$(REAL,IMAG)          A_{0}^{tst}          @ f_{ctrl}    
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_A_PUM_$(REAL,IMAG)          A_{0}^{pum}          @ f_{ctrl}    
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_A_UIM_$(REAL,IMAG)          A_{0}^{uim}          @ f_{ctrl}    
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_A_TOP_$(REAL,IMAG)          A_{0}^{top}          @ f_{ctrl}    

    Calcalulated records:
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_A_TST_MODSQ                 |A_{0}^{tst}|^2      @ f_{ctrl}
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_A_TST_NEGINV_$(REAL,IMAG)   - (1 / A_{0})        @ f_{ctrl}
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_A_USUM_$(REAL,IMAG,MODSQ)   A_{0}^{pu}           @ f_{ctrl}  = A_{0}^{top} + A_{0}^{uim} + A_{0}^{pum}
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_A_USUM_INV_$(REAL,IMAG)     1 / A_{0}            @ f_{ctrl}  This is the constant part of Eq. 12
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_C_MODSQ                     |C_{0}|^{2}          @ f_{ctrl}
    $(IFO):CAL-CS_TDEP_DARM_LINE1_REF_INVCLG_$(REAL,IMAG)         (1 + G_{0}) / C_{0}  @ f_{ctrl}  

For Eq 9,
    Calculated Record:
    $(IFO):CAL-CS_TDEP_REF_INVA_CLGRATIO_TST_$(REAL,IMAG)         - (1 / A_{0}^{tst})|f_tst *  C_{0} / (1 + G_{0})|f_pcal * (1 + G_{0}) / C_{0}|f_tst
                                                                  This is the constant part of Eq. 9
For Eq 11,
    Calculated Record:
    $(IFO):CAL-CS_TDEP_REF_CLGRATIO_CTRL_$(REAL,IMAG)             C_{0} / (1 + G_{0})|f_pcal * (1 + G_{0}) / C_{0} |f_ctrl
                                                                  This is the constant part of Eq. 11

for f_{pcal2} @ ~330 [Hz] (which are currently running on PCALY)
    User entered EPICs records:
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_OLG_$(REAL,IMAG)           G_{0}                @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_D_$(REAL,IMAG)             D                    @ f_{pcal}     For Eq. 15 
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_C_$(REAL,IMAG)             C_{0}                @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_C_NOCAVPOLE_$(REAL,IMAG)   C_{res}              @ f_{pcal}     For Eq. 15 
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_A_TST_$(REAL,IMAG)         A_{0}^{tst}          @ f_{pcal}     For Eq. 15 
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_A_PUM_$(REAL,IMAG)         A_{0}^{pum}          @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_A_UIM_$(REAL,IMAG)         A_{0}^{uim}          @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_A_TOP_$(REAL,IMAG)         A_{0}^{top}          @ f_{pcal}
    
    Calcalulated records:
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_A_USUM_$(REAL,IMAG)        A_{0}^{pu}           @ f_{pcal}    = A_{0}^{top} + A_{0}^{uim} + A_{0}^{pum},  For Eq. 15 
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_G_MODSQ                    |G_{0}|^{2}          @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_G_TWICEREAL                2 Re{G_{0}}          @ f_{pcal}
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_ONEPLUSG_MODSQ             |1+G_{0}|^2          @ f_{pcal}    
    $(IFO):CAL-CS_TDEP_PCALY_LINE2_REF_CLG0_$(REAL,IMAG)          C_{0} / (1 + G_{0})  @ f_{pcal}    for Eq. 9 and Eq. 11


I've not yet installed all of the above user defined EPICs records, bare with us while we get the MEDM infrastructure updated, and then we'll fill in the values needed. Note, the only difference from what I installed on Friday (see LHO aLOG 20291), is what was quoted for the "ESD_LINE" there is now called "DARM_LINE," and I need to install new values for the *actual* "ESD_LINE".

Also, I've committed all model changes to the userapps svn repo, and I have captured all of the new new settings (thus far) in the SDF system, initializing new channels, and removing old channels.

JeffK, Darkhan

MEDM screens are undergoing changes to repliate recent front-end model changes (see attached screenshots). The screens are currently in the state at which we can input parameters needed for calibration: C_0, D_0, A_0^{tst}, A_0^{pum}, A_0^{uim}, A_0^{top}, line frequency and amplitude.

Current status of the screens have been committed to SVN (@ r11235). The modification process will continue tomorrow.

We also found a bug in front-end model that need to be fixed (using Im instead of Re part of a quantity, see attachment).

There were some typos in the SEI_STATE test that were preventing the node from restarting.

I destroyed and created the node (probably unnecessary), and then started it.

Also, SYS_DIAG_tests.py had not been checked in to the SVN for quite some time.

Thanks, Evan.  It was definitely unecessary to destroy/recreate the node, but it doesn't hurt anything.  Probably all you needed to do was just reload.

It seems the text file of glitch times didn't make it into the attachments, would you mind trying to attach it again?

Ops! Here's the file with the glitch times.

Gabriele,

Did you check which of Robert's glitches caused any ADC/DAC adjurations? The glitch shape will start changing significantly once the amplitude is big enough to start saturations. 

PS: The ODC master channel has a bit that will toggle to red (0) is any of the subsystems reports a saturation (with 16k resolution) - it might be exactly what you need in this case.

Stefan, I checked for some ADC and DAC overflows during this data segment. The OMC DCPDs ADCs overflowed during several of these. There were still some with SNRs of 10,000 that didn't overflow like this. The segments are pasted below. They're a bit conservative because I'm using a 16 Hz channel without great timing. There were no ADC overflows in POP_A, and no DAC overflows in the L2 or L3 of the ETMs. I didn't check anything else. This is not quite the same as what the ODC does, which is a little more stringent. I'm just looking for changes in the FEC OVERFLOW_ACC channels.

    1123084682.4375 1123084682.5625
    1123084957.3750 1123084957.5000
    1123086187.3750 1123086187.5000
    1123086446.8125 1123086447.3750
    1123088113.0625 1123088113.1875
    1123088757.4375 1123088757.6250
    1123088787.1875 1123088787.3125
    1123088832.3125 1123088832.4375
    1123089252.6250 1123089252.7500
    1123089497.2500 1123089497.3750

This is very interesting. Can you sort and plot the raw time series of the larger glitches according to X vs. Y arm? (The attack should be unipolar and of opposite sign for the two arms.)  

It will also be interesting to note if there is a FWHM dependence on axial position. 

I've attached a list of all Omicron triggers in the lock with SNRs above 100. The columns are the GPS time, peak frequency, and SNR. Rows marked with an X have an ADC overflow in the OMC DCPDs, so they may not be as useful for determining the shape of the glitches.

Several of the glitches have very messy shapes in OMC DCPD. There's a few in the Y arm that have a fairly unambiguous single upward spike, for instance 1123084687.570​. The whitened timeseries is attached. The shape is a triangle with a base of roughly 1 or 2 milliseconds. I haven't found anything in the X arm yet with a simple unambiguous shape, but I haven't checked everything.

While we're at it, the I copied the seismic FOM into userapps/isc/h1/scripts/Seismic_FOM_split.xml and checked it into the SVN, since the original directory (/ligo/home/controls/FOMs/) is not version controlled.

Added to the Wiki.

Prior to this change,  photodiodes (TX and Rx PD) calibartion coeffcient were reported in metres/Volt *(1/f^2). Now with the suspension model in place, we have calibrated the photodiodes in terms of Force Coefficient (N/V). The filter banks, as shown in the attachement above, now reflect these new N/V calibration factors. Appropriate changes have been made to the DCC document  (T1500252) as well.

This is an additional note about the quack function -- when I was using quack, I had a difficulty in quacking an state-space suspension model into a foton filter. See the detail below.

In matlab, I had been using something like:

It wasn't really clear from this run where the minimum in frequency coupling was (maybe because of the 5 W blast at the start), so I went back to 0.23 W of heating and let the frequency coupling reach a steady state (by driving the same line as before, this time with 100 ct amplitude). Around 2015-08-08 10:18:30 I kicked the TCS power to 0.53 W and started the datataking again.

Once the frequency coupling reached a steady state again, I made a guess for what TCS power we need to minimize the coupling. At 12:43:30 I changed the TCS power to 0.43 W.

I have revered the ALS/CARM cabling to its nominal configuration.

Preliminary analysis from this second run suggests that, of the TCS powers that we probed, our current TCS power is the best in terms of intensity noise coupling.

The attached plot shows the transfer function which takes ISS outer loop PD #1 (in counts) to DCPD A (in milliamps). The coloring of the traces just follows the sequence in which they were taken. Black was taken at 0.23 W of TCS power, and the lightest gray was taken at 0.53 W of TCS power.

The measurements and the plotting script are in evan.hall/Public/Templates/LSC/CARM/FrequencyCouplingAuto/Run2.

Below are plots showing the effect of differnet whitening filters including the one that was being used unitl now (5 x 1Hz zeros and 5 x 100 hz poles). These plots are the basis for new filters for DeltaL residual and DeltaL control. In those plots blue curve corresponds to actual data and other colors represent different whitening filters applied to the data.

With the new filters installed we looked at the DeltaL residual and DeltaL control during a recent lock. Below we have attached the spectrum of both along with DeltaL external as a reference (which is still being used with old 5 x 1 Hz zeros and 5 x 100 Hz pole filter). In the plot the channels are dewhitened with the corresponding filters.

When Stefan and I hooked the injection back up, we found that the digital enable/disable switches weren't doing their jobs. Toggling the outputs of H1:PSL-ISS_TRANSFER2_INJ and H1:PSL-ISS_TRANSFER1_INJ had no effect on the appearance of the noise in DARM.