Marc P, Chris W

As per Work Permit #6104, we added a 200 kHz lowpass filter (D1600314) to the fast path of the Common Mode Servo Board (D040180), located in the LVEA ISC-R1 rack. The serial number of the servo board is S1102626.

When reconnecting the power to the Common Mode Servo Board, the 17V supply was connected first (should connect 24V first or use the sequencer), which resulted in blowing diodes D4 and D5 at the power input (see D0901846). At the time, we saw LEDs of other boards on the rack turning off. The diodes were replaced and the current drawn by the Common Mode Servo Board was confirmed to be the same as drawn by an equivalent spare board. The board was then replaced in ISC-R1 rack, this time using the sequencer switch to power cycle the whole rack.

After Daniel's h1ecac1plc1 code changes, I have installed the new INI file and restarted the DAQ.

Ramped CP4 LLCV in 5% increments, every 5 minutes, until it reached 100% full (39% to 63% open). 

Note:  generated alarm in CDS due to overfilling

Attached is a snap of the exhaust flow and pressure as LLCV ramped.

I lowered the fill set point from 92% to 88% and and will redo experiment once CP ramps down to 88%.

I've made a script to somewhat automate the weekly oplev trends FAMIS task. It makes 3 plots like the attached image of the oplev pit, yaw and sum channels for the test-masses, BS, PR3 and SR3. It still requires a little fiddling with the plot, you have to zoom in manually on any plots that have 1e9-like spikes, but this should still be easier than running dataviewer templates. It uses h1nds for data and a pre-release version of the python nds2 client that has gap handling, so updates in the future could break this. I'll try to maintain this script, so any changes or improvements should come to me. The script lives in the userapps/sys/h1/scripts folder.

The script is run by going to the sys/h1/scripts folder:

jim.warner@opsws0:~ 0$ cd /opt/rtcds/userapps/release/sys/h1/scripts

And running the oplev_trends.py script with python:

jim.warner@opsws0:scripts 0$ python oplev_trends.py

You will then need to do the usual zooming in on useful data, saving screen shots and posting to the alog. I'll look into automating more of this, but it works well enough for now. It would also be very easy to add this to a "Weeklies" tab on the sitemap, which I believe LLO has done with some similar tasks.
 

All vacuum pumping related connections are now removed from HAM5/HAM6

Darkham, Jeff, Jim, Dave:

h1susetm[x,y] models were restarted following changes to QUAD_MASTER.mdl.

Change is to replace DAQ DQ channel H1:SUS-ETMY_LKIN_P_LO_DQ with H1:SUS-ETMY_L3_CAL2_LINE_OUT_DQ and add an oscillator (H1:SUS-ETMY_L3_CAL2_LINE).

DAQ did not restart nicely. My change to add h1sysecatxxplcysdf INI and PAR files to daq master caused h1dc0 to stop on error "channel '' has bad DCU id 1024". I have removed these from the master and the DAQ is running.

PT-210b CC was not reading pressure, so I remotely rebooted.

[Sheila, Jenne]

This is starting to feel a bit like we're using popsicle sticks and duct tape to make a splint and hold things together, but we're still having trouble with the vertex ASC at high powers, so we have tried implementing a dither/ezcaservo combo loop for MICH pitch.  As of now, Sheila has a script that will turn on a dither line for BS pitch and set up the demodulators in the ADS.  The script then sets up a cdsutils ezca servo to move the offset of ASC-MICH_P to zero the output of the demodulator. 

Earlier, we tried just a regular dither servo, moving the BS to minimize the demodulated version of AS90, but that wasn't working.  Note that earlier today we removed the AS90 element from the SRM dither loop, so the SRM dither now only looks at POP90. 

Since adding MICH offsets worked okay over the weekend to fix the sideband buildup after the POP offsets are adjusted, we thought we'd give the demodulator-adjusted offsets a try. This is well after fixing the TCS situation described in alog 29237.

