I made a comparison between TxPD and RxPD at calibartion line frequencies beginning Dec 1 until yesterday. TxPD has not changed over time but RxPD changed after the break.

Here's a graphical version of what Sheila wrote, showing the time on Oct 11 when the 1083 Hz glitches started. The dither amplitude was reduced at 3:20 UTC, but the servo gain was increased to compensate. There are no 1083 Hz glitches at this time. Severe RF45 noise starts an hour later and lasts until the end of the lock. The 1083 Hz glitches are evident from the beginning of the next lock, and persist in every lock until the recent fix.

The dither amplitude stayed low in the second lock, but the servo gain was reset back to its low value. Apparently, both need to be low to produce the glitches.

Keita tells me that people are concerned about making this change because of the increased noise below 25 Hz in the screenshot attached to the original post.  We did not run the A2L decoupling durring this lock strech, and it was not well tuned.  The shape of the HARD loop cut off at 25Hz is visible in the spectrum, which is one way of identifying bad ASC noise.  The high coherence between CHARD P and DARM at this time is another way of seeing that this is angular noise (attachment). 

So I think that this is unrelated to the OMC gain change and not really a problem. 

1080Hz removal OMC gain/line conditions, does it make more low frequency noise?
Josh, Andy, TJ, Beverly

Conclusion: For two on/off times each for the two OMC gain tests (total 8 times) it looks like the high gain / low line configuration that takes away 1080 Hz (and also takes away some bumps around 6280Hz) coincides with a bit more noise below 25Hz.

Request: We hope this connection with noise below 25Hz is chance (It might have just been drift and we chose times unluckily) and we would like debunk/confirm it. We could do that with a couple cycles of on/off, (e.g. 5 minutes each, with the current configuration vs high gain / low dither configuration). 

See the attached PDF. The pages are: 

• 2,3: January 9th test configuration from Sheila's page: "We ran with the servo gain set to 24 (to give us the nominal 6Hz ugf) and the lowered dither line amplitude from 19:21 UTC to 19:51 UTC Jan 9th." Red/Orange are the test time with low line / high gain, and no 1080Hz
• 4,5: Similar experiment from October. Blue/green are the test time with low line / high gain, and no 1080Hz.

Also: There is no coherence above 10Hz between STRAIN and OMC LSC SERVO/I for any of these test times. So coupling must be non-linear. 
Also: When the 1080Hz bumps disappear we also see a bump around 6280Hz disappear (attached image, sorry no x-axis label but its 6280Hz)

Our post crossed with Sheila's. If possible, we'd still like to see a quick on/off test with the A2L tuned. Could we have five minutes with the gain high and then ramp it down? Maybe with one repeat. Since this is a non-linear effect, we'd like to make sure there's no funny coupling with the CHARD noise. We're not too worried by excess noise below 25 Hz now, but it might be important when we're able to push lower.

While LLO was down I attempted to do a test by increasing the OMC length gain while in lock, which unlocked the IFO.  So on/off tests aren't possible.  Edit:  I broke the lock by changing the gain after the integrator (which had been OK when not on DC readout), we can change the gain upstream instead without unlocking.  

For now I put the new gain into the guardian so the next lock will be with the increased gain, and hopefully see that the low frequency noise is fine. 

Now we have relocked, Patrick ran a2l, and Jeff, Evan, Krishna and I did an on off test by ramping H1:OMC-LSC_I_GAIN:

• high gain for about 15 minutes before 23:55 UTC Jan 12th
• low gain from 25:56:20 Jan 12th to 0:03:21 UTC Jan 13th
• high gain from 0:04 UTC to 0:13:22 UTC
• back to low gain

The attached screen shot using the same color scheme as in the presentation above shows that there is not a difference at low frequency between high gain and low gain.  

We are back in observing in the low gain configuration, but the gain is set in an unusual way (and accepted in SDF so that we can go to obsevering). Keita would like us to hear confirmation from detchar before making this permanent. 

Thank you Sheila, this looks really good. No change at low frequency. 1080Hz gone. The 6280Hz just varies on its own timescale. From our end we're happy with the configuration change since it only does good. Sorry for the red herring about low frequencies. 

Installed new cable for IP5, after removing old cables/connectors for previous version of controller.

Note: New controller is using the connection to pump A of old system, same calibration as other similar GAMMA (LPC +) controllers.

Trends are back for now, but maintenance is ongoing.

