It looks like about 20 minutes after the increase in TCSY from 0 to 0.4W the range started to drop and continued until lock loss. Plot attached.

Set to 2 seconds and saved in SDF.

11:23UTC, changed TCSY from 0W to 0.4W, TCSX was at 0.2W and remains at 0.2W, next change in about 90 minutes.

State of H1: Nominal Low Noise

Activities that will contnue:

• changing TCS
• testing roll mode damping change that was good for ITMX, may or may not be good for the rest of the optics
• possibly work on violin modes and 2nd harmonic

I did a few more things tonight

• Turned off LP80 in SRCL, this reduces the gain peaking in that loop from almost 5dB to 2dB.  The second attached screen shot shows the control signal, the orginal configuration (with LP80) is the blue reference, the green reference is with the LP120 that I added to SRCL2, and the red trace is with only the 200Hz cheby low pass on.  Since SRCL noise doesn't bother us at 100Hz, it seems OK to add some noise there to reduce the control signal at 40 Hz.  (I've removed LP80 from the guardian)
• I also did a little bit of SRCL FF tuning, I used the old FF filter which is not as good as Jenne's JFF from september, but lets us split the FF into high and low frequency parts to adjust the gains seprately.  The third attachement shows the marginal improvement this made, but Jenne's new and improved filter will probably be better. After this I ran A2L, there was a bit of coherence (0.2 ish) from 20-30 Hz with CHARD Y, so we can probably puch the gain in that loop down and make the low passing more aggresive. 
• The remaining noise in DARM from 40-20 Hz was not very stationary after these small changes, but slightly better than where it was at the start of the lock. 
• Next I tried a little bit of driving the compensation plate while watching the camera.  I ended up drive 600 counts into RO DAMP L at 0.1 Hz for ITMX, the second to last attachment shows the 4 fringe wrapping shelves that show up with our nominal alingment of no offsets.  I could change offsets and make some shelves larger while other shelves got smaller.  A compromise position was -93 urad P, no Y offset, which is shown in the red trace. I wasn't able to see anything convincing in the SRM/SR3 camera.
• After Cheryl relocked the IFO (I caused the lockloss), I did a similar excitation on ITMY CP, and different noise in DARM.  For CPY only 100 counts excitation was needed to see noise in DARM up to 100Hz.  Cheryl and I watched the cameras, and might have seen something that was related to moving the CP.  We were able to steer the CP to reduce the noise in DARM while we were driving it, but it seems to make no difference to DARM when we aren't driving.

Now that we have the DBB plugged in again, we can relook at the coherences of the QPDs.  The screenshot shows coherences for DARM and SRCL with for the 200W beam (opening the 35W shutter unlocks the IFO).

We have small coherences with DARM just below 1kHz and around 4.2kHz, but not otherwise.  SRCL does have more coherence with one of the QPDs below 100Hz.

I think that the nominal setting of the CAL-PINJX_TRANSIENT filter bank gain is supposed to be zero. When a transient injection is imminent, then the gain is ramped to 1.0, the injection happens, and then the gain is ramped to zero. However, the SDF safe set point is 1.0. Therefore, I am setting the gain to 0 and accepting the change in the SDF safe file.

Jeff B, Cheryl, Travis and Kiwamu,

In the past two days, Jeff, Cheryl and Travis performed a random walk on the CO2 settings for me (30920 and comments therein). I don't see significant change so far. In fact, it might have deteriorated the jitter peaks slightly.

I now ask the operators to perform differential scans instead (e.g. raising only one CO2 at a time).

The motivation was to see if we can exert any kind of effects on the jitter peaks in 200-1000Hz by changing the CO2 settings. Because TCS measurements usually take a long time, I have asked the operators to do some random walk on the TCS settings when possible. So far we have done a common scan (i.e. raising both CO2 powers simultaneously) and I don't see big change in the jitter peaks in 200-1000 Hz, in particular the ones at 285, 365 and 620 Hz. The attached shows DARM spectra with different CO2 settings.

These curves correspond to the following time.

• ref 0: 27/10/2016 9:40:00 UTC
• ref 1: 27/10/2016 11:30:00 UTC
• ref 2: 27/10/2016 17:00:00 UTC
• ref 3: 28/10/2016 11:30:00 UTC
• ref 4: 28/10/2016 13:00:00 UTC
• live: 28/10/2016 15:30:00 UTC