On at least one occasion, this new system didn't keep up with the IFO heating when starting the offset from zero, so now it starts the pit offset from the value that Sheila et al. found the other day.

We've tried it now with both BS pitch and yaw under this new additive-offset-like configuration, but the sideband buildups still seem to be decaying.  Perhaps SRM dither should go back to the AS/POP ratio, and BS should be servoed to maximize POP18?

Side note:  We have got to find time to re-look at the OMC ASC.  Engaging the dither loops once again rails the OMC suspension.  This was happening last summer, and then the problem somewhat mysteriously went away, so I don't have any magical solution right now.  But this certainly can't be good for our noise.

Jenne, Sheila

We had an unusual lockloss a few minutes ago, related to 28255

I happened around 8:11  August 23rd UTC, the DRMI gaurdian seemed to think that the lock was lost although it was not.

All Times Pacific Standard Time (PST):

• Took Observatory Mode to:  COMMISSIONING
• Commissioning work continued with ASC work at the beginning.
• Then moved on to high power work.
• 17:15  OMC/ISI trip (H1 had been at ~50W)
• 17:47  EX HEPI & ISI tripped (did not see any Pump Controller issues, so simply untripped WD).
• You will notice that L1 is on the board for the last 4+hrs with a range between 10-20Mpc---Woo Woo!!  :)

[Jenne, Sheila, Terra, Corey]

We've been having trouble with MICH ASC lately.  Sheila suggested that I double-check the TCS power settings, and in fact, the ITMX CO2 guardian is setting the laser to the wrong power. 

At 50W, we want TCS-CO2_X to be at 0.2W, and TCS-CO2_Y to be at 0.0W.  However, the guardian was taking both to 0.0W.  This is because the PSL_power_checker function inside of the TCS guardian has bad gain and offset values (I think).  This function calculates the desired TCS power based on the current PSL power, and the gain and offset values are defined separately for each CO2 laser.  This function wants to set the TCS-CO2_X power to 0.0W, and the TCS-CO2_Y power to -0.2W.  It has a check so that if it's trying to go to a negative power, just go to 0W, which is why both are being set to 0W.  At least for 50W, it seems that if we increase the offset values by 0.2W for each laser, we would be getting the power that we want.  However, I don't know that this will give us the correct CO2 power for any other PSL powers, so I am not changing it.  Someone from the TCS group should look into the calculation of CO2 power versus PSL power in the guardian, please.

After looking into things, I'm actually not sure why we were getting 0.2W for TCS-CO2_X.  It looks like the TCS guardian hasn't changed since its original checkin mid-May, and that it has always been calculating (using the PSL_power_checker function) that it should set TCS-CO2_X to 0.0W in the NOMINAL_LOCKED_CO2_LEVEL state, and that we've been requesting that state in the..... As I was typing, I realized why we weren't getting the wrong TCS powers.  Over the last few months, we've spent a lot of our time commissioining in the Increase_Power state for ISC_LOCK, where we had forgotten to comment out an explicit TCS power request from before we had the guardians.  The TCS guardians weren't requested to do anything until Coil_Drivers, the state after Increase_Power.  So, we were getting the TCS powers we wanted from the explicit request that should have been deleted, and weren't going to the wrong powers because we weren't advancing the ISC guardian. 

When Sheila shuffled a few guardian states over the last few days to make things more clear after we arrive at 50W, she put the TCS request in a state that we are now always going to, so that's why we've recently run into this.  For now, I've commented out the request for the TCS guardians to go to their "nominal" powers, and am leaving in the explicit request in Increase_Power.  Once Team TCS confirms the calculation of CO2 power versus PSL power, we can go back to using the TCS guardians.

Terra and I used the PI damping infrastructure to excite the butterfly and drumhead modes on EY, and then ring them down.

We excited the butterfly mode (6053.9 Hz) during a 50 W lock. The observed ringdown time was 23.5 minutes (= 1410 s), giving a Q of 27×10⁶.

