Overall, regardless of fixing the capacitors, the response will be accurate to within 1 % up to above 100 kHz.

The other aspect that may give some frequency dependant error is coherence time in the sphere:

There is an equation listed in integegrating sphere technical notes, as well as presentations by NASA [page 4] that looks at exponenetial time decay of pulsed signals, this can be used to get an  apporximation for the coherence time constant within the integrating spheres. From that, the bandwidth (FWHM linewidth) of the sphere is: 1/ (pi * tor)

It can be calculated that the sphere itself is good within 1 % up to 2.14 MHz.

So the electronics boards are the main limiting factor.

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 fix for the missing observing time on January 9th is as follows (from Robert Bruntz):

• The segments will remain in the DB as they were originally published (in H1:DMT-ANALYSIS_READY:1).
• A new flag has been created, H1:DMT-ANALYSIS_READY_9JAN2020_OBS_INTENT_FIX:1, which duplicates H1:DMT-ANALYSIS_READY:1, but with the segment [1262582081,1262592115) changed from not active to active (expanding an active segment from [1262592115,1262595538) to [1262582081,1262595538) ). New segments are being copied from H1:DMT-ANALYSIS_READY:1 and published to this flag regularly (every 6 hours, with a 2 hour lag) through at least the end of O3 (planned to be the end of April 2020). Thus, the flag will be a complete duplicate of H1:DMT-ANALYSIS_READY:1, except it will include the ~2 hr 45 min of active segments, and it will be published at higher latency (i.e., the newest segments will be 2-8 hours old; if this is an issue for anyone, contact me, and we might change that). This gives any pipelines which want to use the additional 2 hr 45 min of science time a flag to use while waiting for C01 data to become available.
• Once C01 data become available, pipelines should switch to that, thus making the error in H1:DMT-ANALYSIS_READY:1 irrelevant.

Also, the link to my shift, as I didn't originally include it in my aLog.

Not only do you have to toggle the autolocker off/on in rapid succession (click OFF then immediately click ON), when you perform the toggle is important as well.  If it's having trouble relocking it will get to a point where it wants to grab, but for some reason can't (you'll see the 00 flashes on the PSL quad display, upper-left quadrant).  You want to toggle the autolocker during this state, when it should be grabbing a 00 mode but isn't.  If the autolocker is running through its temp search (seen by a triangular shape to the NPRO crystal temp graph on the FSS MEDM) then toggling the autolocker will do absolutely nothing.

There have been a few instances of the FSS RefCav having issues relocking in the last few days (a couple on Friday, and the two reported by Corey).  This seems to be a growing trend, but oddly enough we very rarely have problems getting the RefCav to lock when we perform work on it.  I suspect there may be issues with the archaic FSS RefCav autolocker code; it was written in one of the variants of C many years ago and hasn't been touched since.  I'll formalize this in a Wiki page, but here are some pointers if the autolocker continues to have problems (in no particular order):

• Pause the PSL_FSS guardian node
  • This is the code that detects an oscillation in the FSS and drops then slowly raises the FSS Common Gain to attempt to clear the oscillation
  • If this code is yanking the common gain around when the FSS is trying to lock (which happens), it can greatly increase the time it takes to lock the RefCav
  • Be sure to re-enable this node once the FSS RefCav has locked
• Look at the 1st loop ISS diffracted power, turn it OFF if it's not sitting at a steady value
  • Upon a lockloss and the sudden turning off of the 2nd loop ISS, the 1st loop ISS can have some residual "anger issues" that take some time to settle out
    • If the diffracted power is moving around, I've seen this increase the time it takes the RefCav to lock
  • Press the OFF button under Autolock in the ISS MEDM screen; the autolock indicator and the 1st loop indicator above it should both go red; if the 1st loop indicator doesn't go red, open Manual Mode (under the Autolock) and press the red OFF button in the small window that opens; when OFF, the diffracted power sits at ~2.8% and the graph above it is a flat line
  • Be sure to re-enable the ISS 1st loop once the RefCav has locked (press ON under Autolock in the ISS MEDM screen)
• As metioned above, toggle the FSS autolocker off/on
  • Do this only when the FSS is attempting to grab a 00 mode (you'll see the flashes on the PSL quad display)
    • Done at other times it will not help (it also will not hurt, so don't worry if you don't time the toggle correctly)
  • The FSS will generally grab on the first toggle, but I have seen cases when it doesn't; if this happens, just toggle it again.

I also had the FFS not locking on Tuesday (alog 54329), the wind was very high at this time though I don't know if that could have any effect. 

How would you suggest pausing the PSL_FFS code? Will taking it to INIT do this as it is Managed by ISC_LOCK.

Thanks for the notes about this, Jason---this helps alot!  It was the middle of the night, and I totally did not want to phone you for something like this.  I did think I tried different types of toggling of the Autolocker, but I definitely did not correlate toggling with looking at the RefCav flashing modes.  

Camilla:  (Correct me if I'm wrong Jason) One can PAUSE the PSL_FSS node (and any node) by going to the node's Main Screen & for the "OP" pull-down, click that and select PAUSE (other choices are STOP & EXEC).  I imagine we can do that even if PSL_FSS is MANAGED?

It's my opinion that comparative anemometers on either side of each windscreen would be a more valid assessment. Typically the variance of the wind speeds from the CS to either unprotected end (and mids) can show fairly large differences. Keeping the H1PEM_WINDSPEED MEDM screen open is part of my regular screen setup (I stack Obs Mode/Wind Speed and Range)

I've been looking at the early data for the impact of the wind fence, and looking from 1st January to 8th January there's on average a ~5mph discrepancy between CS wind speeds and EX and EY (looking at CS wind speed - EX/EY wind speeds), and 2-3mph looking at data from 12th December onwards (I'm looking at max minute trends since that's what I used to see the impact of gusts of wind), compared to discrepancies of 0-1mph on average for O3a and for before the wind fence was completed.