TITLE: 03/21 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 6mph Gusts, 4mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.14 μm/s 
QUICK SUMMARY: Locked 11h30. Environment is good. The PSL cameras are blank but it seems like Dave knows about this from alog 55704. 

IFO was knocked out of Observe, looks like 11:30-11:37 utc, based on IFO guardian log, because hardware injections failed? Not sure what happened, I didn't do anything to fix it. IFO resolved itself, but I still got the notfication. I can't find any evidence that anything else happened.

TITLE: 03/20 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 118Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY: One lock loss from observing, likely from an earthquake that was too close to respond to in time. Got a call from Dave about the network switch (see his alog).
LOG:

00:46 UTC Started Jenne's move SR3 back script.
01:38 UTC Lock loss, likely from earthquake,
01:39 UTC Nearby earthquake from United_States
01:43 UTC Set SR3 Pitch to 438.4
02:18 UTC Lock loss from DARM_TO_DC_READOUT
02:39 UTC Lock loss from POWER_10_W
IR not found, adjusted manually.
03:29 UTC Observing. No SDF differences.

The Cisco network switch in the CER went down for 12 minutes this evening from 09:34 to 09:46 PDT. While this was down, the network connection to the PSL diode room IOC was unavailable and the EDC showed 357 disconnected channels. The CDS H/W monitor also showed network disconnection to h1pslctrl0.

After the switch rebooted, several cameras did not come back and need to be rebooted. These do not appear to be critical and hopefully we can delay rebooting them until tomorrow.

                   H1 MC Refl (h1cam02) has a frozen image
                        H1 PR2 (h1cam08) has a frozen image
                        H1 MC1 (h1cam11) has a frozen image
                        H1 PRM (h1cam13) has a frozen image
                    ISCT6 SHG TRANS (18) has a frozen image
                       H1 ITMX (h1cam21) has a frozen image
                            BS (h1cam26) has a frozen image
                     H1_IO_GIGE1_h1cam28 has a frozen image
 

TITLE: 03/20 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
    SEI_CONF state: WINDY
    Wind: 10mph Gusts, 7mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s 
QUICK SUMMARY:

No known issues.

Starting at 14:15 Pacific I am moving SR3 in pitch in steps of 0.01, with several seconds of pause between each step.  This is slow enough that it is okay to do in Observing.  I'll update this alog or add a comment when I'm done.

To do this in observe, I unmonitored the SR3 opticalign sliders.

Earlier today during commissioning time I was trying to move faster, and killed the lock with a step of 1.0.  At that time, I also had the DARM offset reduced to about 5pm, which makes it easier to see the change in junk light getting to the DCPDs. 

WP8572 h1tw0 raw minute data offload

TJ, Dave:

With H1 out-of-lock, I have started the h1tw0 offloading process. I have switched the active /trend/minute_raw to an empty directory set at 12:35 PDT, its data epoch is 12:39PDT. The data directory with the last 8 months of data was named /trend/minute_raw_1268768058.

h1tw0's minute trend data is served by h1nds0. The only NDS client of h1nds0 is the guardian system. Looking at the guardian user code and speaking with TJ, we think the only guardian NDS requests are for full data (taking averages over time periods from 1 to 10 seconds). Therefore I am not going to restart h1nds0 to serve recent minute-trend data from the temporary location /trend/minute_raw_1268768058 since restarting h1nds0 will have a greater impact on guardian than the loss of the last 8 months of raw minute trends.

I'm preparing h1fw0 to start the copy of the minute-raw files from h1tw0 to their final archival location on h1ldasgw0 compressed ZFS raid. The copy is expected to take the whole weekend to complete.

Since we lost lock this morning, I took this opportunity to change the max gain to nominal values for ITMY mode 3, 12 and 15. Previously these modes had their max gain set to zero (although we had non zero nominal values for them). Often Guardian would set the gain to max for these modes and hence stop damping them - which is not ideal. In the changed scenario, Guardian will damp these modes regardless of whether max or nominal gain is applied. I have committed the lscparams.py on the svn and loaded the coefficients.

I will track their development over the next few lock stretches.

   Currently relocking the IFO. No other issues at this time.   

TITLE: 03/20 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 116Mpc
INCOMING OPERATOR: Jim
SHIFT SUMMARY:

• Nothing of consequence to report.
• Shift was a quiet one
  • there were a few rumblings that wern't significant enough to cause any changes in SEI_CONF
• Initiating transition to remote Owl operations

LOG:

This afternoon we took almost an hour of commisioning time to do noise budget injections (from home).  I did MICH, SRCL, PRCL, IMC PZT P+Y, ISS, CHARD P+Y, DHARD P+Y, and MICH ASC P+Y. 

We then took 15 minutes of reference time with no squeezing starting at 1268683369 (1:03-1:19 local time)

The most important injection that I didn't do was frequency noise, which requires a cable to be plugged in for the excitation.

Cheryl (over phone), Rahul

This morning we made changes to the damping filter for ITMX mode 2,3,4. We narrowed down the band pass filter and moved them away from Interfering from each other. Next we loaded the coefficients and made the gains to be zero on lscparam (followed by svn commit). Jeff. B then attempted to lock  the IFO and during this time I found a good gain settings for ITMX mode 3 (gain of -20) and was tinkering with IMTX mode 2 (with a very small gain of -0.1). We lost lock after some time hence I was not able to find a good value for mode 2. 

During the second attempt of locking, the modes were rung up and we lost lock very quickly. Next I reverted all the damping filter settings (including lscparams) back to how it was this morning at 8am. In the third attempt I requested Jeff. B to hold on at PREP_ASC_FOR_FULL_IFO, while I was manually damping the rung-up modes. We stayed at this state for an hour or so, and the rung up modes were damping well. Hence I requested Ed (who took over form Jeff. B) to start moving up the ISC lock state - here we lost the lock once again.

In the fourth attempt, the violins looked fine and we are currently locked and Observing (at 0:14 UTC).

No obvious cause.