Additional CBC injections are scheduled:

1164747030 H1L1 INJECT_CBC_ACTIVE 1 1.0 Inspiral/{ifo}/bbhspin_hwinj_snr24_1163501502_{ifo}_filtered.txt
1164751230 H1L1 INJECT_CBC_ACTIVE 1 1.0 Inspiral/{ifo}/bbh_hwinj_snr24_1163501502_{ifo}_filtered.txt
1164755430 H1L1 INJECT_CBC_ACTIVE 1 0.5 Inspiral/{ifo}/imri_hwinj_snr24_1163501530_{ifo}_filtered.txt
1164759630 H1L1 INJECT_CBC_ACTIVE 1 0.5 Inspiral/{ifo}/imri_hwinj_snr24_1163501538_{ifo}_filtered.txt

Continuing the schedule for this roaming line with a move from 2501.3 to 3001.3 Hz.

Frequency    Planned Amplitude        Planned Duration      Actual Amplitude    Start Time                 Stop Time                    Achieved Duration
(Hz)         (ct)                     (hh:mm)                   (ct)               (UTC)                    (UTC)                         (hh:mm)
---------------------------------------------------------------------------------------------------------------------------------------------------------
1001.3       35k                      02:00                   39322.0           Nov 28 2016 17:20:44 UTC  Nov 30 2016 17:16:00 UTC         days    @ 30 W  
1501.3       35k                      02:00                   39322.0           Nov 30 2016 17:27:00 UTC  Nov 30 2016 19:36:00 UTC         02:09   @ 30 W         
2001.3       35k                      02:00                   39322.0           Nov 30 2016 19:36:00 UTC  Nov 30 2016 22:07:00 UTC         02:31   @ 30 W
2501.3       35k                      05:00                   39322.0           Nov 30 2016 22:08:00 UTC  Dec 02 2016 20:16:00 UTC         days    @ 30 W
3001.3       35k                      05:00                   39322.0           Dec 02 2016 20:17:00 UTC
3501.3       35k                      05:00                   39322.0           
4001.3       40k                      10:00                   39322.0           
4301.3       40k                      10:00                   39322.0                
4501.3       40k                      10:00                   39322.0           
4801.3       40k                      10:00                   39222.0           
5001.3       40k                      10:00                   39222.0           

Frequency    Planned Amplitude        Planned Duration      Actual Amplitude    Start Time                 Stop Time                    Achieved Duration
(Hz)         (ct)                     (hh:mm)                   (ct)               (UTC)                    (UTC)                         (hh:mm)
---------------------------------------------------------------------------------------------------------------------------------------------------------
1001.3       35k                      02:00                   39322.0           Nov 11 2016 21:37:50 UTC    Nov 12 2016 03:28:21 UTC      ~several hours @ 25 W
1501.3       35k                      02:00                   39322.0           Oct 24 2016 15:26:57 UTC    Oct 31 2016 15:44:29 UTC      ~week @ 25 W
2001.3       35k                      02:00                   39322.0           Oct 17 2016 21:22:03 UTC    Oct 24 2016 15:26:57 UTC      several days (at both 50W and 25 W)
2501.3       35k                      05:00                   39322.0           Oct 12 2016 03:20:41 UTC    Oct 17 2016 21:22:03 UTC      days     @ 50 W
3001.3       35k                      05:00                   39322.0           Oct 06 2016 18:39:26 UTC    Oct 12 2016 03:20:41 UTC      days     @ 50 W
3501.3       35k                      05:00                   39322.0           Jul 06 2016 18:56:13 UTC    Oct 06 2016 18:39:26 UTC      months   @ 50 W
4001.3       40k                      10:00                   39322.0           Nov 12 2016 03:28:21 UTC    Nov 16 2016 22:17:29 UTC      days     @ 30 W (see LHO aLOG 31546 for caveats)
4301.3       40k                      10:00                   39322.0           Nov 16 2016 22:17:29 UTC    Nov 18 2016 17:08:49 UTC      days     @ 30 W          
4501.3       40k                      10:00                   39322.0           Nov 18 2016 17:08:49 UTC    Nov 20 2016 16:54:32 UTC      days     @ 30 W (see LHO aLOG 31610 for caveats)   
4801.3       40k                      10:00                   39222.0           Nov 20 2016 16:54:32 UTC    Nov 22 2016 23:56:06 UTC      days     @ 30 W
5001.3       40k                      10:00                   39222.0           Nov 22 2016 23:56:06 UTC    Nov 28 2016 17:20:44 UTC      days     @ 30 W (line was OFF and ON for Hardware INJ)

   Ops has been seeing high dust count alarms in the PSL. Trended the PSL and LVEA dust monitors for 15 and 90 days. The trends show constant major alarm dust levels in the PSL enclosure (Monitor PSL101) in the 0.3u particles and several 0.5u alarm level events. This trend holds for the PSL Anti-Room (PSL102) as well, although at a lower level of alarm raising events. 
   The PSL Enclosure and the Anti-Room have not been cleaned for quite some time. Will arrange for a cleaning of the PSL during the next maintenance window. If this does not lower the PSL dust counts, will need to start looking into the air filtration system feeding the PSL enclosure.         

