CP6 and CP8 deliveries scheduled for Tuesday, April 11th. My recollection from Friday was that CP6 was in the mid 20's - increased consumption or bad memory?
2:42UTC LLO concurred. Guardian acting normally. 1 hr stand-down time in effect.
TITLE: 04/08 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 59Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
Wind: 20mph Gusts, 18mph 5min avg
Primary useism: 0.08 μm/s
Secondary useism: 0.27 μm/s
QUICK SUMMARY: No issues. Ran a2l after LLO lost lock.
17:03 UTC LLO lost lock. Going out of observing to run a2l.
17:08 UTC Back to observing.
21:07 - 21:40 UTC Chandra leading tour through control room.
Only out of observing to run a2l after LLO lost lock. No issues to report.
TITLE: 04/08 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 62Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
Wind: 10mph Gusts, 8mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.42 μm/s
QUICK SUMMARY:
No issues to report.
TITLE: 04/08 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 64Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: Very quite shift, locked for 9.5hr.
LOG: Nothing to note
5.5hrs at 65Mpc. Wind has calmed down adn useism seems to be on its way down as well.
TITLE: 04/08 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
Wind: 23mph Gusts, 20mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.53 μm/s
QUICK SUMMARY: Hour and a half at 67Mpc, wind is still a bit elevated and teh useism is a bit high as well.
TITLE: 04/08 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
See previous aLogs
LOG:
02:25UTC After about 1hr15min of NLN the a2l measurement showed about .7 out of PIT in X arm. Yaw looked nice and coherent. Livingston operator was informed.
02:30 H1 back to Observing
Ed, Miriam
Accepted SDF diffs for the damping. Will leave it to the discretion of others to determine the SVN check-in status of this change.
TITLE: 04/08 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Wind
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
Wind: 28mph Gusts, 24mph 5min avg
Primary useism: 0.12 μm/s
Secondary useism: 0.57 μm/s
QUICK SUMMARY:
Re-Locking has been a bit daunting: Bad fiber polarization, SRC acting up, locklosses occurring at CARM_ON_TR. the wind is coming back to more reasonable levels so I may try going back to the nominal WINDY state for the ISI configuration. Stay tuned.
Successful locking at WINDY ISI config. Gonna stick with what works.
[JimW, Jenne]
While the IFO was down due to high microseism and high wind this afternoon, we have measured the 2 transfer functions needed for MC2's M1 stage to create the L2A decoupling feedforward filter.
For both L2P and P2P measurements, the pre-existing flat L2P decoupling gain of -0.007 was disengaged. So, we started from scratch since we weren't sure about that number.
In order to get good coherence for the L2P measurement, I was driving MC2 enough that the IMC was having trouble staying locked. So, I unlocked the IMC and just used the MC2 OSEMs as my pitch witness. Before unlocking the mode cleaner, I saw that I was already getting better coherence with the OSEMs than MC2 Trans, so I don't think I lost out on anything by doing the measurements with the IMC unlocked.
We fit the FF TF using vectfit, and hand-added a pair of poles at a few Hz to make the high frequency shape roll off rather than being flat. The result looks very similar to what Arnaud and Marie got for the PRM at LLO (LLO alog 32503), which is good since they're the same type of suspension.
The new filter is in the H1:SUS-MC2_M1_DRIVEALIGN_L2P FM3. The IFO has started relocking though, so we are leaving the pre-existing flat L2P decoupling gain in place and our new filter off. When we turn on the new filter, we'll need a gain of unity in the filter bank.
Next commissioning window, I think we're ready to do an on/off test with L2P transfer functions, to show that the filter is doing good things.
Attached are the individual L2P and P2P transfer functions (excitations done with awggui), and the measured and fit TFs that we've installed.
TITLE: 04/07 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ed
SHIFT SUMMARY:
Locked for a few hours at the beginning of the shift & then high winds (as high as 50 mph!) caused us grief for most of the shift.
LOG:
I have been investigating the seismic system watchdogs. We want to know if the watchdogs threshold amount of motion to shut down the controls of the system can be relaxed. As a first step in doing this I found the threshold values for each of the suspension watchdogs. The channel and the corresponding threshold are shown below. H1:SUS-ITMX_M0_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-ITMX_R0_WD_OSEMAC_RMS_MAX 10000.0 H1:SUS-ITMX_L2_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-ITMX_L1_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-TMSY_M1_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-SRM_M1_WD_OSEMAC_RMS_MAX 15000.0 H1:SUS-SRM_M3_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-SRM_M2_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-SR3_M1_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-SR3_M3_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-SR3_M2_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-PR2_M1_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-PR2_M3_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-PR2_M2_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-ETMX_M0_WD_OSEMAC_RMS_MAX 25000.0 H1:SUS-ETMX_R0_WD_OSEMAC_RMS_MAX 25000.0 H1:SUS-ETMX_L2_WD_OSEMAC_RMS_MAX 25000.0 H1:SUS-ETMX_L1_WD_OSEMAC_RMS_MAX 25000.0 H1:SUS-OMC_M1_WD_OSEMAC_RMS_MAX 12000.0 H1:SUS-IM2_M1_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-OM3_M1_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-ITMY_M0_WD_OSEMAC_RMS_MAX 13000.0 H1:SUS-ITMY_R0_WD_OSEMAC_RMS_MAX 13000.0 H1:SUS-ITMY_L2_WD_OSEMAC_RMS_MAX 13000.0 H1:SUS-ITMY_L1_WD_OSEMAC_RMS_MAX 13000.0 H1:SUS-BS_M1_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-BS_M2_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-IM1_M1_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-MC3_M1_WD_OSEMAC_RMS_MAX 25000.0 H1:SUS-MC3_M3_WD_OSEMAC_RMS_MAX 15000.0 H1:SUS-MC3_M2_WD_OSEMAC_RMS_MAX 15000.0 H1:SUS-RM1_M1_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-IM4_M1_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-OM1_M1_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-MC1_M1_WD_OSEMAC_RMS_MAX 25000.0 H1:SUS-MC1_M3_WD_OSEMAC_RMS_MAX 15000.0 H1:SUS-MC1_M2_WD_OSEMAC_RMS_MAX 15000.0 H1:SUS-ETMY_M0_WD_OSEMAC_RMS_MAX 16000.0 H1:SUS-ETMY_R0_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-ETMY_L2_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-ETMY_L1_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-TMSX_M1_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-SR2_M1_WD_OSEMAC_RMS_MAX 11000.0 H1:SUS-SR2_M3_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-SR2_M2_WD_OSEMAC_RMS_MAX 8000.0 H1:SUS-OM2_M1_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-PR3_M1_WD_OSEMAC_RMS_MAX 15000.0 H1:SUS-PR3_M3_WD_OSEMAC_RMS_MAX 15000.0 H1:SUS-PR3_M2_WD_OSEMAC_RMS_MAX 15000.0 H1:SUS-MC2_M1_WD_OSEMAC_RMS_MAX 18000.0 H1:SUS-MC2_M3_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-MC2_M2_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-RM2_M1_WD_OSEMAC_RMS_MAX 25000.0 H1:SUS-PRM_M1_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-PRM_M3_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-PRM_M2_WD_OSEMAC_RMS_MAX 80000.0 H1:SUS-IM3_M1_WD_OSEMAC_RMS_MAX 8000.0
A link to the corresponding report for Livingston https://alog.ligo-la.caltech.edu/aLOG/index.php?callRep=32886
Summary: there seems to be a correlation between computer errors (for instance timing or IPC errors) with one or two types of blip glitches in DARM.
Explanation:
With the help of Dave Barker, in the last days I have been looking at several FEC_{}_STATE_WORD channels to find times of computer errors. First I used the minute trends to go back 90 days, and after that I used the second trends to find the times of the errors with an accuracy of a second (going back two weeks). I have been looking for error codes up to 128, where 2=TIM, 4=ADC, 8=DAC, 16=DAQ, 32=IPC, 64=AWG, and 128=DK. Finally, I generated omega scans of GDS-CALIB_STRAIN for the times of errors and found that they often show glitches.
Since there were some times that did not glitch, we are trying to track down how the coupling between the errors and the glitches is happening to see if it can be fixed or if the times can be vetoed. It might not be possible to fix the issue until we go into commissioning time at the end of O2, so DetChar might want to consider creating a flag for these times.
Investigations:
With the times obtained from the second trends, I have created tables of omega scans to see how the errors propagate and where the glitches appear. All those tables can be found here as html files, and the lists of times of errors for the last ~two weeks as txt files. So far, the model with the highest rate of glitches vs non-glitches is the susetm(x/y)pi.
I have been looking at some of these glitches, and the loudest ones coincide with small range drops. Also, the three glitches that had a strong residual in the subtraction of the MASTER signal from the NOISEMON signal (see aLog 34694) appear in the minute trends as times when there were computing errors (I haven't tracked those times down to the second though) in the h1iopsusey model.
Between March 24 and April 3, this population of glitches corresponds in average to approximately 10% of the population of blip glitches reported by the low-latency blip hunter (see aLog 34257 for more details on the blip hunter). The maximum percentage obtained is 22.2%, and the minimum is 2.8%
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.