As you can see, the ambient noise (most of the time appears to be shot noise) varies depending on the time because some of them overlapped with the active injection tests by Robert. But, this is not something I am looking for. Among the 6 noise curves, the best jitter noise was obtained from 27/10/2016 9:40:00 UTC which is actually before the series of CO2 tests started. So it is possible that the common CO2 may have deteriorated the jitter peaks slightly. We should do a differential scan next.

J. Kissel, B. Weaver

Betsy grabbed charge measurements yesterday. I've processed them. The charge is still right around 0 [V] effective bias -- we're ready for regular bias flipping. 

Summary- the sensing sign in the online calibration for SRCL has been wrong.

This has been causing overestimated noise in 10 - 100 Hz in the past years(!). My bad. This is now fixed.

Details- Daniel and Stefan a week or two ago told me that changing the shape of the digital filter in SRCL affected the calibrated SRCL displacement spectrum. This statement made me suspect that something was wrong in the online calibration or aka CALCS. Today, I have re-measured the SRCL open loop gain in nominal low noise with an input power of 25 W. A plot of the open loop is attached in this etnry. The absolute value of the SRCL sensing was found to be the same. However, the measurement indicated that the sensing gain should be a negative number (dP/dL < 0 or smaller counts as the SRC length expands). This contradicted with what we have had in CALCS where the sensing was set to positive. This is very simillar to what we had in the online DARM calibration (29860), but this time SRCL has been wrong for years.

Flipping the sensing gain in CALCS (so as to match the sign with the measurement) decreased the noise level in the online monitor by a factor of 2 at 60 Hz in 10 - 100 Hz. You can see the difference below.

The cyan is before the sign flip in CALCS, and the green is after. In order to double check the validity, I produced the calibrated spectrum only using SRCL_IN1 (blue) which agreed with the online calibration. There is small discrepancies between SRCL_IN1 and CAL-CS by a few % which, I believe, is due to the fact that we don't take the time delay of the system into account in CAL-CS. The sign flip is now implemented by adding a minus sign in FM1 of CAL-CS_SUM_SRCL_ERR (which is now a scaler value of -9.55e-6). I did not change the absolute value.

Additionally, I looked at some calibration codes that I made some time ago (18742) and confirmed that I mistakenly canceled the minus sign in the sensing gain of the model. Also, according to the guardian code ISC_LOCK and trend data, the sign of the SRCL servo gain in LSC or the relevant filters in the SUS SRM did not change at least in this past year. I am fairly sure that this calibration has been wrong for quite some time.

The relevant items can be found at the following locations.

Open loop measurement: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Measurements/LscDrmi/SRCL_oltf_25W_20161028.xml

Open loop analysis code: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Scripts/LscDrmi/H1SRCL_OLTFmodel_20161028.m

Plots for open loop: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Results/LscDrmi/2016-10-28_SRCL_openloop.pdf

                /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER10/H1/Results/LscDrmi/2016-10-28_SRCL_openloop.png

J. Kissel

With hints of improvement last night from Sheila (see LHO aLOG 30947) on reducing the most egregious ~41 Hz peak in DARM (which is known to be the HSTS roll modes, a.k.a R3), I launched a campaign of adding similar ~1 Hz wide notches to all HSTS suspensions' local damping loops (M1_DAMP) at both the highest roll mode and highest vertical modes (a.k.a V3 at ~27.5 Hz).

The filter designs are
V3 notch: FM8 "SB27.5" ellip("BandStop",4,1,60,27.05,28.05)gain(1.12202)   [Input -- Always On; Output -- Ramp; Ramp Time -- 2 sec]
R3 notch: FM9 "SB40.9" ellip("BandStop",4,1,60,40.4,41.3)gain(1.12202)     [Input -- Always On; Output -- Ramp; Ramp Time -- 2 sec]
where I've made sure that the lowest and highest frequency V3 modes (coincidentally both IMC mirrors: MC1 @ 27.38 Hz, MC2 @ 27.74 Hz) faLL within the stop band of the notch (and I've confirmed that this is true with Sheila's R3 notch design as well). Further, the V3 notch causes a phase loss of only 2.2 [deg] at 10 Hz, so it will not impact any of the damping loop's phase margins. To confirm, I've spot checked SR2's local damping open loop gain tfs just to be sure. Indeed all DOFs are still quite stable (and quite poorly tuned, as expected).