current weather situation:

4 Jan 2017 plots are here:

14 Dec 2016 plots are here:

1 Dec 2016 plots are here:

good catch cheryl, when you see fun cps signals, can you check the inertial sensor signals (HEPI and ISI) also, to make sure that it is motion and if so of what?

thanks

Looks too that ITMX has some broadband elevated noise on Stage1 V1 and Stage2 H1.  We may need to cycle board power/seating if it persists.

J. Kissel

Documentation of how the above 2017-01-03 parameters were fit from measurement is in LHO aLOG 33090. 

What is not included in LHO aLOG 33090 is how to convert the [N/ct] listed in the above table into [N/A] or [N/V^2] which is how each actuator stage is entered into the configuration file for the DARM loop model. 

Since this is more relevant to updating the configuration files and DARM loop model described in this above aLOG 33004 (as opposed to processing measurements to obtain the fit values), I describe the process here for the 2017-01-03 parameter filer set:

- Copy over 2016-11-12 configuration file, 
     ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/params/
         H1params.conf   (r4042, lc: 3957) 
to the new reference model location in the O2 directory,
     ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/params/
         H1params.conf   (I committed the first version r4044 after I copied over the file and 
                          changed the DRIVEALIGN filters to account for the new L2/L3 crossover 
                          filter configuration) 

- Copy the script that converts the new [N/ct] to new [N/A] or [N/V^2] using the model as it stands with the former values in place (the purpose is to grab the DAC gain, the AI gain, and the coil driver transconductance or the ESD driver gain which remain fixed in time),
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Scripts/FullIFOActuatorTFs/
        getActValuesForParamsFile.m (r3827, lc: r3827) 
over to the new reference model location in the O2 directory, renamed for the new reference time,
    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/Scripts/FullIFOActuatorTFs/
        getActValuesForParamsFile_20170103.m 
In this script, you have to manually enter in the new [N/ct] values from the MCMC fitting code (which is why you need to make a copy of the function, instead of it being generic to runs and reference times). The script uses the model as it stands with the former values in place, computes the former [N/ct] value, takes the ratio with the new [N/ct] value, and then multiplies the former [N/A] or [N/V^2] value by that ratio to obtain new [N/A] or [N/V^2] values.

- Copy the output of the conversion script into the configuration file, and commit (which is the current rev)
    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/params/
         H1params.conf (r4087, lc: r4087)

I agree with you that this process is clunky. We will work to streamline the update of the parameter file in the future.

The fit parameters for the sensing function are just directly copied into the configuration file from the nlinfit results as listed above. Well, OK, you have to invert 1/Q, and enter in the Q, but that's straight-forward. Again to streamline the process, we may consider changing the DARM loop model to accept 1/Q instead of Q such that we reduce the number of steps in creating a new model.

------------------------

Also of note when creating a new reference model: 
the configuration file that is more meant to compensate non-reference measurements for time-dependence,
    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/params/2017-01-03/
         H1params_2017-01-03.conf     (r4054, lc: r4044)
must be updated to have all kappa values to be unity, and the darm coupled cavity pole must match the reference time, because DARMmodel.m uses these values to overwrite the default params values from 

    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/params/
         H1params.conf                (r4087, lc: r4087)

------------------------

J. Kissel

I repost the table, without typos in the (new analysis) columns in actuation:
                                                                           MAP     (68% C.I.)  MAP       (68% C.I.)

 Date                                                  2016-11-12          2016-11-12          2017-01-03
                                                   (former analysis)       (new analysis)       (new analysis)
 Optical Gain                K_C         [ct/m]        1.15e6              1.164e6 (0.09%)     1.086e6   (0.07%)
 Couple Cav. Pole Freq.      f_c         [Hz]          346.7               346.7   (0.4%)      360.4     (0.4%)
 Residual Sensing Delay      tau_C       [us]          2.3                 2.3     (50%)       0.65      (200%)
 SRC Detuning Spring Freq.   f_s         [Hz]          7.4                 7.4     (1.1%)      6.9       (0.5%)
 Inv. Spring Qual. Factor    1/Q_s       [ ]           0.05                0.05    (8.7%)      0.03      (12%)

 UIM/L1 Actuation Strength   K_UIM       [N/ct]        8.164e-8            8.104e-8  (0.2%)    8.091e-8  (0.2%)
 PUM/L2 Actuation Strength   K_PUM       [N/ct]        6.841e-10           6.773e-10 (0.03%)   6.768e-10 (0.02%)
 UIM/L3 Actuation Strength   K_TST       [N/ct]        4.389e-12           4.347e-12 (0.04%)   4.357e-12 (0.02%)
