≈ 19:30UTC while Livingston is down.
Also: Cheryl is turning the -30˚ ITMX Roll Mode FIlter back on while we are in this state.
Sidenote: GWIstat went RED rather than Yellow? Maybe it only goes Yellow on the way UP to lock and 'thinks' we came unlocked because Intent bit went out of Observe??
model restarts logged for Sun 05/Feb/2017 No restarts reported
No H1 restarts, DTS x1ldasgw1 rebooted at 03:04
model restarts logged for Sat 04/Feb/2017-Wed 01/Feb/2017 No restarts reported
Jonathan, Dave, Jim:
At 03:04 Sunday 5th February the DTS SAM-FS server (x1ldasgw1) rebooted itself unexpectedly. The daqd process on x1fw1 was not running at the time, so no data was lost. We restarted SAM-FS and NFS services and rebooted x1fw1, all is now recovered.
The mouting of /cds-h2-frames took longer than usual (several minutes as opposed to a few second).
Summary of the DQ shift from Thursday 2nd February 00:00 - Sunday 5th February 23:59 (UTC), click here for full report
Laser Status:
SysStat is good
Front End Power is 34.05W (should be around 30 W)
HPO Output Power is 164.3W
Front End Watch is GREEN
HPO Watch is GREEN
PMC:
It has been locked 7 days, 21 hr 17 minutes (should be days/weeks)
Reflected power = 14.81Watts
Transmitted power = 65.69Watts
PowerSum = 80.5Watts.
FSS:
It has been locked for 0 days 14 hr and 11 min (should be days/weeks)
TPD[V] = 1.753V (min 0.9V)
ISS:
The diffracted power is around 2.0% (should be 3-5%)
Last saturation event was 0 days 14 hours and 12 minutes ago (should be days/weeks)
Possible Issues:
ISS diffracted power is Low
I've looked at two images of the IO beam dump steering mirror from Oct 2012 and Nov 2016. Comparing the two images suggests the beam may have moved enough to be clipping on the edge of the steering mirror, which would cause significant scattering. The image from Nov 2016 does not show the entire steering mirror, so there is some non-trivial potential for error in identifying the location of the beam on the mirror. My estimate for that error is around 25%, so if the beam is 25% closer to location of Oct 2012 the risk of clipping is small, but if the beam is 25% farther away from the location of Oct 2012, the risk of clipping is high. Attached: image of beam dump and sterring mirror from Nov 2016, analysis of images (2.4MB)
Joe is using the machine on the sidewalks East of the OSB. Low freq noise is audible in the control room.
TITLE: 02/06 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 63Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY: Locked the whole shift, I had nothing to do.
LOG:
Observing at 62Mpc for 9hrs. Range still seems to be going down very slowly, and now a bit more from Hanford traffic. Still not sure of the cause.
Site is a bit slippery, but the rest of the roads seemed good when I came in.
Out at 08:31UTC while LLO is down to run a2l.
Back to observing at 08:42
Intention bit actually flipped at 08:50UTC. My click didn't register and I didn't register that it didn't work till now.
TITLE: 02/06 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 65Mpc
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
Wind: 8mph Gusts, 7mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.30 μm/s
QUICK SUMMARY: The range seems to be trending down in the last 24hr, you could maybe say that it is from the wind and/or useism but I've been fooled before. 4hr lock so far.
TITLE: 02/06 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC STATE of H1: Observing at 64Mpc INCOMING OPERATOR: TJ SHIFT SUMMARY: One lock loss. New longest O2 lock stretch of 41:53:43. No major issues relocking. Damped PI modes 26 and 27. Wind has come back down. LOG: 03:19 UTC TCSY chiller flow is low verbal alarm. MEDM shows it to be around 3.1, which appears normal. Must have been a glitch. 03:47 UTC Lock loss. Verbal alarms crashed. 04:28 UTC Observing. Damped PI modes 26 and 27 beforehand.
04:28 UTC Observing. No major issues relocking. Damped PI modes 26 and 27.
Reacquiring after lock loss at 03:47 UTC. Cause not clear.
J. Kissel After Keita begin using DELTAL_EXTERNAL_DQ for his subtraction studies, I was reminded that we need to update the control room wall FOM template for the recent DARM loop model changes (see LHO aLOG 33585 and 33434). Also, it reminded me that here at LHO, we have not switched over to using the more precise method of adding the CAL-CS DELTAL_CTRL vs DELTAL_RESIDUAL developed at LLO (see LLO aLOGs 28268 and 28321) that allows us to correct for all of the high-frequency limitations of the front-end CAL-CS DARM loop model replica (see II/ET Ticket 4635) without being limited by integer clock cycles. As such, I copied a script from Shivaraj, /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/L1/Scripts/CALCS_FE/CALCSvsDARMModel_20161125.m that computes what this relative delay should be as a function of frequency. Because it needs interferometer specific information as he's written it, I've put H1's version for the latest reference model time (2017-01-24, after the 4.7 kHz notch was added to the DARM filter bank, again see LHO aLOG 33585) in an appropriate place, /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/CALCS_FE/CALCSvsDARMModel_20170124.m and updated it accordingly. The function also has the bonus of checking the CAL-CS model implementation against the supposedly perfect Matlab model. I attach the output. The first plot shows the ratio between the CAL-CS replica (re-exported back into matlab) and the perfect matlab DARM loop each for each actuation and sensing path. This ratio should expose all the the CAL-CS model is missing: - computational delays, - the light-travel time delay - the pre-warping of high-frequency roll-off filters - the response of uncompensated high-frequency electronics, and - the digital and analog AA or AI filters. That which CAL-CS is lacking is accounted for in the GDS pipeline to form the product consumed by the astrophysical searches, GDS (or DCS)-CALIB_STRAIN. However, since the front-end / CAL-CS is incapable of precisely handling these effects for the real-time control room product DELTAL_EXTERNAL, and they're predominantly high-frequency effects, we, in the past have approximated them with adding a relative delay between the sensing and actuation paths, as explained by LHO aLOGs 32542, 21788 or 21746. The second plot shows the same sensing function ratio, but now with the entire actuation function summed together. The phase difference between the two function on page two, as a function of frequency, is recast as a delay and converted to 16 kHz clock-cycles in the third attachment. Ideally, this phase difference / delay would be flat as a function of frequency, so we'd feel good about applying a single delay number in-between the paths, even if it was a non-integer 16 kHz clock cycle. This is what LLO's looked like in LLO aLOG 28321, and what they installed according to the last paragraph of LLO aLOG 29899. However, LHO's is *not* flat, so I'm not sure what to do. Also, at the DARM loop Unity Gain Frequency (68 Hz) where you would expect the delay needs to be perfect at the crossover between actuation and sensing functions -- the phase difference or delay is exactly 427 [usec], which is 7 16kHz clock cycles, which is at what the delay is currently set. So... do we need an update? I'll converse with Joe and Shivaraj and decide from there. ------------- The DARM model and parameters used to generate the plots in this aLOG are: trunk/Runs/O2/H1/params/2017-01-24/ modelparams_H1_2017-01-24.conf (r4241, lc: r4241) trunk/Runs/O2/DARMmodel/src/ DARMmodel.m (r4241, lc: r4241) computeDARM.m (r4241, lc: r4241) computeActuation.m (r4241, lc: r4241) computeSensing.m (r4093, lc: r4025) trunk/Runs/O2/H1/Scripts/CALCS_FE/ CALCSvsDARMModel_20170124.m (r4263, lc: r4263)
After discussion with the calibration team, we've agreed that -- although the equivalent phase delay between paths is more frequency dependent than LLO -- the virtually exact 7 clock cycles worth of delay at the DARM UGF (68 Hz) means that we should keep the front-end CAL-CS DELTAL_CTRL_DELAY the same as it's been. Thus -- we have made and will make NO change to the DELTAL_EXTERNAL calibration.
19:43UTC Back to Observing
Details about my change: alog 33929.