H1 Status:

Seismically quiet and winds are hovering at 10mph or below.  TJ handed off a 24W H1 with range hovering between 61-69Mpc (but with glitches every ~30min).  The latest glitch at around 12:55am (7:55utc) caused a noticeable drop in the range, but the range is now tightened up to a flatter trend between 61-63Mpc.  I haven't noticed anything noisier on our FOMs to warrant the drop in range, but it does look a little more stable/steady.

Double Coincidence:

L1 has also come back and I chatted briefly with Will & Adam.  They said their locks have generally been lasting about ~5hrs.  At any rate after our step down in range, H1 & L1 are double coincident at about 62Mpc.

Misc:

EY VEA lights still on.  (I shut off all the lights I can shut off here in the corner station for the quieter weekend.)

Evan, Kiwamu, Stefan (WP 5252)

We did a couple of tunings for 2 hours tonight during the time when LLO was down. This resulted in a inspiral range of 66 Mpc.

(ASC SRC1 yaw)
First, we tried powering up the PSL power from 17 W to 23 W to see what optics ran away. We confirmed that SRM was the one who ran away in yaw through the actuation of the ASC SRC1 loop as we went to 23 W. We searched for a signal which may represent this run-away motion of SRM. It seemed that the best choice was AS_A_36_I. Therefore we mixed this signal to the existing AS_B_36_I and AS_36_Q. Right now the SRC1 yaw signal is derived by -0.6 x ASA36I + 0.3 x ASA36Q + 0.3 ASB36I.
So far it kept holding SRC without a run-away issue on a time scale of 2 hour. This change is already reflected in both ISC_LOCK and ISC_DRMI guardians. Attached is a plot with the AS 36 YAW error signals during the tuning phase and first 2h of stable locking at 23W.

(AS36 whitening gain)
When we were at 23 W, we noticed that a few rf segments of both AS_36_A and _B saturated. So we decided to decrease the whitening gain from 24 dB to 21 dB. As a compensation factor we put a gain of 1.4 in the signal conditioning digital filters (i.e. H1:ASC-AS_A(B)_RF36_I1(Q)_GAIN). In this way we avoided updating all the ASC loop gains associated with these signals. This seemed to be fine for the locking sequence as well. So we will leave them in this new whitening gain configuration. We updated the SDF accordingly.

(Switching off ETMX ESD)
Evan forced us to study the effect of the ETMX ESD bias. Evan will post a detailed alog later. We remotely switched off the ETMX ESD and saw an improvement in frequency range from 40 to 100 Hz by a few 10%.

(Calibration correction with Pcal Y)
At the beginning the range went above 70 Mpc and therefore we started checking the calibration. According to the Pcal Y line at 540 Hz, the optical gain was too low by 4% compared with the peak height from this morning -- this underestimated the displacement and hence too-high inspiral range. We then adjusted the optical gain in the OMC error path and now the Pcal line agrees with the one from this morning. So the calibration is good.

(An accidental lockloss)
At around 2015-06-06 3:21 UTC, we accidentally lost the lock due to a senior LIGO fellow mistakenly pressing a wrong button during the high power study. This was the only lockloss we had in the past 10 hours or so.

With the commissioning work done, the Intention Bit is set back to Undisturbed.

We are currently locked at LSC_FF.

WP 5251,

At around 2015-06-06 2:30-ish UTC, I enabled an elliptic low pass filter in the top stage longitudinal damping loop in the SR2 suspension, at FM10. This is something we meant to enable all the time (alog 18694) but somehow got disabled a couple of days ago for some reason. I updated the SDF accordingly. So fat the SR2 suspension looks behaving fine.

With LLO down, we have some work permits to take care of.

The work consists of: Stefan increasing the power back to 23W and Kiwamu enabling a low-pass filter in SUS SR2.

At 19:28pst the Intention Bit was switched to Comissioning to reflect the work being done.

More seriously, since several people asked me how to have "real time" info about the status of the detectors, I advertize here 
 this monitor  that Peter Shawhan and Chad made, displaying basic detector status with ~30-45 seconds average latency:

https://ldas-jobs.ligo.caltech.edu/~pshawhan/gwistat/

Stefan, Kiwamu,

In this morning, DARM had many numbers of glitches which were visible in the DARM spectrum as wide band noise. We looked at various channels to see what caused the glitches, but we were not able to identify them.

We would like to get some help from the detchar people. Could you guys please look for a cause of the DARM glitches ?

The lock stretch which had a high glitch rate is the one starting at 2015-06-05 17:17 -sh to 18:00 -ish UTC. I attach an example time series of the glitches shown in OMC-DCPD A and B. We know that some of the loud ones were so large that they saturated the ADCs of the OMC DCPD.

Note that in the same lock stretch, we changed the DARM offset multiple times which changed the amount of the carrier light resonating in OMC. We do not think our activity with the DARM offset caused the high glitch rate.

