You guys rock! Thank you for all your hard work.

Here is a plot of the data taken from the DCPDs up to 4MHz.  I've removed the 20dB of gain and the poles at 265kHz and 290kHz from D1700376 in this plot.  This was measured with our usual darm offset, restuling in 10mA on each of the DCPDs (we used one of the single PD outputs from D1700376).  We tried to repeat this measurement with a diode set up in the AS air path yesterday, 54636, but the 3.125MHz peak was only 20dB above the noise level, so we weren't able to see any of the other noise apparent in this measurement.  

Thanks, this is useful for ongoing CLF work.

For reference, Koji's measurements of the transimpedance are below. You can see that the rolloff flattens a bit in the MHz, so I'm less certain how real the bump is.

https://nodus.ligo.caltech.edu:8081/OMC_Lab/236

https://nodus.ligo.caltech.edu:8081/OMC_Lab/235

does your RF equipment have the ability to make a decently long cross correlation? That is surely what we need if we can conveniently get equipment to do it. Alternatively, you may be able to take spectra simultaneously in a sum and null output configuration, and then subtract them. It won't be as clean as xcorr, but it will show excess in a way that is less succeptible to systematic errors from inverting the PD response. Sum can be picked off from the SQZ chassis, and null just needs the phase shift before an RF splitter used in reverse (depending on the phase convention of the splitter).

Update, I remembered that I had acquired the LISO model and fit it in IIRrational for just these kinds of occasions. These fits should be decent up to 10MHz where the simulation cut off.

scipy ZPK notation:

(array([-1.09367517e+06+9.16935186e+04j, -1.09367517e+06-9.16935186e+04j,
       -4.54321270e+01+3.94631525e-01j, -4.54321270e+01-3.94631525e-01j,
       -2.85835003e+07+0.00000000e+00j]), array([-1.12584306e+07+1.59926553e+07j, -1.12584306e+07-1.59926553e+07j,
       -3.11667017e+07+1.49827313e+08j, -3.11667017e+07-1.49827313e+08j,
       -4.41594538e+07+5.59042545e+07j, -4.41594538e+07-5.59042545e+07j,
       -1.51046460e+07+2.52263715e+07j, -1.51046460e+07-2.52263715e+07j,
       -1.02822684e+05+0.00000000e+00j, -9.54273138e+04+0.00000000e+00j,
       -5.08417603e+02+0.00000000e+00j, -4.91824766e+02+0.00000000e+00j]), 2.71124765615596e+56)

foton notation:
ZPK([
  -174063.80969071676 + 14593.476738924443*i; -174063.80969071676 - 14593.476738924443*i;
  -7.2307475830315395 + 0.06280755795247621*i; -7.2307475830315395 - 0.06280755795247621*i;
  -4549205.365087142;
],[
  -1791834.8749338891 + 2545310.1382306265*i; -1791834.8749338891 - 2545310.1382306265*i;
  -4960334.630691198 + 23845757.522465646*i; -4960334.630691198 - 23845757.522465646*i;
  -7028195.359231514 + 8897438.443450466*i; -7028195.359231514 - 8897438.443450466*i;
  -2403979.0673290133 + 4014901.7200727463*i; -2403979.0673290133 - 4014901.7200727463*i;
  -16364.738450407038; -15187.728699344743;
  -80.91717459920993; -78.27634271397135;
], 2.71124765615596e+56, "f")

Attached are the fits and the output of the LISO model. I think the model differs a touch from Koji's measurements on the exact 3MHz cutoff frequency.

Here is a plot (and the data used to make it) of the DCPD output measured with the analyzer in noise mode.  The first set of data (in the original log above) were taken in spectrum mode.  The dark noise in this new plot was measured durring Friday's EQ in Turkey, the "squeezer blocked" trace was taken durring the commisioning time Thursday (54681).   These are calibrated using the filters in D1700376 and Lee's estimate of the OMC DCPD transimpedance above.  Both spectra were taken with 30Hz resolution bandwidth and 3Hz video bandwidth.  A potential problem with this measurement could be that the squeezer came unlocked and the beam diverter closed partway through the measurement, although that didn't seem to have an impact on the spectrum here.  

It does seem suspicous that the quadrature difference, which should represent noise coming from the interferometer light, has a spectrum so similar to the dark noise. 