We excited the drumhead mode (8158.0 Hz) during at 2 W lock. The observed ringdown time was 13.5 minutes (= 810 s), giving a Q of 20×10⁶.

The templates containing the spectrum data for these ringdowns live in my directory under Public/Templates/SUS/BodyModes.

TITLE: 08/22 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Corey
SHIFT SUMMARY: Lots of commissioning work ongoing.
LOG:

• 16:10 Kyle to LVEA to check progress from Friday
• 16:15 Marc to LVEA crimping a wire by BSC3
• 16:33 Kyle out
• 16:47 Marc out
• 22:13 Chandra to CP3

3:20pm local

34 sec. to overfill CP3 with 1/2 turn open on LLCV bypass valve

Overview

A synchronized oscillator was added to QUAD_MASTER model test mass stage (L3). After re-compiling the SUS-ETMY model there will be two synchronized ossilators in L3 stage that will be used for driving calibration lines: *_L3_CAL_LINE and *_L3_CAL2_LINE.

Removed channel LKIN_P_LO from the list of DQ channels and added L3_CAL2_LINE_OUT into the list.

The h1susetmy model must be recompiled in order for the changes to take effect.

Details

For one of the two calibration lines that we needed to run during ER9 we used a pitch dither oscillator, SUS-ETMY_LKIN_P (see LHO alog 28164). After analyzing the ER9 data we found two problems with this line (see LHO alog 29108):

• First, the drive amplitude that we set was not sufficient for estimation of the time-dependence in the ESD actuation strength.
• Second, the CAL-CS model that calculates the time-dependent parameters rely on an oscillator that is synchronized with the ones in the SUS-ETMY and CAL-PCALY models. Since SUS-ETMY_LKIN_P is not a fixed phase (synchronized) oscillator, the phases have to be adjusted by hand every time the oscillator gets restarted. With synchronized oscillators this is will not be necessary.

The second synchronized oscillator was added at L3_CAL2_LINE_OUT and the list of DQ channels was modified accordingly. The L3_CAL2_LINE_OUT was added with sampling rate 512 Hz. LKIN_P_LO was removed from the list of DQ channels.

The changes were commited to USERAPPS repository, rev. 14081.

HEPI BS Tripped few minutes before ITMX ISI.  This is the only HEPI that tripped in the neighborhood of the large quake.

ITMY ISI tripped--timing (H1:ISI-ITMY_ST2_WD_MON_GPS_TIME) indicates stage2 tripped on ACTuators 1 second before Stage1 on T240s but looking at the plots, the Actuators have only registered a few counts, nothing near saturation/trip level.  But the T240s hit their rail almost instantly.  It seems the Stage2 Last Trip (H1:ISI-ITMY_ST2_WD_MON_FIRSTTRIG_LATCH) should be indicating ST1WD rather than Actuator. On ETMY, the Trip Time is the same for the two stages and Stage2 notes it is an actuator trip but again, there are only a few counts on the MASTER DRIVE; seems this too should have been a ST1WD trip[ indication trip on Stage2--I'll look into the logic.

On the BS ISI, the Stage1 and Stage2 trip times are the same, and the Last Trip for Stage2 indicates ST1WD.  The Stage2 sensors are very rung up after the trip time but not before unlike the T240s which are ramping to to the rail a few seconds before trip.  ETMX shows this same logical pattern in the trip sequence indicators.

On the ITMX ISI, Stage1 Tripped 20 minutes before the last Stage2 trip. This indicates the Stage1 did not trip at the last Stage2 trip.

No HAM ISI Tripped on this EQ.

Bottom line: the logical output of the WDs are not consistent from this common model code--needs investigating. Maybe I should open an FRS...

Attachment 1) Trip plots showing Stage2 trip time 1 second before the stage1 trip where the stage2 actuators do not go anywhere near saturation levels.

Attachment 2) Dataviewer plot showing the EQ on the CS ground STS and the platform trip times indicated.