TITLE: 11/16 [Day Shift]: 16:00-24:00UTC 

STATE Of H1: Observing at ~80 Mpc

SUPPORT: Usual CR crowd

SHIFT SUMMARY: Locked most of the shift. Winds quietish <20 mph, useism is medium low

ACTIVITY LOG: 

17:00 JohnW Bubba driving around site looking at tumbleweed situation

17:00 Keita & Me running excitations on ETMX & ETMY ISIs, earthquake arrives at the same time, lockloss

I rotated the HAM2 STS2 to see if elevated power in the Y channel was from tilting or a bad channel.  The first attachment shows the 5 site SEI STS2s when the wind was fairly quiet.  The top row of panels is from 19 October before the HAM2 STS2 rotation; the bottom row is from 12 Nov after the sensor was rotated.  The HAM2 Y channel still shows elevated signal even though it is now rotated to align with the X axis.  So this isn't related to orientation wrt SW facing wall.  Additionally, these are quiet wind times (<10mph) so hard to explain this away with wind tilt noise.

The second attachment is similarly arranged with the same 19 October panels in the top row but now the lower panels are from 13 November when the wind was really honking (20 to 60mph.)  Notice that all the X & Y signals are much larger at lower frequencies (<~0.3hz,) except the HAM2 Y channel which in the lower panels is actually pointing in X.  This channel has a larger magnitude until you get to about 10mHZ but it does not respond anywhere near to amount that the other sensors do.  This indicates to me that the HAM2 Y channel is definitely not healthy.

O1 day 59

model restarts logged for Sun 15/Nov/2015 No restarts reported

In preparation for my rezeroing of the active oplevs tomorrow I've taken 7 day minute trends of these oplevs.

LHO's second-Saturday public tour occurred on the afternoon of 11/14.  Arrival time at LSB = 1:00 - 1:30 PM.  Departure time = 3:45 - 4:15 PM.  Group size = ~30 adults.  Vehicles at the LSB = ~15 passenger cars.  The group was on the overpass near 2:50 PM and in the control room from about 3:10 to 3:40.  Landscapers were working on tumbleweeds near the corner station near 2:45 PM. 

TITLE: "11/16 [OWL Shift]: 08:00-16:00UTC (00:00-08:00 PDT), all times posted in UTC"

STATE Of H1: Observing at ~80 Mpc

SUPPORT: Jenne

SHIFT SUMMARY: Spent first couple hours with initial alignment and lock acquisition. Issue with ALSY* both during initial alignment and locking ALS. Later OMC flashed at the wrong mode. An attempt to adjust OMC alignment was made but it seemed to fix itself somehow. Low wind and nominal EQ seismic band through out the shift. Useism ~0.5e-1 um/s.

INCOMING OPERATOR: Jim

ACTIVITY LOG: See alog23433 and alog23429 + comments therein.

* when I said I had problem with ETMY I actually meant ALSY. There's no problem with ETMY. 

Robert, Jess, Nutsinee

Back in September Robert and control room folks did an injection of "5 people jumping in sync" (alog21180). A followup showed that the injection indeed coupled into DARM (alog21191) from ~10-400Hz (an omega scan of a jump can be found here). So I continue to followup the coupling mechanism hoping it would shed some light on how ground motion coupled into DARM (we suffer a slight range drop daily during high traffic time). Using Robert's Acoustic Coupling Functions (alog22797 figure 9) I was able to pin down the coupling mechanism above 100Hz. Figure1 shows the calibrated DARM and the PSL periscope accelerometer spectrum at 100-400 Hz.

• At 210Hz periscope amplitude measured 4e-4 m/s^2/sqrt(Hz), multiply by the coefficient of 3e-16 the predicted DARM becomes 12e-20 m/sqrt(Hz). The actual DARM amplitude measured 10e-20 m/sqrt(Hz). Off by a factor of 1.2. 
• At 120Hz  periscope amplitude measured 2e-4 m/s^2/sqrt(Hz), multiply by the coefficient of 3e-16 the predicted DARM becomes 6e-20 m/sqrt(Hz). The actual DARM amplitude measured 7e-20 m/sqrt(Hz). Off by a factor of 1.2. 
• At 360Hz periscope amplitude measured 1.2e-4 m/s^2/sqrt(Hz), multiply by the coefficient of 3e-15 the predicted DARM becomes 3.6e-19 m/sqrt(Hz). The actual DARM amplitude measured 1.7e-19 m/sqrt(Hz). Off by a factor of 2.

