The IMC-I and the LSC-REFL_SERVO_CTRL readback channels have calibration factors in Hz, which need to account for the optical gain in the IMC REFL path. They were outdated even before the recent increase in optical gain. The new value is 4.4 times smaller than the previous calibration factor.

The REFL_SERVO_CTRL filter banks also contains a filter labeled aogain. This needs to be the exact same value as the IMC-REFL_SERVO_IN2GAIN. It has been changed to -22dB from -24dB.

Following PLC4 restart, its SDF also needed a restart.

TITLE: 05/09 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 111Mpc
INCOMING OPERATOR: Jeff
SHIFT SUMMARY:

Mostyly the type of shift we like to have.  H1 has been locked for 9+hrs.  However after the first 80min, we have had the AS36 oscillation and I was not able to run the script to change AS36 phases (see alog).  Other than that, nice and quiet evening
LOG:

7:16 ASC Oscillations are visible for LSC & ASC signals on Strip Tools; command to address this did not work (see alog for specifics).

Other than the ASC oscillation, smooth sailing for H1 with a range hovering just above 110Mpc and lock going on 5.5hrs (& currently 100+min of triple coincidence).

Oh, and also wanted to note NO DIAG_MAIN messages this whole shift (i.e. no messages for violin modes, HWS, ALSx polarization, etc.).

[Noticed this a few days ago and wasn't sure if this was always the case or not, but I'm pretty sure this is a new feature.]

In the LHO Control Room, on one of our wall monitors we have the BNS Range via a DMT viewer showing the last 24hrs.  Underneath it we have "H1 h(t) triggers, last hour (DMT Omega)"....and previously instead of DMT Omega, it was Omicron.  This "live" updating plot comes from the H1 Summary Page.  (attached is a screenshot of the entire Summary Page, BNS range, and also the H1 ISC_LOCK(12hrs) plot to compare to the BNS Range)

I remember it was nice to have this "last hour" tool up so we can take a look at how things were looking in real time for the last hour.  Tonight when I glanced up at it, I saw what looked like something strongly sweeping in frequency (attached is a screenshot of the DMT Omega screen w/ a sweeping feature, as well as screenshot showing both plots as they look on our wall in the Control Room).  Thought that was odd, so investigated.  Looks like the Summary Pages (where we get the DMT Omega trigger plot from) are posting  updates to a time 7hrs back in time.  So, the swept sine feature I saw was not something that happened in the last hour, it was something which happened 7-8hrs ago, and it is updating from 7hrs earlier in the day.  This makes more sense, because at that time there was commissioning/calibration work going on 7hrs ago.  Is this how the Summary Pages were intended to run?

I do remember these plots would update within a couple minutes of the current time (instead of 7hrs earlier) & this was something useful to glance at when sitting in the Control Room.  I think I noticed this a few days ago when I wanted to check on how H1 was doing from home by looking at the "H1 ISC_LOCK guardian, last 12hrs" plot (which is on the Summary Page which also has the DMT Omega trigger page mentioned above), and noticed that the most recent 7hrs were missing.

