Starting CP3 fill. LLCV enabled. LLCV set to manual control. LLCV set to 50% open. Fill completed in 17 seconds. TC B did not register fill. LLCV set back to 17.0% open.
Starting CP4 fill. LLCV enabled. LLCV set to manual control. LLCV set to 70% open. Fill completed in 107 seconds. LLCV set back to 38.0% open.

Attached is a graph showing the most recent 40 hours of PT120 pressure data.

I drove IM1 in yaw to look for clipping in the IO Faraday, and did not discover any strong evidence for clipping, however, my calculations show that that's not a surprising result.  The beam in the IO Faraday is off center in yaw by about 8mm, but that's still enough clearance that before there is any significant clipping in the Faraday, the beam travels off of the IM4 Trans QPD.   The total angle I calculated that's needed to drive the beam off of the IM4 Trans QPD is 2500 urad, and the actual amount I drove IM1 was 2150 urad, a difference of 350 urad, which might be an indication that the beam did start to clip in the Faraday, or could be error in the calibration of the alignment drive sent to IM1.

In order to fix an EPICS channel conflict between H1HWSMSR and H1HWSMSR1, I killed the HWSX EPICS softIOC on H1HWSMSR and restarted the HWS code.

The EPICS channel names are specified uniquely on each HWS machine by modifications to the environment variables of that machine in the BASHRC file.

The HWS code currently generates two sets of EPICS channels per instantiation. This is an artifact of the corner station code running two HWS on a single machine. Currently, we're running each Hartmann sensor on a separate machine. In order to avoid creating duplicate channel names on different machines, we added fake prefixes into the names in BASHRC (ITMY0 on the HWSX machine and vice versa).

However, we missed re-running the BASHRC file on H1HWSMSR (the HWSX machine). So two machines were producing channels with the prefix H1:TCS-ITMY_HWS.

So, between killing the EPICS softIOC and restarting the HWSX code, I logged into the TMUX session on H1HWSMSR and reran source ~/.bashrc to fix the problem. The results can be seen here:

This should permanently fix the problem in TMUX. To be super-sure, I'll get Dave Barker to reboot the machine.

Moved the Seismometer a couple meters ~9 days ago.  Attached are similar plots to previous looks of the ground motion in quiet and windy periods.  The quiet time is 23 May at 1100utc and the windy period is 24 May at 2300utc.  Not a great difference here compared to the Roam3 position, 35938, about 2 meters +Y from this Roam4 location.  I might could argue that the Roam4 location shows a bit less increase in the X dof below 20mHz but this is too subtle to be significant.  Bottom line, again, another location not as quiet as ITMY, during windy periods.

The attached plots show the CS wind velocity and the coherence/ASDs of the Roaming instrument (HAM5) and the ITMY.

Found IFO unlocked and set to down upon arrival. Going through alogs. Jim is running low frequency measurements on end Y ISI.

J Kissel S Dwyer

We now think that the IMC alignment wasn't the real problem, which we had suspected earlier today 36424.

•  Peter Jason and I went into the PSL this afternoon and moved the spots in yaw to match the two irises in the bottom periscope path).  
• Afterward Kiwamu and I realigned the IMC by moving the PZT and MC1, and Jeff picomotored to center the IMC WFS. The spots on IM4 trans and the second loop QPD are closer to where they were before the vent, but this didn't help us lock. 
• Jeff did an initial alignment
• We attempted to get through the CARM offset reduction, but saw that our recycling gain hadn't improved. We were still seeing the symptons in alog 36439
• Jeff and I used the procedure described in the comment to 29082 to co-align the red and green in the Y arm. With the Y arm locked and full green ASC engaged for the Y arm
  • ISC_LOCK to initial alignment
  • ALS_YARM to INITIAL_ALIGNMENT (Green locked, all green ASC running)
  • We locked the PSL to the Y arm (ALIGN_IFO to YARM_IR_LOCKED).  
  • Jeff continuously adjusted the beam splitter to maximize the IR transmission through the arm (LSC-TR_Y_NORM, goal is 1) while I moved the camera offsets and we waited for the green ASC loops to converge.
