TITLE: 03/27 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 65Mpc
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT: Wind: 16mph Gusts, 13mph 5min avg Primary useism: 0.05 μm/s Secondary useism: 0.34 μm/s
QUICK SUMMARY: Been locked for 10.5 hours. Balers should be done by now (Bubba reported that they should be done by 16:30 local) Nothing else to report.
TITLE: 03/27 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
INCOMING OPERATOR: Nutsinee
SHIFT SUMMARY:
LOG:
15:00 Bailers on Xarm
21:00 Betsy, TJ to Opstics Lab, out 22:00
21:15 Fil & Richard on Xarm, working on vault
22:00 Gerardo to optics lab
21:30 Evan & Miriam doing blip glitch measurements while LLO is down
WP 6544, ECR E1700107,
I have updated the following frontend models to implement the time-domain DCPD cross correlation technique.
omc.mdl (master model)
h1omc.mdl
CAL_CS_MASTER.mdl
h1calcs.mdl
The h1omc
and h1calcs
models will be installed and restarted tomorrow during the maintenance period.
[The changes]
Here is a list of things that I newly added today in the OMC models (namely h1omc.mdl
and omc.mdl
). Also the attached are screenshots of relevant part of the models.
h1calcs
.Here is a list of things I added today in the CAL CS models, e.g. h1calcs.mdl
and CAL_CS_MASTER.mdl.
H(L)1:CAL-DELTAL_A
and H(L)1:CAL_DELTAL_B
).After these changes, I confirmed that they compile without an error. They are ready for tomorrow's installation. The models are checked into svn.
Evan, Miriam,
While L1 was having a small lock loss, we made a series of injections (with H1 in comissioning mode) in the H1:SUS-ETMY_L2_DRIVEALIGN_Y2L_EXC channel. The injections are single sine-gaussian pulses that simulate blip glitches (see https://ldas-jobs.ligo-wa.caltech.edu/~miriam.cabero/sine-gaussian.png ).
We started very quiet and slowly increased the amplitude, so that only the last 3 of the 9 injections appear in GDS-CALIB_STRAIN. The GPS times of the injections are:
1174684631
1174684680
1174684715
1174684745
1174684793
1174684854
1174684889 *
1174684945 *
1174685355 *
* Can be seen in CALIB_STRAIN
We will be repeating this kind of injections at opportunistic times (L1 not observing) in the next days, taking different blip morphologies, and different amplitudes.
Only the loudest of these saturated the noisemons, and it did so by hitting an analog limit at plus/minus 22000 counts. I projected the drive signal into noisemon counts and looked at the last three injections on the list. In the first two, the noisemon signal tracks the drive, and the subtraction of the two is just noise. In the last (loudest) injection, the noisemon hits an analog saturation at both plus and minus 22,000 counts leaving a huge glitch in the subtracted data. This is good because it suggests that the only important analog limit in the noisemon is this threshold. I don't have time to document it now, but I've tried the same with a set of loud detchar injections, which go up to hundreds of Hz, and I get the same behavior. So when the drive signal does not push the noisemon beyond 22,000 counts, we can trust the subtraction, and anything we see has entered the signal between the DAC and noisemon; it's a glitch in the electronics and not a result of the DARM loop. Attached are the three subtractions, noisemon minus projected drive signal.
Apollo is working at Mid-Y on the HVAC controls upgrade project. Both air handlers are down and will be for the night. This may cause a slight temperature rise in the building and may trigger some alarms. These are minor and only temporary.
Jim, Dave:
At 15:44:58 UTC (08:44:58 PDT) we received a timing error which only lasted for one second. The error was reported by the CNS-II independent GPS receivers at both end stations, they both went into the 'Waiting for GPS lock' error state at 15:44:58, stayed there for one second, and then went good. The IRIG-B signals from these receivers are being acquired by the DAQ (and monitored by GDS). The IRIG-B signals for the second prior, the second of the error, and the following two seconds (4 seconds in total) are shown below.
As can be seen, even though EX and EY both reported the error, only EX's IRIG-B is missing during the bad second.
The encoded seconds in the IRIG-B are shown in the table below. Note that the GPS signal does not have leap seconds applied, so GPS = UTC +18.
Actual seconds | EX IRIG-b seconds | EY IRIG-b seconds |
15 | 15 | 15 |
16 | missing | 16 |
17 | 16 | 17 |
18 | 18 | 18 |
So EY was sequential through this period. EX slipped the 16 second by a second, skipped 17 and resynced at 18.
Summary: All problems were in CNS II GPS Channels at LHO. No problems were observed in the Trimble GPS Channels at either site, nor in the LLO CNS II Channels, with the exception of a change of -80ns in the LLO Trimble GPS PPSOFFSET a few seconds after the anomally (see below). It seems that both LHO CNS II Clocks simultaneously dropped from 10 to 3 satellites tracked for a single second. There is no channel recording the number of satellites locked by the Trimble clocks, but the RECEIVERMODEs at both sites remain at the highest level of quality, OverDeterminedClock (level 5 for the Trimbles) with no interruption at the time of the anomaly. It is unclear whether the LLO PPSOFFSET is causally related to the LHO event; the lack of other anomalous output from the LLO Trimble clock suggests that it is otherwise performing as intended. Descriptions of anomalous plots below. All anomalous plots are attached. Dilution of precision at BOTH LHO CNS II clocks skyrockets to 100 around the event (nominal values around 1) (H1:SYS-TIMING_X_GPS_A_DOP, H1:SYS-TIMING_Y_GPS_A_DOP). Number of satellites tracked by BOTH LHO CNS II clocks Plummets or two seconds from 10 to 3 (H1:SYS-TIMING_X_GPS_A_TRACKSATELLITES, H1:SYS-TIMING_Y_GPS_A_TRACKSATELLITES). In the second before the anomaly, Both of the LHO CNS II Clocks' RECEIVERMODEs went from 3DFix to 2DFix for exactly one second, as evidenced by a change in state from 6 to 5 in their channels' values (H1:SYS-TIMING_X_GPS_A_RECEIVERMODE, H1:SYS-TIMING_Y_GPS_A_RECEIVERMODE). The 3D Speed also spiked right around the anomaly for both LHO CNS clocks (H1:SYS-TIMING_X_GPS_A_SPEED3D, H1:SYS-TIMING_Y_GPS_A_SPEED3D). LHO CNS II Clock's 2D speeds both climb up to ~0.1 m/s (obviously fictitious) (H1:SYS-TIMING_X_GPS_A_SPEED2D, H1:SYS-TIMING_Y_GPS_A_SPEED2D). LHO Y-End CNS II Clock calculated a drop in elevation of 1.5m following the anomaly (obviously this is spurious) (H1:SYS-TIMING_Y_GPS_A_ALTITUDE). LHO X-End CNS II Clock thinks it dropped by 25m following the anomaly! I'm not sure why this is so much more extreme than the Y-End calculated drop (H1:SYS-TIMING_X_GPS_A_ALTITUDE). The Livingston Corner GPS PPSOFFSET went from its usual value of ~0+/-3ns to -80 ns for a single second at t_anomaly + 3s (L1:SYS-TIMING_C_GPS_A_PPSOFFSET). The GPS Error Flag for both LHO CNS II clocks came on, of course (H1:SYS-TIMING_Y_GPS_A_ERROR_FLAG, H1:SYS-TIMING_X_GPS_A_ERROR_FLAG)
Using my very limited knowledge of Windows administration, I have attempted to list the events logged on h1ecatc1 from 8:00 - 10:00 AM on Feb. 27 2017. Attached is a screenshoot of what was reported. I don't see anything at the time in question. However, there is a quite reasonable chance that there are other places to look that I am not aware of and/or I did not search correctly.
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill not completed after 3600 seconds. LLCV set back to 15.0% open. Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 1127 seconds. TC A did not register fill. LLCV set back to 44.0% open.
Raised CP4 to 45% open.
Manually overfilled CP3 from control room at 100% open (@1:35pm local). Took 9 min. to overfill. Raised nominal value to 17% open.
Attached are plots with this months' data.
I have finished my DQ shift at LHO for 23-26 March 2017. Here are the highlights:
My full report can be read at the DQ shift wiki page.
Everything appears normal.
TITLE: 03/27 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC STATE of H1: Observing at 63Mpc INCOMING OPERATOR: Jim SHIFT SUMMARY: One lock loss from 6.1 mag earthquake west of Alaska. No issues relocking after seismic settled down. Accepted SDF differences from Cheryl's bounce mode damping filter changes. LOG: 07:22 UTC Powercycled video0 11:13 UTC Lock loss (earthquake). Set to down. Set observing bit to earthquake. 13:18 UTC Back to observing. Accepted SDF differences for Cheryl's bounce mode damping filter changes (see attached). 13:25 UTC Powercycled video2 13:40 UTC Damped PI mode 27 by changing phase from -80 to 0 13:48 UTC Damped PI mode 27 by changing phase to 20 14:09 UTC Bubba to mid Y with Apollo to work on HVAC controls
15:12 UTC Balers are at mid X and working towards end X
15:14 UTC Damped PI mode 28 by changing sign of gain
6.1 Attu Station, Alaska Was it reported by Terramon, USGS, SEISMON? Yes (twice), Yes, No Magnitude (according to Terramon, USGS, SEISMON): 6.1, 6.1, NA Location: 66km W of Attu Station, Alaska; 52.798°N 172.199°E Starting time of event (ie. when BLRMS started to increase on DMT on the wall): ~10:58 UTC Lock status? Both L1 and H1 lost lock. EQ reported by Terramon BEFORE it actually arrived? Not sure
Have remained in observing. No issues to report.
3.1 Eureka, Nevada Was it reported by Terramon, USGS, SEISMON? Yes, Yes, No Magnitude (according to Terramon, USGS, SEISMON): 3.1, 3.1, NA Location: 35km S of Eureka, Nevada; 39.189°N 115.938°W Starting time of event (ie. when BLRMS started to increase on DMT on the wall): ~9:24 UTC Lock status? H1 stayed locked, L1 broke lock, but L1 operator says not likely due to earthquake EQ reported by Terramon BEFORE it actually arrived? Not sure
This is a classic case of "Middle-Click Syndrome". Someone highlighted that OMC DCPD line in the Verbal Terminal and then accidentally middle clicked later. I checked this by first checking the Verbal logs to make sure it wasn't in there, and then I went to the alarms work station and middle clicked in the Verbal Terminal. Sure enough, the same March 10 OMC DCPD saturation message showed up.
About an hour after coming on shift I noticed something in the CR air and put on my mask, but after a while it was clear that that didn't help, so I started looking for other things, and realized it sort of smelled like burnt plastic. Called Corey, Richard, Dave, and a couple other people. Turned off most of the CR computers (about 4 warm ones), checked the MSR, checked the Computer user's room, and the smell was only in the CR. Tried to contact Robert, waited, but then turned off his computer, and am now waiting to see if that computer was overheating, and if turning it off clears up the air.
Currently watching H1 from the Computer Users Room, and have Verbal Alarms running in here.
we were not able to pin down where the odor was coming from, and there are no odors today.
I have added an (unreleased) algorithm into the GDS/DCS pipeline to compute the SRC spring frequency and Q. This algorithm was used to collect 18 hours of data on February 4 (first plot) and 18 hours of data on March 4 (second plot). The plots include kappa_c, the cavity pole, the SRC spring frequency, the SRC Q, and 4 of the coherence uncertainties (uncertainty of the 7.93 Hz line is not yet available). The derivation this algorithm was based on is similar to what Jeff has posted ( https://dcc.ligo.org/DocDB/0140/T1700106/001/T1700106-v1.pdf ), with differences noted below: 1) The approximation made at the bottom of p4 and top of p5 was only used in the calculation of kappa_c and the cavity pole. So SRC detuning effects were not accounted for in computing S_c. However, kappa_c and the computed cavity pole were used in the calculation of S_s. 2) In eq. 18, I have a minus (-) sign instead of a plus (+) sign before EP6. S_c = S(f_1, t) has been computed this way in GDS/DCS since the start of O2 (I assume during O1 as well). 3) Similarly, in eq. 20, I have a minus sign (-) before EP12. 4) In the lower two equations of 13, I have the terms under the square root subtracted in the opposite order, as suggested by Shivaraj. (Also, I noted that the expression for Q should only depend on S(f_2, t), with no dependence on S(f_1, t). ) The smoothing (128s running median + 10s average) was done on f_s and 1/Q, since that is the way they would be applied to h(t). Therefore, the zero-crossings of 1/Q show up as asymptotes in the plot of Q. I think it would be better to output 1/Q in a channel rather than Q for this reason. There is a noticeable ramping up of f_s at the beginning of lock stretches, and the range of values agrees with what has been measured previously. I've noted that it is quite difficult to resolve the value of Q with good accuracy. These are some reasons I suspect: 1) Higher uncertainty of calibration measurements at low frequency can add a systematic error to the EPICS values computed at 7.93 Hz. This may be why the Q is more often negative than positive ?? 2) In the calculation of S_s, the actuation strength is subtracted from the ratio of pcal and DARM_ERR. Since this is such a low frequency, the subtracted values are close to the same value in magnitude and phase. Thus, subtracting magnifies both systematic error and uncertainty. 3) The imaginary part of S_s (see eq. 13, bottom equation) in the denominator, is very close to zero, so small fluctuations (about zero, as it turns out) in 1/Q cause large fluctuations in Q. These reasons make it difficult to measure Q with this method. The effect of these measured-Q fluctuations on S_s, the factor we would actually apply to h(t) (see eq. 22), is not enormous, so long as we apply the smoothing to 1/Q, as I have done here.
First attachment is a hand written note containing derivation of the equations 13 in DCC document T1700106. As Aaron mentioned above, in the derivation the order of the quantities in the sqrt function comes out to be in the opposite order (Re[S] - abs[S]^2 instead of abs[S]^2 - Re[S]). The second plot show the estimation of the four sensing function quantities for 2017-01-24 calibration sweep measurement done at LHO (a-log 33604). Instead of tracking across time here we track across sweep frequencies. The top two plots in the second figure show the estimation of optical gain and cavity pole frequency assuming no detuning. We see that above ~100 Hz we get almost constant values for optical gain and cavity pole frequency suggesting detuning doesn't affect the estimation of those quantities (currently we use 331.9 Hz line at LHO for estimating optical gain and cavity pole). Substituting back the optical gain and cavity pole calculated this way, we then calculated detuning frequency and Q. The bottom two plots of the second figure show those. We see that upto ~60 Hz we can use the lines to estimate detuning frequency (currently at LHO we are running the line at 7.83 Hz). However the Q is hard to estimate, the variation is pretty large (Evan's recent a-log also indicate this 34967; Aaron also finds this to be the case). Also in the 7-10 Hz region its value seems to be negative (need to look at more data to make sure that it not just a fluctuation). With the current set of calibration lines, it seems tracking of detuning frequency would easy but estimating Q might be a little difficult.
In the second page of the derivation, at the half way point I have unintentionally switched the notation from S_s to S_c (it should be S_s till the end of the page 2).
[Daniel Finstad, Aaron Viets] The time series and histograms attached show additional data collected using the DCS calibration pipeline from Jan 19, 2017 at 21:44:14 UTC (GPS 1168897472) until Jan 20, 2017 at 09:02:38 UTC (GPS 1168938176).