8/21 OWL Shift:  7:00-15:00UTC (00:00-8:00PDT), all times posted in UTC

Handed an H1 (~55Mpc) which has been locked for 7.5+hrs from TJ with H1 Undisturbed & Observing. 

NOTES (Beginning of shift with Locked H1) :

• SDF Overview:  There are RED states for LSC, ASC, OMC, SUSITMy, SUSITMx, SUSSR3, SUSETMx, SUSETMy, CALCS
• ODC Master:  Mostly, green, but there are (5) RED states for:  ALS Summary, LSC Summary, OMC Summary, ADC Overflow Summary, DAC Overflow Summary, & Subsystem Parity Summary.
• Ops Overview:  GREEN

Activity Timeline:

• 7:02 - 7:40:  Transfer Function for DARM Matlab model (Darkhan). 
• ~8:02:  L1 back up (64Mpc)
• 10:00:  Talked with LLO Operator Mike to see how they are doing.  They were commissioning for much of the night & are now in Observing Mode with nice range.  We are both flying solo in each of our Control Rooms.
• ETMy glitches during the shift came up with the VocalAlarm tool.

Went through the SDF to see if I could make sense of the differences on there.  I did not make anything GREEN (i.e. I did not ACCEPT or REVERT anything because I'm not sure whether we want Operators to do this or Detector Engineers to do that). 

Here are some of my notes of Differences we have by subsystem:

SUSITMY

• H1:SUS-ITMY_L2_DAMP_MODE2:  Stefan violin mode damping (8/20 00:30PST).  Are we happy with this and can we accept?

SUSITMX

• H1:SUS-ITMY_L2_DAMP_MODE1 (8/19 15:24):  violin??  Revert or Accept?
• H1:SUS-ITMY_L2_DAMP_MODE7 (8/19 14:36):  violin??  Revert or Accept?
• H1:SUS-ITMY_L2_DAMP_MODE9_GAIN:  Can't find alog (8/20 16:31PST)

SUSETMX

• H1:SUS-ETMX_L2_DAMP_MODE10:  IN?  What does this mean?
• H1:SUS-ETMX_L2_DAMP_MODE7:  IN?  What does this mean?
• H1:SUS-ETMX_L2_DAMP_MODE8:  IN?  What does this mean?
• H1:SUS-ETMX_L2_DAMP_MODE9:  Nutsinee violin damping (8/20 16:20PST).  Are we happy with this and can we accept?

SUSETMY

• H1:SUS-ETMY_L2_DAMP_MODE10 (8/19 23:29) Stefan violin damping. 
• H1:SUS-ETMY_L2_DAMP_MODE3 (8/19 8:33) Stefan violin damping. 
• H1:SUS-ETMY_L2_DAMP_MODE9 (8/19 13:55) ???

SUSSR3

• H1:SUS-SR3_M2_OLDAMP_P_GAIN (8/19 14:38):  ??
• H1:SUS-SR3_M2_TEST_P_GAIN (8/19 14:36):  ??

LSC

• H1:LSC-MCL_TRAMP (8/20 16:31):  ??  Can we revert?

ASC

• H1: ASC-INMATRIX_P_5_3 (8/20 16:52):  ?
• H1: ASC-INMATRIX_P_5_8 (8/20 16:52):  ?
• H1: ASC-INMATRIX_Y_16_3 (8/19 0:31):  ?
• H1: ASC-INMATRIX_Y_16_7 (8/19 0:31):  ?
• H1:ASC_MICH_P_OFFSET (8/19 22:16):  ?
• H1:ASC_MICH_Y_OFFSET (8/19 21:11):  ?

OMC

• H1:OMC-DCPD_A (8/20 17:16):  ?
• H1:OMC-DCPD_B (8/20 17:15):  ?

CALCS

Lots of channels here.  Seems like many can be ACCEPTED

8/21 OWL mid-Shift:  7:00-15:00UTC (00:00-8:00PDT)

Handed an H1 in Observing Mode by TJ (10+hrs of lock during current stretch).  The range has been hovering around 55Mpc.  L1 is now done with Commissioning at are at 65Mpc.  All is quiet.

7:02-7:40:  Darkhan requested to run a Transfer Function (DARM Matlab model), and since L1 was down for commissioning, I decided to let him proceed.  In hindsight, I should NOT have allowed this activity since it is outside of the 1pm-10pm LHO Commissioning period.  It was a judgement call I made since L1 was down.  Range dropped down briefly to 10mpc during his sweep.

10:07:  ETMy glitch VocalAlarm and observed on DARM spectra

Took DARM open-loop transfer function measurement using template:

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/DARMOLGTFs/2015-08-17_H1_DARM_OLGTFtemplate.xml

As opposed to measurement taken on 2015-07-17 (see LHO alog #20614), we did not turn off calibration lines during this measurement.

Measurement XLM file was committed to SVN (@ r1097):

CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/DARMOLGTF/DARMOLGTFs/2015-08-21_H1_DARM_OLGTF.xml

Times in UTC

2300 Just lost lock before I showed up, realigning then comissioning

234 Itbit ON

333 Nutsinee had been damping violin modes during the time that the ITbit was set. She has stopped now.

340 Reloaded ISC_LOCK Guardian for some of Nutsinee's new violin mode gains

431 Eric Thrane HW INJ start

TJ, Keith, Eric

We restarted psinject at GPS = 1124166257. For ER8, the CW group has added two new pulsars not included in ER7. Also, the previous pulsar amplitudes have been decreased. One of the new pulsars is high-frequency, 1991 Hz. Keith Riles was worried the high frequency could cause saturation problems. However, TJ and I checked the output from the HWINJ filter bank and it appeared low, well below the current 200-count limit. TJ did not observe any decrease in the inspiral range or in the glitch rate coincident with the CW injections restarting. We are leaving the injections running. We are using "release" = ER8_test.

Using ETMX_L2_DAMP_MODE9 FM6, FM8, FM9 gain -350

The damping information has been added to The Table.

Guardian now turns on the gain for ETMX L2 DAMP MODE2 and MODE3 (1003.78 and 1003.67). These two filters have to be turned on together. I noticed mode2 rings up 1003.67 just so slightly and by turning on mode3 it damps the 1003.67 faster than it rung up. I guess I can make a narrower bandpass in the future...

This is not a quantitative argument or anything, but just an observation.

In the morning yesterday, I noticed that the beam shape at AS AIR looked ugly presumably baecause of a non-optimum alignment servo configurations which seemed to have tuned the alignment where noise below 100 Hz was more non-stationary. After the commissioning work last night (alog 20699), the interferometer alignment seems to be better and indeed the beam in the AS AIR camera looks more Gaussian. The attached are a camera image of AS AIR from yesterday and this after noon. Both images are from the time when the interferometer was locked on DC readout at 24 W with the ASC loops fully engaged. The beam diverter happened to be open for both images.

As shown in these picutures, the beam of yesterday has some halo structure (mostly shown in purple) surrounding the bulk of the light while the one from this after noon does not have such a dirty halo. Interestingly, the white saturation area at the center in today's image appeaeres to be smaller than the one from yesterday. This can be an indication of less higher order modes (including misalignment) in the current alignment configuration. I checked the exposure time of two images and confirmed that were set to the same exposure time, 1800 usec.

Also, in yesterday's morning, I saw a ring-looking halo component moving up and down in the AS AIR camera behind the bulk of the light on a time scale of a few seconds. This ring-looking component can be actually seen in the above image -- it is on the upper left from the center Gaussin component and seen in white/purple. I did not get a chance to identify what optic was making the halo move up an down.

The mixed matrix is put in during the ENGAGE_ASC_PART2 stage. The final switch to AS_A_RF36 happens at the very end of the INCREASE_POWER stage.

J. Kissel, R. Savage, S. Karki, K. Izumi

After considering the front-end precision issues found in the DELTAL_EXTERNAL calibration yesterday by Stefan and Evan (LHO aLOG 20700), we've agreed to move the pole frequency which reconstructs the integrator (a pole at 0 [Hz]) in FM1 of the L1 (UIM) ETMY control signal chain from what was quickly installed yesterday -- 0.001 [Hz] -- up to 0.01 [Hz] to gain another factor of ten high-passing of the control singal, such that we don't suffer from floating point single precision issues. Rick and Sudarshan will follow up shortly, repeating the study on the correct whitening filter we should use.

Note: The means that the DARM calibration is invalid below ~ 0.5 [Hz]. If you need to have a calibrated DARM spectrum below there, then make sure you (offline) compensate for this.

The history is as follows: 
- In ER7, we ran with this integrator compensator OFF, accepting that the front-end calibration below ~1 Hz was incorrect. LHO aLOG 17528, or LHO aLOG 18248
- A few days ago, Kiwamu updated all of the digital control filters to make that actual suspension filter chain using an automated script, forgetting about this dynamic range issue. LHO aLOG 20617
- Yesterday, Stefan Evan and Sudarshan rediscovered the issue, and moved the pole frequency up to 0.001 [Hz], and added more stages of whitening on the DELTAL_CTRL signal. LHO aLOG 20700

Today on the calibration call, Joe reminded us that he moves the compensation filter's pole up to 0.1 [Hz]. After comparing our options (in course 1 mHz, 10 mHz, 100 mHz increments), we decided that 10 mHz caused the least loss of phase in the 1 - 10 [Hz] region (where we need to worry about accurately reconstructing the PUM / UIM and PUM / TST cross-overs), for the most amount of high-passing of the large DC control signal.

Jeff, Kiwamu, Evan

We increased the EY UIM filter from 0.3 ct/ct to 0.6 ct/ct in order to relieve the rms drive of the PUM.

Before, the PUM drive was about 8000 ct rms per coil, and the UIM drive was about 1000 ct rms per coil. Now, the PUM drive is about 3000 ct rms per coil and the UIM drive is about 1500 ct rms per coil.

The ASC control of the SRC hasn't been making sense.  I did some calculations to see if the SRC might head towards an unstable condition if we run the IFO at high power (24W).   We were interested in whether thermal lensing effects in the ITMs could cause a big enough gouy phase shift to cause us troubles.

At 24W there is 120kW of power in the arms and that the surface absorption of the ITMs is 0.5ppb (galaxy).  The HR surface curvature of the ITMs changes by 1.06 udiopter/mW absorbed power (LLO alog 14634).  This means we could expect a change in ITM curvature of 120e3*0.5e-6*1.06e3=65udiopters, or a change in the radius of curvature from 2000m to roughly 1750m as we go from cold state to 24W input power.  I haven't considered substrate absorption, and G060155, slide16, indicates change in index of refraction due to bulk heating is roughly 10% of the surface absorption effect.

Putting this hot state ITM ROC into an aLaMode model of the interferometer (based on Lisa's model T1300960 with Dan's additions, alog 18915), the round trip gouy phase decreases from 32 to 22 degrees.  Calculating the stability parameter for the SRC using the round trip transfer matrix, the cavity goes unstable.  (A stable cavity occurs when -1<1/2*(A+D)<1.  This parameter changes from 0.8 to 1.3.)

These numbers are just estimates,  but the take away message is that as we increase the power, the SRC becomes less stable, and could be pushed into an unstable regime around about now.  Turning on the ITM ring heaters would make the SRC more stable.  (see comment) A ring heater on SR3 would also make the SRC more stable.

An additional note on transverse mode spacing:  The SRC mode spacing is 240kHz in the cold state and 180kHz in the hot state.  The cavity Finesse is 13.5, the free spectral range is 2.67MHz, so the full-width-half-maximum is 200kHz.  So heating of the ITMs also pushes the SRC closer to degeneracy.

Sheila, Jenne

We're looking into why we lost lock here after our nice long overnight + most of the day lock. 

Hang's new lockloss tool (result plots in /opt/rtcds/userapps/release/isc/common/scripts/lockloss/python/rec/lockloss_1124145611.531/) indicates that some ITM yaw LOCK drive outputs are some of the first to go out of "norm" after the lockloss, which led us to look more closely into ASC-related channels.

It looks like DHARD is our culprit here (see attached plot), with yaw going out of normal a teeny bit earlier than pitch.  Also in the attached plot are oplevs for all 4 test masses, and we see that none of them gets a kick of any kind by the time that the DHARD loops start to go unstable.

The frequency of the DHARD oscillation is about 18.9 Hz, which is awfully similar to one that Sheila saw earlier this week: aLog 20601.

The UGF of the DHARD loops is a few Hz, and the phase crosses zero degrees below 10 Hz, so it's not a loop oscillation.  Is there something crazy happening, like BS roll mode doing something that lets a signal out to the AS port, which then gets fed back into the DHARD loops?

Pretty slow day here, but in a good way.  We were locked on Low Noise for all but the last 15 minutes of my shift.  This includes staying locked through the last 4 hours of ~30mph winds. 

This is a follow up analysis of Robert's anthropogenic noise injections on August 12th. So far I don't see any convinving evidence that these activities were actually coupled into DARM. There were couple of injections ("human in optics lab" and "jumping in the change room") that seemed to coincide with DARM noise around 20-100Hz but it was unclear whether those injections were actually causing the noise. The noise *blobs* started prior to the injection and the PEM seismic sensor only coincided with one of them. Plus I would expect to see a coupling at much lower frequency if human jumping up and down the change room actually injects noise into DARM.

Note that the first injection time (15:05) is still unconfirmed. The time in the original table was wrong.

There has been some speculation the 40Mpc dip in range was tidal related.  It might just be coincident but this is because the dip sorta follows a portion of the ETMY tidal offset drive.  However, it doesn't line up eactly and only follows for part of the drive, albeit the extrema.  So it could be that once the HEPI hits a certain offset and its YAW misaligning pushes a WFS loop too far and allows a misalignment until it comes back in range.

See attached with the Range DMT above a 12 plot of the HEPI beam line position.  I plotted these to make sure the platform was actually moving and looked too at the local sensors and saw that no corner hit some limit requiring others to make up any shortfalls to satisfy the cartesian loop.

I'll continue to dip down stream to look for trouble.  But for now, it looks like HEPI is doing what it is told.

As part of the recovery effort today we stumbled upon a way that seems to fairly reliable allow us to transition from PRMI to DRMI (we were 3 for 3 today - we'll try again tomorrow).

The procedure is:

- Let Guardian set up for DRMI locking.
- Misalign SRM
- turn off H1:LSC-SRCL OFFSET, INPUT and OUTPUT
- Let PRMI lock
- make sure H1:LSC-SRCL OFFSET, INPUT and OUTPUT are off (guardian turns on OFFSET), and clear history.
- Pause ISC_LOCK and ISC_DRMI guardian
- Align SRM, wait until it damps down. Today the PRMI always stayed locked in this configuration.
- Turn on H1:LSC-SRCL OUTPUT
- Turn on H1:LSC-SRCL INPUT. DRMI is now locked.
- Turn on H1:LSC-SRCL OFFSET, if desired for mode-hopping suppression