TITLE: 04/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 68Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY: Went out of Observing briefly to run a2l, but other than that it has been running very smooth. 50.5hours
Out of Observing from 02:26 - 02:31UTC to run a2l while LLO was down.
FAMIS6894
ITMX_ST1_CPSINF_V1 high freq noise is high
These plots were made via the python script by Jim and the above message was what it printed out.
Greg, Dave:
While investigating IOP-SUS ADC+Timing errors, I found an event at 03:07:01 Sunday 4/16 PDT in which all of the SUS-EY front end models reported a STATE_WORD of 16 (DAQ error). At the same time, the DAQ Data Concentrator reported a sequence of 23 data blocks with invalid CRC check sums (except for h1susetmypi which reported 24). Greg confirms that the GDS/DMT calibration code did see an invalid data flag at that time.
The CDS overview for the end station sus systems is attached. The EX CRCs incremented at 04:39 4/14 UTC, the EX CRCs incremented at 10:07 4/16 UTC (21:39 Thursday and 03:07 Sunday PDT respectively). Greg says that the EX event on Thursday did not cause a calibration issues as only EY data is being used.
Trending over the past 150 days (to start of O2) shows CRC error burst have occurred 6 times at EX and 8 times at EY.
Detailed time plot of Sunday morning's 03:07 EY event suggests that the data error is contiguous for 23 blocks of data (1/16th second blocks), meaning 1.44 seconds of bad data.
Investigation is continuing.
Miriam, Evan and Dave:
Over the past few weeks we have been investigating the correlation between end station sus computer model glitches and blips seen in the calib_strain channel. Some past glitch events were analyzed by hand, which proved to be time consuming. I have written a python script to capture glitches in real time and log them to a file (script is report_fec_glitches.py in the cds/h1/scripts area).
Today I analyzed 20 glitches which occurred between 4/12 and 4/15. I have written up this analysis on the following wiki page: https://cdswiki.ligo-wa.caltech.edu/wiki/EndStationSusGlitchBlipAnalysisApril2017
As the investigation continues, results will be added to this wiki page.
The raw data can be found in /ligo/cds/lho/h1/fec_glitches/2017/04
Executive summary: about 35% of SUS front end computer glitches appear to cause a blip in calib_strain. The detailed sequence of ADC, Timing and IPC errors differs significantly between glitches.
Located our mobile STS2 (C) as close to the ITMY STS2 (B) as possible which means about 18in center to center.
The two graphs attached show low wind (~5mph) and high wind (~20mph) graphs of ASD and coherence between the two huddling STSs. Good coherence moves well down during the windy conditions as the ground motion increases to above the instrument noise. Coherence above 0.9 moves from 50ish mHz to 5 or 10mHz (depending on dof.) Tomorrow I'll move the roaming machine to around BSC8 and then wait for calm and wind.
In the quite time plot the HAM5 channel (mobile STS?) is noticeably noisier then the IMTY channel, is it the instrument? or the mounting?
TITLE: 04/17 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: TJ
SHIFT SUMMARY: locked entire shift
LOG:
TITLE: 04/17 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 64Mpc
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
Wind: 19mph Gusts, 14mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.15 μm/s
QUICK SUMMARY:42.5 hrs lock, rode through a good sized earthquake.
Shifter: Beverly Berger
LHO fellows: Karl Toland, Vaishali Adya
For complete results see https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20170413.
Activities:
I started to repeat the measurement described in llo alog 28797 while we were waiting for LLO to come back up around 20:05 UTC. Since LLO is back, I have stopped and put things back to normal, and Cheryl is running A2L before we go back to observing. (This was about 45 minutes of commisioning).
I got as far as tuning an excitation and finding that an offset of around 0.3 in POSY may be about right, but that we need to wait a long time for the OMC ASC loops and the slow kappa C calculation to settle when making these measurements. The template with the excitation is saved at sheila.dwyer/OMC/OMC_alignment_jitter_check.xml We will continue this Wednesday.
Set the gain of PI modes 27 to zero next time you do this measurement.
As Cheryl noted, mode 27 rang up during your work today (mode 19 was just bleed over from 27). Since we're using OMC DCPD as the error signal for this mode, driving OMC ASC loops changes the phase as seen by this mode such that we must've been driving up the PI; mechanical drive up was real, as it was seen by the TransMon QPD.
This mode is nominally stable after the thermal transient, so as long as you're an hour or so into a lock, you can just set the gain of mode 27 to zero during OMC commissioning.
I also took about 10 minutes with the interferometer locked on RF just now to put some offsets into the OMC alignment loops. These dither loops are very slow, it takes about 3 minutes for them to react to an offset change. For POS X introducing an offset of 0.3 decreases the transmitted power to 88%, for POS Y an offset of 0.3 decreases it to 95% of the power for the normal alingment. I didn't get to check the ANG loops, but it seems like they will need larger offsets (2 or 3).
Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 1200 seconds. LLCV set back to 20.0% open. Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 1484 seconds. LLCV set back to 38.0% open.
Raised both by 1%.
CP3 to 21%
CP4 to 39%
Contemplating the next layer of automation by adding to code incremental increases/decreases to LLCV control value.
RickS, VaishaliA, HeatherF, SudarshanK
We analyzed the pictures of the ETM and Pcal beam spots taken on 2017/04/11 (Tuesday maintenance) to determine the position of the Pcal beams. The numbers below are the position of the Pcal beams from their nominal position of [ 0, 111.6] mm for upper beam and [0, -111.6] mm for lower beam.
Upper Beam [1.1+/-0.3, 1.1+/-0.2]
Lower Beam [-1.1+/-0.2, 1.3+/-0.3]
These numbers are comparable to numbers obtained from the pictures taken few weeks ago - LHO alog # 35347.
P.S. The number reported here are mean values of multiple analysis on multiple pictures and the number in the attached picture is only one such number and thus may be different.
I don't see any egregious excursions. The brief dip in the EX pressure was previously noted in TJ's trend from March 20 (aLog 34936). Also, the glitching in the EY pressure noted in the same aLog seems to have been fixed. This closes FAMIS task 4531.
TITLE: 04/17 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 64Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
Wind: 9mph Gusts, 7mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.13 μm/s
QUICK SUMMARY:
TITLE: 04/17 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 55Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:
Nothing to report. IFO locked for 34hrs20min
LOG:
7:28UTC YAW out by .65
7:33UTC Intention Bit Undisturbed
J. Kissel
Gathered regular bi-weekly calibration / sensing function measurements. Preliminary results (screenshots) attached; analysis to come.
The data have been saved and committed to:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Measurements/SensingFunctionTFs
2017-03-21_H1DARM_OLGTF_4to1200Hz_25min.xml
2017-03-21_H1_PCAL2DARMTF_4to1200Hz_8min.xml
2017-03-06_H1_PCAL2DARMTF_BB_5to1000Hz_0p25BW_250avgs_5min.xml
J. Kissel
After processing the above measurement, the fit optical plant parameters are as follows:
DARM_IN1/OMC_DCPD_SUM [ct/mA] 2.925e-7
Optical Gain [ct/m] 1.110e6 (+/- 1.6e3)
[mA/pm] 3.795 (+/- 0.0053)
Coupled Cavity Pole Freq [Hz] 355.1 (+/- 2.6)
Residual Sensing Delay [us] 1.189 (+/- 1.7)
SRC Detuning Spring Freq [Hz] 6.49 (+/- 0.06)
SRC Detuning Quality Factor [ ] 25.9336 (+/- 6.39)
Attach are plots of the fit, and how these parameters fit in within the context of all measurements from O2.
In addition, given that the spread of the course of the detuning spring frequency is between, say 6.5 Hz and 9 Hz, I show the magnitude ratio of two toy transfer functions, where the only difference is the spring frequency. One can see that -- if not compensated for, that means a systematic magnitude error of 5%, 10%, 27% at 30, 20, and 10 Hz, respectively.
Bad news for black holes! We definitely need to track this time dependence, as was prototyped in LHO aLOG 35041.
Attached are plots comparing the sensing and response function with and without detuning frequency. Compared to LLO (a-log 32930), at LHO the detuning frequency of ~7 Hz has significant effect on the calibration around 20 Hz (see response function plot). The code used to make this plot is added to svn,
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O2/H1/Scripts/SRCDetuning/springFreqEffect.m
Attached are plots showing differences in sensing functions and response functions for spring frequencies of 6 Hz and 9 Hz. Coincidentally they are very similar to the plots in the previous comment which show differences when the spring frequencies are 0 Hz and 6.91 Hz.
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).
