Accumulated hours are as of 8 am local time on February 3rd, 2017.

Original front end diode box S/N OBS2-FE-DB.  This diode box has since been
refurbished.
18082 hours

Replacement front end diode box (this box was only swapped out due to a power supply failure)
This diode box still has diode current head room despite the large number of operating hours.
S/N DB-1207
18116 hours

Current front end diode box S/N SPARE3-FE-DB
5104 hours

The high power oscillator diode boxes, OBS2-DB1, OBS2-DB2, OBS2-DB3 and OBS2-DB4
have 15795, 15795, 15794, and 15794 hours respectively.

TITLE: 02/03 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC

STATE of H1: Observing at 66Mpc

INCOMING OPERATOR: Corey

SHIFT SUMMARY: Quiet shift. Been locked for 22 hrs. Leaving a bit early. It's snowing outside.

LOG:

~15:30 Peter to Diode room to take some picture.

After falling quite low the previous week, the reference cavity transmission increased without
intervention.  With the decrease in room temperature the reference cavity transmission has
decreased again.  Attached is a plot showing the trend.

Been locked for 18.5 hours. Not much happened since shift started. Cleared timing error on IOPASC0 when I got here.

TITLE: 02/03 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 64Mpc
INCOMING OPERATOR: Nutsinee
SHIFT SUMMARY: 14hr lock, so it was quiet.
LOG:
 Corey had the IFO locked when I got here. I'm leaving it locked for Nutsinee. Not much happened in between.

Summary of the DQ shift from Monday 30th Jan to Wednesday 1st Feb (inclusive), click here for full report:

• High and variable duty cycles; 95%, 66% and 80% Observing for each day of the DQ shift. The 66% was Maintenance day.
• Range sitting around 65-68 Mpc.
• Noticed a single overflow of H1:ASC-AS_C_SEG# (which relates to my aLOG).
• One of the locklosses on the 30th Jan may be caused by winds (despite they are not as strong as the ones LHO is capable of handling) (see attached pic for time coincidence).
• The other lockloss on the 30th Jan while there was a time coincidence with Keita operating the ETMY SDF restore screen, it may have been only coincidental because the most obvious cause was the strong peak on ground motion at ETMY which started tens of minutes before the lockloss.
• The highest NewSNR glitch reported by PyCBC live took place on the 30th Jan, with a NewSNR of 11.9. It was a blip glitch coincidental with SUS-PR2_M2 and CS LVEA MAG. (see attached pics).
• As usual ETMY ESD overflows dominated the sharp range drops.
• Reminder: The ETMX ESD high voltage amplifier turned off after some Beckhoff work this morning. This was turned back on, however there is indication of considerable discrepancy between running current after the switch on and previous notes that Patrick had.
• Notice that 15-25 Hz glitches up to half an hour before the lockloss of the 31st Jan may have been due to scattering from RM2 mirror (see attached pic).
• First lockloss of 1st Feb may have been related to increased very low frequency (0.01-0.03Hz) motion on ETMY, also observed saturations of the End Y Transmission B QPD. (see attached pics)
• The 2nd lockloss of 1st Feb was due to TCSy Laser Tripped, IR Sensor Fault. Once resolved, it was followed by yet another TCSy Laser Trip . This may be related to the excess noise of 'ITMY TCS CO2 outofloop ISS' during the day. (see attached pic)
• Long time duration range drop of 1st Feb after first lockloss (about 15:00 UTC) is clearly due to PI ring up (also mentioned by operator). (see pic)
• Hveto had one relatively high Significant veto channel before the first lockloss of 1st Feb, with Round 1 winner being H1:ASC-AS_A_RF45_Q_YAW_OUT_DQ (signidicance of 79.38). These glitches are coincident with huge glitches on the main suspension channels 14 secs before lockloss.
• IMPORTANT: Between the first and 2nd lockloss of 1st Feb there were continues Softwarte saturation of H1:LSC-X_ARM_CTRL.

TITLE: 02/02 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC

• 16:40 PSL Chiller fill (Patrick)
• 17:02-17:44 Down For Lockloss (Reason?)
  • MC lockloss during PRMI which was odd
• 17:08-17:25 Attempting to recenter STS2 (Hugh & TJ).  Forgot to turn off BRSy, but did not see a rung up BRS.
• 17:50-17:53 Turning ON propane forklift engine to charge battery (Joe)---->This caused noise on DARM, don't allow!  
• 18:28-19:28 GRB Stand Down completed for H1 & L1.
• 18:58 Installing new Ops Station (operator0)
• 19:00:55, 19:05:22, 19:10:16, 19:43:40-19:44:00 Mass Storage Room door slam (not seen on DARM spectra)
• 19:19 TCSy Chiller Flow Low
• 20:38 Routing timing cable to H2 Elec Room (Barker)
• 22:02:58, 22:06:15 Heard something heavy drop (in MSR?)---most likely tiles dropping for cable work.

I looked at a few times pointed out to me by Aidan and Betsy and didn't find any evidence that the flow rate sensor glitches are coupling into h(t). I've attached one example where there are two fairly large glitches in the flow rate readout with no visible effects in the h(t) spectrogram from the same times.

WP6465 Re-route timing for EE-lab to DTS

Dave, Jim, Fil:

Instead of running the EE-Lab timing-fanout directly from the MSR timing-master, we re-routed this fiber line to the timing-fanout in the DTS (H2 building). This means the EE-Lab timing-fanout can be turned on and off without impacting on the Beckhoff SDF settings.

