FAMIS 11020

    Laser Status:
    Front End Power is 31.85W (should be around 30 W)
    70W Output Power is 69.36W
    Front End Watch is GREEN
    70W Watch is GREEN

    PMC:
    It has been locked 6 days, 14 hr 31 minutes (should be days/weeks)
    Reflected power = 10.1Watts
    Transmitted power = 54.36Watts
    PowerSum = 64.46Watts.

    FSS:
    It has been locked for 0 days 3 hr and 47 min (should be days/weeks)
    TPD[V] = 4.934V (min 0.9V)

    ISS:
    The diffracted power is around 2.2%
    Last saturation event was 0 days 3 hours and 51 minutes ago (should be days/weeks)

FAMIS 11225

ITMX is approaching +10 urad in pitch.

TITLE: 07/09 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    Wind: 7mph Gusts, 4mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.19 μm/s 
QUICK SUMMARY: Timing is red on CDS overview (alog 50445). No other issues.

TITLE: 07/09 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: Tough relock, had issues with ALS (alog50449). Ended up using the picos in HAM1 to change the COMM beatnote and that seemed to help out. Observing for 2.5 hours. Useism seemed to have leveled out, it might even be on its way down.
LOG:

• 2345 Gerardo to MX
• 0022 Changed observatory mode to corrective maintenance. There seems to be an issue with the handoff for ALS COMM
• 0033 Sheila to LVEA to measure IMC VCO
• 0429 Observing

Earlier tonight before the ALS problems started, I made a couple of changes to the guardians. 

1) I set the AS36 offsets to 0 when they are turned off before ENGAGE_ASC for full IFO.  This will stop the ASC SDF diffs that operators have been accepting each lock. 

2) I made some changes to the PRMI path. 

• I reduced the time that it tries to lock DRMI from 10 minutes to 5 minutes before the guardian redirects to try locking PRMI and running the ASC. 
• Watching the guardian run through this step as Jeff B was relocking, it locked PRMI then calculated the shortest path to low noise was to go right back to DRMI without running the ASC, so I rearranged some paths. 
• With help from TJ and Jamie I added wieghts of 5 to several paths in this part of the graph, which makes those paths longer in the shortest path calculation.  I think this should now run through the PRMI ASC, offload it, and then move onto DRMI locking. I didn't stay long enough to see this work though. 

Picoing to help out the beatnote seemed to do the trick. See my previous alogs for more info.

SDFs: ASC Sheila warned me about, accepted. SUS MC3, not sure why these are monitored but I accepted them thinking that there must be a reason.