(Looking at the L1 Summary Page, I'm seeing the same 7-hr-in-the-past feature for them as well.)

At about 80min (7:16utc) into this current lock the ASC (mosty yaw) Oscillation began.  I got everything set up to run the command to change the phases (SDF window up to Accept changes, Observatory Mode to change mode, Intent Bit, AS36 window to watch phases, and a terminal to run the command).

From alogs, the most recent incarnation (alog 49116) of command to run that I found was:

z step H1:ASC-AS_A_RF36_SEG1_PHASE_R -1,28 H1:ASC-AS_A_RF36_SEG2_PHASE_R -1,28 H1:ASC-AS_A_RF36_SEG3_PHASE_R -1,28 H1:ASC-AS_A_RF36_SEG4_PHASE_R -1,28 -s 1

However, when I tried to run this step command, I received the following error:

corey.gray@zotws3:~$ z step H1:ASC-AS_A_RF36_SEG1_PHASE_R -1,28 H1:ASC-AS_A_RF36_SEG2_PHASE_R -1,28 H1:ASC-AS_A_RF36_SEG3_PHASE_R -1,28 H1:ASC-AS_A_RF36_SEG4_PHASE_R -1,28 -s 1
usage: step [-h] [-s time_step] [channel steps [channel steps ...]]
step: error: unrecognized arguments: -1,28 H1:ASC-AS_A_RF36_SEG2_PHASE_R -1,28 H1:ASC-AS_A_RF36_SEG3_PHASE_R -1,28 H1:ASC-AS_A_RF36_SEG4_PHASE_R -1,28

At first I thought it was a copy/paste issue, but no.  I'm guessing by the "unrecognized argument" it lists above, there is something wrong starting at the " -1", but that's a guess since I'm not familiar with this command (and I don't know where HELP about the "time_step" field resides).  I had run the previous command with no issues a couple of days ago; for comparison it was:

z step H1:ASC-AS_A_RF36_SEG1_PHASE_R +1,40 H1:ASC-AS_A_RF36_SEG2_PHASE_R +1,40 H1:ASC-AS_A_RF36_SEG3_PHASE_R +1,40 H1:ASC-AS_A_RF36_SEG4_PHASE_R +1,40 -s 1

I am stumped by the "[-s time_step]" because it looks like this should work!  The only difference between commands from last Thurs/today is the +/- signs.  Ugh!  Workaround thoughts (only thoughts):

• Could be a permission issue, so I logged in as controls, but had same error. 
• Try to run the command one quadrant at a time (but was scared to try that because maybe we want this change to happen to all quandrants in parallel, ASC world can be finicky).  
• Try running the original command from last week (but I assume we have this new command for a reason, so did not do this either)
• Wish we knew of a sandbox where I could play around with the step command to see what it does before running it on H1!

After the rough shift from last night while flying solo, and since the range/sensitivity has not taken a noticeable nosedive, I am deciding to live with our wiggly ASC/LSC signals with a ~2min period, and stay in OBSERVING.  If we have a lockloss, I will spend a few minutes tinkering around with this command to see what I'm missing.  If anyone reads this during my shift, and know what I'm missing, please give me a call to let me know what I'm missing so I can run it.  Apologies for not being able to run this.  I'm sure it's something basic. [Oh--I'm attaching a snapshot of where we currently stand with the AS36 R phases.]

TITLE: 05/09 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 112Mpc
OUTGOING OPERATOR: Niko
CURRENT ENVIRONMENT:
    Wind: 6mph Gusts, 5mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY:

Starting the evening with 67min of Triple Coincidence under our belt.  Beginning to faintly see the ASC yaw oscillation easier than a few minutes ago when Niko and I were talking about it (will address [after I check alogs for latest recommendation]  if it gets to big).  Nicely quiet seismically.  (Saw our coyote lingering around the parking lot as I pulled up)

TITLE: 05/07 Eve Shift 23:00 – 07:00 (16:00-00:00), all times posted in UTC

STATE of H1: Observing

INCOMING OPERATOR: Corey

SHIFT SUMMARY:  Started locked and then lost it after 5 hours due to a glitch that can be seen in ASC CSOFT/CHARD. After trouble relocking (constant OMC warnings from verbal alarms before lockloss), I did an initial alignment. Leaving it locked for an hour at 113 Mpc.

LOG:

23:00 (16:00) Start of shift

23:25 (16:25) Accepting negligibly small sfd changes in SUSSR2 and SUSHTTS to go into Observing

23:41 (16:41) GRB (E331770)

00:44 (17:44) Out of Observing for more CAL measurements

00:57 (17:57) Rick, Sundae to Optics Lab

01:07 (18:07) Rick, Sundae out of Optics Lab

02:09 (19:09) Accepting negligible SUSSR2 and SUSHTTS sdf changes, and accepting changes for raising the AS_A_RF36 phase by 10 degrees (see alog)

