This is a plot of the jitter measured by the IMC WFS DC PIT/YAW sensors during last nights lock. The 280 Hz periscope peak reaches about 1x10^-4/√Hz in relative pointing noise, or about 3x10^-4 rms. The relative pointing noise out of the HPO is about 2x10^-5/√Hz at 300 Hz. After the attenuation through the PMC this would correspond to a level below 10^-6/√Hz. The jitter peaks show up in DARM, if they are high enough. This is clearly visible in the coherence spectra.

The ISS second loop control signal is an indication of the intensity noise after the mode cleaner with only the first loop on. The flat noise level above 200 Hz is around 3x10^-6/√Hz in RIN, with peaks around 240 Hz, 430 Hz, 580 Hz and 700 Hz. Comparing this to the free-running noise in alog 29778 shows this RIN level at 10^^-5/√Hz. We can also compare this with the DBB measurements, such as in alog 29754: the intensity noise after the HPO shows a 1/f behaviour and no peaks. Looking at the numbers it explains the noise below 300 Hz. It looks like a flat noise at the 10^-5 level including the above peaks gets added to the free-running intensity noise after the PMC. The peaks in the controls signal of the second loop ISS line up with peaks visible in the pointing noise. But, neither the numbers nor the spectral shape matches. These peaks have coherence with DARM.

I have done a cross correlation analysis of the two OMC DCPDs in order to study the spectral shape of the broad band noise that has been limiting the sensitivity in 200-1000 Hz band. Here are some results.

The red curve is cross-correlated noise of the two DCPDs in terms of the DCPD current in mA (with DARM loop effect removed).The data I used is a lock stretch from Sep. 26th which lasted for 6 hours in undisturbed. The frequency resolution or bandwidth is set to 0.1 Hz. The data length is 3 hours starting at 9:00:00 UTC of the day. The DARM suppression is taken out from OMC DCPD SUM. I have used the latest PreER10 DARM model (29931) to obtain a reasonable DARM suppression function. As we all know, there is high noise in 200-1000 Hz whose level is as high as shot noise (or null stream shown in green) in this frequency band.

I also made another plot, which is an overlay of 11 cross correlated spectra each of which is from different time but from the same lock stretch. See below.

This time, the frequency resolution is set to 1 Hz, so that we can get several FFTs out of the same lock stretch. Each spectrum is produced by an 18 minutes integration. As shown in the plot, there was one spectrum which is polluted by some kind of glitch. Otherwise, the shape of noise stayed almost unchanged over 3 hours. Also fig files are available.

@ ≈23:45 UTC

Summary:  Morning was spent recovering from Power Glitch.  Afternoon H1 was handed over for Commissioning.  Here are some notable activities from shift:

• 6-11am Power Glitch Recovery (see specific alogs)
• 8-11am PCal Y Work (Travis & Rick)---->Turned OFF BRS while they were out there & turned back on when they were done.
• ~11 Started Initial Alignment (with some issues)
• 12:30 Started locking (with some issues)
• 1:30 H1 at INCREASE_POWER & staying here so Terra can monitor PIs (mainly because since the ESDs went down during Power Glitch, PIs can be finicky for the next 12hrs as the ESDs return to a nominal state).
• For the afternoon, commissioners took H1 at various "mid-states" (i.e. INCREASE_POWER, DC_READOUT, etc.)

Notes:

• CP4 Alarms today (Chandra)
• PCal-Y crew left an illuminator ON at EY.  They will turn it off on Tuesday (Travis)

Locking Notes:

• ALSy had trouble getting over 0.6.  Possibly Clearing History for ALSy WFS fixed this.
• In FIND_IR while trying to adjust the DIFF OFFSET, TR_Y's zero was not at zero...it was more like 0.25.  Did NOT run DARK_OFFSETS & instead addressed this by hand by going to LSC OVERVIEW / LSC_CUST_TRPD / LSC_CUST_TRPD_INPUT.  And on here we adjusted the offsets for -TR_X_QPD_B_SUM & -TR_Y_QPD_B_SUM.  (after getting H1 to lock, these offsets would be taken care of by Guardian later).

model restarts logged for Thu 29/Sep/2016
2016_09_29 03:35 h1nds0
2016_09_29 14:10 h1nds0
2016_09_29 14:27 h1nds0
2016_09_29 14:32 h1nds0

installed more memory in h1nds0 to make it the same as h1nds1, no further unexpected restarts of h1nds0 for the rest of the day (and none on Friday at time of writing).

BruCo scans (see here for the most recent one) showed a large coherence with IMC alignment signals, in the region between 100 and 1000 Hz. The most significant coherence is with IMC-WFS_B_DC_PIT.

I computed the transfer function between this IMC beam spot position signal and the OMC DCPD SUM signal, for a few different time periods in the past couple of days. The transfer functions are basically non changing over time in the different locks. This suggests that, if the increased coupling is due to a IFO misalignment, this is quite repeatable and constant over time (fig. 2)

Not much of a smoking gun, but some hints.

Overfilled CP4 again:

