16:15UTC I noticed that the Diode Chiller alarm was intermittently flashing RED. When I went into the Diode room I didn't see the light on the unit blinking at all less the frequency at which medm was reporting it. I'm going to add water to it and check the status again. THe frontend warning light is also intermittently flashing. Are the two related? Below is a plot from the last 7 days. I looked back 20 days but saw nothing else.
16:40 Added 500mL of water to Diode Chiller. Chiller alarm has ceased. Frontend alarm still flashing, frequently, for a couple of minutes following the drink but seems to have ceased as well. Perhaps the two were related after all.
I think you'll find that if the front end laser power dips below 34 W, then the MEDM status button will flash.
TITLE: 02/26 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 63Mpc
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
Wind: 8mph Gusts, 6mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.24 μm/s
QUICK SUMMARY:
The lockloss at ~14:00 UTC was likely caused or related to this 3.5 M earthquake: http://earthquake.usgs.gov/earthquakes/eventpage/uw61252706#executive
This was an unusual event: short but strong high-frequency seismic waves. It should be an interesting case to analyze.
Quiet first half of the shift. Nothing out of the ordinarily to report.
Dropped out of Observing from 09:08 (01:08) to 09:16 (01:16) to run the A2L script, while LLO was recovering from a Lockloss. The Yaw signal was rung up. After running the script both Pitch and Yaw are comfortably below the reference.
TITLE: 02/26 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 64Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY:
TITLE: 02/26 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 65Mpc
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
Wind: 13mph Gusts, 10mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.26 μm/s
QUICK SUMMARY:
TITLE: 02/25 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 66Mpc
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:
LOG:
Nothing unusual to report:
16:45UTC
16:53UTC H1 back to Observing
TITLE: 02/25 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 67Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
Wind: 7mph Gusts, 5mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.23 μm/s
QUICK SUMMARY:
Locked for 02hr27min
TITLE: 02/25 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
INCOMING OPERATOR: Ed
SHIFT SUMMARY:
PSL trip at the beginning of the shift made for a tough first half of the shift. This was followed by a random & mysterious lockloss. Other than that, shift ended quietly with double coincidence.
LOG:
Just as I submitted the Shift Transition Summary, the PSL Went Down (Flow Sensor #1 for Crystal Chiller; with the cap popping off & water geyser-ing out).
I have put us in the CORRECTIVE MAINTENANCE Observatory Mode State.
I left a voicemail with Jason at 12:38am local time. This requires a PSL Expert for recovery. Once we have a PSL Expert available to assist, it should take us ~30-60min to get the PSL back and then another 30-60min to get H1 back to NLN.
I've also appraised the LLO Operator of our status.
Lockloss at 8:38utc.
Got a hold of Jason. On phone with Jason from 2:35-3:10am to restore the PSL. Some Notes:
opsws1 and opsws2 have been replaced by zotac machines with new names. Best to use opslogin when logging in remotely.
I could not reproduce the problem with opsws12
FRS ticket is: Ticket 7499 - PSL Tripped Due To Head 1 Flow Error
https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=7499
This trip appears to have been caused by the flow reading from the Laser Head 3 flow sensor dropping below the trip point and therefore tripping the "Laser Head 1-4 Flow" interlock. This is in contrast with the previous trips from 2-20-2017, which were caused by the flow reading from the Laser Head 2 flow sensor dropping below the trip point. The first attachment shows all of the active laser head flow sensors as well as the "Laser Head 1-4 Flow" interlock that caused the trip. It is obvious that the flow read by the Laser Head 2 flow sensor was the cause of the interlock trip. The second attachment is a slightly zoomed in view of the Laser Head 3 flow sensor signal and the "Laser Head 1-4 Flow" interlock.
In addition, while restarting the laser I had difficulty injection locking the PSL; it took 3 attempts to injection lock the PSL. I believe this was due to drop in laser power due to the natural decay of the output power of the pump diodes. To alleviate this I increased the HPO pump diode currents by 0.5A each. I had planned to do this during the 2-28-2017 maintenance window, but it was necessary at this time to maintain stability of the injection locking. In the interest of returning to OBSERVING ASAP, I did not temperature tune the pump diodes; this will be done during the 2-28-2017 maintenance window.
[Vaishali, Kiwamu, Sheila(remotely)]
WP 6497
Sheila suggested us doing an interesting test today during the commissioning time window. The measurement we did is a coherence measurement between the bullseye sensor and DARM while changing the PR3 spot position.
The result suggests that a part of the broadband lump in 200 Hz-1 kHz is due to beam size jitter with a caveat that we couldn't fully reproduce the broadband lump.
[Background]
Back in pre-O2 commissioning, we had unidentified broadband noise in 200 Hz - 1 kHz (e.g. alog 30752) which was found to be a function of the PR3 spot position. One hypothesis was beam size jitter somehow coupling to OMC DCPDs.
[The measurements and results]
We tested three different PR3 spot positions, all of which is characterized by POP_A QPD readouts as follows.
Our intention was to reproduce what Sheila observed in this past November (31628) with a hope to reproduce the broadband lump. However, we didn't get drastic increase in the frequency band -- we only obtained a 18% increase at around 400 Hz. See the second attachment for the increased DARM noise. Despite different alignment, configurations (B) and (C) gave almost identical DARM noise. Increased noise below 30 Hz is presumably due to mistuned A2L couplings, as we have moved the spot position.
The first attached figure shows the coherence between the bullseye sensor (sorry for any confusion, but PIT = beam size jitter, YAW = horizontal pointing jitter). The dashed lines are the ones from configuration (A). Notice that they are almost at the same level as the previous measurement (31628). The solid lines are the ones from configuration (B). Those from configuration (C) are not shown as they are almost identical to configuration (B). As we have moved the PR3 spot position, the coupling of beam size jitter increased while the horizontal jitter coupling reduced. The coherence for beam size jitter became 0.05-ish above 300 Hz corresponding to a fractional contribution of 22 % to the DARM amplitude spectral density. Also, at the same time, the power recycling gain improved which is consistent with what Sheila observed.
These results indicate that broadband noise is more or less reproducible, and also, a part of broadband noise is due to beam size jitter.
Later, we tried further exploring the parameter space of the PR3 spot position to see if we can further elevate noise in 200 Hz - 1 kHz. This lead to a lockloss presumably due to too much misalignment on PRM when we were at (POP_A_PIT, POP_A_YAW) = (-0.3, +0.6). We couldn't find a location where the broadband lump becomes more prominent.
[A minor change in bullseye signals]
Besides, we made minor modifications on the bullseye settings.
Another caveat:
Later, Keita pointed out that we shouldn't have put a low pass in the sum channel because it spoils the dynamic cancelation of intensity noise. However, if this theory holds, the implementation of the low pass shouldn't decrease the coherence between PIT and SUM as it allows for intensity noise to contaminate both channels in a same way. But we saw a significant decrease in the coherence by a factor of 100 or so. We will get back to this point in the next week and assess what is going on.
With single precision floating point representation and two poles at 30 mHz anything above ~30 Hz is probably bit noise.
A follow up on the beam size jitter measurement.
So far the data seems still consistent with the hypothesis that excess noise in 200 - 1000 Hz is due to beam size jitter which happens to be coherent with intensity noise at the output of the high power oscillator (HPO).
The first attachment is a screenshot of plots showing the coherence of DARM with some relevant intensity noise channels. The data is from configuration (C), see the above entry for details. The below is a list of remarks on the plots.