Displaying report 1-1 of 1.
Reports until 12:26, Tuesday 29 November 2022
H1 CAL (CAL, ISC)
jeffrey.kissel@LIGO.ORG - posted 12:26, Tuesday 29 November 2022 - last comment - 12:26, Tuesday 29 November 2022(66062)
Building Confidence in pyDARM's computation of low-frequency corrections from Super Nyquist Effects to DELTAL / PCAL Corrections
J. Kissel, E. Goetz

We continue to try to build up confidence in our new math that more accurately corrects the ratio of (H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCALY_RX_PD_DQ) for each channels' artifacts (from T1900169) to turn the (H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCALY_RX_PD_DQ) TF into what we really want -- a direct measurement of the systematic error in the detector's calibrated data stream. More specifically, building confidence in pyDARM's computation of the transfer function that is Eq. (98) from T1900169 -- the low frequency corrections to the (H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCAL_RX_PD_DQ) "systematic error" transfer function that result from super-Nyquist features and other acausal parts of the DARM loop.

Yesterday, in LHO:66046 Louis aLOGged our first confidence builder -- that the pyDARM-produced, super-Nyquist correction TF looks roughly the same as one of the existing correction TF that we apply to one of our DTT templates that measure the (H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCAL_RX_PD_DQ) systematic error TF. Indeed, there they were different were a result of real changes to the DARM loop, or well-understood (and thus far inconsequential) mistakes made in the past.

In this aLOG, I process three (H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCAL_RX_PD_DQ) systematic error transfer functions that were taken *prior* to the calibration pipeline changes made on Nov 23 2022 (LHO:65973) in order to:
   - demonstrate that the frequency response of the acausal correction TF's has very week dependence on the the overall gain of the sensing and actuation paths, and
   - re-enforce what we already know -- that the systematic error transfer function evolves, quite clearly, as a function of time due to real interferometer changes.

The low-frequency Correction TF from super-Nyquist effects depends only weakly on the overall gains of the sensing and actuation paths
First Attachment: 
syserrFunction_H1_proc20221129_model20221118_meas20221123_2106UTC-20221123_2236UTC_pcal2deltal_correctiontf_comparison.pdf 

I use the flexibility of pydarm's pythonic interface in this attachment to show the low-frequency correction-for-super-Nyquist-effects TF with two different cases of sensing and actuation gains. The two sets of values for these gains are chosen for their current relevance: 
    - ("from 20221118 model") are the MCMC fit values for the gains originally copied from the 20220527 model parameter set, which were informed by sensing sweep measurements taken on 2022-05-25 and actuation sweep measurements taken on 2022-05-27. (The versioning up of the parameter set to 20221118 was for other reasons unrelated to the overall gain.)
    - ("from Fudge") are the reconstructed gains from combing the CAL-CS filter-bank values for these gains used from 2022-07-22 to 2022-11-23 with the fudged EPICS modifications to these values reviewed in LHO:65497.

In summary, the difference between these two values are as follows:

    Optical Gain from 20221118 model: 3.206e+06 (ct/m)
    Optical Gain from Fudge: 3.216e+06 (ct/m)
    Fudge / 20221118 = 1.003
 
    UIM from 20221118 model: 1.622e+00 (N/A)
    UIM Gain from Fudge: 1.630e+00 (N/A)
    Fudge / 20221118 = 1.005
 
    PUM Gain from 20221118 model: 3.003e-02 (N/A)
    PUM Gain from Fudge: 3.104e-02 (N/A)
    Fudge / 20221118 = 1.034
 
    TST Gain from 20221118 model: 4.669e-11 (N/V^2)
    TST Gain from Fudge: 4.761e-11 (N/V^2)
    Fudge / 20221118 = 1.020
So, in this example overall path gain difference -- little-to-no gain change in the sensing path, a 2-3% difference in PUM and TST gains -- the correction TF changes at the 0.1% / 0.1 deg level.
Of course, this example is not all-encompassing, so we need to continue to be careful, and make sure we give pyDARM the right overall gains for the given time that we're calibrating, but it gives me some confidence that the calculation of the correction TF isn't as dependent on overall gains -- and therefore also on time-dependent correction factors -- as I had once worried. Eventually, we should extend the math of T1900169 further to confirm and/or account, but at least in this one example, we see little difference.

