H1 has been locked for 10 hours as of 20:00 UTC with a steady range of a bit more than 60.  The detector has experienced one or two momentary disruptions per hour over the last seven hours.  Since 17:00 when I arrived, the voice inside has indicated ETMY when these have occurred.  Cheryl had initiated an oplev strip tool earlier this morning; the H1:SUS-ETMY_L3_OPLEV_SUM_OUTPUT trace has moved higher throughout the last couple of hours.  SDF:  OMC Table (5) and Calcs Table (29) are red.  Vacuum:  Several LX and LY ion pump status readouts are linking red. And CP-1 is reading 23.  Dust:  EX dust is alarming white.

8/22 OWL Shift:  7:00-15:00UTC (00:00-8:00PDT), all times posted in UTC

Arrived to Commissioning on a locked H1, and L1 down for last 12+hrs.  Environemental conditions were nominal with wind dipping below 20mph & all seismic bands also quiet.

Want to reiterate that for ER8, we are deeming 1pm - 10pm (with L1 down) as the Commissioning window.  And I'd say if you need a measurement done during the 1-10pm window and H1 is locked, break lock in H1 and do your measurement if L1 is already down.

Additionally, before Evan, Dan, Stefan left, I made sure to have them clean up any differences on SDF.  Most were cleared up except for the OMC. 

After the Commissioning work, H1 has been locked the rest of the shift with nice range ~65Mpc & a few ETMy glitches dropping range.  DARM looks nice.  At times we seem to run below the reference from 10-20Hz.  There is also a bump at about 330Hz which is above reference.  H1 was much less glitchy for this OWL shift vs yesterday.

Shift Activities:

• 7:30 Dan & Evan out to LVEA for PLL set-up
• 8:30 Dan/Evan back.  Mentioned noise around HAM4 (transformer making noise and something else also making noise)
• 9:27 EY Dust monitor started alarming (not surprising with smoke in the air) with high counts for most of the shift on the order of tens of thousands of counts.
• 10:20 On CDS Overview noticed a CFC bit for H1OMC (due to Evan).  Load Coefficients was run to clear this.
• 10:25 With Violin Modes low, Added Whitening to the OMC (via OMC_LOCK guardian)
• 10:31  Went to Observing Mode
• 12:06, 12:38, 13:00, 13:55, 14:42 ETMy saturation
• 13:00 Gave a call to LLO to check on their status (because here they looked like they had good range, but on the GWI.stat page, their status is listed as "NOT OK".  Traced issue to their ODC Observation Ready bit (operator buttons were marked for:  Undisturbed & Observing)--  It was RED.  We then tracked this down to possibly a PSL excitation.  Gary was able to kill the excitation test point and they are now back to GREEN (i.e. OK + Intent).
• Handing off to Cheryl on this smoky morning.

SUMMARY:  Arrived to an H1 locked and in Commissioning, and L1 down for last 12+hrs.  There was some commissioning work and then H1 was taken to Observing Mode at 65Mpc.  Environemental conditions were nominal with wind dipping below 20mph & all seismic bands also quiet.

Commissioning Activity

Had a discussion about WP5442 with commissioners and since L1 was down and there was a measurement which needed to be done before O1, gave them a few hours to run a PLL measurement (they had it from roughly 7-10UTC).

H1 Back To Observing

Once they were done and H1 was back up to Low Noise, a roll mode was noticed aroudn ~41Hz (Dan/Evan mentioned it's a triple).  It rung down after about 10min, but it was huge at the onset.

While checking items before going to Observing Mode, noticed a CFC bit for H1OMC on the CDS Overview.  This was due to Evan & a diagnostic for LSC CARM (which we don't use).  I hit Load Coefficients to clear this bit.

At this point we were hovering at about 55Mpc.  Since we had low violin modes, transitioned from READY_FOR_HANDOFF to  ADD_WHITENING on the OMC_LOCK guardian (and then went right back to READY_FOR_HANDOFF).  This took the range up to 65Mpc. 

The range then went to a cool 65Mpc and the DARM spectrum looked very nice (compared to the previous night)--spectrum was very close/better than the reference.

SDF Overview had some DIFFERENCES, but Evan/Dan cleared most of them.  The only differences left were for:

OMC (5 diffs)

• slider one state at lock acquisition & another value at low noise....should we Not Monitor?
• offsets:  these will change quite a bit.  Not monitor?

CALCS (29 diffs)

• Long list as mentioned earlier

We ran dither lines for BS and SRM during the power increase, as well as during the 45MHz EOM modulation depth reduction:

Lines:
H1:SUS-SRM_M3_ISCINF_P_EXC 7.0Hz, 300cts
H1:SUS-SRM_M3_ISCINF_Y_EXC 7.5Hz, 900cts
H1:SUS-BS_M3_ISCINF_P_EXC  8.0Hz, 100cts
H1:SUS-BS_M3_ISCINF_Y_EXC  8.5Hz,  30cts

Lines started by        2015/08/22 06:23 UTC
Start PWR UP:           2015/08/22 06:24 UTC
Stop PWR UP:            2015/08/22 06:26 UTC
Start EOM MOD:          2015/08/22 07:02 UTC
Stop  EOM MOD (-4dB):   2015/08/22 07:11 UTC
Lock loss:              2015/08/22 07:15 UTC

The EOM reduction reached -3dB, and was lost due to a SRC1_Y run-away.

Attached are (all plots have 72 min span, halting just before lockloss):
- Plot 1: AS RF36 PIT and YAW signals, plus the ASAIR_A_LF_OUTPUT for reference, showing i) power increase, ii)  beam diverter closing, and reopening, iii) modulation index reduction.
= Plot 2: All quadrants of the AS36 WFS, on the same scale
More details later.