We repurposed the fiber pair connected to ports [13,14] of the Multimode patch between MSR and H2 Building. Last year we had used this line for temporarily extending the CDS network into the DTS for environmental monitoring (we left the fiber-ethenet converters in place in the DTS and MSR).

The EE-Lab timing-fanout was turned on and locked its signal correctly.

Putting the concrete floor tiles back in the EE-Lab and MSR made some noise, this was noted by the operator.

CDS group running cable (WP6465) & heard loud thumps from HEAVY floor tiles (50-70lbs) being dropped.  This happened multiple times and some of the drops were seen on the H1 DARM Spectra.  

Here are times where we saw the bumps:  

22:02:58 & 22:06:15

General Keita Notes:

• LSC Spokesperson election brought up:  give your opinion to a Council Person
• SDF Diffs:  If a change is made to one's system, please stay on-site until we are close to OBSERVING (namely, when we check for SDF Diffs).  We would like an expert to go over SDF Diffs which come up.  If this happens late at night, the operator should try to call the person who made the change & consult with them.

Tues Maintenance Day (1/31) Hold Over Items (possible for next Tues?) 

• BRSy PEM STS2 still address centering (hugh)
• MX purge air maintenance (gerardo)
• updating cal deltaL external (kissel)
• ITMx scatter measurement (betsy, jason)
• RF EM Field investigations cont. (dick)
• Cleanroom curtains?  (bartlett)
• ITMx oplev deglitching....jason needs to get set up for this & then will file work permit when ready.  (Will update Sheila on this point)

Next Tues New Items

• Inspection/investigation temperature sensors for TCS (Vern)
• EY roofing contractor (Bubba)
• Control Room HVAC work Tues morning (Bubba)
• Work station swaps (Carlos) ongoing
  • Remember to logout of computers when done!
• Restart ISIs HAM1,2,3----> Will do HAM3 on Tues (can do ALL IF a big EQ trips them all & Hugh/David are on-site)  [Hugh]

Just remembered to install the latest autoBurt.req in the h0vacex target area, stemming from Tuesday's code change.

[17:50-17:53 Flagging H1 Data due to Forklift engine near LVEA.]

Right after getting to NLN there was a request to power ON our propane forklift  (to charge battery) which is here at the Corner Station just outside the Receiving Roll Up Door area.  We don't allow driving of forklifts around the VEAs while in Observing (go/no go document), so I thought just turning on the engine would be fine, BUT Evan noticed some noise on DARM between 40-50Hz on DARM.  So, I quickly ran out to ask Joe D to power off the forklift (And yes, it was noisy...even before getting outside I could hear the lound engine.)

So, we should move the activity of powering this forklift to Tuesdays during Observation Runs.

Using the updated create_guardian_autoburt.py script in (userapps)/cds/h1/scripts/, I created an updated list of channels with the appropriate read only (RO) tag so that Patrick can put them in ConLog.

Dave had also asked me to check the the .ini files for Guardian are also up to date. The guardctrl interface will automatically update these files whenever it creates/destroys a new/old node, so it should always be automatically taken care of.

PyCBC analysts, Thomas Dent, Andrew Lundgren

Investigation of some unusual and loud CBC triggers led to identifying a new set of glitches which occur a few times a day, looking like one or two cycles of extremely high-frequency scattering arches in the strain channel.  One very clear example is this omega scan (26th Jan) - see particularly LSC-REFL_A_LF_OUT_DQ and IMC-IM4_TRANS_YAW spectrograms for the scattering structure.  (Hence the possible name SPINOSAURUS, for which try Googling.)

The cause is a really strong transient excitation at around 30Hz (aka 'thud') hitting the central station, seen in many accelerometer, seismometer, HEPI, ISI and SUS channels.  We made some sound files from a selection of these channels :

• PEM-CS_SEIS_LVEA_VERTEX_Z (sped up by factor 4)
• PEM-CS_ACC_OPLEV_ITMY_X (sped up by factor 4)
• PEM-CS_ACC_BEAMTUBE_MCTUBE_Y (sped up by factor 2)

PEM microphones, interestingly, don't pick up the disturbance in most cases - so probably it is coming through the ground.

Note that the OPLEV accelerometer shows ringing at ~60-something Hz. 

Working hypothesis is that the thud is exciting some resonance/relative motion of the input optics which is causing light to be reflected off places where it shouldn't be ..

The frequency of the arches (~34 per second) would indicate that whatever is causing scattering has a motion frequency of about 17Hz (see eg https://ldvw.ligo.caltech.edu/ldvw/view?act=getImg&imgId=154054 as well as the omega scan above).

Maybe someone at the site could recognize what this is from listening to the .wav files?

Krishna

I took a quick look at the data from the PEM STS at EndY, which is mounted on the BRSY platform. The channels are mentioned in 33533.

First plot shows the GND STS (used by SEI) and the PEM STS converted to angle units (by multiplying by w^2/g) in comparison to the BRSY - rX. The wind-speed during this time was less than 2-3 m/s. The GND STS sees less signal than the BRS below ~50 mHz, but the PEM STS sees a lot more. The second plot shows the coherence between some channels and the third plot shows the X-direction signal. The Z channel is not recorded so I can't access it through ligodv-web.

The source of extra noise in the PEM STS could be  - a) Insufficient mass centering or b) Extra temperature noise either on the STS case or the table it sits on; more insulation to the table and the STS case might help...