WP5250

I have changed the CDS STATE_WORD overview MEDM screens to show a red rectangle if any of the DAQ systems stop updating. If today's freeze up of the broadcaster were to re-occur, it should now show a red alert. I'm using the h1ioppsl0 GPS counter as the standard against which I compare the DAQ GPS counters. If they lag by 60 seconds the alert is shown.

There has been some discussion on how alogs are ordered on the web page. Here is what I learned this afternoon after speaking with Ryan.

Each page displays 20 entries. These can be new entries made recently with no comments or new entries with recent comments, in which case they are listed in chronological order of the initial post.

If any of today's entries are comments to an old post (one which would normally not be displayed in the page) then the initial post is shown in today's page, along with every comment it has garnered including today's comment(s). These "promoted" entries are shown at the bottom of the page in chronological order of the initial posting.

For example, at the bottom of today's (Friday 05 June 2015) first page there are two old posts which were commented on recently, they are in the order: 

evan.hall@LIGO.ORG - posted 21:21, Thursday 04 June 2015 - last comment - 12:47, Friday 05 June 2015(18878)

kiwamu.izumi@LIGO.ORG - posted 11:16, Friday 29 May 2015 - last comment - 14:45, Friday 05 June 2015(18693)

Note the order of the initial post, not the order of the last comment.

Therefore the alog entry numbers can be out of sequence. Also some numbers may not appear at all if they were assigned to a draft entry which was subsquently abandoned.

For some guidance regarding beam centering in HAM6, I post here the estimated Gouy phase for the optical elements between SR3 and the OMC.  The a la mode script that was used is attached, along with the parameters file which uses the best available positions of H1 optical elements in HAM6.  This is the same material that was posted in alog:14023, here I add information and SR2, SR3, and AS_C.

From these results there's no obvious pairings of actuator --> sensor, except for OM1 --> AS_B and OM2 --> AS_A, which is essentially what we're using right now.  The OMC QPDs are degenerate, but we construct a waist basis for the OMC alignment, {OMC_A, OMC_B} --> {POS, ANG} using the known geometry of the OMC breadboard.

The plots attached show the beam propagation for the path from OM1 to AS_C, the AS WFS, and the OMC, respectively.  Note that these beam propagations are for a single-bounce beam from ITMX.  We know the mode from the full IFO is different (because the mode-matching into the OMC is different, between a single bounce and the full IFO), but it's not a large difference.

Anyways we shouldn't rely on simulation, we should measure the sensing matrix from {SR3,SR2, OM1, OM2, OM3} --> {AS_A, AS_B, AS_C, OMCA, OMCB} and work out a control scheme.

The a la mode script and parameters file are attached.

Apollo finished the beam tube this afternoon.

No other site related activity to report.

IFO:

Short lock around 17UTC was very glitchy, and didn't last.

I helped the DRMI alignment when relocking and while it took about two hours and more than one attempt to get the IFO back to full lock, the current lock has been going for almost 3 hours.

Intent bit was engaged and alogged earlier.

Changes during this lock are that the OMC Dither was turned off and then on again.

SDF was red but now green.

Kiwamu has an approved work permit to enable a filter on SR2, which has glitched a few time during this lock.

Stefan has an approved work permit to try for 23W locks as soon as he has an opportunity.

Chris S.

Beginning 120 meters from the corner station on the X-Arm, 40 joints were cleaned and metal strips attached. 
Caulking still needs to be completed on those joints. 

Scott L. Ed P.

Cleaned 33.5 meters of tube ending 8.4 meters north of HNW-4-066. Cleaning crew left at noon, both feeling ill.

A total of 3297 meters of tube cleaned to date.

With help from Betsy and Corey, and confirmation from Kiwamu and Hugh's alog, I cleared the IMC-DOF offsets - confirmed as a change from Robert's work and working well.

I also turned the OMC-ASC_DITHER_MASTER off.

I don't see any of the alogs I posted last night.  I can see them if I search myself, and they show up, but they aren't showing up in the alog.  BUG!!!

Something is not healthy on SR2 suspension.

Recently we noticed that some DAC on SR2 suspension saturated intermittently at a rate of roughlu once per 10 minutes or so. At the begginig we thought this was due to some ISC feedback saturating some DACs when we lock the interferometer. However, it turned out that it saturates even when no ISC feedback is sent.

The attached is a one-hour trend of all the saturation motniors of the SR2 top stage actuators from the period when SR2 was aligned and damped without any ISC feedback signals yesterday. As seen in the plot, the RT and LF DACs saturated mutiple times. The LF saturated more frequently than the RF actuator. Looking at the suspension screen, Betsy and I found that the longitudinal dampig showed higher signal level at its output than every one else. It is on the order of 100 counts at the output. Betsy is currently checking the longitudinal damping loop by running a transfer function measurement.