Mostly quiet night, first couple of hours were hindered by winds maxing out at ~40mph. Once the max got down to ~35 we were able to lock. Winds have been slowly declining since.

~1:00 UTC Dan discovered an OMC PZT was tripped. See alog 20767.

Most of the rest of the night has been noise hunting.

~6:55 UTC, I went on the roof to look for grass fires as the front of the OSB smelled like smoke, and the cameras were too grainy to see anything. Commissioning crew reported no clear effect on IFO, but there was a series of saturations on ETMY.

[DanH, Jenne]

We have turned on the dither alignment for the OMC once again. 

Prior to the vent and addition of the shroud, the dither alignment was trying to drive the OMC suspension farther than the range of the actuators.  We gave it a try again today though, and it worked just fine. 

We used /opt/rtcds/userapps/release/omc/common/scripts/ditherDCsense.py to measure the DC sensing matrix, and write the calculated input matrix to OMC-ASC_DACTMAT. The matrix was somewhat different.   The servo filters and gains are unchanged, with the exception of the OMC-ASC_MASTERGAIN, which is now 0.05 (was 0.1 when using the QPDs). This is the same gain value that was previously used for the dither loops.   

The offsets in the OMC QPDs have been set so that they will servo the OMC to the same place as the dither servos, so that they agree. 

We didn't see any change in the ~300 Hz bump, even though Gabriele did see the OMC alignment correlate with the size of that hump (alog 20555). 

The use of the dither servos is now back in the guardian.

I've been working on implementing blended inertial isolation on the HAM1 HEPI. This requires designing higher UGF loops, which I've been struggling with. I have Arnauds commissioning scripts, which I used as a starting point, but it was really hard to get as high a UGF as he did. When I dug into his data I realized that his plant was very different from mine. The first attached pdf compares his cartesian super-sensor transfer functions and mine (LLO is green, LHO is red, dof order is X, Y, RZ, HP, Z, RX, RY, VP). The only known difference between the two sites is the grouting on the HEPI piers. To test this, I looked at HAM4 and 5 here. I chose these chambers (4&5) because they are oriented the same direction, their payloads are similar (enough) and HAM5 is not grouted, while HAM4 is. Second attached pdf shows what i found (blue is HAM4 (grouted), orange is HAM5 (no grout), dof order is the same). Clearly grouting makes a difference. On all DOFs except HP HAM4's modes are higher by ~20-40%.

I don't think this makes a huge difference for HAMs 2-6 right now, but for HAM1 it will be difficult to make higher gain loops without grouting. It's not clear that better isolation at HAM1 will get us much right now, though Jeff took some initial measurements a few days ago, in alog 20664.

Jenne, Dan, control room people

Attached are some additional plots of the glitches that Sheila posted about earlier today.  These are the same 'DRMI' glitches which we observed back in ER7 -- or, at least, they are similar enough that I can't tell the difference. 

In our most recent lock stretches, started around 0400 UTC, the glitches have gone away.  The mystery continues.

The excess noise is loudest in POP_A_RF9_I_ERR, which is what we use for PRCL in low noise.  We also see noise in POPA_45_I_ERR (used for SRCL), and not so much in the Q-phases.  See the first plot.  So, they're not an issue with the PD or the demod electronics.  It seems like real length noise, except the noise is very flat.  It's hard to imagine a glitchy actuator making flat noise in the PRC and SRC lengths.

FWIW the noise is also visible in POPAIR, with the same pattern as POPA.  We also see the excess noise in REFLA_45_I and Q (second plot).

Since these glitches appeared in ER7 we have implemented the offloading of the PRM and SRM M3 stages, so the drives to the last stage are mostly around zero.  We looked for any correlation with zero-crossings in the SRM and PRM M3 coils (third and fourth plots).  No smoking gun.

Kiwamu, Darkhan

Recently we analyzed our measurements of AI chassis taken at LHO EY before ER7 (see LHO alog 18639) and fit a zpk filter to a mean of measurements of 20 AI channels using LISO. Standard deviation in magnitude between these measurements were +/- 0.0001 V/V (see LHO alog 18628).

In DARM OLGTF model for ER7, AA/AI chassis TF model was based on measurements taken at LLO (see notes in Matlab file by Joe B and Jeff K that was used to create AA model). LHO EY measurements have a noticably smaller residual over newly created zpk model of AA/AI chassis transfer function at higher frequencies > 1 kHz, than the AA/AI model for ER7. Currently we are using this new AA/AI model to create DARM OLGTF Matlab model for ER8/O1.