03:58 (20:58) Lockloss, verbal alarm said EX before it dropped out

04:36 (21:36) After two locklosses while acquiring DRMI, going into Initial Alignment

05:09 (22:09) Finished with Initial Alignment, starting to relock

06:06 (23:06) Locked, accepted sdf changes, going into Observing

07:00 (00:00) End of shift

Accepting the following changes to get into Observing after an initial alignment and relocking.

We have since lost lock, but here are the AS_A_RF36 sdf changes that were accepted before going into Observing at 02:09 UTC (19:09).

J. Kissel

As the title suggests, I used this week's calibration measurement time to gather some before & after thermalization measurements of the sensing function. Further, because Lilli saw improvement in the uncertainty in the response function around 50 Hz when using more actuator data (LHO aLOG 48968), I grabbed more actuator data. I'll process the data in due time, for now I just list where the data lives.

    ^/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs
        2019-05-08_H1_DARM_OLGTF_LF_SS_5to1100Hz_15min.xml     # During thermalization
        2019-05-08_H1_PCAL2DARMTF_LF_SS_5t1100Hz_10min.xml

        2019-05-09_H1_DARM_OLGTF_LF_SS_5to1100Hz_15min.xml     # After thermalization
        2019-05-09_H1_PCAL2DARMTF_LF_SS_5t1100Hz_10min.xml

    ^/trunk/Runs/O3/H1/Measurements/FullIFOActuationTFs
        2019-05-08_H1SUSETMX_L2_iEXC2DARM_8min.xml
        2019-05-08_H1SUSETMX_L2_PCAL2DARM_8min.xml 

        2019-05-08_H1SUSETMX_L3_iEXC2DARM_8min.xml
        2019-05-08_H1SUSETMX_L3_PCAL2DARM_8min.xml

As a sneak peak of the analysis, I attach a comparison between all previous sensing function data vs. the 2019-05-08, pre-thermalized data. You'll notice that the detuned spring frequency is quite low (~2.2 Hz), even lower than the 2019-05-02 measurement. However, Jenne and I noticed that we took the IFO out of observe about ~15 minutes in to nominal low noise, and the ADS loops (aka the spot positions on the TMs) had not yet converged. And looking at the past 45 minutes of power signals in the IFO (arm powers, POP power, SRC power, etc, the standard traces on the wall) after the measurement was complete, we saw a steady increase. Once we went back to nominal low noise to let it thermalize for an ~hour, the ADS lines came back on, finished converging, and the power signals dropped a bit.
Our guess is that because of the changes in SR3 disc heater power, the "best" spot position may not be the best any more, and revisiting the spot positions for this new cavity mode may be beneficial.

Gerardo M., Kyle R.

Both channels (a.k.a. pumps A and B) of the newly arrived reconditioned 2500 l/s ion pump (s/n tbd) tested good -> 10-11 torr after a few minutes.  Stopped long term testing of preceeding 2500 l/s ion pump. 

With the lower noise seen in CARM, we can now see clear coherence of some higher frequency lines with DARM. The frequencies are centered at 556, 574, 835, 860, 1115 and 1148 Hz, but are not very high Q. The third set of twin lines looks like a straight harmonics of the first set, whereas the second set is 1.5 times the frequencies of the first set. This would indicate fundamentals at 278 and 287 Hz, which are barely visible. There is also a small indication of the 5th harmonics at 1393 and 1435 Hz.

 The multi-mode misery of the squeezer laser continues. 22 days ago the laser was adjusted and it looked reasonable for a few days with 45-50mW green output. Now it seems to vary between 35 and 45mW. At 40mW and below the power stabilization circuit is running out of range and rails the actuator.

It was reported that we cannot lock the squeezer laser when the noise eater is turned off. This is simply due to the fact that the auto-locker stops when there is an apparent error in the laser, and the current laser screen expects the noise eater to be on. Added a new nominal state for the noise eater relay that should take care of this problem in the future. It requires the new Beckhoff code to be activated first.