(times in PST)

0:04 - Locked @ LSC_FF, started PCAL swept line measurement

0:29 - PCAL measurment done, started DARM OLGTF measurement

0:50 - Both measurements done and no more for now it seems, Intention Bit set to Undisturbed

There were eight separate locks during this shift, with typical inspiral ranges of 60 - 70 Mpc. Total observation time was 28.2 hours, with the longest continuous stretch 06:15 - 20:00 UTC on June 11. Lock losses were typically deliberate or due to maintenance activities.

The following features were investigated:

1 – Very loud (SNR > 200) glitches
Omicron picks up roughly 5-10 of these per day, coinciding with drops in range to 10 - 30 Mpc. They were not caught by Hveto and appear to all have a common origin due to their characteristic OmegaScan appearance and PCAT classification. Peak frequencies vary typically between 100 - 300 Hz (some up to 1 kHz), but two lines at 183.5 and 225.34 Hz are particularly strong. These glitches were previously thought to be due to beam tube cleaning, and this is supported by the coincidence of cleaning activities and glitches on June 11 at 16:30 UTC. However, they are also occurring in the middle of the night, when there should be no beam cleaning going on. Tentative conclusion: they all have a common origin that is somehow exacerbated by the cleaning team's activities.

2 – Quasi-periodic 60 Hz glitch every 75 min
Omicron picks up an SNR ~ 20 - 30 glitch at 60Hz which seems to happen periodically every 70 - 80 min. Hveto finds that SUS-ETMY_L2_WIT_L_DQ is an extremely efficient (use percentage 80-100%) veto, and that SUS-ETMY_L2_WIT_P_DQ and PEM-EY-MAG-EBAY-SEIRACK-X_DQ are also correlated. This effect is discussed in an alog post from June 6 (link): "the end-Y magnetometers witness EM glitches once every 75 minutes VERY strongly and that these couple into DARM".  Due to their regular appearance, it should be possible to predict a good time to visit EY to search for a cause. Robert Schofield is investigating.

3 – Non-stationary noise at 20 - 30Hz
This is visible as a cluster of SNR 10 - 30 glitches at 20 - 30 Hz, which became denser on June 11 and started showing up as short vertical lines in the spectrograms as well. The glitches are not caught by Hveto. Interestingly, they were absent completely from the first lock stretch on June 10, from 00:00 – 05:00 UTC. Daniel Hoak has concluded that this is scattering noise, likely from alignment drives sent to OMC suspension, and plans to reduce the OMC alignment gain by a factor of two to stop this (link to alog).

4 – Broadband spectrogram lines at 310 and 340 Hz
A pair of lines at 310 and 340 Hz are visible in the normalized spectrograms, strongest at the beginning of a lock and decaying over a timescale of ~1 hr as the locked interferometer settles into the nominal alignment state. According to Robert Schofield, these are resonances of the optic support on the PSL periscope. The coupling to DARM changes as the alignment drifts in time (peaks decay beacuse the alignment was tuned to minimize the peaks when the IFO is settled.) Alogs about this: link, link, link.

There are lines of Omicron triggers at these frequencies too, which interestingly are weakest when the spectrogram lines are strongest (probably due to a 'whitening' effect that washes them out when the surrounding noise rises). Robert suspects that the glitches are produced by variations in alignment of the interferometer (changes in coupling to the interferometer making the peaks suddenly bigger or smaller).

5 – Wandering 430 Hz line
Visible in the spectrograms as a thin and noisy line, seen to wander slightly in Fscan. It weakened over the course of the long (14h) lock on June 11. Origin unknown.

6 – h(t) calibration
Especially noisy throughout the shift, with the ASD ratio showing unusually high variance. May be related to odd broadband behavior visible in the spectrogram. Jeff Kissel and calibration group report that nothing changed in the GDS calibration at this time. Cause unknown.

Attached PDF shows some relevant plots.

More details can be found at the DQ shift wiki page.

Times UTC

3:12 Locked LSC_FF @ 23W by request of Evan. Evan running measurments.

4:00 Lockloss.

6:00 Locked LSC_FF.  Still at 23W and Evan and Dan still taking measurements.

6:55 Back to LSC_FF @ 16W.  Starting remaining PCal and OLGTF measurements.

7:00 Handing off to TJ to bring ER7 home.

Times UTC

23:00 Still locked LSC_FF.

