Took transfer functions on IM1, IM2, and IM3.  The analysis of the data is in progress.  I've checked the alignment of the optics, before/after, and all (including IM4) match to within 2 urad, their alignment before the previous lock (last unlocked data before Maintenance 5/28 3:30 UTC, compared to "now," 19:04 UTC).

- Rahul, Cheryl

I reset both PSL power watchdogs at 19:02 UTC (12:02 PDT).  This completes FAMIS 10712.

Main message: I've made another change to the squeezer laser current, which will hopefully give us a week or two without mode hopping, but it seems that we need to start planning on changing out the squeezer laser. 

The first attachment shows a 60 day trend of the squeezer laser power, and the green power produced by the SHG degrading as the laser mode hopping becomes worse.  Jeff B and I had made a small adjustment to the laser current last Friday, 49327 but this step was not large enough to fix the problem.  

We have potentially three ways to quickly see that the laser is multi-mode, SHG scan, OPO scan, and by looking at the beatnote.  Today it seemed like the OPO and SHG scans are both useful, but I could not tell the difference between the two current settings by looking at the beatnote.  The second attached screenshots shows the SHG and OPO scans before and after lowering the laser current from 2A according to the laser controller to 1.857A on the laser controller.  The readbacks for the laser current are consistently lower (shown in yellow in the screenshot) than the front panel readbacks.  While watching both of these scans with the laser current set to the multi-mode value, I tried blocking the two main paths to see if that would change the behavoir.  (While watching the SHG scan, I blocked the path which goes to the seed, clf and beatnote, saw not change in mode hopping in SHG scan. Then I blocked the SHG while watching seed scan of OPO, no change).  So if the problem is due to laser feedback it is from a problem upstream of the split between the two paths, I looked through this path two weeks ago during Tuesday maintenance and again today.

This new current setting is low, which may mean that we cannot engage the noise eater with this setting.  I changed the diode current nominal level to reflect the change.  

Since I had brought the chiller down today, it found a new lock point with a slightly different power. I just eyeballed and guessed H1:TCS-ITMY_CO2_LASERPOWER_POWER_IN from 4.6W to 4.5W and this seemed to make the power guardian happy.

Recap: The TCS Y chiller was found to be very low on water on May 21 (alog49382). Since then there was a steady decrease in water, but over the weekend it seemed to have stopped leaking.

Today I turned off the chiller and started looking for any trace of a leak. This chiller has leaked before creating large corroded areas, so it is hard to find any new leaks that may have dried up. I was unable to find any water where it shouldn't be, but I did find some corrosion streaks that I didn't recall being there before. These streaks can be traced back to near the lip of the fill port.

I talked to Betsy and she mentioned that she had noticed the flow going into the filter splashing a bit more than usual when she had checked on the 23rd. She adjusted the wire mesh and the splashing went away. According to the fill log, this was right around the time that we stopped losing around 0.5L/day. Our current theory is that the wire mesh that the incoming water to the reservoir has to pass through, had moved a bit and caused some splashing. We have seen this before, and there is not much we can do to prevent it, other than check on it from time to time. We will keep an eye on it in the coming days to make sure that this is actually the cause. I fired up the chiller again and reset the controller and all seems well.

Side note: I swapped out the water and air filters for TCSY and just the air filter for TCSX because they were gross and probably past due to change. This is reflected in the paper log, as well as here, obviously. (The picture of the water filters has the one I just pulled from TCSY on the left, and the last one that I pulled from a chiller on the right. Seems that the color is a bit less green and more gray now.)

Still no further MC SUS glitches.  I searched back thru the weekend lock loss and lock attempts for those MC SUS glitches which were a problem a week ago.  They are still not a problem.

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=49366

Attached is spectra of the EndX Anemometers during a wind event over the weekend.  The start time is 2100 on 26 May when the average speed hits 15mps and stays up for ~5 hours with averages touching 30mps.  These channels come in as meter per second so I only applied a calibration of 1 so I think the units displayed are correct.