This was a quick EQ during the OWL shift at 6:16amPST (14:16utc).  H1 rode through it.

USGS link

• Magnitude of EQ (according to Terramon):  4.9
• Location of EQ (according to Terramon):  11km ENE of Petatlan, Mexico
• Starting time of Event:  14:16 UTC (saw small peak over a few minutes on 0.03-0.1 BLRMS)
• Lock Status:  H1 Remained in OBSERVING
• Terramon posted 1.0 um/s.  LHO BLRMS saw 0.25 um/s

TITLE: 12/02 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 73.9893Mpc
OUTGOING OPERATOR: Nutsinee
CURRENT ENVIRONMENT:
    Wind: 2mph Gusts, 1mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.41 μm/s
QUICK SUMMARY:

• Somewhat quiet.  The useism has been slowly increasing over the last 10hrs.
• H1's range is hovering around 75Mpc & currently going on a 16.5+hr lock.  
• A2L was last run around 16hrs ago (~0:13utc).
• Quick Look at DARM Spectra:  Looks good.  Only places it's noisy by glancing at it (i.e. where I see reference) are:  
  • 10-70Hz (perhaps warranting an A2L?  Or just happen to see a glitch?  Or related to increased usesim.
  • A couple bumps between 300-350Hz

As reported in logs 32076 and 32079, HAM3 ISI Corner2 CPSs started glitching around 8am yesterday.  Looking this morning, given that they had glitched several times in just a few hours yesterday once they started and now have not reoccurred since power cycling the satellite rack and seating the probe gauge boards a few times, I'd say the issue has been suppressed for now.

Given that saturations are automatically removed after 1 hour, just looking at the HAM3 watchdog periodically is not sufficient to know if saturations have occurred.  If one wants to know if the platform has seen sensor saturations, trend:

H1:ISI-HAM3_WD_CPS_SAT_COUNT and

H1:ISI-HAM3_WD_CPS_SAT_SINCE_RESTART

The former channel will be reset upon WD trip, the latter channel will accumulate the saturation.

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

STATE of H1: Observing at 75.0267Mpc

INCOMING OPERATOR: Corey

SHIFT SUMMARY: Quiet shift. Been locked all night. TCS hasn't been a problem. BRS thing also didn't happen again during the shift.

TITLE: 12/02 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 73.5385Mpc
INCOMING OPERATOR: Nutsinee
SHIFT SUMMARY: Mostly a quiet shift, but there were a couple SDF issues
LOG:
Corey had just relocked after an earthquake when I arrived. Shortly after going to OBSERVE the TCS guardians knocked us out, as Kiwamu logged. Then quiet until just a couple minutes ago. SDF_DIAG kick us out of OBSERVE, looking at the log I find:

2016-12-02T07:51:08.18971 DIAG_SDF [RUN_TESTS.run] USERMSG 0: DIFFS: ngn: 1
2016-12-02T07:51:10.70676 DIAG_SDF [RUN_TESTS.run] USERMSG 0: DIFFS: ngn: 3
2016-12-02T07:51:17.18839 DIAG_SDF [RUN_TESTS.run] USERMSG 0: DIFFS: ngn: 1

I can't find an (the? I didn't know we had one) NGN guardian, but I know where the CS_BRS guardian lives. When I looked at that guardian, it had just started a recenter cycle at the same time:

2016-12-02T07:51:07.99681 CS_BRS JUMP target: TURN_OFF_DAMPING
2016-12-02T07:51:07.99694 CS_BRS [RUN.exit]
2016-12-02T07:51:08.05901 CS_BRS JUMP: RUN->TURN_OFF_DAMPING
2016-12-02T07:51:08.05920 CS_BRS calculating path: TURN_OFF_DAMPING->RUN
2016-12-02T07:51:08.05959 CS_BRS new target: TURN_OFF_PZT_CTRL

...

Did the CS_BRS guardian throw an SDF difference in NGN that dropped us out of OBSERVE?
 