The overall systematic error in the calibration (after being corrected for low-frequency corrections from super-Nyquist effects) remains time-dependent because of real alignment / thermalization changes in the IFO
Second Attachment syserrFunction_H1_proc20221129_model20221118_meas20221123_2106UTC-20221123_2236UTC_pcal2deltal_comparison.pdf

In this attachment, I show the post-processed (H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCALY_RX_PD_DQ) systematic error transfer function for three measurements taken at 
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs
      measurement                                                     start time                    excitation type
    - 2022-11-23_2106UTC_H1_PCALY2DARMTF_BB_3min.xml:                 2022-11-23 21:06:02 UTC       Broadband, colored, band-passed random noise
    - 2022-11-23_2129UTC_H1_PCAL2DARMTF_LF_SS_5to1100Hz_10min.xml:    2022-11-23 21:29:10 UTC       Swept sine
    - 2022-11-23_2236UTC_H1_PCALY2DARMTF_BB_3min.xml:                 2022-11-23 22:36:00 UTC       Broadband, colored, band-passed random noise
where the first measurement was taken a bit over an hour after the IFO achieved high power (50W) at 2022-11-23 20:01 UTC.

One clearly sees a frequency dependent time evolution at the "several %" level of the H1:CAL-DELTAL_EXTERNAL_DQ / H1:CAL-PCALY_RX_PD_DQ systematic error transfer function the three measurements taken over 1.5 hours. While we don't know exactly which of our "basic" or "fundamental" parameters of our loop model are changing -- the one's we assign the moniker "time dependent correction factors," or TDCFs :: the optical gain and cavity pole for the sensing function, or the overall path gains of each of the three SUS ETMX stages we use as the DARM actuator -- but there's clearly something changing.

The third attachment, 2022-11-23_H1CAL_CavityBuildups_vs_Time_DuringDELTALoverPCALTFs.png shows the evolution of laser power  at various ports in the IFO. The vertical dotted time traces indicate the start times of the first and last measurement.

This one should come as no surprise, but for this time dependence,
    (a) It's been a while since the systematic error change has been so clearly and confidently demonstrated, and 
    (b) It's new/surprising that it takes *so long* for the IFO to become thermally / "alignmently" stable -- the traditional "1 hour after achieving the final laser power" used to be enough time,
    (c) This stresses the need to take a *different* DARM_IN1 / PCAL = C/(1+G) = response function transfer function for every set of DARM_IN1 / DARM_IN2 = G = open loop gain transfer function or DARM_IN1 / SUS_EXC_i = A_i * C / (1 + G) that needs taking over the course of ~2 hours to get measures of C and A_i alone.
    (d) It makes me look forward to the work Vlad Bossilkov is doing to drastically decrease these "sweep" measurement times by driving them simultaneously.

More to come!
Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:32, Tuesday 29 November 2022 (66069)
Plots produced by the script
    /ligo/gitcommon/Calibration/ifo/scripts/fullifosyserrtfs/ligo/gitcommon/Calibration/ifo/scripts/fullifosyserrtfs/compare_fulliforesponsetf_BBandSS_20221123_2106UTC-2236UTC.py
    
with pydarm "compiled from source" via "development" conda environment called "pydarm-dev" (rather than standard release at the moment, which is 0.0.6), which lives in my collection of conda environments here:
    /ligo/home/jeffrey.kissel/.conda/envs/pydarm-dev

which was created on 2022-11-28 with that day's version of the pyDARM main branch,
    $ python -m pydarm --version
    0.0.7.dev20+gb3a53f7
    $ git log | head -1
    commit b3a53f7b 
    
"created" means following the "Install from source in a conda environment" section from https://git.ligo.org/Calibration/pydarm/-/blob/master/INSTALL.md, 
    $ cd /ligo/gitcommon/Calibration/pydarm/
    $ conda env create --name pydarm-dev --file conda/environment.yaml
         (this takes ~3-5 minutes)
    $ conda env list #show the available environments to activate
    $ conda activate /ligo/home/jeffrey.kissel/.conda/envs/pydarm-dev
    $ python -m pip install -e .
    
I used pydarm via this "installed from source, custom conda environment" solely in order to receive the fixes to Issue #154 with the deltal_ext_pcal_correction method in calcs.py module, solved with the recent Merge Request #166.
Displaying report 1-1 of 1.