Check the mapping in the third attachment of 49387 to see the location of the Fence wind sensors.  Verbally, SPEED_4 is ~collocated with the WIND_ROOF sensor.  Speed_3 is west and high, Speed_2 is closer to the fence and only 12' up.  During this windy period the direction of the wind was pretty 'northerly' coming almost straight down the Xarm toward the corner

Generally, the WIND_ROOF sensor has a higher ASD than the FENCE sensors.  Does this indicate it is more sensitive or more noisy?  Based on the time series though, the PEM weather sensor is more responsive than the PCE Fence sensors, even the #4 up on the roof.  The other two sensors are understandably appear less sensitive as they are at less than 1/2 the altitude as the roof top sensors.

S Banagiri, P Covas, R Schofield

We looked into the adhoc rain pem injection in more detail ( mentioned here before ), using transfer function measurements by Philippe Nguyen with the HAM6 Vac accelerometer. Quantitatively, these predictions show that we somewhat underestimate the noise in DARM during rain using only the HAM6 accelerometer prediction. I attach a plot of a DARM background ASD and DARM during rain plotted in black and red respectively using about 5 minutes of data. Also plotted are the predictions of DARM noise in the 30 - 100 Hz band using the HAM6 Vac accelerometer. The blue curve is the ambient noise prediction and the green curve is the prediction during rain. 

Ops Shift Transition: 05/28/2019, Day Shift 15:00 – 23:00 (08:00-16:00) - UTC (PT)

State of H1: Locked

Intent Bit: Commissioning

Weather: Low wind, clear sky

Primary 0.03 – 0.1Hz: 0.01 um/s

Secondary 0.1 – 0.3Hz: 0.08 um/s

Outgoing Operator: Jeff

Quick Summary: Out of Observing for Tuesday maintenance, still locked for now.

   Posted are the plots from the weekly CPS Noise Spectra. For the most part they look OK. There are several spikes in V1, V2, and V3 channels for almost all the platforms, which may be normal.  

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

    PMC:
    It has been locked 13 days, 18 hr 48 minutes (should be days/weeks)
    Reflected power = 10.04Watts
    Transmitted power = 54.57Watts
    PowerSum = 64.61Watts.

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

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

    Possible Issues:

   Good Observing for first half of the shift. The range is around 110.0Mpc. The wind and microseism have settled down a bit over the course of the morning. In general, all is well.

TITLE: 05/27 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Jeff
SHIFT SUMMARY:

Mainly focused on PSL RefCav for first part of shift.  Made it back to OBSERVING & have been locked for 3+hrs.

Most of H1 activity alogged earlier.
LOG:

• 23:35 Checked TCS chillers (while Cheryl was here)--->  BOTH looked fine, no water added.
• 23:40-0:06 Beginning INITIAL ALIGNMENT
• 0:06 Locking
  • 1st attempt:  at OFFLOAD_DRMI_ASC, had to touch up SRM mainly in Yaw to optimize POP18.  Hung out about 2-3min, and then lockloss at PREP_ASC_FOR_FULL_IFO.
  • At 0:38 Took FSS Common Gain from 26 to 29dB (this was a suggestion from Sheila over phone)
    • Have had 3-consecutive locklosses at LOCKING_ALS :-/
• 1:38 -3:00:  PSL Ref Cav alignment
• 4:43 Back to OBSERVING (SQZ Manager notification...see alog).

Pretty sure this is my fault. 

Noticing a Notification for ISC_LOCK node:  SQZ_MANAGER:  REQUEST CHANGED (was:  SQZ_READY_IFO, now:  SQUEEZING)

This does not keep us out of OBSERVING.  Did I change the nominal?  If so, will want to make SQZ_READY_IFO nominal next time we are out of OBSERVING.

4:43:  H1 back to OBSERVING!! (joining L1 & V1 who were in Stand Down from a couple of GRBs)

Very tough first 1/2 of the shift.  COMM Gain increase might have made locking tough at the beginning.  So, attempted to touch up RefCav alignment via picomotors (see earlier alog).

After my paltry RefCav improvement, attempted locking.  Something still not quire right.  Alignment looks decent from earlier INITIAL ALIGNMENT, but ASC drives someone off around OFFLOAD_DRMI, so need to be quick to correct it (I chose SRM yaw)!