During the campaign I found that PRM, MC1, and MC3's "ellip50" standard low-pass filters were not engaged, so I engaged them.

I've greened up all ODC status lights, and then accepted all of the changes in the SDF system -- V3 filters ON, R3 filters ON, ellip50 filters ON, and Correct Damp State.

While haven't had an uber-long lock stretch since I've turned on all of these notches, I was at least able to grab 5 averages of a 5 [mHz] BW ASD and compare against the long data set from last night. The notches appear to have done their job -- a large fraction of the modes have been squashed and don't show up in DARM anymore. Success! 

The SR2 damping loop open loop gain TF templates have been committed here:
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SR2/SAGM1/Data/
2016-10-28_2223_H1SUSSR2_M1_openloop_L_WhiteNoise.xml
2016-10-28_2223_H1SUSSR2_M1_openloop_P_WhiteNoise.xml
2016-10-28_2223_H1SUSSR2_M1_openloop_R_WhiteNoise.xml
2016-10-28_2223_H1SUSSR2_M1_openloop_T_WhiteNoise.xml
2016-10-28_2223_H1SUSSR2_M1_openloop_V_WhiteNoise.xml
2016-10-28_2223_H1SUSSR2_M1_openloop_Y_WhiteNoise.xml

model restarts logged for Thu 27/Oct/2016
2016_10_27 10:30 h1psliss
2016_10_27 10:32 h1broadcast0
2016_10_27 10:32 h1dc0
2016_10_27 10:32 h1fw0
2016_10_27 10:32 h1fw1
2016_10_27 10:32 h1fw2
2016_10_27 10:32 h1nds0
2016_10_27 10:32 h1nds1
2016_10_27 10:32 h1tw0
2016_10_27 10:32 h1tw1

Daniel's ISS model change with associated DAQ restart.

model restarts logged for Wed 26/Oct/2016
2016_10_26 00:26 h1fw2
2016_10_26 06:36 h1fw2
2016_10_26 08:21 h1fw2
2016_10_26 12:14 h1fw2
2016_10_26 12:32 h1fw2
2016_10_26 12:38 h1fw2
2016_10_26 13:44 h1fw2
2016_10_26 16:45 h1susetmx

Jonathan's daqd work on fw2. Jeff restarted susetmx as part of BIO investigation.

model restarts logged for Tue 25/Oct/2016
2016_10_25 08:23 h1sushtts
2016_10_25 08:38 h1susmc1
2016_10_25 08:38 h1susmc3
2016_10_25 08:38 h1susprm
2016_10_25 08:39 h1suspr3
2016_10_25 08:40 h1susim
2016_10_25 08:48 h1susmc2
2016_10_25 08:48 h1suspr2
2016_10_25 08:48 h1sussr2
2016_10_25 08:57 h1sussrm
2016_10_25 08:59 h1susomc
2016_10_25 08:59 h1sussr3
2016_10_25 09:10 h1susbs
2016_10_25 09:10 h1susitmx
2016_10_25 09:10 h1susitmy
2016_10_25 09:18 h1susauxasc0
2016_10_25 09:20 h1susauxh2
2016_10_25 09:20 h1susauxh34
2016_10_25 09:20 h1susauxh56
2016_10_25 09:22 h1susauxb123
2016_10_25 09:33 h1susetmx
2016_10_25 09:35 h1sustmsx
2016_10_25 09:37 h1susetmy
2016_10_25 09:37 h1sustmsy
2016_10_25 09:40 h1susauxex
2016_10_25 09:41 h1susauxey
2016_10_25 10:23 h1alsey
2016_10_25 10:23 h1caley
2016_10_25 10:23 h1iopiscey
2016_10_25 10:23 h1iscey
2016_10_25 10:23 h1pemey
2016_10_25 10:28 h1broadcast0
2016_10_25 10:28 h1dc0
2016_10_25 10:28 h1fw0
2016_10_25 10:28 h1fw1
2016_10_25 10:28 h1fw2
2016_10_25 10:28 h1nds0
2016_10_25 10:28 h1nds1
2016_10_25 10:28 h1tw1
2016_10_25 11:58 h1iopiscex
2016_10_25 11:58 h1pemex
2016_10_25 12:00 h1alsex
2016_10_25 12:00 h1calex
2016_10_25 12:00 h1iscex
2016_10_25 12:02 h1fw2
2016_10_25 12:10 h1fw2
2016_10_25 12:27 h1fw2
2016_10_25 12:28 h1fw2
2016_10_25 12:32 h1fw2
2016_10_25 13:52 h1fw2
2016_10_25 13:56 h1fw2