The predicted DARM value is expected to agree with the actual measurement within a factor of 2. Thus it is reasonable to blame PSL periscope for ground-to-DARM coupling at above 100Hz. However, at f < 100Hz the coupling mechanism is still a mystery (figure4).  Robert wasn't able to make periscope motion couple into DARM at low frequency (refer to figure 7 of alog22797). However, we were able to rule out HAM2 and HAM6 as coupling sites based on the upper limit (alog22797 figure 3 and 6). Figure 2 and 3 attached show that both HAM2 and HAM6 GS13 rise about a magnitude above the noise floor, while the upper limit from Robert's alog is about 1.5-2 order of magnitude. Meaning, shaking HAM2 and HAM6 GS13 at 2 order of magnitudes above its noise floor at low frequency didn't couple into DARM.

Whatever the coupling mechanism is at low frequency, we believe the same mechanism is responsible for HVAC coupling into DARM. Figure5 shows DARM spectrum during the HVAC injection time (alog22532). HVAC noise shows up in DARM at 20-100Hz.

I accepted SDF change of OMC alignment. I didn't want to risk losing lock by reverting it. Screenshot of the old and new value attached below. This might have caused by me attempting to touch the OMC alignment slide bar earlier.

I trended all the optics that I know are in the green light path back to where they were before we lost lock (~10hours ago). TMSY alignment was off by 5.6 um. Adjusting TMSY alone improved the flashes from 0.4 to 0.6. The rest was the combination of ITMY and ETMY adjustment. Seems like I have some magic fingers =p

One mistake that I used to make is that touching either ETM or ITM without realizing that both mirrors have to be aligned with respect to one another. Other than looking at the camera and dataviewer try imagining how optics actually move could be helpful.

TITLE:  11/16 OWL Shift:  00:00-08:00UTC (16:00-00:00PDT), all times posted in UTC     

STATE of H1:  ALSy not locking

Incoming Operator:  Nutsinee 

Support:  Talked with Jenne a couple of times (as well as Mike)

Quick Summary:

Tonight was a bust.  ALSy was giving Jim trouble at the end of his shift, and it continued that way for all of my shift.  Basically, having trouble aligning ALSy.  Not able to get to a 0:0 mode (and this was with tweaking ETMy, TMSy, & ITMy).  Frustrating shift.

ALSy Notes:

• Checked ALS Laser Power (Diode Head #1 & #2):  Look stable for last few hours/days.
• Temperatures in LVEA & EY:  EY looks pretty flat.  LVEA had some excursions before the lockloss, but nothing out of the norm looking over many days.
• Oplevs (ETMy, ITMy):  Good
• Thought it was worth noting that the spot seems to move a little for ALSy (but maybe it always moves like this.
• Jenne pointed me to archives of the digital cameras (/ligo/data/camera/archive/2015/11/16/[file]).  So attached is a comparison to an ALS camera shot today & Saturday afternoon:  Basically the spot looks to be in the same area (no gross misalignment of the beam spot).  Thought of addressing cameras when we saw a message in the ALS_YARM log stating:  "Camera centering too far off.  Need to turn on slowly."
• Have basically went through several iterations of alignment here.  Have restored ETMy/ITMy/TMSy to state before lockloss, and have tweaked the alignment several times (as alogged earlier).

To Do :

Hoping a new set of eyes (Nutsinee's!) has better luck here.  Jenne and I both think it's an alignment issue.  And since it's ALSy, the only knobs to turn are for ETMy/ITMy/TMSy.  So mabye I just didn't have the magic touch:  I just wanted a 0:0!!!!

I picked Jenne's brain for anything I could pass on to Nutsinee and basically all we have is:

• Work on alignment.  Get 0:0 mode.
• Then see what happens once you get it (hopefully WFS likes it).
• If WFS drive off alignment of a 0:0, try disabling WFS DOF3 PIT (on ALSy Overview), minimizing it's input, and then re-enable.

Rough Night.

Jess, Laura, Paul

We have been following up on the periodic 60Hz EY glitches which have been seen at LHO since at least June (alog 18936). These glitches are witnessed by various magnetometers and couple into DARM.

It seems that the glitches indicate the switch-on of some electronic device. Spectrograms of H1:PEM-EY_MAG_EBAY_SUSRACK_QUAD_SUM_DQ show lines at several frequencies (30, 42, 60, 80, 120 Hz) that start when the glitch occurs, then stop with a rather softer glitch about 27 minutes later. Attached are spectrograms from yesterday and last Thursday. There doesn't appear to be anything correlated in the HVE or H0:FMC channels.

We recently investigated something similar at LLO (alog 22549), which we managed to trace to an unmonitored air-conditioning unit outside the EY station. The behavior at LLO is somewhat different in that the glitch is much louder and the subsequent noise (in both PEM channels and DARM) is quieter, as well as the fact that it stays on longer each time. However, because the turn-on and turn-off are so predictable it should be possible for someone to go down to EY and listen for anything turning on and off at the expected time.

Returned ETMy, ITMy, & TMSy to state they were before last lockloss (by using the M0 & M1 DAMP p/y INMON values & using sliders to return SUS to these values).  

Still have issue of not being able to get ALSy power over 0.5.  The best I could do was actually up to 0.65 with a 0:1 mode (I changed trigger threshold to 0.8), but as soon as I took the threshold down to 0.5, the WFS engaged and drove the alignment off (not surprisingly since what they had was a bad 0:1 mode).

I have had zero luck at getting a 0:0.  Not sure what other knob I can turn to help me get out of this bad alignment hole.

Have continued Jim's work on trying to get ALSy to a point where WFS can take over but have not been able to get to a 0:0 mode, and thus have not had much luck getting powers much over 0.5 (when WFS can kick in, after 10sec).

The problem from my point of view, is that ALSy will lock on a mode 0:1 (and uglier modes) for only a few seconds--why can't it stay in a mode for longer so I can get an idea of which way to move sliders(!).  This isn't long enough for me to tweak and observe the power to improve it.  I wish I could get it to a 0:0, because then I could atleast get it above 0.5.

I started out just moving ETMy, but at this point, I have also been adjusting sliders for TMSy & ITMy to no avail.

I did finally get a 10+sec stretch of 0.5 - 0.6 (which was a 0:1 mode), but when the WFS kicked in, they drove the power down & knocked it out.  SOOO, I really want to get a 0:0 with any power and try to get WFS to help out.  

SDF shows no difs for the ISIs of the Y-arm.  (SDF isn't useful for the SUS's because they are always RED in this state).

This is a classic tale of IM1-3 woes - IM1-3 are very likely to move when the HAM2 ISI trips, so need to be checked every time.

The IMs come from IOO, so they are unlike any other optics we have, and so behave in a very different way, and are suscetable to changing alignment when they experience shaking, like they do when the ISI trips.

The IM OSEM values are consistant, and when the optic alignment shifts, it is consistantly recovered by driving the optic back to previous OSEM vlaues, regardless of slider values.  The OSEM values, when restored, consistantly restore the pointing onto IM4 Trans QPD.

IM4 Trans QPD reads different values for in-lock vs out-of-lock, so it's necessary to trend a signal like OMC DC A PD to correctly compare times.

IM4 does sometimes shift it's alignment after shaking, but because it's moved around by the IFO, choosing a starting value can be difficult.  In the case of IM4, restoring it's alignment to a recent out-of-lock value should be sufficient to lock, but ultimately IM4 needs to be pointing so that we can lock the X arm in red.

I've tracked the alignment changes for the IM1-3 since 9 Nov 2015, and they are listed below.

• 11/12, starting values, all optics change by only around 2urad for the previous 3 days (11/9-11/12)
• 11/13, the ISI tripped, and IM2 Pitch changed by 40urad, and IM3 Pitch changed by 8urad
• 11/14, around 00:30UTC, there's a clear step in signals, but alignment is unchanged, possible 1st attempt at correcting alignment (?)
• 11/14, around 23:45UTC, an alignment correction, however optics do not retun to starting values

These alignment changes are big enough to effect locking, and it's possible that the IFO realignment that was necessary last night was in part a response to IM pointing changes.

I've attached plot showing the IM alignment channels.

Armed with those channels, and the knowledge that the IM OSEM values are trustworthy, and the knowledge that under normal running conditions IM1-3 only drift 1-2urad in a day, checking and restoing IM alignemt after a shaking event (ISI trip, earthquake) should be a fairly quick process.

After the alignment tweaking with Jenne, and getting through PRM, I continued with the Initial Alignment.  The Dark Michelson came up on its own fairly well aligned and I only barely touched it.

After the IA, attempted locking.  First attempt was on an ugly DRMI mode.  Second Attempt locked DRMI within 10-15min.  Proceeded through Guardian States.  First hitch was at ENGAGING ISS 2ND LOOP.  Ended up having to Engage by hand (via Kiwamu's alog); this was scary as it's hard to engage when output is close to zero---had a big glitch when I engaged, but it rode through (yay!).

Finally made it to NOMINAL LOW NOISE with range around 80Mpc (but had a few DIFFS on SDF).  The Diffs were:

Input Pointing Diffs:  

• IM1 & IM3 pointing changed at ~14:45 PST today (Jim?)
• RM1 & RM2 pointing changed by me this evening

Some ISIs in GS13 LO Gain Mode Diffs for HAM2, HAM5, ITMx

• Called Jim and he said these were probably stragglers left in LO gain from our seismic issues of the last few days.  He said switching to HI gain might drop H1 out of lock...I ACCEPTED the input point issues above first, and then switched HAM2 GS13s to LO gain:  This knocked H1 out of lock.  I switched HAM5 & ITMx ISIs to LO gain while down.

Now working on getting H1 back UP (& going to have dinner soon).