There is evidence of the NPRO trip and current tweaking from last week. Head flows/pressures are being monitored closely on a regular basis, currently. Also included, for your entertainment is a plot of the power stability into the IFO from the rotation stage from the previous 12 hours of lock. Gerardo was questioning the "bouncy" (+/- .1W) numbers of the input power showing on the Ops overview, so we trended it.

23:54 as a segue into some commissioning work. LLO was notified.

TITLE: 07/24 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 51Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    Wind: 10mph Gusts, 5mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.17 μm/s
QUICK SUMMARY:

TITLE: 07/24 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 50Mpc
INCOMING OPERATOR: Ed
SHIFT SUMMARY: 11.5 hour lock at 50Mpc, not much else going on.
LOG:

• 18:26 Corey to MY
• Dave starting WP7083 
• 18:46 Corey Back

model restarts logged for Sun 23/Jul/2017 - Mon 17/Jul/2017 No restarts reported

John, Bubba, Dave:

WP7083

the cell phone alarm system was reconfigured and restarted to add the CS, EX and EY water pump status channels. In the  FMCS EPICS database there is a CALC record which performs an inclusive OR on the pump status. If at least one pump is running, the STATUS is ONE. If no pumps are running, the STATUS is ZERO. The alarm levels are HIGH=1.5, LOW=0.5. There is no delay in sending the cell phone texts when an alarm is triggered. This completes this WP.

The full report can be found on the detchar wiki: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20170720

Below I summarize the main highlights of this shift:

-The duty cycle was 78.5%, the range was stable around 53Mpc.
-We went to out of observation intentionally at 19:13UTC to dump violin mode on Thursday.
-The glitches around 20Hz at 10:00 UTC seem to be due to overflows in all of the test mass L2 coils
, perticularly the pitch motion of soft mode in cavity, similarly at 8:00UTC on Thursday.
-GRB alert occured at 01:49 UTC, 02:48 UTC, 04:31 UTC, 16:16 UTC and 21:11UTC.

Laser Status:
SysStat is good
Front End Power is 33.94W (should be around 30 W)
HPO Output Power is 154.9W
Front End Watch is GREEN
HPO Watch is GREEN

PMC:
It has been locked 5 days, 23 hr 37 minutes (should be days/weeks)
Reflected power = 17.22Watts
Transmitted power = 57.55Watts
PowerSum = 74.77Watts.

FSS:
It has been locked for 0 days 6 hr and 20 min (should be days/weeks)
TPD[V] = 2.354V (min 0.9V)

ISS:
The diffracted power is around 2.8% (should be 3-5%)
Last saturation event was 0 days 6 hours and 20 minutes ago (should be days/weeks)

Possible Issues:
PMC reflected power is high

Need some commissioning time today. New items from DetChar and old items that they didn't have time for last week.

Virgo engineering run coming up soon. They will most likely be on GraceDb, not GraceDb-test for this run.

Went over Tuesday Maintenance activities tomorrow, see whiteboard for complete list. New items:

• Bubba will be running the well pump in the morning to fill the fire tanks
• Dozen or so UW students in for tour tomorrow, would like to go into LVEA
• PCAL might want to go to EY for line investigation
• Sudarshan may want to do a PCALX spot move test
• Jim wants to do a HAM4 SRCL FF TF
• Jeff K to run rubbing TFs on CS optics
• CDS on floor taking measurements for future squeezer equipment

Update on Raven/Crows/Black Birds LN2 lines:

• Chandra will bring a company out to insulate the lines.
• Not sure of timeline yet.

Attached are the PSL Laser Head flow rates for the last 3 days.  On 7-22-2017 at 15:45 UTC (8:45 PDT) all 4 heads saw a drop in flow of ~0.03 lpm.  This lasted for ~2 hours, and then all flow rates returned to normal.  None of the other flows or pressures showed a change at this time, so it is unclear what the cause was.  The flow reading from the Head 2 flow sensor continues to have periods of noisy readings, which has been the case for this sensor since it was installed.

