Rotation stage is disabled at 2W input power to the IMC.

Of course, the shutter is closed, so there is no beam from the PSL into the vacuum system.

We closed the shutter for two laser beam pipes between PSL and HAM1.

Lexan plates were installed on all HAM6 viewports. Yellow covers were installed on these viewports except one. For the remaining one, Gerardo will find and install one later).

Cable connections were documented and photographed, and all cables were disconnected from the table.

The accelerometer cable on HAM6 North door was disconnected fron the accelerometer and was taped on HAM5 North door. But the accelerometer itself is still on HAM6 North door.

ISCT6 was moved out of the way.

Took 12 sec. to overfill CP3 until LN2 poured out exhaust, with 1/2 turn open on LLCV bypass valve.

Lowered CP3 LLCV from 18% to 17%.

Chandra, Gerardo, Kyle

Added ~ 2 Qts Turbine oil.  Routing output to LVEA

In order to move ISCT6, the lightpipe from the PSL needed to be closed.

Jenne closed it and locked it closed - it should remain until after the HAM6 vent.

• The arms were locking in green with buildups of 1.06.
• The IMC was locking well and had been locked at 2W for about 12 hours.
• IR power in TR_X(Y)_NORM_OUT was flashing, though no locking in IR was attempted

Hugh did a lot of work over the last few weeks diagnosing the ITMX ISI, with respect to it tripping earlier than the other platforms during an earthquake. His fix last week seems to have worked, at least for the earthquake Friday. First 2 attached plots are the ST1 WD Triggers (the ISI has tripped when the trigger /= 0, first plot shows the triggers separately, second is all on the same plot) , and ITMX, ITMY and ETMX all trip at roughly the same time. ETMY and the BS trip several minutes later, but they were in different configurations (BS is always Isolated_Damped, ETMY had it's sensor correction turned off). This was a large earthquake that came up quickly (third plot shows ETMY Z STS 30-100 mhz BLRMS and ITMX WD trigger) , but for now it looks like ITMX is behaving like the other platforms.

The following is a short calculation of the ITM lensing estimates for O1 for the recycling cavities based on the measurements from the HWS.

WP 6022

I have updated the PI models (28462) in order to accommodate four excitation paths for test mass' drum head modes. The h1omcpi and h1susprocpi models will be restarted tomorrow. The modification will be used

1. as a part of the OMC beacon (or deacon) dither alignment control, and
2. as a part of study on the mobility of test mass's mechanical modes.

This update actually involves not only h1omcpi and h1susprocpi models but also h1omc. However, in light of the upcoming in-vac activity with the OMC, we will hold off the update on h1omc so that we can recover the interferometer with least confusion. The update on h1omc will go in some time later once we recover the interferometer.

[eLIGO amplitude locked loop]

Here is a screenshot of the digital amplitude locked loop of a drum head mode that had been used in eLIGO.

This algorithm is imported to the current PI models. One update we might additionally implement in some future is a clock recovery with iWave instead of the clipping-based clock recovery.

[Modification on h1omcpi]

h1omcpi has one update i.e., normalization of the OMC DC signals.

I modified one of the down conversion channels, chan 8, to have a normalization using the OMC DCPD SUM. It is show in the orange-shaded region. This signal is sent to the susprocpi model and processed to generate feedback signals for the test masses.

[Modification on h1susprocpi]

Here is a screenshot of the top level of h1susprocpi in which a parallel excitation block for the drum head modes (a pruple block at the bottom) are shown.

This block contains four identical amplitude locked loop for generating excitation signals. The feedback outputs (shown as yellow tags) are summed on the right hand side of the output matrix so that they are sent to the test mases to excite the drum head modes. Also the rms information of a selected mode will be sent back to h1omc through an PCIe communication so that it can be used as a beacon alignment error signal. The contents of the purple block look like this:

As seen in the upper right, one can select which mode to use for the OMC alignment. The red blocks on the left hand side contain the function blocks as seen in the following screenshot.

The amplitude error signal is generated by a combination of an Abs block and lowpass filter. Then it is fed back to the output of the clock generator (which is based on the clipping technique as was done in eLIGO). The bandpass filter on the left allows one for selecting a mode out of the four modes. In addition, we placed an iWave block so that we can read out the frequency directly. A future expasion would be to use the output of the iWave block to generate the clock or sinusoidal excitation signal instead of the clipping-based one.

The Problem: The SEI configuration nodes have been in error since Friday at 2:58 local due to a bug in the WD decorators, and a bit of oversight by the one who coded that part (me). The regular SEI guardian nodes were tripped and then someone requested the config nodes to change, but these config nodes were not designed to be changed when everything was tripped. The decorator that caused the isse is just copied code and so it tried to jump to a state that didn't exist. Glad this was found before O2.

The Fix: removed all of the decorators that check on WD's, isolation, and damping of the regular nodes. Jim W and I talked and decided that it wasn't really necessary for the config nodes to even have to watch that, so lets lose them. Changing the config states while it is tripped or isolating was thought to maybe be an issue before, but doesnt seem to pose a problem anymore.

• top left - SEI_HAM6 guardian manager - PAUSED
• middle left - ISI_HAM6 guardian - HIGH_ISOLATED now - hopes to keep it in DAMPED tomorrow (when not locked)
• bottom left - HPI_HAM6 guardian - in READY, since it's locked
• top righ - HAM6 ISI
• bottom right - HAM6 HEPI

Status:  Discussed smoke from nearby fires.  DetChar F2F starts this morning.  HAM6 vent plan for the week--most likely crack bolts on HAM6 on Tues, BUT we will only start this work when we confirm no dust/smoke issues in the LVEA.

Due to upcoming vent work, we did not go through status of the SEI & ISI.

Bake RGA at end station might start today (Kyle)

HAM6 ISI:  should be isolated or atleast damped (see Hugh)

For Tuesday Maintenance:  Timing work and PI model work were mentioned as primary tasks.  PSL work will cover Mon/Tues per work permit.

For any tours, please remember to fill out a work permit & check with the operator as to whether it is OK (if there is active work in an open chamber we may want to limit tours at that time.)

Visitors This Week:  DetChar people, visitors from China (Fred), KAGRA visitors for PCal (Kiwamu), Krishna/Micahel from UofWA (Hugh)

Attached are trends of the LVEA Dust Monitors.  

• Dust Monitor #6 is in the HAM6 Cleanroom
• Dust Monitor #10 is in the Beer Garden

On the 24hr trend, there was a little bit of dust in the LVEA between 8am-1pm, but in the cleanroom, were have been near zero for the last 24 hrs.

On the 4-day trend, the only dust in the HAM6 cleanroom was from technical cleaning on Friday.

Jeff is going to take some more readings outside.

Terra, Evan, Stefan

With the spot move script from last alog we could reliably maximize the recycling gain. We reached 30 (as measured by LSC-PR_GAIN - Evan claims this is more like 35).

The instability in AS90 could be removed by manually aligning the SRM - but POP18 got worse when doing so.

Interestingly - the same move that fixes the recycling gain at 50W, has almost no impact on the recycling gain at 2W.

For reference, the last lock loss was at about 6:15 UTC on Aug 1st.

We had to adjust the soft loop gains to

            ezca['ASC-DSOFT_P_GAIN'] = 0.5 # 3 killed it
            ezca['ASC-DSOFT_Y_GAIN'] = 3  # oscillates at lower UGF when much lower
            ezca['ASC-CSOFT_P_GAIN'] = 0.5 # designed differently
            ezca['ASC-CSOFT_Y_GAIN'] = 3  # oscillates at lower UGF when much lower
 

State of H1: earthquake, unlocked, ISC_LOCK set to Down, IMC_LOCK set to Offline

Activities:

• HAM6 vent prep
• EY ion pump power supply issues - update: power supply is off for the weekend
• EY leak testing

Since EQ:

• 21:50UTC - Gerardo to EX - and back at 22:35UTC
• 22:00UTC - Marc in LVEA - at HAM5/6 terminating cables - out as of 4:10PM PT
• 22:40UTC - Jenne/David in LVEA - looking for Marc - out as of 4:10PM PT
• 22:42UTC - RichA/guest in LVEA - prep for filming in the LVEA tomorrow - still in LVEA

The OMC alignment servos keep turning on, even though the OMC guardian is paused.  I found that it gets turned on in engage_wfs_centering whenever we do any ASC since it's in a generate states function.  So, I have commented out that line, but we must uncomment it when we have the OMC back and are ready to use it again.  It is currently line 113 in ISC_GEN_STATES.