Staging ladders, pumps etc. for GV10 AIP replacement (tomorrow) Drove past CS on Y-arm side @ 1415, 1435, 1455, 1515 hrs. local
Shift Summary: Total duty cycle were 47%, 36% and 16% for three days respectively. Mostly locks were broken due to earthquakes/ increased ground motion or saturation of different parts (like ITMX, PRM etc) Other than some non-stationarity at low frequency, spectrogram looked clean. Most of the high SNR glitches were noticed below 300Hz In general high SNR glitch rate was low, but increased due to seismic activity and ETMY saturation 60Hz magnetic periodic glitches are still present with SNR <15, 50Hz glitches are noticed ( alog) Still loud glitches due to ETMY saturation are the main problem for LHO Most of the loud events are vetoed out successfully by Hveto Glitches caused by earthquake showed up as a very loud event (with new SNR 8.5) in BBH search on 7th September. Some follow up studies of the Loud glitches: It is suspected that the load glitches might be caused by the ETMY saturation or may be because of some other reason. I scanned few randomly chosen loud glitches. Few omega scans can be found here: https://ldas-jobs.ligo-wa.caltech.edu/~nairwita/wdq/H1_1124466556.481/ https://ldas-jobs.ligo-wa.caltech.edu/~nairwita/wdq/H1_1124467378.953/ https://ldas-jobs.ligo-wa.caltech.edu/~nairwita/wdq/H1_1125200626.78/ https://ldas-jobs.ligo-wa.caltech.edu/~nairwita/wdq/H1_1125622097.394/ I did see the glitches in ASC_Y_TR_{A/B} channels. But not always before DARM glitches. I am mentioning these particular channels as during ER7 dust glitches were observed in these channels too. But I have scanned all the times given in the alog by Stefan and could not find the same pattern. https://ldas-jobs.ligo-wa.caltech.edu/~nairwita/wdq/H1_1126294545/ https://ldas-jobs.ligo-wa.caltech.edu/~nairwita/wdq/H1_1126434798/ https://ldas-jobs.ligo-wa.caltech.edu/~nairwita/wdq/H1_1126437892/ https://ldas-jobs.ligo-wa.caltech.edu/~nairwita/wdq/H1_1126441165/ https://ldas-jobs.ligo-wa.caltech.edu/~nairwita/wdq/H1_1126442379/ I also ran the modified Lockloss tool with the help of Nutsinee using default channel list and did not find any significant channel (other than SUS-ETMY_L3_MASTER_OUT) except the glitch happened at 1126437892. I have attached the lock loss plot for this particular loud glitch and the significant channels came out as the result of modified lockloss script are as given below (the numbers in the second column show the seconds after those channels had loud glitches): H1:ASC-OMC_B_YAW_OUT_DQ 0.000 H1:ASC-OMC_B_SUM_OUT_DQ 0.000 H1:ASC-OMC_B_PIT_OUT_DQ 0.000 H1:ASC-OMC_A_YAW_OUT_DQ 0.000 H1:ASC-OMC_A_SUM_OUT_DQ 0.000 H1:SUS-ETMY_L3_MASTER_OUT_LR_DQ 0.001 H1:SUS-ETMY_L3_MASTER_OUT_LL_DQ 0.001 H1:SUS-ETMY_L3_MASTER_OUT_UL_DQ 0.001 H1:ASC-OMC_A_PIT_OUT_DQ 0.001 H1:ASC-AS_B_RF36_Q_YAW_OUT_DQ 0.001 H1:ASC-AS_A_DC_PIT_OUT_DQ 0.001 H1:SUS-ETMY_L3_MASTER_OUT_UR_DQ 0.001 H1:ASC-AS_A_DC_SUM_OUT_DQ 0.001 H1:ASC-AS_A_RF45_Q_YAW_OUT_DQ 0.001 H1:ASC-AS_A_RF45_Q_PIT_OUT_DQ 0.001 H1:ASC-AS_A_RF45_I_PIT_OUT_DQ 0.001 H1:ASC-AS_A_RF36_Q_PIT_OUT_DQ 0.001 H1:ASC-AS_B_RF36_I_YAW_OUT_DQ 0.001 H1:ASC-AS_B_DC_SUM_OUT_DQ 0.001 H1:ASC-AS_A_RF45_I_YAW_OUT_DQ 0.001 H1:ASC-AS_A_RF36_I_YAW_OUT_DQ 0.001 H1:SUS-ITMY_L3_LOCK_P_OUT_DQ 0.004 H1:SUS-ITMY_L3_LOCK_P_IN1_DQ 0.004 H1:SUS-ITMY_L2_LOCK_P_OUT_DQ 0.004 H1:SUS-ITMY_L2_LOCK_P_IN1_DQ 0.004 H1:SUS-ITMX_L3_LOCK_P_IN1_DQ 0.004 H1:SUS-ITMX_L3_LOCK_P_OUT_DQ 0.004 H1:SUS-ITMX_L2_LOCK_P_OUT_DQ 0.004 H1:SUS-ITMX_L2_LOCK_P_IN1_DQ 0.004 H1:SUS-ITMY_L1_LOCK_P_IN1_DQ 0.007 H1:SUS-ITMY_L1_LOCK_P_OUT_DQ 0.007 H1:SUS-ITMX_L1_LOCK_P_OUT_DQ 0.007 H1:SUS-ITMX_L1_LOCK_P_IN1_DQ 0.007 H1:ASC-DHARD_P_OUT_DQ 0.009 H1:SUS-ITMY_M0_LOCK_P_IN1_DQ 0.011 H1:SUS-ITMX_M0_LOCK_P_IN1_DQ 0.011 H1:ASC-DHARD_Y_OUT_DQ 0.140 For all those five times (given in alog 21522) SUS-ETMY_L3_MASTER_OUT had glitches 0.001s after DARM had the loud glitch.(-0.001s before as written in the plot title- Thanks to Hang for noticing this). In conclusion, it is still not clear to me if ETMY saturation is the reason behind these loud glitches or not.
J. Kissel, D. Tuyenbayev, J. Betzwieser, S. Kandhasamy We recently found out LHO has not included the LSC Output matrix in their matlab model of the DARM loop (see LHO aLOG 21601), and this resulted in a discrepant phase in the calculation of the time-dependent parameters. Independently, of the few hardware injections we've managed to test thus far, there remains a minus sign found in the H1 reconstruction (LHO aLOG 21616). Finally, Maddie has found that the sign of DELTAL_CTRL is different between the two observatories (no aLOG yet). The messages: - We have found that CAL-CS *also* does *not* include this LSC OUTPUT MATRIX -1. We think this is an error, yet somehow the CAL_DELTAL_EXTERNAL is still showing sensible results, and we don't understand why. - We believe this explains the missing sign in the inverse actuation filter. LHO has been inverting the DARM matlab model's version of the actuation function, which did *not* include the LSC output matrix, i.e. a -1, and hardware injections are injected upstream of this output matrix in the DARM path. - We don't understand what we see when the CAL-CS installations comparing between sites (LHO does NOT account the output matrix, where LLO does, and both sites produce sensible DELTAL EXTERNAL ASDs). Attached are screenshots of the CAL-CS MEDM screen, the replica of the LSC output matrix, and its actual counterpart in from the LSC overview screen, to prove to myself what is true. The path forward: - A sanity check: Take two transfer functions, DELTAL_CTRL to DELTAL_EXT and DELTA_RESIDUAL to DELTAL_EXTERNAL. Export them into matlab, add them and subtract them. Check if DELTAL_EXTERNAL would even notice if A was + or -. Our intuition says "yes, it should make some nasty bump or zero in the calibrated ASD." - Make a sign table like LLO has in LHO aLOG 20587. - Plot comparisons between both models, and make sure it makes sense. - Figure out how to handle "the feedback minus sign" convention, to confirm that we're both obeying what's shown in LHO aLOG 21601
C. Cahillane I have posted my latest uncertainty components plots including the propagated Actuation and Sensing Uncertainty: I have also deflated my kappa uncertainties to 3% and 3 degrees: σ_|A_tst| = A_coeff_sigma_mag_A_tst .* abs(A_tst); σ_|A_pu| = A_coeff_sigma_mag_A_pum .* abs(A_pum) + A_coeff_sigma_mag_A_uim .* abs(A_uim); σ_|C_r| = C_coeff_sigma_mag_C_r .* abs(C_r); σ_|kappa_tst| = 3; σ_|kappa_pu| = 3; σ_φ_A_tst = A_coeff_sigma_phase_A_tst; σ_φ_A_pu = A_coeff_sigma_phase_A_pum + A_coeff_sigma_phase_A_uim; σ_φ_C_r = C_coeff_sigma_phase_C_r; σ_φ_kappa_tst = 3; σ_φ_kappa_pu = 3; σ_kappa_C = 3; σ_f_c = 23.4731; We have very high phase uncertainty above 1000 Hz due to our large systematic error in our sensing phase there. Recall that I have simply quadratically summed our systematics and statistics into a single uncertainty expression, and that this is giving up valuable info on our error! Otherwise, we have reasonable error even for 3% and 3 degrees uncertainties in the kappas.
15:00 UTC Handoff from Nutsinee. IFO in observing mode. 16:46 UTC Jeff B. to mechanical room to check fitting on pump 16:47 UTC Gerardo getting trailer and attaching to pickup truck 16:49 UTC Jeff B. back 16:58 UTC NORCO technician here 17:00 UTC NORCO technician through gate 17:04 UTC Gerardo taking NORCO technician to end X, pressure testing LN2 dewars on way back towards vertex 17:04 UTC Out of observing 17:16 UTC Back in observing 17:17 UTC Helicopter flyover 17:37 UTC Gerardo at end X, going to mid X ~17:44 - 17:50 UTC Gerardo reports hearing shelling from Yakima firing range 17:57 UTC Tour in control room 18:26 UTC Gerardo and NORCO technician at corner station. Will move towards end Y 19:45 UTC Helicopter flyover Still in observing mode at ~ 70 Mpc.
Gerardo got auxcart while at end X. Says he did not go into LVEA, just opened door, wheeled it out and put it in trailer. ~ 17:15 - 17:20 UTC 20:17 UTC Gerardo and NORCO technician done. Technician will be leaving site shortly.
~ 19:45 UTC Went outside to look. Seemed to pass over Y arm near corner station heading toward inside of arm vertex.
A tour group was on site this morning. Arrival time at LSB = ~9:00 AM. Departure time = ~11:45 AM. Group size = ~20 adults. Vehicles at the LSB = ~7 passenger cars. The group was in the control room near ~11:00 AM and on foot near the overpass near 11:30 AM.
17:17 UTC Heard what turned out to be a helicopter flying overhead. Gerardo says he saw it come within half a mile of end X. We were in observing mode.
17:04 UTC Taking out of observing so Gerardo can take LN vendor along X arm. (WP 5504)
17:16 UTC Back into observing. Told that Gerardo's work will not affect state of IFO.
STATE Of H1: Observing OUTGOING OPERATOR: Nutsinee QUICK SUMMARY: Winds less than 20 mph. Lights off in LVEA. Lights appear off in PSL enclosure. Lights appear off at mid and end stations.
RickS, SudarshanK, CraigC, JeffreyK, DarkhanT
To calculate DARM time-varying parameters we use EPICS records precalculated from DARM OLG TF model, as described in T1500377-v7.
Earlier we reported that EP1 calculated from the canonical DARM model for ER8/O1 had an unexplained phase discrepancy (see LHO alog 21386) that came from measured TF taken between x_tst excitation point to DARM_ERR at cal. line frequency being off by -136.7 degrees compared to TF calculated accoring to Eq. 5 in T1500377 from DARM model. In this alog we outline current status of our investigations of this discrepancy.
The negative sign of the DARM feedback loop that was shown on the simplifed DARM loop diagram in T1500377-v7 was not placed where it actually appears. This update affects only how xtst line to DARM_ERR (and DARM_CTRL) TF is calculated in the DARM model; Pcal and xctrl line to DARM_ERR (and DARM_CTRL) TF equations remain valid in T1500377-v7.
Figure below shows the correct location of the sign flip of the DARM loop (that's not included into C, D or A) accroding to our investigations; we'll update T1500377 with the correct diagram in the next version. (notice that this simplified diagram, as it was cited in T1500377, was borrowed from G1500837 where it might also need to be corrected)
In ER8/O1, since now we have xtst (ESD) calibration line that is injected from the suspension front-end model (inside of the block "A" on the diagram), additional to the knowledge that the sign flip is between the xctrl (DARM line) excitation point and ΔLext, we also need to know the location of it w.r.t. the xtst excitation point.
With the -1 sign flip placed in the new location Eq. 5 and Eq. 7 in T1500377 should not have a "-1" factor. Hence, Eq. 19 will also not have a "-1" factor, meaning that our calculation of EP1 was incorrect by 180 degrees.
Currently there's an unexplained +44.4 degrees of discrepancy (instead of earlier -136.7) between measurement x_tst / DARM_ERR vs. the model itself, that appears in EP1 (we looked into the measurement of x_tst / DARM_ERR on Sep. 10). We are investigating the source of this discrepancy.
The location of the sign was confirmed by using measurements of
meas. file: CalSVN/Runs/ER8/H1/Measurements/FullIFOActuatorTFs/2015-08-29/2015-08-29_H1SUSETMY_L3toDARM_LVLN_LPON_FullLock.xml
meas. file: CalSVN/Runs/ER8/H1/Measurements/DARMOLGTFs/2015-09-10_H1_DARM_OLGTF_7to1200Hz.xml
meas. file: CalSVN/Runs/ER8/H1/Measurements/DARMOLGTFs/2015-09-10_H1_DARM_OLGTF_7to1200Hz.xml
Are you talking about the LSC output matrix as a place to keep a minus sign or somewhere else ?
Kiwamu, that's correct the -1 in the "H1:LSC-ARM_OUTPUT_MTRX" was not included into either D or A.
And as I can see from comparing measurements to the model, it's the only sign flipping factor that was not included into C, D or A transfer functions of the DARM model.
When the Operator found the ISIs in the wrong SDF state, 21609, they reported digging through the logs but not finding anything. After reporting what the filters do, they accepted the changes and went to observing. This is just the opposite of what we should do. If no supporting evidence is found for the change, reverting to the .snap values is the correct path. Of course there is some risk to the IFO lock in filter switching, not very appealing after being out for so long.
In the Evening shift operator's summary, The TM ISIs seem to be reported back in high gain:
02:05 Attempt to bring back End Station ISIs seems succesful. GS 13s back to high gain. Seismic graph is showing 3µ/S.
02:09 Ditto for ITMs
02:10 Begin bringing up Input and Output HAM SEI.
02:15 Kissel brought ESDs back and restored ETM alignment.
02:31 All SEI back to nominal isolated states. GS13 gains switched back to HIGH.
This sort of implies the ITMs were put back into High gain but that is not the case. They were switched to low gain (H1:ISI-ITMY_ST2_GS13INF_H1_SW1R: FM4 & 5 On) 0005 utc and remain there still. At this point the SDF should have been consulted for proper configuration.
The SEI system is untouch by IFO locking guardians. SEI SDFs should be green well before looking at going into Observation mode.
One may argue that this difference is not critical: these filters compensate for changes in the analog gain and whitening. The output level of the filter bank is unchanged. On the other hand in nominal seismic environment, having greater SNR when digitizing the GS13 signal gives better ISI Damping and Isolation.
Operators, please always feel free to contact me anytime reqarding such matters, even at 4am--Hugh
Four burst signals have been injected into H1 since the new inverse actuation filter was installed Sunday evening (Timeline of CAL-CS Calibration Filter Updates), with different waveforms: GPS 1126270500 - White noise burst, frequency 125 Hz, bandwidth 150 Hz GPS 1126280500 - White noise burst, frequency 300 Hz, bandwidth 350 Hz GPS 1126300500 - Sine-gaussian, frequency 20.82 Hz, Q=7.32 GPS 1126310500 - Sine-gaussian, frequency 413.0 Hz, Q=85.1 The low-frequency, low-Q sine-gaussian offers the clearest check of the calibration amplitude and phase among these signals. (It would be better to use detchar injections, i.e. a set of sine-gaussians at a range of frequencies, as was done during ER7, but we have not performed any detchar injections during ER8 yet.) I used a matlab script (attached) to plot the intended strain waveform (the file produced by Chris P. and read by tinj to inject the signal) and the H1:GDS-CALIB_STRAIN channel from the hoft frames in the archive at Caltech. Both have been bandpass filtered bidirectionally with 'filtfilt' around the frequency of interest. I also did a crude matched filter, stepping the intended strain waveform by integer samples and considering both upright and inverted overlaps with the data. As you can see from the plot, the signal that came through in the H1:GDS-CALIB_STRAIN channel is consistent with being *inverted* relative to the intended strain signal. That was also the case in ER7, but we thought the recent calibration work and a careful look at sign conventions would have resolved that. Is there any possibility that the GDS calibration process running on Monday, producting H1:GDS-CALIB_STRAIN, had not yet been updated with the final resolution of sign convention?
TITLE: Sep 17 OWL Shift 07:00-15:00UTC (00:00-08:00 PDT), all times posted in UTC
STATE Of H1: Observing at 77 Mpc
SUPPORT: Sheila
SHIFT SUMMARY: After 12+ hours of not locking, we are back in business. I redid the initial alignment followed the printed Initial Alignment Checklist on the desk after the seismic nosie came down to almost nominal because PRMI looked hopeless. LLO is still trying to acquire lock.
INCOMING OPERATOR: Patrick
Activity log:
8:00 Begin initial aligment. Adjusted PR3 to maximize COMM beatnote. Spent 10 minutes at INPUT_ALIGN without luck. Trended IM4 and PR2 back to the last time the ifo was locked. I brought IM4 back to where it was. Touched PR2 YAW to get 00 mode on As Air camera.
8:04 Darkhan left
9:11 Craig left
9:12 BS ISI WD tripped during MICH_DARK_LOCK twice. Requested down and waited until the optic became settled and moved on.
ENGAGE_ASC_PART3 took ~5 minutes.
Guardian stalled at DC_READOUT_TRANSITION (alog21608). OMC was not ready for handoff and was locked at the wrong mode. I called Sheila for help but the ifo lost locked shortly.
10:52 Locked at NOMINAL_LOW_NOISE
11:13 Back to Observing after I cleared the SDF diff.
13:15 Lockloss. More earthquake....
13:46 Locked at NOMINAL_LOW_NOISE
13:48 Undisturbed.
15:00 Hand off to Patrick.
Attached is agallery of 5 "dust" glitches. Still clueless of what they are, but - ETMY saturation is a symptom, not a cause - it is not possible to produce such a white glitch from saturating a drive. - The DCPD spectrum shows a roll-off for all of them - But the roll-off frequency (i.e. glitch duration) varies significantly = from about 300Hz to 3kHz. Example 2: GPS: 1126294545 UTC: Sep 14 2015 19:35:28 UTC ETMY saturation: yes Example 3 GPS: 1126437892 UTC: Sep 16 2015 11:24:35 UTC ETMY saturation: yes Example 4 GPS: 1126434798 UTC: Sep 16 2015 10:33:01 UTC ETMY saturation: yes Example 5 GPS: 1126441165 UTC: Sep 16 2015 12:19:08 UTC ETMY saturation: yes Example 6 GPS: 1126442379 UTC: Sep 16 2015 12:39:22 UTC ETMY saturation: yes
WIth Hang's help, I managed to investigate these glitches with the new lockloss tool using SUS-ETMY_L3_MASTER_OUT_LL_DQ as a reference channel. The script couldn't find any other optics that glitch prior to the ETMY. And sometimes the glitches are seen by ETMX 30-40 miliseconds after.
I've attached the plot of the glitches at the time you've given. I've also attached the list of channel I told the script to look. Basically all the SUS MASTER OUT DQ channels. Please let me know if you have any suggestions on whereelse I should look at.
Attached are time traces of the DCPD_SUM for the 5 examples.