This appears qualitatively a bit different than the post-demodulation measurement of the spectrum at LLO50307. There the blocked and dark noise ASD's changed by a factor of about 1.5. This appears to be substantially less than that at 3.125MHz.

Here is one more plot of the DCPD spectrum up to high frequency, again.  In the original version of the attached plot in 54753  I made two mistakes in the calibration, which are fixed here..

• The field on the DCPDs could be written as E_carrier +E_clf + E_am where E_am is am sidebands from the interferometer at audio frequencies around 3.125MHz.  The amplitude noise spectrum we measure on the DCPD is E_carrier*E_am while the term that could cause audio frequency noise by downconverting with the CLF is E_clf*E_am  The requirement for the amplitude noise around 3MHz is that the ASD of the photocurrent at 3MHz should be smaller than our audio frequency photocurrent asd*abs(E_carrier/E_clf)  In other words, the amplitude noise requirement around the CLF (and RLF) fields is less stringent than that at DC by the amplitude ratio of the clf to carrier light.
• With 20mA total on the DCPDs, our shot noise limited sensitivity on each individual diode is 6e-11A/rtHz, without squeezing. 
• We have been running with 5uW CLF injected into the OPO, and about -29dBm of RF power at the 3.125MHz demodulator since Nov 26th, before that we used -19dBm.  These powers are measured after the 20dB of gain in D1700376. This means we get 10uW of RF power out of the transimpendance amp, which is 92uA of photo current from the beat note of the 3MHz sideband with the DC power (20mA, 23mW). This means that we were using about 0.5uW of CLF on the DCPDs for the first part of O3, when we had noice from the CLF just below DARM.  Edit: The filter cavity design document T1800447 states on page 24 that there will be 10uW of CLF and RLF combined on the DCPDs OMC, which means about 0.1uW on the DCPDs, so this is similar to our current operating power. 
• This means that to determine if ampltude noise down-converted by the CLF can explain the observed CLF noise, we would need to measure the spectrum of the DCPDs a factor of a few below 1.7e-8A/rtHz on a single diode.  To allow for 20 times more CLF power reaching the DCPDs with the filter cavity, we'd need to measure noise below 3e-9A/rtHz. 

The attached plot shows, in addition to the dark noise and locked spectrum, the level of amplitude noise which I think would be needed to create downconverted noise about equal to the current shot noise limited sensitivity.  One conclusion is that the dark noise of the DCPDs at 3MHz is too high for us to measure the level of amplitude noise that we need to measure to be sure that we can turn up the CLF power to the level required for the filter cavity controls. However, the difference between the in lock and the dark noise spectrum suggests that the current level of amplitude noise is well above this level, such that it should be dominating the noise in DARM.  So something seems to be wrong either with the measurement or with my projections.

One could worry that there might be significant variation between the individual transimpednce amplifiers at 3MHz.  We have a measurement made at 3.12MHz with the installed amplifier: 47540  which is roughly consistent with the one that Koji measured and Lee's fit above.  Another worry could be that we are running with a different transimpedance than these measurements were taken with, but we are running in high Z which is 400 Ohms at DC according to D060572, My plot of Lee's fit above gives a DC transimpedance of 200 Ohms, but it is ~220 Ohms at 3.125 MHz, so I think it is close enough.

Tested ETMY mode 20 damping at a of -0.5, which damped but effected mode13, tested gain at -0.2, which works, effects mode 18, but not by much, gain is set back to zero.  Guardian code loaded.

Tagging ISC, SUS and SEI.

Very cool result, and great detective work!

Great job Jenne + Robert!

Demonstrating Measurement to Model residual systematic error.

I have plotted the diffference between observed data of the UIM L2L transfer function in comparison with the following models:

• A Pure 1 / f^6 TF
• CALCS filter before 20200113
• pyDARM model from 20190909 params file
• CALCS filter after 20200113
• pyDARM model from 20190103 params file

The order is chesen to be in decending order with increasing "goodness" - this way to best one is plotted on top of the rest

The plots are broken up into 5 parts of the freuquency spectrum (where we have data: 5 to 550 Hz), to make the lare amount of infromation more readable.

Going through these plots is informative in understanding how each model is "good" is various parts of the spectrum, and how it can be "bad" in other parts.