• We ended up changing the YAW camera offset to 397 from 367.95.  Yesterday when I first aligned the Y arm, the camera spot was near this position.   Engaging the camera servo moved the beam off the trans diode on ISCT1, so I moved the beam splitter to restore it.  What Jeff and I did today was the reverse of this procedure.  We think that the green camera reference for the Y arm has gone bad somehow (gotten bumped), so we have updated it.  We tried this procedure for pitch but ended up with the same camera and beamsplitter positions as we started with. 
• After this we redid the alignment of SR2 and SRM.  DRMI locked well, we didn't have the same problems with ASC engaging we have been having.  We did not have as large of a 10 mode at the AS port just before DHARD WFS confirming that the camera and beamsplitter move was good for the alignment of the interferometer. 
• This locking attempt we were able to get through the CARM reduction.  The first ASC loops to be engaged (REFL POP WFS) brought the recycling gain down.  Then when some further ASC loops came on (probably POP-> PRM which is ASC_PART2) we unlocked the interferometer.  
• Since that we have had several locklosses in the final steps of the CARM offset reduction sequence, but the reflected power is consistently better during the offset reduction than it was before we moved the camera reference. 

Other things tonight:

• ALS locking has been not very reliable.
• Searching for DIFF was not working well, I updated one of the offesets in alsDiffparams.dat
• the mode cleaner has not been locking well, we can lock it by puting an offset on MC2 length and taking it off again.  We might need to relook at the triggering. 
• I changed the gain for the initial alignment of the laser into the X arm, I changed INP1Y gain from -50 to -40 to get rid of an oscillation. This is in the guardian.

Jeff K, Sheila

Here are some symptoms we have that our initial alignment is not giving an alignment that is good enough to get through the CARM offset reduction.

1) REFL power drops too early in the acquisition sequence, because the recycling gain is low and the CARM offset is smaller than it normally would be.

2) AS port camera looks bad just before DHARD WFS come on (you can see misalingment modes, Jeff got a picture to attach)

3) When we switch the AS36 Matrix while offloading the DRMI ASC, the sideband build ups get better. 

We are making progress, update coming later. 

At my request, Apollo enlisted the services of a air balancing company [Test Comm] to test and calibrate the air flows as well as the chilled water flows at the out buildings where the HVAC Controls Upgrade have been completed.  In order to have accurate readings on the new controls and to balance the systems we needed to have current flow rates.

During this testing it was discovered that the chilled water flows were greatly reduced as were the fan flows causing us great difficulty in maintaining a stable temperature at  the end stations. The chilled water flows were far below the chiller minimum water flow required for the chillers which is 84 GPM. 

We were restricted to 30 GPM. The chilled water pumps are rated at 105 GPM.
 
The reduced chilled water flow was mostly attributed to the reduction of the motor input from the VFDs which in the case of End Y was down to 30 Hz. I increased the running chiller pumps to 45 Hz and this allowed us to mostly control the temperatures in the VEAs.

If there is continued insistence on reducing the output of the motors of the chilled water pumps, perhaps we should consider resizing the pumps.  

Jeff K., Dave B., Patrick T.

Explicit steps given for reference.

1. Jeff K. noted that the readbacks for the end Y ALS EPICS channels were turning white on the ALS overview screen.

2. The current time for each PLC on h1ecaty1 was still updating on the CDS overview screen (bottom left corner under Slow Controls).

3. I ran rdesktop -T 'h1ecaty1' -g 2048x1280 -x l h1ecaty1 to connect to h1ecaty1 using remote desktop.

4. I logged in as controls.

5. The IOC terminal was minimized. I opened it by clicking its icon on the taskbar (circled in attached screenshot).

6. There were no errors initially shown in the terminal.

7. I hit enter in the terminal. The error shown in the attached screenshot appeared.

8. I hit enter again. No further errors appeared.

9. I restarted the computer by double clicking the icon on the desktop labeled 'RESTART'.

10. The issue was resolved.

HAM11's annulus ion pump (AIP) went railed high recently.  Both the pump and the controller are new and have low hours.  I hooked up a pump cart and banged on the pump with me knuckles  to break up any "whiskers" that may have grown to the point of shorting between the electrodes.  It seems to have now recovered. 

This is a continuation of yesterday's entry see https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=36371 

It appears that the scan taken on May 8th, just prior to the vent preparations, was taken before any large gate valves had been closed.  The scans that I took yesterday, May 24th, were just prior to opening the large gate valves.  In order to make a meaningful comparison, I will need to take a scan with the site configured as it was on May 8th, i.e. as it is now.  

