Title: 09/21/2016, Evening Shift 23:00 – 07:00 (16:00 - 00:00) All times in UTC (PT) State of H1: IFO is locked. Environmental conditions are good. Wind and microseism are low. The seismic band being somewhat elevated in X & Y is subsiding. Commissioning: On going commissioning Outgoing Operator: Ed Activity Log: All Times in UTC (PT) 23:00 (16:00) Start of shift Title: 09/21/2006, Evening Shift 23:00 – 07:00 (16:00 – 00:00) All times in UTC (PT) Support: Jenne, Sheila, Lisa, Kiwamu Incoming Operator: N/A Shift Detail Summary: Good Shift. Had one lockloss at beginning of the shift. IFO locked for ~7 hours, most at 50W NOMINAL_LOW_NOISE. Commissioning work continues apace.
Kiwamu, Darkhan,
Summary
EPICS records used for calculation of the DARM time-dependent parameters have been updated with the values calculated using the most recent DARM model configuration parameters for ER10.
All κ's except for κPU calculated in the CAL-CS model are within reasonable ranges (see attachment 1):
κTST ≈ 0.75
κPU ≈ -0.25
κc ≈ 1.2
fc ≈ 345 Hz
We will investigate why κPU calculations are incorrect.
Details
The H1 DARM model parameters used for generation of the EPICS values are
Runs/PreER10/Common/params/IFOindepParams.conf
Runs/PreER10/H1/params/H1params.conf
Runs/PreER10/H1/params/H1params_2016-09-19.conf
Output files: raw EPICS values, a verbose log and a Matlab file with EP# variables (T1500377-08, Table 2) were committed to the calibration SVN (rev. 3335):
Runs/PreER10/H1/Scripts/CAL_EPICS
./callineParams_20160919.m
./20160921_H1_CAL_EPICS_VALUES.txt
./D20160921_H1_CAL_EPICS_VALUES.m
./20160921_H1_CAL_EPICS_verbose.log
./writeH1_CAL_EPICS.m
Runs/O2/Common/Scripts/CAL_EPICS/writeO2_TDEP_EPICS.m
The changes were accepted in SDF_OVERVIEW (safe.snap and OBSERVE.snap). For ER9 EPICS see LHO alogs 28180, 29104.
Since we have started putting the ALS and SEI_BS nodes into their nominal states, I have uncommented them from the list of monitored nodes for the main IFO guardian.
Recall (alog 28280) that they were commented out before ER9, and have remained so, so that we could set the Observation Intent bit when the IFO was being left alone, so that the analysis teams could check their pipelines. Now we're back in the state of being ready to monitor those nodes, I've uncommented them.
As we wind down on creating new nodes, perhaps TJ can do an audit of all the nodes that should be monitored, and make sure that they are being watched by the main IFO guardian. There shouldn't be anything left that we want un-monitored, except the SDF. We're still not quite ready for that.
Here is a frequency noise coupling transfer function during tonight's lock.
I calibrated REFL9 into watts using a the factor 2900 V/W (from the diode to the output of the demodulator) and 12 dB, −21 dB, and 2 V/V for the analog and digital signal gains.
If the loop is shot-noise-limited (with 4.6 mW on the diode), this implies a noise of about 40 pW/Hz1/2. This would imply a noise in DARM that is more than a factor of 10 below DARM shot noise.
Daniel and I spent some time looking at the various CARM error and control signals we have on hand.
Here we have referred the fast (ao) control signal back to the error point in watts. The horizontal line is the shot noise for 5 mW.
The slow control signal (LSC-REFL_SERVO_SLOW) would also probably work as a proxy for the error point, once properly referred. The error readback (LSC-REFL_SERVO_ERR) is heavily contaminated by some kind of white noise. Ditto LSC-REFL_A_RF9_I_ERR.
[JeffK, Sheila, Jenne]
The bounce mode has been giving us extra trouble today. In the end, we used a very fine bandwidth spectrum to confirm that it really was ITMY's bounce mode (as the monitor bar graph was telling us). We tried out some different phases, and ended up with some settings that are now working. When I went to put the new settings into the guardian, I found that these exact filters had once been used for ITMY, but had been commented out and changed. I'm not sure how long ago this happened, but it was at least before Sheila made the gain=-1 filters, so that the numerical gain is positive for all test masses, since that filter wasn't included in the commented-out settings.
So. Why did the damping phase change some time ago, and why did it change back? Unknown.
J. Kissel, S. Dwyer First attachment -- a screen cap the currently functional Bounce and Roll mode damping settings that work as Jenne describes above. One potential cause Shiela and I explored: we're using DARM_CTRL as our error signal for the bounce mode damping. We've always assumed that the DARM open loop gain is large enough that the open loop gain of the bounce mode damping loop is unaffected by changes in the DARM filter, D, or the DARM plant, or sensing function, C. Given recent, uncompensated issues with SRC cavity detuning cause optical spring changes in the plant, the DARM open loop gain near 10 [Hz] has been questionably low. We've been struggling with interferometric SRC alignment signal, and therefore leaving SRC angular control essentially off recently. This implies the SRC detuning can be changing from lock-stretch to lock-stretch, which means the DARM optical plant is changing from lock-stretch to lock-stretch. And if the overall DARM open loop gain is low enough, then the phase impacts of this change in optical plant will change the phase necessary to damp the bounce modes. The second attachment compares Kiwamu's DARM OLG TFs taken on 2016-09-16 vs 2016-09-21, and indeed, the open loop gain magnitude is only ~4 to 5 at 10 [Hz], and once can clearly see substantial phase differences between the two measurements. The third attachment shows the loop math to aide the following proof of how the two loops are coupled: C = DARM IFO plant, or sensing function D = DARM filter bank A = ISC L to TST L DARM super-actuator TF V = Bounce mode damping filter alpha = TOP V to TST L actuation function xi = coupling from TST L to DARM Delta L_{res} = Delta L_{V} + Delta L_{ctrl} = Delta L_{V} + A D C Delta L_{res} d_{ctrl} = D C Delta L_{res} --> Delta L_{res} = d_{ctrl} / (D C) d_{ctrl} / (D C) = Delta L_{V} + A D C d_{ctrl} / (D C) d_{ctrl} = D C Delta L_{V} + A D C d_{ctrl} G_{darm} = - A D C (1 + G_{darm}) d_{ctrl} = D C Delta L_{V} d_{ctrl} / Delta L_{V} = D C / (1 + G_{darm}) --> G_{V} = alpha xi beta D C / (1 + G_{darm}) --> IF G_{darm} << 1, then G_{V} ~ alpha xi beta D C and we have dependence on the changes in the optical plant of DARM. --> IF G_{darm} >> 1, then G_{V} ~ alpha xi beta D C / G = alpha xi beta / A and we have the scenario we have always assumed was happening. Now that Jenne's just restored old damping, this is less of a suspicion, but I wanted to write it down so that we keep this sort of loop inter-dependence in mind.
15:43 Cleaning crew headed to mid stations
15:47 Keita doing ISS measurements
16:31 Karen leaving MY
16:43 Jim headed to EX to tame the BRS beast
16:48 Kiwamu to LVEA to check TF of ISS loops
16:50 Christina left MX
17:01 Jim back. Report is damping was turned off last night to allow ring down(didn't happen). At this point no correcive action has been taken.
17:08 Kyle to MY
17:33 Chandra and John to head to MY
17:34 Kiwamu out of LVEA. We can return to locking
17:45 Jeff K restarting CAL_CS model
18:18 John and Chandra are back
18:25 Kyle back from MY
21:03 Kyle Gerardo and Chandra going to MY
21:49 Kyle Gerardo and Chandra back from MY
22:30 Tour group into control room
Nothing here looks out of the ordinary.
Here is some of the data from Saturday's jitter injections (29780), plotted differently. The main point is that we should be able to reduce the yaw jitter coupling by at least a factor of a few, and this should help the DARM spectrum, but not enough to get the noise a factor of 10 belpw the quantum noise with the current level of jitter.
I have taken open loop transfer functions of the 1st loop in this morning to see where the UGF currently is.
Based on the measurements, I set the gain slider in the medm to 9 dB which gives us a UGF of 50-60 kHz.
Also, the raw data is attached as a zipped file.
Apart from these measurements, I confirmed two features as follows.
During the measurements, I kept the suspiciously high offset value of 20 for the 1st loop. The second loop was off.
I added 125 mL to the crystal chiller. I noted that the fill port water is very turbulent, swirling and full of air bubbles. I recall that it is usually calm.
FAMIS 6489.
SudarshanK, TravisS, RickS
Yesterday, we went to Xend to assess and optimize the Pcal beam locations on the ETM surface.
Since O1, we have known that the beams were clipping somewhere on the receiving side.
Unsing an updated method of assessing the beam locations that is based on the work that Miranda Chen (REU student from UTRGV) did this summer (basically using the ESD electrode pattern rather than the edge of the ETM) we found that the Pcal beams were quite far from their optimum locaitons (see first image attached below). The offests from the optimal locations (111.6 mm above and below the center of the face of the optic) were U [ 1.71, 12.27], L[10.02, -7.27] where U and L denote the upper and lower Pcal beams and the coordinates are [x offset, y offset] in millimeters with the usual conventions, positive x to the right, positive y up. Because we use 2" diameter optics in the Pcal periscope structure and because the receiveing-side mirrors are twice the distantance from the ETM, an offset of 12 mm at the ETM would correspond to an offset of ~24 mm at the periscope, likely the cause of the clipping we have observed. The reflected power measured by the power sensor in the receiver module increased by about 50% from about 4 V to 6.2 V.
We adjusted the beam locations using the steering mirrors in the Pcal transmitter module and ended up with positions that are within a mm of the optimal locations (see second image attached below): U [ 0.15, 0.43], L[-0.18, 0.05].
The third image below shows the Pcal spots on the ETM surface (inside green circles), visible when the chamber illuminator is off.
We are in the process of modeling the expected calibration errors resulting from bulk elastic deformation induced by the Pcal forces being so far from the optimal locations, but we expect errors as large as 20-40% at frequencies above 4 kHz for offsets as large as what we had before correcting the positions yesterday.
Attached is a plot that shows the expected calibration error at higher frequencies due to the effect of bulk elastic deformation of the test mass. The estimated error is calculated using the COMSOL modeling (worked on by Nicola and Shivaraj this summer) for the pcal beam configuration prior to moving the beam (LHOX_ER9). This is the same configuration in which we were running the the high frequency calibration lines during ER9 and even during O1 (there is no reason to believe the beam positions have changed appreciably since O1). The measurement data plotted alongside are the high frequency calibration lines run during the end of O1 and described in LHO alog 26275. The data is normalized to the model at 1 KHz and agrees closely to the model at frequencies above it. The beams are now moved to their optimal position as described above. The model shows smaller error (plotted in cyan) due to bulk elastic deformation for this optimal configuration (LHOX_ER10). Similar measurement will be done during and before ER10 in order to confirm the model.
Note that the movement of the beam on the ETM, per quarter turn on the adjustment knobs of the mirror mounts in the tramsmitter module, is about 10 mm (judging by what we experienced yesterday).
If one works out the numbers using the 100 TPI actuators in the mount and the 1.5" between the actuator and the pivot point, the result is about 12 mm per quarter turn, assuming the mirror is about 7 m from the mount. It might be closer to 8 meters given the distance from the mirror mount to the periscope and the path in the periscope (larter for the lower - outside - beam).
Attached is the OLTF in two configurations with 7dB VGA gain.
50W (actually 48W), AC coupling OFF, and boost ON (solid line)
50W (actually 48W), AC coupling ON, boost OFF (dashed).
UGF is about 9kHz with phase margin of 40 deg or so (boost ON) or 50 (boost OFF).
Boost buys us about 9dB more gain at 1kHz.
I asked Kiwamu to do an analog measurement up to higher frequency on the floor.
Here is a transfer fucntion with SR785 to check the high frequency portion.
Also, the attached zip contains the data, plot script, and figure.
Taking this data I looked at modifications to the ISS board to increase its bandwidth. The attached plot shows:
Adding the 20kHz zero is a no brainer, since it only requires to limit the dominant pole in the circuit. It improves the phase margin over the measured curve and allows the ugf up to move to 20kHz. This will increase the ISS gain by 2 at 1kHz. The increased ugf and phase margin will in turn allow us to move the knee of the boost higher with the option to add a second boost. The later two solutions will add another gain of 2 at 1kHz.
We engage the ISS boost twice today in low noise, and did not see any impact on the DARM noise. We expected an improvement at 1 kHz at least. Attached are before and after spectra of the in and out of loop diodes (at least that's what I think the new cahnnel names mean). If it is correct that INNER means in loop and outer means out of loop, we are sensor noise limited at 100 Hz with the boost on.
Lisa, Kiwamu,
We think that the calibration has been wrong and therefore it lifted up the noise floor below 300 Hz. We need another set of eyes tomorrow to doublecheck our theory (we are currently too sleepy to do systematic investigation).
In short, we believe that the sign of ETMY L3 stage in CALCS (or somewhere else similar to it) is wrong which is exactly the same situation as what happened in this past July (28396).
Because I knew that our DARM open loop model is accurate and consistent with the recent measurement (29748), I made a calibration filter for DARM_IN1 which converts DARM_IN1 to DARM displacement as opposed to the use of both DARM_IN1 and DARM_OUT. Here is a comparison of the CALCS spectrum against the spectrum derived from DARM_IN1.
As shown in the plot, the CAL CS spectrum overestimates the noise floor below 300 Hz or so. This is exactly the same behavior as what we have experienced in this past July. In addition, we have noticed that the noise floor of CALCS changed as a function of the DARM control gain which should not happen in the calibration scheme used in CAL CS. Also, when we flipped the sign of the EY L3 stage in CAL CS, the leve of the noise floor became identical to the one derived by DARM_IN1 and also became insensitive to the control gain. This increased our confidence that the L3 sign was wrong in CALCS.
We are leaving the L3 stage gain flipped (DRIVEALIGN_GAIN -30 --> +30) for the night. If our theory is correct, we regain the binary range back to ~60 Mpc with this change.
Also, we took a DARM open loop and PCAL sweep measurement within the same lock stretch. We did not analyze them yet, but they are available at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/PCAL/2016-09-21_H1_PCAL2DARMTF_4to1200Hz.xml
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/DARMOLGTFs/2016-09-21_H1_DARM_OLGTF_4to1200Hz.xml
Also, my code which generated the calibration filter for DARM_IN1, as well as, the generated filter are available at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/CalibrateH1DARM_IN1.m
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/DARM_IN1_calib.txt
I don't know what was decided this morning, but somehow we ended up with the wrong actuator sign in the front-end calibration again. So I reinstated the sign flip in the drivealign calibration filter.
After we fixed the sign flip on the night, the Pcal to CAL-CS transfer function looked indeed correct. See the attatched screenshot below.
The transfer function from Pcal to CAL-CS is almost unity in magnitude and zero in phase which double-confirms that the sign flip was the right action. The dtt template was updated with the latest DELTAL_EXTERNAL whitening filter, known delays.
The dtt file can be found at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/PCAL/2016-09-21_H1_PCAL2DARMTF_4to1200Hz.xml
The matlab script which produced the calibration filter can be found at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/H1_pcal2darm_correction.m
Finally the calibration filter in ascii formt is available at:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/ControlRoomCalib/pcal2darm_calib.txt
By the way, in the script, I needed to add an additional minus sign in order to get the resulting phase close to zero rather than close to 180 deg. I feel like this is one of theose things we had found during O1, but I can't recall what introduced a minus sign. In addition, the calibration filter currently does not include the effect of the supernyquist poles of OMC DCPDs which introduces a phase delay at high frequencies.
The open loop transfer function(s) can be now analyzed by a copy of Evan G's code,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/DARMOLGTFs/compareDARMOLGTFs.m
The attached are the resulting figures from the code. I have not adjusted kappas or examined each piece of the DARM loop yet, but the model showed a good agreement with the measurement-- no crazy bug so far in the model.
I took a quick look at six hours of 30-minute SFTs automatically created by FScans this morning (thanks for setting the intent bit!), to see if recent line mitigation attempts have reduced the amplitude of the 1-Hz and other combs at low frequencies. Unfortunately, the low-frequency noise floor is too elevated to say much yet about that mitigation success, but in the band 28-32 Hz, where last night's noise is lower, there do seem to be fewer and lower-level lines, including reduced amplitudes for the 1-Hz comb with a ~0.25-Hz offset. Please note that the 56.84-Hz comb reported in the ER9 data (present but weaker in O1 data) remains quite strong. There are other strong lines present, too, but I gather noise-hunting is just getting started. The 56.84-Hz comb suggests a DAQ problem somewhere, as noted before. The attached plots show different bands of O1 data (narrow black curves) superposed on last night's data (broad red swath). In each case, an inverse-noise weighting is used, to suppress periods of elevated noise. Figure 1 - 10-2000 Hz Figure 2 - 10-28 Hz Figure 3 - 28-32 Hz Figure 4 - 32-50 Hz Figure 5 - 50-100 Hz Figure 6 - 100-200 Hz Figure 7 - 200-1000 Hz Figure 8 - 1000-2000 Hz
Ansel just brought to my attention this alog entry by Robert identifying a 56.8-Hz line with the EX HWS. In that entry Robert suggests isolating the HWS power supply at EX as was done at EY (if I understand correctly) or shutting off the HWS during O2. Is there any reason to leave either HWS on during O2? The 56.84-Hz comb was visible at a low level in O1 data.
Update after looking at this + subsequent lock stretches (through last night):
These results are pretty consistent across the recent locks. Attached: a representative plot of these combs in the 30-50Hz region in 2 hours of the most recent lock stretch.
Kiwamu I, Jeff K, Darkhan T,
Overview
Today we looked at the calibration line coherence values calculated in the front end. We discovered that in the front-end model with the currently used averaging parameters the coherence value is updated once every 10 seconds (first 1.5 minutes in Fig. 1).
We propose modifying the averaging code to improve coherence calculation and avoid potential aliasing (see details).
Details
A front-end model that calculates coherence uses N data points taken every Scycles computational cycles to calculate cross-spectral density of the signals. Scycles is controlled by an EPICS record $(IFO):CAL-CS_TDEP_COH_STRIDE
(or simply STRIDE
): Scycles = FE_RATE * STRIDE
. There are drawbacks associated with this approach:
STRIDE
seconds;
We can deal with the first problem listed above by reducing STRIDE
. On Fig. 1 we show coherence values for N = 10 and STRIDE
set to 10, 5, 1, 1/16 and again 1. Notice that this test was done when the IFO was not locked, thus we do not expect a coherence of ~1. When STRIDE
is set to 1/16, we can see that the number of averages must be increased in order to include actual fluctuations in the signals (in the last 2.5 minutes N = 120).
Fig. 1
Several minutes later IFO locked (at t = -5 in Fig. 2) and the coherence became ~0.8. After we set the line amplitude to its nominal value we got coherence of ~1.
Fig. 2
Next, to avoid aliasing we should use all data points (equivalent to setting STRIDE = 1/FE_RATE
in the current code) and increase N accordingly. Thus to integrate over 10 seconds and avoid aliasing the current code will require O(FE_RATE
* 10) = O(160k) operations per cycle and a buffer for 160k values, which is unnecessary expensive.
A following minor modification of the averaging code can solve the issue described above. Instead of adding every Scycles'th data point into the averaging buffer, we could insert an average of Scycles values. E.g. buffer_and_average()
can be modified as follows:
...
static int mini_sum = 0;
...
//Increment cycle count
mini_sum += data;
cycle_counter++;
if (cycle_counter >= cycles_between_data) {
buffer[current_pointer] = mini_sum / ((double) cycles_between_data);
current_pointer++;
cycle_counter = 0;
mini_sum = 0;
}
...
With this modification and N = 160, STRIDE = 1/16 (Scycles = 1024), the coherence will be calculated with 10 second integration and will require O(160) operations per cycle, and the coherence value will be updated every 1/16 of a second.
Jeff K, Kiwamu I, Joe B, Darkhan T,
The modifications suggested above have been implemented at LHO (the modification was implemented during a bug fix, LHO alog 29876). The modifications also include an increased max buffer size:
...
#define MAX_SIZE 256
...
static double mini_sum = 0;
...
//Increment cycle count
mini_sum += data;
cycle_counter++;
if (cycle_counter >= cycles_between_data) {
buffer[current_pointer] = mini_sum / ((double) cycles_between_data);
current_pointer++;
cycle_counter = 0;
mini_sum = 0;
}
...
The changes have been committed to cds_user_apps
repository, r14301.
Following is how coherence was calculated for locked but with high noise floor at lower frequencies (see attached displacement ASD during this measurement), so only PCAL_LINE2 (at 331.9 Hz) has coherence of ~1, and all three of the ~35 Hz lines do not have good coherence:
Fig. 1
The coherences were calculated with H1:CAL-CS_TDEP_COH_STRIDE
set to 1/16 and H1:CAL-CS_TDEP_COH_BUFFER_SIZE
(N in the original alog) set to 80 (at [-4, -2] min time interval) and 160 (at [-2, 1] min time interval). With H1:CAL-CS_TDEP_COH_BUFFER_SIZE
set to 160, each of the coherence calculations include data points from past 10 seconds.
Attached is a plot of the DARM time-dependent parameters calculated in the front-end when the IFO noise floor was reasonably low (at about 23 UTC). Notice that Y-axis for coherence is zoomed to 1 for a better detail.
It seems that the ER9 Matlab DARM model parameters for H1 that was used for calculation of current TDEP EPICS values needs an update. The ESD sign is opposite to the one in the DARM model. Calculation of κPU is hugely biased due to the wrong sign of κTST and it's magnitude being incorrect by an order of magnitude.
During last night's lock stretches the sign of κTST calculated in the front-end was positive (see attachment 2), opposite to the currently calculated value. A possible explanation for this is that L3 stage sign flip commisioning activities are underway (see LHO alog 29860).