louis.dartez@LIGO.ORG - posted 17:15, Friday 27 January 2023 - last comment - 17:53, Friday 27 January 2023(67061)
2023-01-27 Calibration Measurements
J. Rollins, A. Neunzert, J. Kissel, L. Sun, E. Payne, L. Dartez
We took a new set of calibration measurements; the first after changing over to the 524 kHz OMC DCPD sensing chain and with the new D2200215-style whitening chassis.
The other bonus from this measurement set is that taken the data by exercizing some of the new 'pydarm measure' framework that the Calibration group has been working on. For better or worse, though, that means we're saving the files in an entirely different location under different file names. We list the file locations here. Processing results will come later.
Sensing, Actuation, and their corresponding PCAL measurement files have been stored at:
/ligo/groups/cal/data/H1/measurements/2023-01-27T21:40/.
file name which tf is this file?
SUSETMX_L1_2023-01-27T21:40.xml A_UIM * C / (1+G)
PCAL2DARM_2023-01-27T21:58.xml C / (1+G)
SUSETMX_L2_2023-01-27T22:17.xml A_PUM * C / (1+G)
PCAL2DARM_2023-01-27T22:35.xml C / (1+G)
SUSETMX_L3_2023-01-27T22:53.xml A_TST * C / (1+G)
PCAL2DARM_2023-01-27T23:11.xml C / (1+G)
DARM_OLG_2023-01-27T23:29.xml 1 / (1+G), DARM Open Loop Gain
PCAL2DARM_2023-01-27T23:47.xml C / (1+G)
Broadband injections (taken at the beginning and the end of the session) are stored at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/
2023-01-27_2134UTC_H1_PCALY2DARMTF_BB_3min.xml
2023-01-28_0007UTC_H1_PCALY2DARMTF_BB_3min.xml
A screen shot of this last broadband injection shows the current level of calibration's systematic error -- the transfer function between our known displacement reference (PCALY_RX_PD) and the current best real-time calibrated data stream (CAL-DELTAL_EXTERNAL). This plot comes with all the usual warnings about how this DTT template has not been corrected for super-Nyquist effects, and thus, there's an additional known ~2-3% wiggle that's not pulled out of this "raw" data. Indeed, we usually wave our hands at that and say "well at least those super-Nyquist effects haven't changed between reference and current data" but in this case, the super-16 kHz-Nyquist frequency response has changed drastically too. But it's the first thing that we can quickly show.
Other details about the current IFO configuration:
(see attached screenshot of the "calibration" screen and the trend of IFO power build-ups)
- Input Power: 60 W from the PSL input to the IMC, 56.8 W into PRM
- LSC: Still no SRCL offset, Still no DARM length to Arm Cavity angle ("L2A") control decoupling the ETMX PUM stages
- ASC: CSOFT and DSOFT gains are a factor of 2x less, HARD loops remain unchanged
- QUADs: ESD bias voltage is at -9.3 DAC volts, PUM drivers are in State 3,
- TCS: Ring heaters on are IX (0.4 W), EY (1.4 W), C02 lasers are X = Annular 4.0 W, Y = Central 1.7 W
Images attached to this report
Comments related to this report
Attaching first draft of new report generated for these measurements.
Non-image files attached to this comment
Some comments about the measurement 'pydarm measure' method:
On what it does:
(1) (this has already been changed, but) the method should take a broad-band PCAL transfer function before and after the sweeps, in addition to the sweeps.
(2) The current infrastructure takes the sweeps in A_UIM, A_PUM, A_TST, C order. We should take the sensing function, C, sweeps first, then A_TST, A_PUM, then A_UIM actuator measurements. This is an "in case of lock loss" order that gives insurance: you still have the most important measurements if you lose lock in the middle of the 1.5 hour sweeps set. The sensing function sweep (which includes a response function systematic error sweep) is the *most* important to get as the sensing function changes the most from measurement to measurement. Then, I reverse the order of the actuators because A_TST is most important (it contributes the most in the most sensitive band of the detector), then A_PUM, then A_UIM.
(3) We should make sure that for each pair of sweeps, (where a pair is the in-loop actuator driven measurement, and its corresponding PCAL out-of-loop actuator measurement), make sure that the frequency vector sweeps down for PCAL, then up for the DARM actuator, or conversely down for the DARM actuator and up for PCAL. Either way, this means that the least amount of time will have past from when the DARM actuator passed through low frequency and the PCAL actuator passed through the same frequency points, minimizing the amount of TDCF drift, making the ratio of the two tfs more accurate.
(4) This may already be in the works, but it should have the ability to drive both EX and EY actuator measurements (at the moment, LLO needs this feature.)
On the formatting of the products it makes (in order of preference):
(5) We should include the IFO in the file name
(6) We should include the style of excitation in the file name ("BB" or "SS" for broadband vs. swept sine excitation; eventually I guess there will be "MS" for multi-sine), since otherwise the broadband measurement (1) will be confused with the PCAL2DARM
(7) We should specify *which* PCAL has been used in the PCAL transfer functions (PCALY2DARM tf or PCALX2DARM)
(8) I think we can remove the underscore between DARM and OLG in the DARM_OLG_${timestamp}.xml file. That makes all the files symmetric in their use of underscores, helping out future automatic parsing.
(9) I'd really prefer if we didn't use the ":" special character in the folder and file name, and identify that the time is UTC. I.e. change '2023-01-27T21:20' to '2023-01-23-2140UTC.'
(10) It's far more important for librarianship that the given PCAL measurement file is tied to the given darm actuated measurement. In addition, a measurement collection *needs* to be in the same lock stretch, so the likelihood of needing to differentiate the exact time of each measurement start is not so important. So, let's just put the measurement *collection* start time in all the files (that matches the folder), rather than time stamping each measurement accurately.
(11) Since we're making such a dramatic change in our file names anyways, I wouldn't be opposed to switching the actuation stage names to UIM, PUM, and TST. This way we remove the confusion of L1 being overloaded to mean both the name of the LLO detector and the channel name for the UIM stage.
If all format changes are implemented, a future data set would look like
/ligo/groups/cal/data/H1/measurements/2023-01-27-2140UTC/.
file name which tf is this file?
H1_DARMOLG_2023-01-27-2140UTC.xml 1 / (1+G), DARM Open Loop Gain
H1_PCALY2DARM_forOLG_2023-01-27-2140UTC.xml C / (1+G)
H1_SUSETMX_UIM_2023-01-27-2140UTC.xml A_UIM * C / (1+G)
H1_PCALY2DARM_forUIM_2023-01-27-2140UTC.xml C / (1+G)
H1_SUSETMX_L2_2023-01-27-2140UTC.xml A_PUM * C / (1+G)
H1_PCALY2DARM_forPUM_2023-01-27-2140UTC.xml C / (1+G)
SUSETMX_TST_2023-01-27-2140UTC.xml A_TST * C / (1+G)
H1_PCALY2DARM_forTST_2023-01-27-2140UTC.xml C / (1+G)