We have been unable to relock due to what seems to be the same issue as on June 14 (Georgia's alog49932). ALS COMM cant seem to turn up the gain on the analog LSC refl servo without lock loss. Sheila noticed that the COMM beatnote was low so we opted to try to move PR3. This allowed up to make it past the ALS COMM point, but now the OMs seem to be railed whenever DRMI manages to lock. Initial alignment has not helped with this.

After an initial alignment, DRMI will lock up fine at first but then OM1 and 2 will begin to saturate and the powers will drop in POP18 POP90. This makes me think that the light getting to the OMs is way off, and that this PR3 alignment isnt going to work. With the history cleared for the OMs, the flashes for DRMI look great and it will sometimes catch for about two seconds, but then immediately drop it.

J. Kissel

As we're continuing to investigate the nonsensical low-frequency behavior of the DARM loop's sensing function (some times referred to as detuning of the SRC causing an optical spring), for the past month's worth of weekly calibration measurements, we've been gathering PCALX to DARM transfer functions as well as the "nominal" "reference" PCALY to DARM transfer functions. 

Remember, this measurement of the sensing function is the ratio of two transfer functions:
      DARM IN1         C
(1) -----------   = -------
    PCAL X or Y     (1 + G)

      DARM IN2      1 
(2)   -------- = -------
      DARM EXC   (1 + G)

       (1) 
  >>  ----- =  C
       (2)

So, to create these comparisons, I divided either the PCALX or PCALY to DARM IN1 transfer function with the same DARM IN2 / DARM EXC = 1 / (1 + G) transfer function taken at the immediately after. 

I attach a comparison of those processed measurements taken on each day compared against each other. 

The conclusion: we see the same frequency response at low frequency on both PCALs, and yet that shape is changing from measurement to measurement. So, the change is in the DARM IN2 / DARM EXC transfer function over time.

This strongly suggests that this low-frequency feature is not result of mis-centering of PCAL spot positions.

More data analysis of past data to come.

A detail-oriented person might see that the "optical gain" of the sensing function reported by PCALX is slightly different than PCALY, to the tune of somewhere between 0.5 and 1%. We'll chew on this as well.

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.

TITLE: 07/08 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
    Wind: 8mph Gusts, 5mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.27 μm/s
QUICK SUMMARY: Unknown lock loss, now trying to recover. Useism is on the rise, but shouldn't be a problem yet.

Previous alogs 50099, 49150, 49067, and 49038.

We are adding the FSS fast feedback path and the common mode control signal which feeds back to additive offset of the mode cleaner servo. The FSS fast follwos the frequency noise model of the free running laser up to about 10kHz, i.e., 10⁴/f Hz/√Hz. Above ~10kHz, the crossover with the EOM path will reduce the signal in the fast path, which was not corrected in the plot.

Around 13.7kHz the gain in the FSS is about 40dB, which explains the coherence seen with IMC controls signal. Since the forrest of peaks are not visible in the FSS fast signal, we conclude that these peaks are getting added after the PMC. The noise between 3 and 10kHz seen by the IMC is not suppressed laser frequency noise, and is still a mystery. The IMC sensing noise is around 10^–4Hz/√Hz. Increasing the IMC modulation depth by 20 would reduce this level by a factor of 10.

Summary (highlights) of the DQ Shift for an aLog:

-IFO observed at about 115Mpc with average of 70.02% duty cycle.(91.1+46.6+62.1+63.9+80.2+60+86.3)/7
-Hveto round 1 winner is H1:LSC-POP_A_LF_OUT_DQ for all days through out the week.
-Anthropogenic band ground motion increases after 10hrs UTC
-Lost lock due to earthquakes and/or wind
-90Hz bump on Wednesday
-On Friday and Saturday, the normalised spectrogram showed a red line at 1.5KHz,  the higher harmonics of the violin mode
-Highest peak of PCAL X seemed to be moving from 3KHz to 1.5KHz from Monday to Friday. PCAL Y seemed the same throughout the week, few combs at higher frequency.
-A few GRB alerts throughout the week, and a couple of BBH candidate.

Interesting alogs of the week:

-New v3 baluns installed in CER to replace the leaky ones. alog 48165
-End station electrostatic drivers modified. alog 50348
-SR3 heater calibration issue, power monitor channel is not reporting anything like the power as the requested power. alog 50355
-Bump at 90Hz is non-stationary, periodicity of 3mHz. alog 50371
-Measure the Q of the 10.43KHz of the PI mode that was identified earlier as being on ETMY alog 50374
-Studying the effect of moving the beam spot position on the the measured sensing function. alog 50380

Link to DQShift page: https://wiki.ligo.org/DetChar/DataQuality/DQShiftLHO20190701

    Good first half of the shift in Observing mode.

   Switch SEI_CONF from WINDY to EQ at 19:31 (12:31) for 3 incoming earthquakes from the Timor-Leste area. They are mag 5.0, 5.9, & 6.0. Will see if we ride through them. 

   Secondary microseism has been trending upward for the past 24 hours. It is now around 0.3um/s.

TITLE: 07/08 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY: Remained locked and in observing entire shift. No issues to report.
LOG:

06:46 UTC SEI_CONF to EARTH_QUAKE

07:35 UTC GRB E338075
Confirmed with LLO
Fermi
584264100
Standing down

08:45 UTC GRB E338079
584268316
Fermi

09:01 UTC SEI_CONF to WINDY

11:05 UTC SUS saturations screen on video0 disappeared. Reopened.

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.