Have remained locked and in observing. No issues.

TITLE: 07/10 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 114Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    Wind: 4mph Gusts, 3mph 5min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.09 μm/s 
QUICK SUMMARY: No issues.

TITLE: 07/10 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: Observing since the end of a short commissioning period. Range seems a touch lower than usual, but I don't notice anything glaring at me as to why. The 48Hz peak is a bit higher than it has been lately though...
LOG:

• 2326 Observing

Updated the INIT_ALIGN.adl to better suit the new automated style. Jim's cartoon is displayed in the center of the sliders when we are aligning. Feel free to add things I may have missed.

I also updated the Init_align_lazy.py script, but struggling to get the ndscopes to move where I want them if they move at all. WIP.

Matthew B.

As part of the calibration group's search for the source of the unexplained feature at low frequency in the sensing function inferred from PCAL and DARM open loop measurements, we decided to examine the possibility of PCAL mis-centering. A mis-centering of the PCAL beam on the test mass can cause a torque leading to rotation. This rotation can then couple to DARM via mis-centering of the main interferometer beam causing an extra signal when measuring the sensing function.

I used Brett Shapiro's QuadModel Matlab model to generate length-to-length, pitch-to-pitch, and yaw-to-yaw transfer functions for ETMY. These were used to estimate the uncertainty in a measurement of DARM over the PCAL displacement following the process detailed in P1500248 and P1500249 using the modeled transfer functions rather than 1/f^2 approximations. This percent error takes the form of the dot product of the PCAL and interferometer beams multiplied by the ratio of the length-to-length transfer function to the angle-to-angle transfer function.

Attached is the spectrum of this error using either the pitch-to-pitch or yaw-to-yaw transfer functions for the angle-angle coupling. Here, I used a cavity power of 180kW, a PCAL offset of +10mm, and an interferometer beam offset of -15.7mm for pitch and +13.2mm for yaw. It should be noted that the PCAL offset was just an estimate based on prior observations. The actual value could vary leading to slightly larger or smaller error values. This mis-centering theory seems insufficient as the model does not yield any notable spikes above ~3 Hz, settling to an error of around 1% above this point.

The model I used can be found in /ligo/svncommon/SusSVN/trunk/QUAD/Common/MatlabTools/QuadModel_Production/ascPlantRP_copy.m

When we came back from maintenance, I took an hour and a half to measure squeezing with different squeezing angles and SRCL offsets.  

I will post some plots of the results, but at first glance it seems that changing the SRCL offset doesn't improve our squeezing much. 

Commissioning is done, on to Observing

TITLE: 07/09 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
    Wind: 9mph Gusts, 6mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.10 μm/s
QUICK SUMMARY: Currently commissioning is ongoing for a little bit longer. At NLN right now.

The EY phone was down this week.  It has been repaired and extention 239 works at the entrance door, Change room. and VEA. 

We had a failure at the VG224 analog gateway.   Moved the number to a working channel and re punched all of the wiring at both the corner station and end station.  Phones were tested and are working when plugged in.

When I came into the control room after maintence, Jeff B was hand aligning ETMY.  This is one of the most common things that operators are reporting that they need to do manually while relocking.  

One of the things we have considered to make this easier is to make the baffle dither alignment a part of the routine relocking or initial alignment sequence. 

Jeff B and I tried using the script (userapps/asc/h1/scripts/ditherAlign.py) to align ETMY only.  I had to decrease the power OK threshold to get it to recognize the beam.  This didn't result in an alignment that was good enough for the Y arm to grab, so it seems like this won't be a solution for relocking without doing initial alignment.  

We then went through the whole dither alignment process, misaligning both test masses and running TMS alignment, aligning the ITM and running it's baffle alignment, then repeating ETMY.  All these steps worked fine but they were slow, the dither servo takes about 2 minutes on each PD, the whole process probably will usually take a half hour unless it is sped up.  

At the end we weren't quite well enough aligned for the Y arm to lock and run WFS with our current bad mode matching.  I moved ETMY +2.5 urad in yaw to get good flashes, and then we locked fine.  

GPS error at EX cleared

Daniel:

Power cycling the CNS-II clock at EX cleared its error.

Operator outbuilding-camera-viewer workstation replaced

Dave:

The imac at the operator station (operator2) was broken. I replaced it with a temporary nuc (nuc18) until its permanant zotac is available.

EDC and DAQ Restart

Dave:

I restarted h1edc and the DAQ to acquire Daniel's new Beckhoff channels. This is a delayed restart, it should have happened last Tuesday. 430 INFO channels were added covering all PLCs.

I reset both PSL power watchdogs at 16:16 UTC (9:16 PDT).  This completes FAMIS 10718.

TITLE: 07/09 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Preventive Maintenance
INCOMING OPERATOR: Jeff
SHIFT SUMMARY: Remained locked and in observing. No issues.
LOG:

11:59 UTC SEI_CONF to EARTH_QUAKE for earthquake in Japan
12:14 UTC SEI_CONF to WINDY
12:47 UTC SEI_CONF to EARTH_QUAKE for earthquake in Philippines
13:08 UTC LLO going down for maintenance
14:00 UTC SEI_CONF to WINDY
14:45 UTC Dropped out of observing to run PEM injection script. Observatory mode set to calibration.
14:53 UTC PEM injection script done. Observatory mode set to preventative maintenance.
14:54 UTC SEI_CONF set to SC_OFF_NOBRSXY

Have remained locked and in observing. No issues to report.

Daniel, Dave:

at 19:54 UTC (12:54 PDT) the CNS-II GPS receiver at EX went into an alarm state. Attached image shows EX status on lower left, with EY on lower right for comparison.

Daniel says that the 1PPS signal did momentarily glitch at the time the error was raised, but since then the signal is correct (see attachment). He does not know why the system is reporting 'waiting for lock', it detects and tracks the same number of satellites as EY. If the problem perists overnight, he suggests we power cycle this unit during Tue maintenance.

This afternoon we spent about 3 hours struggling to lock ALS.

At 20:45 UTC we lost lock while transitioning to Earthquake mode (though the ground motion wasn't really that high)

While reacquiring we kept losing lock while trying to lock ALS. We saw a few different problems:

• We were frequenctly losing the IMC. Sheila went to the PSL racks and measured the IMC UGF while it was locked at 2W. It was ~39 kHz, comparable to the last measurement of 40kHz.
• For a while we could not get through ALS_COMM's Handoff_Part_2, where we transition the IMC control from IMC_MCL to LSC_MCL and ALS_COMM. As we increased the analog gain of the LSC refl servo we saw glitches in the Y arm and sometimes in both arms.
  • We temporarily reduced the fianl analog gain from 17 dB to 10 dB.
  • First attachment shows some glitches seen in the transmission of both arms during/after the slider adjustment, followed by the y-arm losing lock, followed by the x arm losing lock
  • Second attachment shows another time when the glitches were more obvious in the y arm, but both arms lost lock at the same time
  • We tried locking COMM before DIFF (normally we lock DIFF first following the saga where ALS-DIFF PLL caused glitches in COMM documented here). And at this point we survived, but not because we changed the locking order - we lost lock again afterwards and reacquired just fine with the normal old guardian settings

In conclusion: for some reason we don't know, we couldn't lock ALS for a couple of hours this afternoon. Then for some reason we don't know, we could lock it again.