23:05 Jeff K taking OLGTF measurements and working on OMC calibration.

23:23 Jeff K taking PCal measuements.

0:05 Lockloss.  Appears to be due to EQ in Canada.

0:45 Lockloss on the way up at BOUNCE_VIOLIN_MODE_DAMPING. 

0:51 GRB/SN alarm.  Unfortunately, not locked at the time.

1:22 Paused locking sequence at DC_READOUT_TRANSITION so Dan can take some OMC measurements.

3:00 Dan done with measurements.

J. Kissel, T. Sadecki, D. Hoak, E. Merilh

As a last ditch effort to be able to recocile the calibration for the rest of the run, given the drastic change to the ETMY ESD, I've completed a DARM OLGTF, and also tuned and completed a PCAL EX to DARM transfer function. I got halfway through the same transfer function using PCAL EY, but the lock broke from some sort of seismic disturbance. The interferometer was at 17 [W] requested input power for all of the below measurements, I attach the relevant digital parameters that are relevant (sadly the list is growing! as so many things are changing!).

Analysis to come, but the measurements have been committed to the CalSVN repo here:
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs
2015-06-13_H1_DARM_OLGTF_LHOaLOG19128_ETMYL3LPOFF.xml

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER7/H1/Measurements/PCAL_TRENDS
2015-06-13_H1PCALEX_2_DARM.xml
2015-06-13_H1PCALEX_2_DARM_stronger.xml

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER7/H1/Measurements/PCAL_TRENDS
2015-06-13_H1PCALEY_2_DARM_stronger.xml

For the PCAL sweeps, I've modified the following settings from what Sudarshan had set up (2015-06-12_pcal_sweep_X.xml in the same folder) such that (a) the measurement would complete in a reasonable amount of time, (b) we'd get coherence over the entire band of measurement, and (c) that the frequency vector would match the DARM OLGTF:
- Changed the frequency range to 5 to 5000 [kHz]
- Changed the frequency vector from linear to logarithmic
- Changed the user-defined amplitude format to Envelope
- Increased the number of cycles to 25
- Increased the duration of a cycle to 1 [sec]
- Increase the drive strength in various frequency bands where there remained no coherence

LHO ER7 data quality shift Wednesday 6/3 to Friday 6/5 (1117378816-1117584015). TJ Massinger was the shift mentor.

Things we noticed:

- Thursday the sensemon was incorrectly generating the inspiral range, which has since been fixed. The range was between 45 and 55 Mpc on Thursday.

- The calibration accuracy seemed to be more widely varying than in previous days, with large departures (factor of >5) at the high frequency (~6kHz) end.

- We saw the 14Hz roll mode ringing down at the beginning of each lock, except for the 11:00-13:00 UTC segment Thursday, where a ring-down measurement was being performed. Nothing to see here.

- Some ugly wandering lines in CARM around 600Hz that also showed up through their 4th harmonic.

- A particularly glitchy segment just before 18:00 UTC Friday. We tracked down the loudest glitch which was identified as 2.16kHz (SNR 3,190). A time plot shows this was actually high frequency glitches riding on a much larger ~7.7 Hz blip. The high frequency components also showed up in the PRM M2 suspension control signals. Some discussion in the aLog about this: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=18918

A link to the shift report: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20150603

15:58PDT

Jeff K in the control room wants to take a DARM loop open gain and correct the calibration. Will wait to go into science mode. Handing of to Travis.

LLO was down at the beginning but came up during the injections. I did most of what I had hoped to do in the first round.

22:09UTC H1 is in science mode:

• The OIB was switched to Undisturbed

• Robert is going to destinations down the Y-arm where shakers will eventually be set up to do some "banging". He will record the time of his actions and the glitches can also be observed by the Detcharrians (spelling?)

• Aaaaaaaaannddd LOCKLOSS @ 22:18 RATS!

After much diddling with PR's and SR's while swinging them and watching camera images and dataviewer I finally came to my happy place with the alignments!

• 13:00 FINALLY got DRMI locked. It kept locking on the wrong mode. Trial and error landed me a manual pitch adjustment of PRM. BINGO.

• 13:08 RESONANCE

• 13:20 After much cautiousness, Locked at LSC_FF about 56Mpc. 

Robert Schofield is here and looking to do some PEM injections. He'll be going into the LVEA.  There seems to be a  strange disturbance in the Force that we can't explain. (see attached screenshot)