Then moved all the way through Locking states up until the Squeezer (for this, since I'm clueless about the Squeezer, I called Georgia & we walked through it).  See her alog for specifics.  Once squeezer was locked, had a few SDFs to take care of (see below).  Also needed to raise the FSS COMM Gain from 25.0 to 26.5 to get rid of the DARM high freq noise "tail".

Notes:

• Had SDF diff for TMSx's pit/yaw alignment sliders....ACCEPTED them.
• FSS RefCav  transmission/alignment issue yielded the known issue with the high freq (2kHz & up) "tail" above reference.  Walked COMM Gain from 25 to 26dB and saw nothing.  Then went from 26.0 to 26.5dB and then this brought it down.  ACCEPTING this value we have to live with until we can improve the RefCav transimission.
• [NOW I'm going to really get lunch now!!  REALLY!  Ha.]

The squeezer got stuck trying to lock the CLF tonight. I thought this could be related to the low LO power at the CLF demoduator (see attached screenshot), but it looks like this level has been low for a while. Corey init'd the SQZ_MANAGER guardian and it locked the CLF just fine so we don't know what was actually causing the problem.

(We initially thought that since CLF_REFL_RF6_DEMOD was super low (-50) that we needed to align the ZM's but we were confusing the LO and CLF loops -- the RF6 was low because the beam diverter was closed and does not get opened until the next step in the locking sequence.)

After running an alignment earlier, Sheila suggested I increase the FSS COMM Gain from 26dB to 29dB (Over last couple of days we have gone up from around 23dB up to 26dB due to the RefCav transmission nose-diving after the big Peru EQ).  Unfortunately after I went to this higher gain, I could no longer get past LOCKING_ALS...even when I reduced the gain back to 26 & 25dB. 

At this point I gave Jason a call so he could walk me through what to do to touch up the RefCav alignment.  Starting at about 1.77V, I was able to take a decent step up to around 1.84V, but after that I just could not get any big improvements...I might have max-ed at about 1.87V...but this is still pretty horrible since this should be up around 4V (and this was with me spending atleast 90min trying to touch up the alignment. (a few hours of the transmission signal is attached).

I finally decided to give up on this and move on. 

The FSS COMM Gain was at 25dB (1dB lower than at the beginning of the shift); I was hesitant to go to 26dB or higher due to the difficulties in getting past LOCKING_ALS earlier. 

LOCKING:

One attempt broke lock at ACQUIRE DRMI.

Current attempt maid it to OFFLOAD_DRMI_ASC...but I really had to watch it toward the end of this step because the last few steps of this state would drive POP18 down & make PRC Gain noisier---I literally had to tweak SRM in Yaw quickly to keep the alignment from being driven off and breaking lock.  Have optimized alignment best I can here at DRMI, and have hung out at OFFLOAD DRMI for about 10min (to make sure everything looks calm & flat before moving on)....Will move on and see what happens.

[And I need a break, so will be making lunch soon.]

TITLE: 05/26 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY:
LOG:

9:35 Begin resetting Watchdogs -

• OFI WD is tripped. I can't find how to un-trip this. It isn't accessible from the Ops Overview screen.
• Found it! SITEMAP>SUS_AS.

9:57 BLRMS below 1um/s - AS spot is low and right

• Bringing SEI_CONFIG back to WINDY

10:07 Everything un-tripped. Everything re-aligned - AS Spot still low and right

• no flashing on ALSY camera
• reset BS and all Y optics back to witness sensor values prior to EQ
• Oplev spots look good

11:40 Just got off the phone with Sheila (she called in to check on the quads). I didn't push the big green RECOVER EQ button!!!!!! -_-

• Things look a LOT better now.

11:45 Begin Initial Alignment

12:10 Raine from LLO called to let me know that ALSY tripped and requires a trip to the end station - phone buddy system in effect

12:33 Raine reported back at the corner station.

12:52 begin re-locking H1

14:00 Lock failed at INCREASE POWER

14:23 Lock failed at INCREASE POWER (again)

• Going to wait at ENGAGE_DC_VIOLINS
• ETMY MODES 1 & 6 are rung up pretty good - gonna take a while

15:00 Handing off to Cheryl