1615 hours local -> I energized the Vertex RGA filament in preparation for taking a scan tomorrow.  I'll use the same RGA parameters as Chandra had used on May 8th and the data generated will provide a good comparison.  

I performed calibrations of both end stations this week as a target of opportunity during the pumpdown of the CS.  I forgot to turn off the CW injections for End X, so the data we got is not good for calibration.  I will revisit End X at a later date.  End Y was successful though and the full report can be found here.  In summary, the RxPD force coeffiecient is within 0.24% and the TxPD force coefficient is within 0.22% of the values used for O2 calibration.

TITLE: 05/25 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR:
SHIFT SUMMARY:
LOG:

13:50 Chris S moved forklift from corner station to mid-X

14:30 Chris S traveled to EY tom remove & discard absorbant pads in fan#2 room. This was due to the Glycol leak noted in aLog from Monday. about 10 mins.

16:45 Nutsinee out to HWS table. Doing fine adjustment of Hartman Y

17:10 Travis to MX for 3IFO work

19:00 Travis back from MX

19:07 Jim and Jeff runningn LF measurements opn all 3 corner station BSCs. Jeff has changed the blends for these in a way that can't be seen in ISI config.

20:00 Fil is at EX

20:17 Sheila is heading into the PSL to perform alignemt of main beam.

20:18 Pep out to EX to make measurements

20:26 Jason and Peter are going to join the PSL enclosure party

20:36 Fil back from EX

20:40 Pep arrived at EX

20:40 Travis back out to MX. Will be craning but not over beam tube.

20:50 Nutsinee goinginto LVEA (TCS cabinet)

22:04 Jason and Sheila out of the PSL for Gabrieles talk

21:22 Pep back from EX

22:10 Kyle into LVEA

22:20 Kyle out of LVEA

S. Dwyer, J. Kissel, J. Oberling

Given our problems yesterday with ALSX laser diode current surpassing an old threshold (see LHO aLOG 36381), I was reviewing whether we should accept the new higher threshold as the new normal. Here, I attach 20 day and 700 day (~2 year) trends of all four ALS laser diode's current (2 at each end). Also, here is the state of current values (a simple 10 sec average) vs. nominal and thresholds:
                                                                     Diff from
                                                    Current [A]      Nominal
    H1:ALS-X_LASER_HEAD_LASERDIODEPOWERNOMINAL      1.842
    H1:ALS-X_LASER_HEAD_LASERDIODEPOWERTOLERANCE    0.5 (was 0.2)
    H1:ALS-X_LASER_HEAD_LASERDIODE1POWERMONITOR     1.863            (0.021)
    H1:ALS-X_LASER_HEAD_LASERDIODE2POWERMONITOR     2.041            (0.199)

    H1:ALS-Y_LASER_HEAD_LASERDIODEPOWERNOMINAL      1.520
    H1:ALS-Y_LASER_HEAD_LASERDIODEPOWERTOLERANCE    0.2
    H1:ALS-Y_LASER_HEAD_LASERDIODE1POWERMONITOR     1.430            (0.090)
    H1:ALS-Y_LASER_HEAD_LASERDIODE2POWERMONITOR     1.588            (0.068)

As Sheila suggests, "It's not crazy that the diode current follows temperature, it's that the temperature has gone crazy over the past 20 days." However, one can see that this ALS X diode 2 current has been slowly increasing over the past 2 years, so we would have hit this threshold in a few months anyways.

For now, we'll keep the new ALS X threshold at 0.5 [A] (and leave the ALS Y threshold at 0.2 [A]).

Question: Is this OK?

The User Manual doesn't explicitly mention a limit on the diode current, but there are several mentions of a temperature controller in section 3.4 "Recommended Operation," and perhaps the most relevant is this statement in the trouble-shooting section:
    "Diagnosis: The temperature controller is not able to stabilize the diode laser temperature at the given value.
     
     Reaction: Try to increase the set temperature for the diode laser slightly using the trimmer at the front panel of the
     control electronics unit, especially if it is set below room temperature. Otherwise contact InnoLight GmbH."
Note the manual also suggests that these diodes are only under warranty for 6 months ;-).

Perhaps we should check the temperature settings on this diode? The other three diodes on site have been pretty insensitive to temperature over the past year, through and including the recent HVAC upgrade. I'll open an FRS ticket.