[Sheila, Craig, Timesh]
Cal SVN root: /ligo/svncommon/CalSVN/aligocalibration/trunk
This morning, Sheila took the usual sweep of measurements for calibration at around 15:56:49 UTC. When looking at the results from the processing sensing script, we see an antispring at f_s = 4 Hz. Attached to this alog is the raw data, the MCMC model with the measurement, the reference model with all the measurements and MCMC corner plot of this measurement.
We tried to re-measure the the Open Loop Gain (OLG) at around 01:10:13 UTC during which, the PCAL measurement ran successfully however the OLG measurement failed due to an earthquake. Before re-running the measurement we set H1:LSC-SRCL1_OFFSET from 100.0 counts to 0.0 counts. The steps in offset was to make sure that there was not a large loss of power in the arms and have the ability to quickly restore the IFO if required. The motivation for changing the offset was that in O3a, a value of 100.0 counts was used to compensate for a pro-spring (for example, see LHO alog 51440 and comment therein) and since we are measuring an anti-spring with the same counts offset, we may have been driving an anti-spring. The hypothesis is that by removing the offset, the spring would tend towards zero.
We were able to collect OLG data from 1083.7Hz down to 10.334Hz before the lockloss. This is not sufficient for re-measuring the spring/anti-spring of the IFO thus, we will attempt to repeat the OLG measurement once the IFO is back into nominal low noise (NLN) and has thermally equilibrated. The dtt files and processing scripts that were used are given below for the original measurements and the re-run measurements (svn revision given in brackets):
Measurements
Sensing:
^/Runs/O3/H1/Measurements/FullIFOSensingTFs2019-10-28_H1_DARM_OLGTF_LF_SS_5to1100Hz_15min.xml (r8632)
^/Runs/O3/H1/Measurements/FullIFOSensingTFs2019-10-28_H1_PCALY2DARMTF_LF_SS_5t1100Hz_10min.xml (r8632)
^/Runs/O3/H1/Measurements/FullIFOSensingTFs2019-10-28a_H1_DARM_OLGTF_LF_SS_5to1100Hz_15min.xml (r8632)
^/Runs/O3/H1/Measurements/FullIFOSensingTFs2019-10-28a_H1_PCALY2DARMTF_LF_SS_5t1100Hz_10min.xml (r8632)
Actuation:
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L1_iEXC2DARM_10min.xml (r8632)
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L1_PCAL2DARM_8min.xml (r8632)
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L2_iEXC2DARM_12min.xml (r8632)
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L2_PCAL2DARM_6min.xml (r8632)
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L3_iEXC2DARM_12min.xml (r8632)
^/Runs/O3/H1/Measurements/FullIFOActuationTFs/2019-10-28_H1SUSETMX_L3_PCAL2DARM_6min.xml (r8632)
Processing
Sensing:
Reference model: modelparams_H1_20190909
^/Runs/O3/H1/Scripts/FullIFOSensingTFs/process_sensingmeas_20191028.py (r8636)
Actuation:
Reference model: modelparams_H1_20190416
^/Runs/O3/H1/Scripts/FullIFOSensingTFs/process_actuationmeas_20191028.py (r8637)
[Craig, Timesh]
We re-measured the sensing by re-measuring the OLG and PCALY. Before re-running the measurement we set H1:LSC-SRCL1_OFFSET from 100.0 counts to 0.0 counts. The Earth stayed quiet enough that we now see a ~9Hz pro-spring after the successfully completion of both measurements. Once again the raw data, the MCMC model with the measurement, the reference model with all the measurements and MCMC corner plot of this measurement are attached to this alog.
I am uncertain what the reason is, or the cause of, the pro-spring/anti-spring in these scenarios.
I'm not confident that the above 0ct SRCL offset data is really a "9 Hz pro spring," and Sheila and I are not so confident it's really bad just yet. (Where "bad" would be "enough of a low frequency response that would drive us to change the sensing function model in the front-end.") I've compared the above two data sets against the last few data sets of O3A in the attachment below. One can see that, although, indeed a 100 ct SRCL offset is an anti-spring, the 0 ct offset data residual looks much like the subtle residual mixing of a detuned SRC and some sort of L2A2L crosscoupling (or whatever label you want to put on the as-of-still-poorly-understood low frequency response that's *not* a detunement of the SRC) that we saw at the tail end of O3A *after* installing the 100 ct offset. Also note that there's no magic to the numbers here: they're all determined by "quick" tests -- easy changes in the IFO configuration that need confirming with ~25 minutes of measurement. We started with no digitally requested offset (0 ct) for most of O3A, and then on one Wednesday after sorting out our August spot position kerfuffle, we tried 100 ct, then 200 ct to try to reduce the severe pro-spring with which we ended up. 200 ct seemed unstable, and 100 ct conveniently seemed to give us the "no detuning" response we wanted. Now, the quick test was "turn it off," and *that* got us close enough, so we're running with that for now. Sadly, we've yet to put together a model that's complete enough to help us understand and/or predict what's going on. So, for now, if we can get the IFO stable enough for us to have the patience to do some more exploring, we'll measure the sensing function again to make sure this new answer -- with 0 ct SRCL offset -- is consistent, or if the resulting low frequency response moves around with time.
Taking a look at the work Timesh did to process the 2019-10-28 actuator data, the answers are
UIM PUM TST
Reference Model 7.67e-08 (N/ct) 6.036e-10 (N/ct) 4.727e-12 (N/ct)
MCMC Fit 7.564e-08 (N/ct) 6.065e-10 (N/ct) 4.781e-12 (N/ct)
kappa via MCMC 0.986054 1.00483 1.0115
kappa via CALCS 0.995 1.0107 1.0133
So these should be close enough that we don't need to update the actuator coefficients.
Note that these will have similar 0.5% levels of systematic error that have been reported by the PCAL system in 52893 from having the wrong ETMX test mass mass. To be determined how we'll rectify this....
