The violin mode monitor is now monitoring each fundamental mode indivudually, using the same band pass filters (and notch filters if there's any) from the SUS damaping filters. The RMS value of each mode should equal to the order of magnitude from the nominal observing noise floor. I haven't had a chance to check if that's true for every mode so there probably will be some changes to the gains in the future. At least it's usable and trust worthy enough for damp job.
Dave (on phone), Nutsinee
Concerned about locking issues, I looked into alignment changes and compared before the power outage to after the power outage and there's a few things that stand out.
IMC MC1-3 alignment changes:
mc1 p | 1.3 | urad |
mc1 y | -24 | urad |
mc2 p | 3.5 | urad |
mc2 y | -8 | urad |
mc3 p | 18 | urad |
mc3 y | -22 | urad |
changes of 8-24urad
Total angular change of each chamber:
HAM2 | 71.4 | nrad |
HAM3 | 6.8 | nrad |
Linear change at 16.4m (IMC length)
HAM2 | 1.2 | um |
HAM3 | 0.1 | um |
change due to ISI is in um range
change in IM4 Trans
im4 t p | 0.02 | normalized QPD |
im4 t y | 0.079 | normalized QPD |
change in IM1 alignment required to account for change in IM4 Trans
IM1 / IM4 Trans conversion | IM4 t diff | calculated IM1 change | ||||
pitch | 287.5 | urad/ normalized QPD | 0.02 | 5.75 | urad | |
yaw | 147.3988439 | urad/ normalized QPD | 0.079 | 11.64 | urad |
IM1 would have to move 11.64urad in yaw to account for the change on IM4 Trans.
IM1 hasn't move 11.64urad, so changes on IM4 Trans are coming from somewhere else
change in WFSA and WFSB yaw (before values are approximate)
before | after | diff | |
approx | |||
WFSA yaw | -0.83 | -0.88 | -0.05 |
WFSB yaw | -0.83 | -0.88 | -0.05 |
diff value is not so much the problem
both WFSA and WFSB are close to or already railed in yaw, at -0.9 on a +/-1.0 scale
Seems like these things have been drifting over a long long time, see attached. Note that IMC WFS PIT and YAW signals are physically YAW and PIT on IOT2L, but PIT and YAW in chamber.
In the attached trend for 180 days, you can see that the WFS DC pointing was pretty well centered in YAW (PIT on table) and about 0.25 in PIT (YAW on table) until about 10-days after O1 concluded. There have been 5 distinct jumps since then and each step made the YAW (PIT on the table) centering worse.
It could be the loose periscope mirror on MC REFL periscope in HAM2 (alog 15650) but it's hard to say for sure.
Anyway, this means that the beam could be off on the MC length diode. If that's the case this should be fixed on the table, not by MC WFS picomotors.
Gerardo, John, Chandra Spent a good part of the day troubleshooting CP5 and surveying/fixing the other cryopumps after the electronic actuator install. CP5's LLCV needle coupling was not fully threaded. We tightened and may be seeing an improvement in the % open to % full (% open was approaching upper limit of 100% to maintain 92% full). We measured the pressure in the vacuum jacket of the LN2 supply line. The two ports measured 5 & 6 microns (good vacuum). The top-end regen line connection at CP5 has an ice ball.
13:45 Chris/Bubba/Joe et al out at EX working on wind break wall. All day work. Using tractor outside a well.
15:54 Hanford Emergency EXERCISE take cover message for the 200 area.
16:04 Gerardo,Chandra and John out to MY to check on CP5
16:11 Christina to open exterior high-bay rollup door and move items woith forklift. Currently locked at DC Readout. No one seems to mind.
16:30 Lock Loss OMC M1 WD tripped
16:33 Hanford Emergency Exercise ended.
17:32 Gerardo back
17:33 John and Chandra headed out to Y arm to check on cryo pumps. No incursion into VEA as sensor correction is turned ON.
18:18 John and Chandra back
18:24 Initial alignment. IMC was having some trouble due to some LSC value gone awry; EX was lacking in robust alignment; Too much pitch in DRMI and PRMI
15:00 DAQ training
All of the posts are set in concrete.
adding SEI and PEM tags to wind fence entry to help me find it later. (and thanks Bubba!)
Updated the de-macro'd PSL screens for FSS and ISS, restarted the MEDM web capture program. Noticed that the status, PMC, FSS, and ISS screens didn't display properly because they had been edited and saved while far from the upper left of the display (the web capture program doesn't have a large screen area). I edited the PSL_STATUS.adl, PSL_PMC.adl, PSL_ISS.adl, and PSL_FSS.adl files to move them to the upper left corner of the display. Reran the de-macro script, and restarted the MEDM web capture program again, the screens now appear properly on the web pages. Attempted to check in the modified MEDM screens, but failed. Note that there are several MEDM screens with local mods in the userapps/release/psl/common/medm directory, these should be checked in by the responsible parties.
Peter, Sheila, Evan
We have been having trouble keeping the IMC locked when powering up (without the interferometer).
We found that the UGF of the loop was something like 110 kHz. During O1, we ran with a UGF that was more like 50 kHz. Recall also that the IMC loop at one point had some questionable resonance features above 100 kHz, so it is probably in our interest to keep the UGF on the low side (though we should confirm this with a high-frequency OLTF measurement).
We turned down the loop gain by 4 dB, giving a UGF that is more like 60 kHz. We were able to power up from 2 W to 23 W without lockloss.
Attached is an OLTF measurement after turning down the gain. As usual, the last point is garbage.
To keep the IMC length crossover stable in full lock, Stefan and I increased the gain by 7 dB. This brought the crossover form 16 Hz (nearly unstable) to 40 Hz (stable).
In fact the right way to compensate for the decreased electronic IMC gain is to also decrease the AO gain (not the MCL gain). Now both are decreased by 4 dB.
Jim, Sheila, Haocun,
Turning on the BS stage2 isolation loops sometimes causes locklosses. These are the locklosses for which Hoacun found that there is a glitch in the BS side osem. (27739)
The first attached plot shows the Z isolation loop gain coming on at t=-34 seconds, Jim tells me this comes on with a 10 second ramp, and you can see a small glitch in the Z CPS at around t=-24 seconds when the ramp should be finishing. At just after t=-8 the gain for X, Y, and RZ isolation loops increase, which corresponds to a glitch visible in the CPS, GS13s, and top mass side osem, and optical lever. This is the glitch that breaks the lock.
For now I've rearranged the guardian graph so we won't be isolating the beamsplitter stage 2.
Weird. Please check that the isolation gain is going from 0 to 1 with 2 ramps. The first goes from 0 to (intermediate gain) and the second goes from (intermediate gain) to 1. the intermediate gain is ~ 0.01 (so that the open loop gain at DC is ~1, so that the ERROR SIGNAL of the loop goes to about 1/2 of its final value. both ramps are 5-10 seconds. It looks like the second ramp-time has dropped to 0 (immediate) which would give the system a hearty whack. Please check that there are 2 ramps to get the gain to 1.
WP5938
Evan, Dave:
h1asc model was changed to add REFL A/B WFS channels to the DAQ. 22 channels were added to both science and commissioning frames.
DAQ restart was somewhat messy, requiring mx streamer restarts on various front ends.
To make h1fw0 consistent with h1fw1 and LLO, the /etc/security/limits.conf file was edited to comment out the lines:
controls - rtprio 99
controls - nice -20
Note that the daqd processes on both frame writers are running with priority/nice values of 20/0
Added 184 channels. Removed 8 channels. (see attached)
I remembered that generating the Guardian autoBurt.req file is very hands-on at the moment and was very much out of date (from early O1)
I re-created the autoBurt.req, which allowed conlog to stop attempting to connect to the removed node and now connects to the new nodes. For the record, we now have 97 Guardian nodes running.
Procedure to update /opt/rtcds/lho/h1/target/h1guardian0/h1guardian0epics/autoBurt.req file:
edit the create_guardian_autoburt.py script to get the node listing correct (I use 'guardctrl list')
save the current autoBurt.req into the archive directory
./create_guardian_autoburt.py > autoBurt.req
Then test with
burtrb -f autoBurt.req
IM2 shows more motion in pitch and yaw than IM1, IM3, or IM4. Below is a chart showing the p-p amplitude of the oscillations in the damping signals, in urad, for pitch and yaw.
DAMP_P_IN (urad) | DAMP_Y_IN (urad) | |
IM1 | 0.5 | 0.5 |
IM2 | 3.0 | 2.5 |
IM3 | 0.7 | 0.6 |
IM4 | 1.0 | 0.5 |
Attached is a power spectrum taken today showing OSEM LR, DAMP L, and COIL OUT LR for IM1 and IM2.
See also: alog #26502, alog #25955, alog #25811
Everything looks alright except for one slightly worrying trend. On the Weekly Chiller attachment, the diode and crystal chillers (H1:PSL-OSC_XCHILFLOW and H1:PSL-OSC_DCHILFLOW) both see a slow loss in flow, as does the FE water circuit (H1:PSL-OSC_AMPFLOW) and the HPO power meter water circuit (H1:PSL-OSC_PWRMETERFLOW). In addition, the flow meter for the laser head 1 water circuit (H1:PSL-OSC_HEAD1FLOW) is also showing a slow drop in flow rate. As there is no coinciding increase in humidity (found on the Weekly Env attachment) I don't think we have a water leak. Also, it looks like the Diode chiller flow has leveled off, while the crystal chiller flow does not appear to be doing so. Combine this with the slow increase seen in the pressure of the crystal chiller water circuit (H1:PSL-OSC_PRESS1 and H1:PSL-OSC_PRESS2, sensors located respectively at the entrance and exit of the HPO water manifold underneath the PSL table), this may be an early indication of a flow issue (for example a small obstruction restricting but not blocking the flow) in the crystal chiller water circuit. There's no way to know for sure right now, but this is something we are going to keep a very close eye on.
C. Cahillane I have revamped the uncertainty budget to include covariances between all stages of actuation and all time-dependent parameters. I computed each parameter's covariances in real and imaginary coordinates to provide a consistent basis. I then compiled an6 x 6
Actuation Covariance MatrixC_A
, a2 x 2
Sensing Covariance MatrixC_S
, and an8 x 8
Kappa Covariance MatrixC_K
. Then I compile them into a giant covariance matrixC
:_ _ | C_A 0 0 | C = | 0 C_S 0 | |_ 0 0 C_K _|
Then, I multiply by some conspicuous Jacobian vectorsJ(f)
to get the final2 x 2
uncertainty matrix σ_R^2(f):σ_R^2 = J * C * J'
whereJ
looks like:_ _ | d Re(R) d Im(R) | | --------- --------- .... | | d Re(p_i) d Re(p_i) | J(f) = | | | d Re(R) d Im(R) | | --------- --------- .... | |_d Im(p_i) d Im(p_i) _|
(I was able to use complex differentiation and Cauchy-Riemann here to make the derivatives easier. Recall that R = 1/C + D*A. Now I can compute dR/dA = D and dR/dC = -1/C^2 to formJ(f)
, thanks to 200 year old mathematics) Finally, to make the uncertainties readable by humans, I divideσ_R^2(f)
by|R(f)|^2
, rotateσ_R^2(f)
byangle(R(f))
via a rotation matrix, and read off the square roots of the diagonal of the rotatedσ_R^2(f)
to get the magnitude and phase uncertainties plotted below. I have plotted the uncertainty at GPSTime = 1135136350, the time of the Boxing Day Event. The plot shows an overall increase in magnitude uncertainty of about 1% at low frequency. Phase uncertainty increased by about 0.5 degrees at low frequency. The effects are more dramatic at Livingston. Check out LLO aLOG 26542.
C. Cahillane I have reproduced the uncertainties including covariance for GW150914 for the calibration companion paper. We will have to update the associated uncertainty calculation sections of the paper. I have also attached two .txt files for the R_C01/R_C03 response comparison and the associated uncertainty. Something I failed to emphasize above: Our uncertainties in the response function are now fully covariant... the plots I show of the magnitude and phase are only approximations to the true uncertainty. I have looked at the 3D plots of the covariant ellipses, and it's a fairly good approximation in this case.
C. Cahillane
I have attached and printed my relative covariance matrix. Please see DCC T1600227 for an explanation of the relative covariance matrix.
Basically, the below is percentage covariances.
Re(A_U) Im(A_U) Re(A_P) Im(A_P) Re(A_T) Im(A_U) Re(C_R) Im(C_R) Re(K_T) Im(K_T) Re(K_P) Im(K_P) Re(K_C) Im(K_C) Re(f_C) Im(f_C)
Re(A_U) 0.0166 0.0083 0.0139 0.0079 0.0146 0.0067 0 0 0 0 0 0 0 0 0 0
Im(A_U) 0.0083 0.0209 0.0091 0.0169 0.0071 0.0178 0 0 0 0 0 0 0 0 0 0
Re(A_P) 0.0139 0.0091 0.0163 0.0052 0.0157 0.0066 0 0 0 0 0 0 0 0 0 0
Im(A_P) 0.0079 0.0169 0.0052 0.0181 0.0057 0.0156 0 0 0 0 0 0 0 0 0 0
Re(A_T) 0.0146 0.0071 0.0157 0.0057 0.0251 0.0047 0 0 0 0 0 0 0 0 0 0
Im(A_T) 0.0067 0.0178 0.0066 0.0156 0.0047 0.0187 0 0 0 0 0 0 0 0 0 0
Re(C_R) 0 0 0 0 0 0 0.0207 0.0079 0 0 0 0 0 0 0 0
Im(C_R) 0 0 0 0 0 0 0.0079 0.0208 0 0 0 0 0 0 0 0
Re(K_T) 0 0 0 0 0 0 0 0 0.0025 -0.0002 0.0019 -0.0018 -0.0004 0 0.0004 0
Im(K_T) 0 0 0 0 0 0 0 0 -0.0002 0.0025 0.0017 0.0019 0.0001 0 0.0001 0
Re(K_P) 0 0 0 0 0 0 0 0 0.0019 0.0017 0.0035 -0.0003 0.0002 0 -0.0003 0
Im(K_P) 0 0 0 0 0 0 0 0 -0.0018 0.0019 -0.0003 0.0035 0.0006 0 -0.0005 0
Re(K_C) 0 0 0 0 0 0 0 0 -0.0004 0.0001 0.0002 0.0006 0.0037 0 -0.0036 0
Im(K_C) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Re(f_C) 0 0 0 0 0 0 0 0 0.0004 0.0001 -0.0003 -0.0005 -0.0036 0 0.0054 0
Im(f_C) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0