S. Dwyer, J. Driggers, J. Kissel, L. Sun,
While Sheila spent the day perusing and debugging
^/trunk/Common/pyDARM/src/
actuation.py
in hopes to find the remaining problems with the time-independent path of DELTAL EXTERNAL that continues to plague us (see LHO aLOG 48102 for the latest on that),
Lilli created a DARM loop model that replicates what works in CAL-CS,
^/trunk/Runs/O3/H1/params/
modelparams_H1_20190401_ER14_095A.py
-- see LHO aLOG 48115 for more details.
Once Jenne was convinced that the replica SUS oscillators were a major problem with the computation of the time-dependent correction factors (see LHO aLOG 48129),
I figured that we should update the Reference Time Model Parameters at Calibration Line Frequencies a.k.a "EPICS records" in front-end such, regardless of whether things are perfect, the time-dependent correction factors are at least functional and their parameter values are close.
I generated the EPICs records with
^/trunk/Runs/O3/H1/Scripts/CALCS_FE/
createEPICS_for_20190401.py
which is calling the above mentioned model, and a few functions inside
^/trunk/Common/pyDARM/src/
computeDARM.py
which I've updated to write with 16 significant figures. ***
Attached are the results and a screenshot of the new EPICs records.
Further, I attach a time series of the time-dependent correction factors. One can see
- The values are
kappa_C = 0.99 virtually spot on with the reference model
f_cc = 404 Hz virtually spot on with the reference model
f_s = 13 Hz # bogus because calculation is for anti-spring
Q_s = 0.5 Hz # bogus because calculation is for anti-spring
kappa_T = 0.591 wrong, don't yet know why
kappa_P = 1.054 5%... coincident with what's needed to fix the PCAL2DELTAL TF? Don't understand why, could be coincidence
kappa_U = 1.051 5%... coincident with what's needed to fix the PCAL2DELTAL TF? Don't understand why, could be coincidence
- the time-series of the past 3000 seconds indicate what we've see that these TDCFs are just as stable as the IFO, confirmed by broad band injections (see LHO aLOG 48098)
These time-dependent correction factors are still not actually correcting anything, so the systematic error we claim still remains -- 1% / 5 deg. Again, see LHO aLOG 48102.
The EPICs records have been accepted into both the safe.snap and OBSERVE.snap files, and have been committed to
^/trunk/Runs/O3/H1/Results/CALCS_FE/
epicsrecords_model-H1_20190401_created-20190401.txt
*** We tried to reduce the number of significant figures of the EPICs records such that we wouldn't constantly have to battle the floating point precision comparison with SDF, this we are now writing the records to EPICS with the lines
subprocess.call(['caput',IFO+':'+chan+'_REAL','{:0.16e}'.format(chan_real)])
subprocess.call(['caput',IFO+':'+chan+'_IMAG','{:0.16e}'.format(chan_imag)])
to limit the write to EPICs to 16 significant figures, i.e. the limit of floating point precision. However, differences still have shown up when the .snap file is compared against the running values. We *can* limit the precision of these numbers further, but we want to make sure that limiting the precision on these numbers won't impact the precision of the finally computed time-dependent correction factors.