Tuesday maintenance. All SUS DAQ configurations changed. Unexpected restarts of h1iscey and h1iscex, related to powering of test equipment. Jonathan's daqd testing on fw2.

TITLE: 10/28 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: Jim
SHIFT SUMMARY:  Walked in to a locked IFO.  It broke lock shortly thereafter, possibly due to PEM injections.  After a bit of a prolonged IA, we have been back at NLN for the last half of the day.
LOG:

15:13 Robert to LVEA

15:15 Chris to MX

15:57 Chandra to EX

16:15 Chandra back

16:19 Kiwamu to LVEA for ISS OLTF

16:20 Betsy, Bubba to LVEA

16:36 Betsy, Bubba out

16:37 Kiwamu done

17:30 Adjusted fiber polarization for both arms

18:48 Richard down the Xarm BTE

21:26 Chandra to MY
 

2:30 pm local

Took 24 sec. to overfill CP3 by doubling LLCV to 36% open. TC plot attached.

Kiwamu saked the ops to run some TCS laser noise measurements.

SETUP:

• After IFO is locked at NLN for at least 30 minutes
• Open TCS_MASTER screen
• Open the CO2 X & Y screens
• Open the POWER CONTROLS screens for X & Y
• increase the power by 0.1W
• Wait 90 minutes, and increase the power by another 0.1W
• Repeat until at about 2W
• aLOG the times and power levels

Started the run: 

    TSC X - Initial Power = 0.2W                     TSC Y - Initial Power = 0.0W

At 05:08 Lost lock due to a Mag5.8 EQ in Alaska.

The results of cdsutils.avg() in guardian is sometimes giving us very weird values. 

We use this function to measure the offset value of the trans QPDs in Prep_TR_CARM.  At one point, the result of the average gave the same (wrong) value for both the X and Y QPDs, to within 9 decimal places (right side of screenshot, about halfway down).  Obviously this isn't right, but the fact that the values are identical will hopefully help track down what happened.

The next lock, it correctly got a value for the TransX (left side of screenshot, about halfway down), but didn't write a value for the TransY QPD, which indicates that it was trying to write the exact same value that was already there (epics writes aren't logged if they don't change the value). 

So, why did 3 different cdsutils averages all return a value of 751.242126465?

This isn't the first time that this has happened.  Stefan recalls at least one time from over the weekend, and I know Cheryl and I found this sometime last week. 

Ed, Sheila

Are ezca connection errors becoming more frequent?  Ed has had two in the last hour or so, one of which contributed to a lockloss (ISC_DRMI).

The first one was from ISC_LOCK, the screenshot is attached. 

J. Kissel, for the Calibration Team

I've updated the results from LHO aLOG 21825 and G1501223 with an ASD from the current lock stretch, such that I could display the computed time dependent correction factors, which have recently been cleared of systematics (LHO aLOG 22056), sign errors (LHO aLOG 21601), and bugs yesterday (22090). 

I'm happy to say, that not only does the ASD *without* time dependent corrections still fall happily within the required 10%, but if one eye-balls the time-dependent corrections and how they would be applied at each of the respective calibration line frequencies, they make sense.

To look at all relevant plots (probably only interesting to calibrators and their reviewers), look at the first pdf attachment. The second and third .pdfs are the money plots, and the text files are a raw ascii dump of respective curves so you can plot them however or whereever you like. All of these files are identical to what is in G1501223.

This analysis and plots have been made by
/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O1/H1/Scripts/produceofficialstrainasds_O1.m
which has been committed to the svn.