The take home message is that the new pyDARM model is good up to 200 Hz, and the new CALCS filter is approximately identical to it, and reflects the data just as well.

Demonstrate Model to CALCS residual systematic error.

I had plotted this with MATLAB before, but for improved clarity I'll plot the CALCS differences from pyDARM for all stages L1,L2 and L3 (UIM, PUM, TST) L2L transfer functions: so that it is clear where the models are good and bad when we fit these models into the front end filter banks.

The most drastically different is the L1 stage (which the comment preceeding this claims to be a pretty close fit to observed data). You can see the effect of the removal of a vast amount of poles and zeroes from the TF impacting the low frequency, as well as the two missing features at 90 Hz and 134 Hz, also visible in the previous comment.

At high frequency, gain and phase difference comes about from the fact that the front end model is a discrete model (with a sample rate of 16384) and hence has a Nyquist frequency around 8kHz, so what you see is the contributing fraction of that coming into lower frequencies.

Remake the "contributions to R" plot, using the new 20200103 parameter file.

Now that the paramter file is all its detail about it updated, the previous estimates to the contribution of that 152 Hz feature to the response can be more accurately modelled.

Where I previously said that the contribution was about 8.5%, it is clear that it is closer to 7%.

Make the "final" version of R_foton_new / R_foton_old plot.

With the parameter file update fully, this plot also changes from the one I plotted previously.

This plot is generated by:

• R_foton_old: Calculating R using the 20190909 paramter file, and the transfer functions for the UIM, PUM and TST from the *old* CALCS filter bank.
• R_foton_new: Calculating R using the 20200103 paramter file, and the transfer functions for the UIM, PUM and TST from the *new* CALCS filter bank.

This was the expected change in DELTALEXT/PCAL. The actual observed change was here,with further discussion.

The H1CALCS filter banks were rearranged to make more sense and to make it obvious that there is plently of room to add more filter bank blocks that would do an even *better* job of representing the full transfer functions in the front end.

Attached are the images so that you can see how things are arranged. Below I define what the abbreviations mean:

• susn_RB* : Normalised suspension model for Rigid Body dynamics.
• susn_BD*: Normalised suspension model for (UIM) Blade Dynamics.
• susn_VM: Normalised suspension model for Violin Mode dynamics.
• mpN_20Hz: meters per Newton  - this is simply the overall gain of the L2L transfer functions, and is measured at a reference frequency of 20Hz where the front end transfer function is by definition exactly the same is the one for the pyDARM model.
• Npct_O3B: Newton per count parameter reflecting the 20200103 model
• actsing: 1 or -1 to set polarity of actuation
• armsign: 1 or -1 to set polarity of actuation depending on which arm is being actuated on
• 1/f^* : the 1/f^n (n=2,4,6) roll off transfer fucntion that is removed from the normalised suspension models during their calculation.
• HFpole: extra TF for the TST stage to account for Parametric Instability actuators/dampers affecting TF at much higher frequency
• biassign: -1 for some other exotic polarity setting issue in the TST stage

minor clarification on the biassign, in the above comment, since I was in a rush and not thinking: its the bias on the ESD drive for actuation on the TST stage

To find the code to generate the figures in this alog, consult the following directory:

/ligo/home/vladimir.bossilkov/Work_Done/20200111_calibration_checks

Also as a backup I've included the files from this directory as an attachment. I had to omitted the very densely evaluated transfer function from foton that was used to produce plots in the first set of figures, because it makes the attachment too large. You can probably use ETMX_L1 new and old files used in the second set of files without much error.

While writing the O3A cal paper, I made a comparison plot showing the UIM contributions in 0909 O3A, and the 0909 O3A model with O3B SUS data (trunk/Common/pyDARM/matlab_scripts/20200107_H1_EX_O3_susdata.mat).
The comparison is show in the attached pdf. The "old UIM" is the actual 0909 model. The "new UIM" is 0909+O3B sus.

The first observation ready segment with the updated calibration model start just now at Jan 14 2020 00:47:59 UTC, or GPS 1262998097.

