No issues with IA or relocking.  Here we go again.

The DQ report for December 1 - 4 is online and can be found here.  It's being posted slightly later than normal due to some techincal issues.

Quick Summary:

• Dec 1st had a duty cycle of only 12.9%.  4.7 kHz violin mode harmonics were very rung up and had to be dampened over the course of hours.  Additionally, HAM3 ISI trips and a Peuvian earthquake contributed to LHO's downtime.
• Dec 2nd had a duty cycle of 93% with relatively clean data and low glitch levels.
• Dec 3rd had a duty cycle of 66% and also had generally clean data.  A GraceDB trigger happend at about 20:11 UTC but was rejected by the rapid response team because the LLO Omega scans showed clear glitches.  The LHO Omega scans were less obvious, but it appears Hanford just saw a noise fluctuation.
• Dec 4th had a dutcy cycle of 100% and ended the day ended with an ongoing 33 hour lock.
• The 1080 glitches continue to be prominent.  On Dec 4th Hveto used the channel H1:IMC-REFL_DC_OUT_DQ to veto a significant number of 1080 Hz glitches.
• The loud optical lever laser glitches continue to be seen by DARM.  They are not as frequent as they were a week or so ago but they continue to happen.  During this 4 day stretch some of those loud glitches seemed to be at surprisingly high frequencies (up to ~800 Hz or so).  These were initially reported to be ~20 - 200 Hz.

IFO alignment looks pretty bad which is to be expected after such a long lock stretch.  Running through IA now.

Most likely due to 5.9 EQ in China. 

After JeffB reset the dust monitor alarm level today, the PSL has been intermittently alarming throughout my shift.  Being unable to access the PSL, in addition to being in Observing, I am unsure of what action I can take to investigate this further.

Still locked in Observing.  ~28 hours.

Added 50 mL H2O to Xtal chiller.  Filters look clean.  Completes FAMIS 6500.

Evan G., Jeff K.

Today we identified the H1 parameter file used for the reference model calibration had an incorrect parameter set for loading the inverse sensing function Foton transfer function file. The old file was from pre-ER9 and was when the instrument was running at 50 W. Since we have a different reference sensing function, this file needs to be updated and replaced. This parameter and associated file is only used in the GDS pipeline. Therefore, the EPICS records and front-end do not need to be updated.

Unfortunately, this change means that the GDS pipeline filters will need to be regenerated.

The updated file is stored at: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/Measurements/Foton/2016-12-07_H1CALCS_InverseSensingFunction_Foton_SRCD-2N_Gain_tf.txt

The parameter file has been updated to include this. The reference model parameter files should now be:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/Common/params/IFOindepParams.conf (rev3829)
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/params/H1params.conf (rev3922)
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER10/H1/params/2016-11-12/H1params_2016-11-12.conf (rev3855)

The first attached figure is a comparison of the old inverse sensing function / correct reference inverse sensing function. The low-frequency change is because running at 30 W vs 50 W causes ~2-3 Hz shift in the detuned SRC spring frequency. The mid and high frequency change is because the coupled-cavity pole frequency is different by ~5 Hz and there is a small change in the overall gain, ~5%

Fortunately, we expect the inspiral range computed from GDS to increase. This is because the correct inverse sensing function is smaller than the old inverse sensing function. Since the calibration works as DeltaL = (1/C)*d_err + A*d_ctrl, then with a smaller, correct (1/C), we expect that the displacement noise to be smaller than with the old, incorrect, and too large (1/C). We expect that this may correct some of the discrepancy observed between the GDS pipeline and front-end calibration as shown by the inspiral range (second attached figure). However, we do not think that all the discrepancies will be corrected between the GDS pipeline and the front-end calibration (see third attached figure).

While we were out of observing I did a few quick things to try to make our locklosses a little gentler.  (part of WP 6391)

First, I set limits on the TR QPD pit and yaw signals of 2, rather than 100 which were the previous limits.  These shouldn't go above 1 if we are locked, but can become large after a lockloss and send large signals to the suspensions through the soft loops.  I accepted the new values in SDF so we could go back to observe.

I did a little bit of work on the down state of the ISC_LOCK guardian, and loaded some of the changes.  

• One problem was that it was setting TRAMPS, GAIN and then clearing history for the same filter bank in consecutive lines, which we know doesn't necessarily happen in order, so this might set the gain before setting the tramp, and certaintly will clear the history before ramping the gain down.  
• There were some things that were done in both the ISC_LOCK guardian and in ISC_DRMI, (handling of DRMI ASC) which I've removed from ISC_LOCK.  
• moved the things that are importatnt to the begining of the state, so they will happen faster.  

We can see if this makes things better for the next lockloss.  