Note that (new analysis) sensing function parameter fits are MCMC results, not nlinfit results, which are what is used for updating the DARM loop model. However, MCMC results are consistent with the uncertainty of the nlinfit results, so we consider the results interchangeable. Rather, we use the MCMC results for response function uncertainty, where we use nlinfit results to update the DARM loop model -- we should and will use MCMC results for updating the DARM loop model in the future such that we have a self-consistent pipeline from reference measurement analysis to response function uncertainty estimation. 

I attach an update to the sensing function plot for each reference data set which improves the MCMC fit results vs. measurement plot to show residuals and parameter values with uncertainties, such that it can now be directly compared to the same plot produced by the nlinfit code.

As promised, a complete description of how these results were generated:

            :::: How I generated 2016-11-12 (new analysis) ::::
---------
- Updated measurement base-level processing scripts and DARM model, which fixes the AA/AI filter gain analysis bug identified in LHO aLOG 32907),
${CalSVN}/aligocalibration/trunk/Runs/O2/DARMmodel/src/
    DARMmodel.m        (r4093, lc: r3511)
    computeActuation.m (r4093, lc: r4003)
    computeSensing.m   (r4093, lc: r4025)

---------
- Generated a new fit for actuation parameters using MCMC analysis:
pre-process actuation measurements using
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Scripts/FullIFOActuatorTFs/
        actuatorCoefficients_Npct.m (r4065, lc: r4065)
which spits out text files of the actuation function for each stage with portions known to negligible uncertainty removed (e.g. frequency dependence of SUS dynamics, AI filter shape, etc.),
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Measurements/FullIFOActuatorTFs/2016-11-12/
        2016-11-12_H1SUSETMY_L1_actuationStrength_Npct.txt (r4111, lc: r4111)
        2016-11-12_H1SUSETMY_L2_actuationStrength_Npct.txt (r4111, lc: r4111)
        2016-11-12_H1SUSETMY_L3_actuationStrength_Npct.txt (r4111, lc: r4111)
which are then loaded into
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Scripts/FullIFOActuatorTFs/
        fitActCoefs_Npct.m (r3977, lc: r3977)
where each stage is fit independently, so you have to switch the variable "stage" between 'L1', 'L2', or 'L3'.
Running on ONLY the 2016-11-12 reference measurement time (instead of two days of measurements, as Darkhan originally did)
   dateListRef = {'2016-11-12'};
   gpsListRef = [1162969230];

yields the above results. 

There's a typo in the above table: the new analysis of L3/TST actuator coefficient is 4.347e-12 [N/ct], as shown in the above attachement https://alog.ligo-wa.caltech.edu/aLOG/uploads/32989_20170105090730_2016-11-12_H1_SUSETMY_ACT_COEF_REF_fitCorner.pdf

---------
- Generated a new fit for the sensing function parameters using nlinfit and MCMC analysis:
pre-process sensing function measurements with
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Scripts/PCAL/
        fitDataToC_20161116.m (r4040, lc: r4028)
which produces an nlinfit list of parameters on the IFO optical plant (i.e. with stuff known to negligible uncertainty removed, like frequency dependence of OMC DCPD high frequency electronics), and also spits out a text file of that IFO optical plant for MCMC fitting,
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Results/Sensing
        2016-11-12_H1_meas_sensingTF_withoutDCPDTFs_ctpm.txt (r4079, lc: 4072)
This is loaded into 
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Scripts/PCAL/
        fitCTF_mcmc.m (r4112, lc: r4112)
to produce the MCMC maximum a posteriori (MAP).

Even though all MCMC results are repeated using python code, the sensing function parameter's posterior distribution from the above matlab MCMC code are exported to text:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Results/Sensing/
2016-11-12_H1_sensing_burn80p_nWalk100_output.txt      (r4079, lc: r4077)
2016-11-12_H1_sensing_burn80p_nWalk100_posteriors.txt  (r4079, lc: r4079)
Actuator parameter posterior distributions are not yet exported from the matlab code.

            :::: How I generated 2017-01-03 (new analysis) ::::
--------
- Used the updated versions of same the base-level processing scripts described above for 2016-11-12 (new analysis)