Sheila and Jenne informed me that the TSC ITMY CO2 guardian suddenly had changed its state this evening, kicking us out of the observing mode

I trended some relevant data and checked the guardian logs. It seems that since the upgrade of the guardian machine this morning (32072), the TCS CO2 guardians for both X and Y arms unlocked multiple times for some reason. The first attachment is the trend of some relevant channels for this past 12 hours. As shown in the upper panels, the guardians changed their states multiple times in the past hours due to the lasers unlocked. Reading the guardian logs (which are attached) and codes, these events were indentified to be due to the PZT output signals exceeding some thresholds that are set in the guardian codes. This had not happened in the past four or five days until this morning. The number of incidents seems to decrease as a function of time. I am hoping that the CO2 lasers will eventually settle to some kind of stable point in which the guardians don't need to change the state any more.

For operators,

If this happens again (which should be obvious as it flips the intent bit back to commissioning), please follow the following procedure.

• Determine whether if the TCS ITMX(Y) CO2 guardian changed the state.
  • The easiest would be to look at the log of the IFO guardian (accessible at the very top of GUARD_OVERVIWE.adl)
  • If it's not TCS. The below doesn't apply.
• Record the time of the incident so that the time stamp can be noted in the operator's summary log.
• Wait for the TCS guardian to come back to the nominal state.
• Once the TCS guardian is back to nominal, hit the intent bit and go back to observing.

TJ investigated why the LOCKLOSS_SHUTTER_CHECK guardian was sometimes mistakenly identifying locklosses when there had not been any lockloss while ISC_LOCK was in the DRMI_ON_POP state.

As a reminder, the only purpose of LOCKLOSS_SHUTTER_CHECK is to check that the shutter triggers after locklosses in which we had more than 25kW circulating power in the arms.  The lockloss checking for this guardian is independent of any other guardian.  

The problem TJ found was a consequence of the work described in 31980 .  Since that work when we switch the whitening gain on the transmon QPDs, there is a large spike in the arm transmission channels which the LOCKLOSS_SHUTTER_CHECK guardian recognizes as a lockloss (TJ will attach a plot).  

We edited the ISC_LOCK guardian to hold the output of the TR_A,B_NSUM filter before making the switch, and turn the hold off after the switch is done.  We loaded this when we were knocked out of observe by TCS.  This is a simple change but if operators have any trouble with DRMI_ON_POP tonight you can call TJ or I.  

TITLE: 12/01 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Jim
SHIFT SUMMARY:

Much_Of_Morning Main Issues:

1. ETMy 4735Hz Violin Mode Harmonic damping!  Upgraded Filter Banks for ETMy & damped out the mode(!)
2. HAM3 ISI Saturation & Trips.  Hugh noted, addressed, & appear to be better so far.

LOG:

• 16:25(?) HAM3 ISI tripped while in PRMI; this is unusual.
• 16:35-16:55 Down for Guardian Memory Upgrade (WP6366)
• 19:03 Mid-station visit (Karen)
• 21:57 OBSERVING!
  • NOTE:  Have been getting DIAG_MAIN message about the FAST Shutter
  • 22:08 Lockloss, nothing obvious from Seismic or StripTools.  It was NOT HAM3ISI.
  • Ran Lockloss select which brought up mainly ASC Channels, but I did not see anything obvious.
• 22:39 OBSERVING
  • 23:22 Incoming Peruvian EQ, Transitioned EX & EY ISIs to "250_SC_EQ" state
  • 23:25 Lockloss
• 0:15 OBSERVING
  • Jim ran another A2L with his new medm/script interface before going to Observe.

Locking Notes:

After hand-off this morning, held at VIOLIN_MODE_DAMPING.  Kiwamu came in to take a look at H1 & wanted to note a few items he checked.

• ETMy:  SUS L3 outputs saturated when trying LOWNOISE_ESD_ETMY:  The Suspect was:  higher order violin mode harmonic at ~4753Hz.
• For next lockloss attempt, Enabled FM3 for LSC DARM2 & Made it to NLN, then made first damping attempt of 4753 Mode.
• A2L run, but later received "OMC DCPD Saturdations"
  • Jenne:  OMC_Lock:  REMOVE_WHITENING state & then back to READY_TO_HANDOFF