Attached are plots of GDS data during the broadband injection, as well as plots showing how well the filters represent the frequency-domain DARM model.  The broadband injection (first plot) looks good, showing deviations no greater than ~2% from 20 Hz - 350 Hz.  The last plot shows how well the low-latency (front-end + GDS) calibration pipeline applies the response function R(f).  The "spike" seen at 4276.0 Hz is not modeled at all by the filters.  The source of this in the model is in all 3 stages of the actuation (only TST and PUM contribute significantly to the response function), and I assume it is a violin mode.  This is a very narrow freature in the model, no wider than 0.25 Hz.  Models for TST, PUM, and UIM all rise 12 or 13 orders of magnitude at this very narrow feature.  We can attempt to model this in the inverse sensing path (which has a high enough sample rate), but it won't be modeled very well if we try, since it is such a narrow feature.  Moreover, this would also compromise accuracy in neighboring frequency bins.  Most likely, there will still be a loud spectral line in h(t) at 4276 Hz, and the systematic error induced by using the current filters would be that this line appears 3 orders of magnitude lower than it actually is.

Here's a comparison between GDS-CALIB_STRAIN's response to a broadband PCAL Y injection before vs. after this model update. Assuming PCAL is a perfect reference, this should be equivalent to a direct measure of the systematic error in the response function and h(t).

One can see that, while we've cleaned up the UIM feature at 153 Hz, and improved the response ratio below 30 Hz, we seemed to made the systematic error worse between 60 and 150 Hz. 

In the first attachment, I show each of the transfer functions on top of each other, to show the former vs. the current level of systematic error.
In the second attachment, I show the ratio of the two transfer functions, to show the *change* in systematic error. 

This second attachment should correspond to what Vlad predicted in LHO aLOG 54523. It's close... but not quite right. 

Still investigating...

The script used to make this plot can be found here:
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs/
        plot_GDS_BB_20200115.py
and relies on data processed by Aaron and committed to 
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Results/GDS_BB_plots/
        H1_C00_over_CAL-PCALY_RX_PD_OUT_DQ_1262638969-178.txt
        H1_C00_over_CAL-PCALY_RX_PD_OUT_DQ_1262990871-153.txt

I did some empirical probing into what could be giving this kind of responce between 20 and 300 Hz.

For this I created a new copy of the modelparams_H1_20200103.py file to play with.

The plot attached here, is where I have taken the ratio of my new version over the currently used version, but I have altered:

• ccOpticalGain is mulitplied by the current Kappa_C written out in the frontend (0.996)
• ccPoleFreq is the current cavity pole frequency in the front end (has minimal effect in this frequency range, but "corrects" for the response change from optical gain at high frequency.

This is plotted against the very data in the above comment, for reference.

It looks like the current systematic error trend can be ?just about? completely explained by this correction! It seems response in this range is *extremely* sensitive to the value of ccOpticalGain in the model.

EDIT: spoke to Jeff - more convincing to reanalyse this w.r.t the Orange line in his figures in the previous comment, and see if it explains the complete error in response.

For reference, here are the values of the TDCFs that were applied to the data in the GDS pipeline during the broadband injections.

During the injection starting at 1262638969:

kappa_tst = 1.0052612

kappa_pum = 1.0198756

kappa_uim = 0.99628365

kappa_C = 0.99136031

f_cc = 411.13184 Hz

During the injection starting at 1262990871:

kappa_tst = 0.99716723

kappa_pum = 1.017796

kappa_uim = 0.99592042

kappa_C = 0.99556768

f_cc = 410.88696 Hz

We needed a better understanding of the impact of this systematic error at ~150 Hz. for the UIM, so I added a copy of ratio plot from LHO aLOG 54565 to the same script,
    ^/trunk/Runs/O3/H1/Scripts/FullIFOSensingTFs/plot_GDS_BB_20200115.py 
and zoomed in around the 100-200 Hz frequency region.

Attached are the results. 

(1) We're, of course, limited by the frequency resolution and noise of the measurement, BUT,
(2) We see what Vlad has told us all along: there are actually three features: highQ anti-resonance at 151 Hz, highQ anti-resonance at 153 Hz, and then a high Q resonance at 154 Hz (rounding to the nearest Hz). Note that this description is of the *ratio* of (fixed) / (not fixed), so take my description of whether the feature is a "resonance" vs. "anti-resonance" with a grain of salt.
(3) Each highQ feature peaks at around a -2%, -3%, and +3%, BUT -- that includes influence from the "underlying" broad frequency dependent error "sweeping through" this region -- known to be a result of problems with the TST actuator model in this low-latency data.