--------
- Generated a fit for actuation parameters using MCMC analysis:
Above mentioned actuation function pre-processing script copied from ER10 directory to O2 directory (prior to making aesthetic changes to the script in rev 4065),
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Scripts/FullIFOActuatorTFs/
        actuatorCoefficients_Npct.m (r3811, lc: r3811)
became
    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/Scripts/FullIFOActuatorTFs/
        fitDataToA_20170103.m (r4095, ls: r4061)                                (Note the intentional name change to match sensing function scripts)
which produces text files of actuation functions with frequency dependence known to negligible uncertainty removed,
    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/Results/FullIFOActuatorTFs/    (Note change in location because the text files are a result,
        2017-01-03_H1SUSETMY_L1_actuationStrength_Npct.txt (r4095, lc: r4056)    not a part of the measurements)
        2017-01-03_H1SUSETMY_L2_actuationStrength_Npct.txt (r4095, lc: r4056)
        2017-01-03_H1SUSETMY_L3_actuationStrength_Npct.txt (r4095, lc: r4056)
which are analysized by the MCMC code copied over from ER10 to O2,
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Scripts/FullIFOActuatorTFs/
        fitActCoefs_Npct.m (r3977, lc: r3977)
became
    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/Scripts/FullActuatorTFs/
        fitATF_mcmc_20170103.m                                                  (Note the intentional name change to match sensing function scripts)
and again, run individually for each stage on 2017-01-03 reference measurement.

--------
- Generated a fit for sensing function parameters using nlinfit and MCMC analysis,
pre-process sensing function measurements with a new copy of
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Scripts/PCAL/
        fitDataToC_20161116.m (r4040, lc: r4028)
now named
    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/Scripts/SensingFunctionTFs/     (Note folder change to match actuator scripts and the rest
        fitDataToC_20170103.m (r4095, ls: r4090)                              of O2 directory structure)
which produces an nlinfit list of parameters on the IFO optical plant (i.e. with stuff known to negligible uncertainty removed, like frequency dependence of OMC DCPD high frequency electronics), and also spits out a text file of that IFO optical plant for MCMC fitting,
    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/Results/Sensing
        2017-01-03_H1_meas_sensingTF_withoutDCPDTFs_ctpm.txt (r4095, lc: 4056)
This is loaded into a copy of
    ${CalSVN}/aligocalibration/trunk/Runs/ER10/H1/Scripts/PCAL/
        fitCTF_mcmc.m (r4041, lc: r4041)
    (copied prior to aesthetic changes to fit vs. measurement plot which now shows residuals in r4112 as described above)
which is now
    ${CalSVN}/aligocalibration/trunk/Runs/O2/H1/Scripts/PCAL/
        fitCTF_mcmc_20170103.m (r4095, lc: r4091)
to produce the MCMC maximum a posteriori (MAP) (and also has the same aesthetic changes as the ER10 version, r4112).

Even though all MCMC results are repeated using python code, the sensing function parameter's posterior distribution from the above matlab MCMC code are exported to text:
${CalSVN}/aligocalibration/trunk/Runs/O2/H1/Results/SensingFunctionTFs/
2017-01-03_H1_sensing_burn80p_nWalk100_output.txt       (r4095, lc: 4058)
2017-01-03_H1_sensing_burn80p_nWalk100_posteriors.txt   (r4095, lc: 4058)
Actuator parameter posterior distributions are not yet exported from the matlab code.
     
----------
A super-duper thanks to Darkhan, Kiwamu, and Evan for writing the brunt of these functions. It took a while to find everything, how the analysis flow was to go, and how to correctly into file names, but it otherwise works like a charm with very reproducible results. I look forward to making the functions even more streamlined, and potentially merging functionality so there's not so many functions of which to keep track. 
----------

Pressure reading from PT180 is once again rising after being valved into main volume. We suspect the water load is causing this. End stations show no sign but also get 2.5x more pumping speed from cyropumps due to smaller volume.

PT140 pressure reading on diagonal volume (no crypopump) started dropping this week after a three month incline. These changes are due to LVEA temperature fluctuations.

Correction:  water pumping speed is more like 1.8x more at end stations. 

Corner volume = 445,000 liters

End volume = 88,000 liters

Corner cyropumping = [100,000 - 3,000] x 2 (L/s)

End cryopuming = 100,000 - 30,000 (L/s)