• Lockloss when trying to take out phase of MODE9....I should have ramped gain down, changed phase, & ramped gain back up. 
• HAM3 trip while going up to REDUCE CARM OFFSET
• Spent a few hours damping 4753Hz in DC READOUT (see other's alogs)

USGS Link

• Magnitude of EQ (according to Terramon):  6.3
• Location of EQ (according to Terramon):  43km NE of Huarichancara, Peru
• Starting time of Event:  22:49UTC (started seeing 0.03-0.1 BLRMS increase
• Lock Status:  H1 Lockloss at 23:25UTC

I have looked at all the A2L data that we have since the last time the alignment was significantly changed, which was Monday afternoon after the PSL PZT work (alog 31951).  This is the first attached plot.

The first data point is a bit different than the rest, although I'm not totally sure why.  Other than that, we're mostly holding our spot positions quite constant.  The 3rd-to-last point, taken in the middle of the overnight lock stretch (alog 32004) shows a bit of a spot difference on ETMX, particularly in yaw, but other than that we're pretty solid.

For the next ~week, I'd like operators to run the test mass a2l script (a2l_min_lho.py) about once per day, so that we can track the spot positions a bit.  After that, we'll move to our observing run standard of running a2l once a week as part of Tuesday maintenence.

The second attached plot is just the last 2 points from the current lock.  First point was taken immediately upon lock, second was take about 30 min into the lock.  The maximum spot movement in the figure appears to be about 0.2mm, but I think that is within the error of the A2L measurement.  I can't find it right now, but once upon a time I ran A2L 5 or 7 times in a row to see how consistent the answer is, and I think I remember the stdev was about 0.3mm. 

The point of the second plot is that at 30W, it doesn't seem to make a big difference if we run a2l immediately or a little later, so we can run it for our once-a-days as soon as we lock, or when we're otherwise out of Observe, and don't have to hold off on going to Observe just for A2L.

Could someone on site check the coherence of DARM around 1080 Hz with the usual jitter witneses? We're not able to do it offsite because the best witness channels are stored with a Nyquist of 1024 Hz. What we need is the coherence from 1000 to 1200 Hz with things like IMC WFS (especially the sum, I think). The DBB would be nice if available, but I think it's usually shuttered.

There's indirect evidence from hVeto that this is jitter, so if there is a good witness channel we'll want to increase the sampling rate in case we get an SN or BNS that has power in this band.

Betsy, Keita, Daniel

As part of the LVEA sweep, prior to the start of O2, this morning, we spent over an hour doing a cleanup of misc cables and test equipment in the LVEA and electronics room.  There were quite a few cables dangling from various racks, here's the full list of what we cleaned up and where:

I also threw the main breaker to the OFF position on both of the free standing unused transformer units in the LVEA - one I completely unplugged because I thought I could still hear it humming.

No monitors computers appear to be on except the 2 VE BECKHOFF ones that must remain on (in their stand alone racks on the floor).

We'll ask the early morning crew to sweep for Phones, Access readers, lights, and WIFI first thing in the morning.

Kyle R., Gerardo M., Richard M. 

(completes WPs #6332 and #6360)

Initial pressure indication shortly after being energized was 3 x 10-3 torr (PT180 is a "wide-range" gauge).  If real, this would be higher than expected for the ~17 hrs. of accumulation -> "burped" the accumulated gas into the connected pump setup while Gerardo monitored its pirani gauge -> it gave no indication of a change and remained steady at 1.9 x 10-3 torr which is as expected.  Neither gauge is calibrated in this pressure region of interest.  Noted PT180 responded as expected to being combined with local turbo -> Isolated temporary local pump setup, valved-in (exposed/combined) PT180 to site vacuum volume, vented locally mounted turbo and removed from PT180 hardware -> Installed 1 1/2" O-ring valve and 2.75" CF to NW40 adapter in place of the turbo and pumped to rough vacuum the space between the two 1 1/2" pump port valves.  

Jenne, Sheila Keita

We had another instance of a jump in POP90, in which both the I and Q phases increased. We think this is a problem with the readback, similar to what is described in 31181.  

We were acquiring lock, and had no ASC running on the SRC.  We looked at witness sensors for all the interferometer optics, and it looks like none of them moved at the time.  We also don't see changes in other RF sensors, like AS36, AS90, or POP18. We looked at both quadratures of POP90 before rotation and it seems to have both a phase shift and a 3.5 dB increase in the sum of I+Q. The RFmon and LO mon on the demod don't have any jumps nearly that large, so if it is a problem in the demod it is probably downstream of the directional coupler for the RFmon. 

This seems not to be the same as the jumps in SRC alingment that started after last tuesday's maintence, (31804 31865 and other alogs), but since the symptom is very similar it would make debugging the other problem easier if this issue could be fixed. Since we use POP90 for a dither lock of the SRM angle durring lock acquisition, this can cause a lockloss if it happens while we are trying to lock.