The glitchy periods at 10 UTC today, and 8 UTC on July 20, seem to be due to overflows in all of the test mass L2 coils. The cause of the overflows looks to be CSOFT pitch.

The attached plots show timeseries of CSOFT pitch and ITMX L2 master for one quadrant, then a spectrogram of the coil signal. It looks like most of the power is in the 2.8 Hz pitch mode of the test masses. From the summary pages, it looks like the RMS of CSOFT pitch has crept up over the last few months.

When the coil drive goes over 131,072 counts, the DAC overflows and the coil glitches. It's possible that I have things backwards, and the glitch comes first and the overflow is a symptom, but that doesn't seem to match the behavior of the RMS at non-glitchy times.

Is there a way to get CSOFT pitch lower, or maybe suppress some of the feedback at 2.8 Hz (which I think is the biggest contributor)?

FAMIS4737

All oplevs seem to be where they should be, looks good.

aLOG 37666

Looked at the BS UR signal as reported by Jenne. Disconnected noise monitor outputs of coil driver and shorted the inputs to the AA chassis. From here we could see that UR has ~10dB gain difference than the other channels. Power cycled both the AA and coil driver, transfer function showed no change. Coil driver S1000355 in SUS-C6 slot U26 was replaced with S1100039. Transfer function for all signal outputs the same.

F. Clara, J. Driggers, R. McCarthy

I'm checking the coil driver switching while we wait for the earthquake to ring down, to ensure that the analog switches are actually switching. Here's a rough note of my method:

* Set BIO state request to negative of the value that you want (i.e. -2 for state 2, -3 for state 3).  This gives you control of the coil out filter banks (ex. H1:SUS-ITMX_L2_COILOUTF_UL). Do this for all 4 quadrants.

* Turn off all filters, so you have a flat digital TF from the excitation point to the driver. Do this for all 4 quadrants.

* For BS (only one with oplev damping), disable oplev damping.

* Take TF from coil output filter bank excitation to fastimon channel (ex. H1:SUS-ITMX_L2_COILOUTF_UL_EXC to H1:SUS-ITMX_L2_FASTIMON_UL_OUT).

* Switch analog coil driver state, retake TF, confirm that it changed as expected.

* Put state request back to positive number that it started at; this resets the digital filters appropriately.

All switching seems fine for PRM M3, SRM M3, ITMX L2, ITMY L2, ETMX L2 and ETMY L2, which is all suspensions and stages that we switch coil driver states for, except for BS M2.  BS M2's UR coil is different from the other coils on BS M2. 

I'm attaching a screenshot of the BS measurements, showing that the shape of the UR analog driver is slightly different in each state, and the overall gain is different by about 8dB. 

I ask that the BS M2 coil driver be looked at first thing in the morning.

Keita pointed out that we have only been using OMC DCPD B for at least the last lock.  I trended the relative gains of DCPD A and DCPD B, and it looks like we've been in this situation since 16July2017 at around 05:30 UTC.

The attached is a 5 day trend of the gains.  The 2 spikes earlier are when we were either adding or removing a layer of whitening, due to the violin modes being too high.  On the 16th, it looks like the guardian was started to switch the whitening, but then maybe got stopped halfway.  This explains why it has looked like the shot noise was too high the last few days.

Clearly we need to write into the READY_FOR_HANDOFF OMC lock state to ensure that the 2 gains are both at their nominal values.  Also, it looks like someone accepted the wrong values into the Observe SDF file, so we've been able to go to Observing with the wrong values :(  No good.  The safe SDF file was correct.  I'll fix the Observe file.

EDIT:  Looking through the guardian log file, it looks like the code gets a bit confused when you try to use these states before we're using the DCPDs for DARM.  So, now if we're at DC_Readout_Transition or before (and don't need to do any gain ramping), we skip the gain changes and just change the whitening.  If we're on DC_Readout or after, the change will happen as before.  Either way, at the end of the state is now a check to see if the DCPD gains are equal (they should both be 1000).  The new code is in the svn and has been reloaded, although not actually used.