1. Opened exhaust bypass valve
2. Doubled LLCV (66% open)
3. Took ~17 min. to fill reservoir from 92% to 100%.
4. Took another hour to see LN2 pour out the exhaust. 
5. TC 252B did not respond to temp. change (and I broke the other one yesterday)
6. Set LLCV to nominal at 32% open in manual mode after the overfill
7. Would like to see how long it takes CP to recover to 92% at nominal LLCV (but may not happen this time since it's the weekend)

I used the borescope to look at the TC junction on the exhaust to see if it's measuring the pipe or the fluid flow. I couldn't see much but I suspect it's measuring just the pipe since the time delay on CP3 is long and temps never drop below -12degC on CP3 (response is faster when heating pipe with heat gun). 

I would like to drill and tap TCs directly into the pipe and use the existing signal lines to measure a more direct temp. for CP3 automation.

The orientation of the ISS second loop qpd was rotated 90 degrees and reversed in sign when compared to the orientation of IM4 Trans QPD.

I changed the QPD matrix and tested the change by exercising IM1 in pitch and yaw.

I've updated SDF.

Details attached.

IM alignment slider gains were reversed, and set the urad / slider count to 0.045.

I've corrected the alignment slider gains for all IMs, and used measured values for each optic such that the urad / slider count is 0.05.

I've attached a snapshot of the new gains, and a snapshot of SDF before I acepted the new gains.

With the gain change, the slider values also change, so any burt restore prior to 30 September 2016 at 20:01UTC (13:01PT) will fail to return the IMs to their correct alignment slider values.

RickS, TravisS, SudarshanK

Using the same procedure used at END-X (LHO alog 29873), we optimized the Pcal beam locations at END-Y today. 

In each of these figure, the optimal locations, 111.6 mm from the center of the face of the optic in both positive and negative y direction, are denoted by red cross and the actual pcal beam locations by cyan circle.

Attached figure (1) shows the beam before they were optimized.  The offsets ([xoffset, yoffset]) from the optimal locations for upper and lower beam were: U[1.36, 7.58] and L[3.18, -8.60] in mm and uses standard co-ordinate sign convention.

Attached figure (2) shows the beam after they were steered to their optimal positions using the Pcal transmitter module steering mirrors.  The new offsets from the optimal locations are U [-0.96, -0.67] and L[-0.59, 0.39].

Everything looks to have restarted on its own or taken care of by the likes of Patrick (EndX) but I haven't been able to pin him down on that.  Actually, just managed to break into those guys--the computers did not stop so there was no restart.  Manual intervention to restart at EndX would be required but this glitch did not drop the BRSs out.

The Ion Pump at EndY has been reprogrammed to restart on its own and that was verified to still be running by EE this morning as well as the drift trends.  The attached shows these trends and the medms of the BRSs.  Again, things look to be running fine.

Krishna

BRS-X, BRS-Y and c-BRS seem to be functioning normally at the moment. I don't know if they were restarted manually or on their own, but ligo-dv web shows normal looking drift channels on BRS-X and BRS-Y and CTRL channel on c-BRS (trends attached).

Jonathan, Jim

The front end computers on the DAQ test stand have been restarted following this morning's power glitch.

J. Kissel, K. Kawabe, T. Shaffer, C. Gray

After a message popped up on the ISC_LOCK guardian to review the last check of the AS port fast shutter, and we realize the last check should have been during the power glitch recovery, we manually checked the functionality of the fast shutter. The fast shutter appears functional, stopping light into the OMC breadboard and the GS13s show an impulse.

The manual check: 
Setup:
- The IMC is locked, and the IFO aligned enough to see flashes on the AS port camera
- Watching the OMC Breadboard QPDs MEDM screen to see a spot moving around (channels H1:ASC-OMC_A_[YAW,PIT]_OUTMON)
- Watching the HAM6 GS13s on a dataviewer session to watch for fast physical motion of the shutter (channels H1:ISI-HAM6_BLND_[X,Y,Z]_GS13_CUR_IN1_DQ)

The test:
- Use the fast shutter detail MEDM screen (sitemap > LSC > shutters > bottom middle "Detail" under the "HAM6 Fast Shutter" name)
- Hit "open" then "close" several times, watch for light to disappear from the OMC Breadboad QPDs, and watch for large impulse on GS13s.

We need to do a similar test after every power outage, no matter how small.
TJ has agreed to create a guardian "PRECHECK" state such that we can do manual check of the fast shutter functionality. (To date we've only done the automatic checks every 48 hours).
Note: There already exists a guardian check in the FAST_SHUTTER node, however, the check is programmed to fail without the IFO MUCH further into the lock acquisition sequence (i.e. DRMI locked), and we'd prefer to check the functionality far before this.

This morning around 8:30am, Nutsinee and I went out and restarted the TCS chillers and the TCS lasers.  We also took the opportunity to swap the greenish filters.  Recall, we had flushed both chillers last week, but when we installed a new set of filters we noticed that they were tinging green immediately even though we had just flushed the system.  These filters sat for ~a week and we swapped them today in hopes that whatever immediately turned them green last week was just still pushing throgh the system.  We also had to add another 750mL (to top off the half way full indicator to full) and again inspected for leaking water (none found).

We'll need to look up how to clean these recyclable filters.