We are leaving the gas N2 bottle connected to lower sensing line overnight. I lowered the N2 line pressure from 180 psig to 100 psig and re-connected the rotameter and adjusted it so if the blockage does break loose flow into LN2 reservoir will be limited to 3 LPM.

Attached is photo of pressure regulator values for Kyle and John. ;)

I will finish installing TCs tomorrow and hope my fingers don't fall off in the process.

J. Kissel (B. Weaver, S. Dwyer)
FRS Ticket 6852

It was recently identified that a Dec 05 lock loss looked suspiciously cpoincident with a glitch in the H1 SUS SR3 M1 T1 and LF OSEMs (see LHO aLOG 32220). The same OSEMs were suspected in a subsequent Dec 06 lock loss (LHO aLOG 32251), and thus an FRS ticket was filed (FRS Ticket 6852), but was later deemed too confusing to draw conclusions (see brief mention of it in LHO aLOG 32279).

Betsy then went back to find the minute trends of the SR3 OSEM noise appeared suddenly louder after the Dec 05 glitch/lock loss in a 5 day trend surrounding the glitch (split into LHO aLOGs 32280 and 32281).

In this aLOG, I investigate further by zooming into 10 minutes surrounding the Dec 05 glitch. I attach three plots:
- A 10 minute trend of second trends for the suspect channels, both in terms of uncalibrated EPICs records (the same that Betsy chose to use in her aLOG) and in calibrated fast channels (stored at 256 Hz). The EPICs records show a similar sudden increase in amplitude of max and min trends, but the calibrated fast channels do not. T1 shows a much larger increase in max/min noise than LF.
- A full-data time-series of the same to channels in the same two formats. Same thing here regarding the sudden increase in noise in T1 INMON, but only a brief glitch in LF's INMON. Again, no such obvious change in behavior on the fast channels. Interestingly, it looks like there's smaller glitch in T1's fast channel 107 [sec] earlier.
- An amplitude spectral density of the calibrated fast channel before and after the glitch happens (15:57 UTC vs 16:06 UTC, 0.04 Hz BW ASD). There's no obvious difference between these spectra. This points to either the excess noise showing up in the INMONs is at higher than ~100 Hz, or the EPICs records are just reporting bogus information. Because I'm suspicious of the apparently incredibly low microseism, I also attach BLRMS of the microseism on the ground and on the ISI around this time. Indeed, the GS13s seem to confirm that the RMS velocity is somewhere around 5 [nm/s], which is roughly equivalent to ~5 [nm] at 0.15 Hz, which in the right ballpark of what the OSEMs report of 2-4 e-3 [um] or 2-4 [nm] or 2-4 [nm/s].

In conclusion -- still no evidence for anything more than a one-time glitch, and there is now little-to-no evidence for permanently different noise behavior after the glitch. We need to wait for more occurances of this issue with obvious evidence before we go for making any change to the instrument.

TITLE: 12/08 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 68.7782Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
    Wind: 10mph Gusts, 8mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.29 μm/s
QUICK SUMMARY:  Observing for 23 hours now.

0:10 Intent bit set to commissioning so Evan can turn off high frequency PCal line for HW inj.

0:11 Evan accepted the new SDF diff for PCal, so we went back to Observe.

0:17 Injection gain ramping dropped us out of Observe, Evan set this gain to 'Not Monitored', and we were back to Observe within the minute

0:34 PCal HF line turned back on, out of Observe.  I am running a2l since it looks like it is time, and Sheila is opportunistically working one of her work permits.
 

I turned off the 4301.3 Hz Pcal line at 00:10 Dec 8 2016 UTC for the planned stochastic injection. This dropped us from observing intent for a brief time. I updated the SDF and we returned to observing. I will turn the line back on once the stochastic injection has concluded.

I've scheduled a coherent stochastic injection for 00:20 UTC (16:20 PT). It will take 13 mins. The update to the schedule file is:

1165191617 H1L1 INJECT_STOCHASTIC_ACTIVE 1 1.0 stoch/Waveform/SB_ER10_{ifo}.txt

TITLE: 12/07 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 70.7388Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:  Pretty smooth shift as far as locking goes.  Some excitement regarding CP4 (see aLog 32283).  Also, set some arbitrarily high thresholds for most dust monitors to stop alarms.  JeffB will reset them tomorrow.  Locked for over 6 hours now.
LOG:

3:35 CP4 alarm

5:24 GRB alert, contacted LLO who verified that they received the alert, begin standdown

6:24 GRB standdown end

7:10 PI mode 27 ringing up, changed phase from 20 to 120.  Did not go out of Observe.  Are we supposed to go out of Observing to make PI mode changes??