Nothing unusual here.
Looking into stand down protocol...
Trigger duration is too long. No Stand Down.
A while ago, I took some data for measuring the Q of the 10430.5 Hz mode (alog 50374). However, the RMS monitor channel for this mode wasn't working, which doesn't make a lot of sense, since it really should just be taking the rms (in the front end system) of the same signal that is being used to ring up the mode. So, I couldn't use pre-existing fitting scripts. I have not yet investigated why the RMS monitor isn't outputting sensible data.
If I pull the H1:OMC-PI_DCPD_64KHZ_AHF_DQ channel and bandpass it (8th order butterworth with 2 Hz width), I clearly see the ringdown of this mode. I start the bandpassing a few hundred seconds before the beginning of the ringdown, so that I don't have to worry about transient effects of the filter. The bandpassed data is the blue trace in the attached plot.
To do the fit, I take a Hilbert Transform of the data (shifts the phase of the data by 90 degrees), so that I can get the magnitude of the ringdown envelope via: sqrt(data^2 + imag(hilbert(data))^2). I decimate this resulting envelope from 64kHz to 1024Hz to make it a less crazy number of points. I fit this envelope data (using data that starts 20 seconds after I stopped exciting up to 100 seconds before we began powering up) to a function of the form A*exp(B*t).
In the attached plot, I show the original bandpassed data, as well as the fitted envelope. Note that the result of the fit doesn't change appreciably if I restrict the data used to [20 sec, 1200 sec].
The fit results in a decay time tau of 259 seconds, which implies a Q of (pi * 10430.5Hz / tau) = 8.48e6 as the Q of the 10430.5 Hz mode.
The attached matlab .m file pulls the data, and does all of the analysis and plotting to get the tau number.
I neglected to mention that this data was taken at 2W, so as not to risk it ringing up and causing a lockloss.
TITLE: 07/15 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
OUTGOING OPERATOR: Travis
CURRENT ENVIRONMENT:
Wind: 8mph Gusts, 5mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.06 μm/s
QUICK SUMMARY:
H1 locked and humming along at ~114Mpc. Travis gave me a quick tour of all the new initial alignment stuff. Am interested to see it work (but not that eager at this particular time) ;-)
TITLE: 07/15 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY: Locked in Observing for ~7 hours after dual locklosses before and early in shift. No issues to report at this time.
LOG:
16:17 Corey checking TCS chillers
16:28 Corey done
17:05 Peter and Sundae to optics lab
17:25 Peter out
18:06 Sundae out
18:30 JeffB to both ends for dust monitor work
20:28 Jeff to both ends to rebuild pumps in Mech. room
20:29 Kyle to MY
20:48 JeffB to both ends to swap vac pump for dust monitors
21:08 Peter to optics lab
21:28 Chris to all outbuilding auditing property
21:52 Jeff back
21:58 Sundae to optics lab
22:04 Chris back
22:50 Gerardo to MX
Checked the HEPI fluid levels this morning. All are working, no new leaks appeared, and fluid levels were good. CS Fluid level was 6 7/16 (1/8 drop) EX Fluid level was 8 9/16 (1/16 gain) EY Fluid level was 9 (no change)
Checking over the historic levels on the white board for the CS indicate that this system varies about ±1/4". The trip level for the CS is set to about 6 1/16" so we are safe from a fluid level trip.
CS vacuum pump is fine. No adjustment of pressure and temperatures were below spec. All is good. Not so with the two end stations. Both pumps have failed in the same way. The motor is still turning but is pulling no vacuum. I have rebuilt pumps ready to go and will be swapping them in shortly.
Added 175mL to the Crystal Chiller. Diode Chiller & pair of filters looked OK.
ITMx Pit is nearing the edge of its acceptable range and should be recentered soon. Trends attached.
I accepted a few SDF diffs but they were all 10^-13 - 10^-15 digit diffs, so I didn't bother taking screenshots of them.
We normally use a limiter in the beamsplitter suspension filters while DRMI is trying to acquire. I've just edited the DRMI guardian to try not having this limiter on, to see if we saturate the coil drivers without it, and to see what the impact is on DRMI locking time.
I will post an update once we've had a few acquisitions like this.
If you have trouble with DRMI acquisition feel free to call me, or revert the changes. You can revert the changes by going to userapps isc/h1/guardian and typing svn revert ISC_DRMI.py
TITLE: 07/15 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
Wind: 6mph Gusts, 5mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY: Cheryl had H1 relocked just before the start of my shift. Just had another lockloss at 15:10 UTC with no obvious cause.
TITLE: 07/15 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
INCOMING OPERATOR: Travis
SHIFT SUMMARY: one lockloss, lockloss tool shows EX about -10 seconds, but it's not clear that that was the cause
LOG: all times UTC
DQ Shifter: Sharan Banagiri
Mentor: Pat Meyers
LHO Fello: Dripta Bhattacharjee
Link to DQ Shift: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20190708
Some interesting and useful alogs.
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=50469
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=50481
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=50512
The observed PCALX line changing frequency is normal behavior where an injection into PCALX is made in order to measure the sensing function at high frequencies. This line is automatically adjusted in the Guardian according to a pre-determined schedule. Attached is a 1 week minute-trend time series of the injection frequency (H1:CAL-PCALX_PCALOSC1_OSC_FREQ) and corresponds to the changes noted in the DQ shift report.
HAM and BSC spectra look good, no alerts.