Looking at the subtraction for today, I noticed that the PEM mainsmon (PEM-EY_MAINSMON_EBAY_1_DQ) was coherent enough to subtract noise at frequencies other than the power lines.  This is pretty unusual, so we're trying to think up things to check, like whether the ETM is much more charged than it used to be.  TVo and Sheila are looking at BruCo to see if anything else looks suspicious.

I'll take a quick look to see if other mainsmon channels are also highly coherent, but this may be an interesting avenue to look at for why we have this extra noise now. 

Of note is that I didn't see this mainsmon subtraction for data from July 15th (alog 37590).

attached is h1guardian0's performance plot for the month of July. The restart of DIAG_MAIN a week ago cleared memory, yesterday's reboot reset the CPU overload.

Everything looks nominally ok except for a couple of glitches in EX

Starting at 04:25 PDT this morning (11:25 UTC) the virgo alert system stopped working.

The log file reports a bad request error:

Traceback (most recent call last):
  File "/opt/rtcds/userapps/release/cal/common/scripts/vir_alert.py", line 498, in <module>
    far=args.far, test=args.test))
  File "/opt/rtcds/userapps/release/cal/common/scripts/vir_alert.py", line 136, in query_gracedb
    'label: %sOPS %d .. %d' % (ifo, start, end))
  File "/opt/rtcds/userapps/release/cal/common/scripts/vir_alert.py", line 162, in log_query
    return list(connection.events(query))
  File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 618, in events
    response = self.get(uri).json()
  File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 374, in get
    return self.request("GET", url, headers=headers)
  File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 488, in request
    return GsiRest.request(self, method, *args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 356, in request
    return self.adjustResponse(response)
  File "/usr/lib/python2.7/dist-packages/ligo/gracedb/rest.py", line 369, in adjustResponse
    raise HTTPError(response.status, response.reason, response_content)
ligo.gracedb.rest.HTTPError: (400, 'BAD REQUEST / {"error":"Invalid query"}')
 

TITLE: 07/19 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 53Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
    Wind: 4mph Gusts, 2mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY:

Smooth handoff. A2l measurement shows some PIT issues but nothing so serious yet as to affect DARM.

At mid shift, all is green and clear. No problems or issues to report. 

All dust monitor vacuum pumps are operating within normal temperature and pressure ranges. The pump at End-Y is getting a bit noisy. Will monitor the exhaust filter for carbon build up, which foretells of a pending vane failure.     

TITLE: 07/18 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: OBSERVING 54Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY:

Post Maintenance Commissioning & Calibration activities started off the shift.  Had a lockloss due to commissioning, but H1 came back with no hitches.

LOCK CLOCK appears down

Reran Verbal Alarm, since it appeared to not work at the beginning of the shift (that's 2-shifts in a row).
LOG:

• 23:40 Harrah Elementary tour by Elizabeth
• 23:43 Back to NLN
  • CARM Gain measurement (Vo)
  • Calibration measurement afterward (Kissel)
• 1:22 OBSERVING
• 5:33 Run A2L While L1 down
• 5:38 Back to OBSERVING

H1's been in OBSERVING for just under 2hrs (& locked for over 3hrs...but the Lock Clock on nuc1 isn't working).

Sheila, Pep, TVo

Motivated by the extra DARM noise below 90 Hz (see Jenne's Alog-37590), Sheila thought that maybe it was do to the CARM loop moving around due to optical gain changes after the Montana EQ.

So we went to the LVEA during commissioning time to take a transfer function (Picture 2), and found the UGF to be around 24 kHz and about 15 degrees phase margin

In a previous Alog-36686, it seemed like a good UGF was around 18 kHz so we decided to change the gain on the REFL servo from 7db to 6db.  This shifted the UGF down to 17 kHz and about 65 degrees of phase margin (Picture 1). 

However, this didn't really help DARM solve its mystery noise mentioned above, so the search continues.

This is a quick summary of work done by many people today:

• We found that we were only using one DCPD for the last couple of days, which made shot noise bad. (Jenne's alog 37585) Fixing this improved our range from ~45MPC to ~55MPC
• We see that the low frequency noise is still bad since the EQ and that it is not coherent with anything. (Jenne's alog 37590) We checked out a few ideas about what could be responsible for this noise.
• The CARM UGF was too high causing the loop to have a good deal of gain peaking (Thomas Vo and Pep Corvas alog 3594)  We reduced the gain by 1dB which helped a bit and this is now in the guardian, but this wasn't the low frequency problem.
• We tried moving the CPs since those could be in a different location than before the EQ.  We saw spots from CPY on both the PRM camera and the SRM camera, where the spot is very close to the SRM spot, but moving them around makes no difference to DARM.
• We tried moving the spot on PR3 (POP A) and looking at the jitter coupling, similar to what was done in 37000. The first attachment here is directly comparable to the plot in 3700 and seems similar.
• After Jeff did some calibration measurements I quickly scanned the full range of the ETMX ESD bias to see if that made any impact on the noise. (It didn't, only the 60 and 120 Hz lines)
• We noticed that the RF9 stabilization control signal became much larger at low frequencies after the work done July 14th on RF72 (37498 and comments).  

The last plot shows a couple of sensitivity curves, illustrating the problem.  

Took H1 back to OBSERVING at 1:22utc (6:22pm).  Had an SDF Diff, but it was related to the REFL Servo Gain noted by Thomas & Pep.

Running with a range of ~54Mpc.