I spoke to Joe Hanson at LLO. At 20:30UTC they were locked on RF and were looking to move forward to DC Readout. I informed him as to our status and the testing that Robert was about to do for the next 1.5 hours or so.

For now.....life is good!

IFO locking difficulties continue:

• I re-checked initial alignment from "the ground up" just to review the state of everything else. Green looked good in both arms. PRM_ALIGN seemed to have gone well. I did improve the alignment on PR3 slightly. I then moved to MICH_DARK_LOCKED which seemed to converge nicely. It needed a little touching but at the outset always seemed to have some movement to it. I then moved on to SRC_ALIGN, which is where TJ handed off to me.

• Spent some time on the phone with Sheila trying to get the SRC alignment back to quasi-nominal. I got the spot bright and as round as I could get it. Increasing the laser power to 10W made the chore easier to deal with. It did lock but the stability was never resolved.

• I took a chance at moving forward to the DRMI_LOCKED state to see what would break. As I suspected by all of the swinging going on in the intial alignment, there was no glory.

• I then reverted back to looking at the PRM_ALIGN and saw that the alignment wasn't to good. Working on that now. Sheila will be in this afternoon. Fun.

As TJ mentioned in a earlier post there is an excitation showing at ETMX with 5-6 Testpoints occupied with some kind of business. We don't know what this is about and we really hope it isn't a contributing factor to our locking woes.  

I'm considering killing them if no one owns them.

Still no locking for my shift. I talked to Sheila for a bit and it seems that when the ISC_LOCK guardian was getting stuck in LOCK_DRMI_1F asking you to adjust by hand, it was only in a PRMI configuration and SRM was misaligned somehow(perhaps related to what I was seeing during IA). I moved SRM around for a bit and brought it back to some old values but still nothing.

Ed will have to finish up the mess I made for him.

model restarts logged for Fri 12/Jun/2015
2015_06_12 23:27 h1fw1*

* = unexpected restart

I took over for Travis as the interferometer was locking DRMI, shortly after I had to damp ETMY and ITMX bounce and roll modes. It then made it to BOUNCE_VIOLIN_MODE_DAMPING before it broke. After recovery, it got stuck on LOCK_DRMI_1F for a long time, much longer than usual (25min is where I would give up) . I have heard this could be from a bad alignment so I did a quick initial alignment with no issues and then made it a few times to REFL_TRANS/RESONANCE before it broke lock.

Again LOCK_DRMI_1F took a long time so I did another initial alignment. This time, I struggled keeping the ALS locked. It would all seem good and then one of them would catch a flurry of large modes and then recover back to a steady power above 1. When I limped through IA to SRC_ALIGN, Guardian said that it was locked and it was not. This happens some times and is normally an easy fix but I couldn't make it work well at all, it was constantly moving around. I eventually got something that was round(ish) but pretty wavey and tried to move on. Made it to LOCK_DRMI_1F and it asked that I adjust it by hand, which is also not working.

That's the rundown of my shift so far, let's hope it improves.

Looks like an excitation got left on for H1SUSETMX. I saw it on the CDS Overview when I arrived, there are 6 test points running on it right now. I don't see anything in the alog about this being here intentionally.

We had four known reasons for having difficulty locking today, one is an unsolved mystery that might be hurting us more often than we realize.

• The BS limiter was off durring DRMI lock acquisition, this is turned on and off by guardian.  I've attached a screenshot of the gaurdian log.  The code should have returned true imediately after having turned off the limiter, and proceeded onto the next state, however, it ran the LOCK_DRMI_1F run again.  The requested state at this time was DRMI_1F_OFFLOADED, which means that this guardian should have moved onto the next state.  Is there a way to search the Guardian logs to see if we have had other instances of this?
  • we have seen this behavoir in the past, and Jamie suggested that this could have been because the state LOCK_DRMI_1F was requested.  I know that was not the issue today, but I changed the state so that it is no longer a requestable state anyway, since it should never be requested.
• The roll mode damping for ETMY was switched off at the output.  All the roll mode damping settings are now enforced by the guardian, using ezca.get_LIGOFilter().only_on.  

I reloaded both ISC_DRMI and ISC_LOCK guardians today, to incorporate these changes.  

• We had difficulty transitioning to ETMY ESD, evan is writting an alog about what we think is the solution
• Now the winds are quite high, the forecast says they will die down around 1 am.  

Good luck TJ!