Notice that in AA/AI chassis model for ER7 gain at DC was manually normalized to 1.0 [V/V] (it can be seen in the Matlab script that was used to create AA/AI model for ER7). In the AA/AI model for ER8/O1 we did not manually normalize gain at DC to be 1.0, because LHO EY measurements from pre ER7 showed gain of 0.9902 +/- 0.0001 [V/V] at DC (see LHO alog 18628).

LISO output, Matlab script and resulting model were uploaded into calibration SVN:

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/AAAI/fit_eyaifilter.fil

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/AAAI/gen_H1ER7_AA_upto10kHzFitLTI.m

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/AAAI/20150813_H1ER7_AA_upto10kHzFitLTI.mat

Parameters of the filter is given below (.FIL file, output of LISO is in SVN in the same directory):

# This is a LISO fitting script which fits the measured
# H1ETMY AI analog responses.
#
# Aug-13-2015
#
# KI
# $Id$
# $HeadURL$

pole 10.6615185502k 1.0770982348  ### fitted (name = pole0)
pole 7.7365806353k  ### fitted (name = pole1)
pole 50.0077782214k  ### fitted (name = pole2)

zero 65.8451204260k 5.7956773354k  ### fitted (name = zero0)

factor 990.2583471071m  ### fitted
delay 358.2748303132n  ### fitted

param pole0:f 9k 12k
param pole0:q 0.5 2
param pole1:f 5.0k 10k
param pole2:f 20k 70k
param zero0:f 60k 70k
param zero0:q 1 300k
param factor 0.9 1.2
param delay 0 30u

Dan, Jenne, Jim

The OMC PZT high voltage supply tripped today, coincident with a lockloss.  This happens rarely, but it's a subtle problem that is hard to notice from the usual MEDM screens.  We should add a check in the SYS_DIAG guardian that warns the operator if OMC_PZT2_MON_DC is less than ~5V.  If the PZT HV is off, the OMC gaurdian will fail at the FIND_CARRIER step.

We trended the DCPD Sum, PZT voltage, and shutter channels around the time of the lockloss.  The shutter function worked as expected, the PZT2 DC voltage dropped to zero at the time of the lockloss.  There was a large spike in the DC voltage a few seconds after the lockloss but it never got back to +50V like it's supposed to after a lockloss.

We reset the power supply in the highbay.

Kyle, Gerardo 

Today we coupled the ion pump to Y2-8 -> The operation was slow and meticulous but we feel confident that no new net forces are realized by the beam tube nozzle -> We also pumped out and leak tested -> Still to do is the pulling of the HV cable and bake out -> In the meantime we will likely move on to X2-8 and repeat the exercise.  

(Note that Mike Z., Ken Mason and others provided the components used)

We were locked most of the day until ~21:00, out of lock for around an hour, and came back up relatively easily ~22:00.  Another successful PRMI-->DRMI transition trick seemed to help expedite the process. 

Although I failed to note specific times, Kyle and Gerardo were working at Y-2-8 most of the day, and Jodi visited the mid stations for property tagging work.  Neither of these seemed to effect the IFO performance noticably.

Winds have been in the 20-30mph range for the past 4 hours, with a few gusts to ~40mph.

Summary:

A huge range variation from the day before is very likely due to green light. One less thing to worry about.

Chronicle:

In the attached 12-hour trend, t=0 is Aug 20 2015 07:20:43 UTC.

At around t=3.6h, ALSX green transmission started to fluctuate a lot (third plot from the top), and at around the same time the range started dropping (top).

At around t=6.2 something happened, both ALSX and Y unlocked for a short while and then locked to a new lock point (bottom).

After relocked to the new lock point, Y was OK while X was in a bad-but-better state, and the H1 range was similarly bad-but-better.

At around t=9.6, Y arm ALS gave up and lost lock.

Finally, at around t=10.2,  Y arm ALS beam started flashing in the arm and made a huge drop in the H1 range.

We misaligned the PZT for both green beam injection (and later closed shutters) and the H1 was happy.

I will not investige further.

Control room problem:

This is not related to glitches, but NOT being able to get any DMT data in the control room except from DMT viewer and/or NDS2 means that, for example, we cannot use dataviewer for plotting binary inspiral range.

Why?

Ligodv was unusable at least on opsws7 (one of the control room workstations) due to graphics artefacts which is probably Ubuntu problem.

Ligodv on the web (https://ldvw.ligo.caltech.edu/) doesn't have much options for plotting, Travis and I completely failed to make several traces in separate subplots.

Using DMT viewer and dataviewer in separate windows is a pain.

You can go on your own (e.g. matlab like I did here, or python or whatever), but is this really how we are supposed to work in the control room?

On top of that, even though NDS2 works, it takes 2-hours-ish before the binary range data becomes available in NDS2, so if we want a quick analysis of range-noise correlation we need to use DMT viewer and something else in separate windows.

This is a pain.

Sudarshan reports that a PCal line was turned off sometime last night.  He is turning it back on at 17:53.