Plot 1 shows the ASC coherence during an imperfect A2L strech this morning. this resulted in a power-law increase in DARM below 60Hz.

We designed slightly more agressive cut-off filters for DHARD_P, CHARD_P and CHAD_Y. They , take the ASC signal below other noise above ~35Hz, even if the A2L tuning runs away a bit.

Plot 2 shows the the new (sold) and old (dashed) drive levels of the ASC.

The new filters were integrated with the ELP10 filters for DHARD_P and CHARD_P (FM4 and FM2 respectively). For CHARD_Y I copied the cut-off filter from FM9 to FM3 before modifying it in FM3. This preserves the old 40W cut-off filter. I switched Guardian over to use FM3. The new filter uses less than 7deg extra phase at the UGF. The last 50W transfer function measurment suggest that we have about 60deg at the UGF, so the filter should also work at 50W.

The ISC guardian was again checked into SVN after the modification.

Rick S, Sudarshan K, Travis S, Jeff K, Darkhan T,

We uploaded the updated force coefficients (N/V) into the PcalY filter file. This has effect on following calibrated outputs:

H1:CAL-PCALY_TX_PD_OUT*
H1:CAL-PCALY_RX_PD_OUT*

Calculation of the factors is described in T1600520-v1. Relevant sources (other T documents containing WS, GS and end-station calibrations) were referenced in that document. The Matlab script that produced the factors is attached to the document above and also can be found in CalSVN (or a newer version of the script in the same directory):

https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/scripts/pcalEndstation/pcalForcecoefficient.m

The old and new values are listed below:

• TxPD: old value 1.515^-9 N/V, new value 1.516^-9 N/V, changed by 0.07%.
• RxPD: old value 1.049^-9 N/V, new value 1.0475^-9 N/V, changed by 0.14%.

One can notice that these values are nearly identical, which is a mere coincidence. We consider PCALY is now in a new epoch w.r.t. O1 time because we adjusted beam positions on the ETM (also addressed clipping at RxPD integrating sphere) and we adjusted the angle of the transmitter module beamsplitter which adjusts the power balance between the two beams (see LHO alog 30877).

• 16:24 Intent Bit was dropped to Commissioning.  Asked around the Control Room & no one confessed.  Hugh was working on SDF stuff but we don't think it was that.  I could have sworn I saw a PEM_MX excitation Message on the DIAG_EXC by chance.  Looking at the DIAG_EXC node's log, I see there is a mention of:  "EXC:  pemmx excitation!" at 16:24:09 & 16:25:37.  What is this??
• 17:36 Out Of Observing for A2Ls
• Went in/out of Observing whenever available...don't want to list every time.
• 18:15  Input Beam Pointing test (Kiwamu)
• 18:30 TCS Settings test (Kiwamu)
• Looked at ETMx 2nd Harmonic violin modes
• 21:34 Hanford Fire going to EY to check RAFAR alarm
• 22:46 LOCKLOSS! (after 15hr30min lock)----> Possibly a 5.6mag Indonesia earthquake which Terramon said would arrive a few minutes earlier than our lockloss time.  (L1 also dropped out...as predicted by Terramon.
• 22:50 Hugh addressed SDF DOWN snapshots (mainly for SDF nodes in the "LSC Column" on the SDF Overview.
• 23:07 CP3 fill (Chandra)
• 23:58 Made it back to NLN after 2nd attempt & handing over to Nutsinee.  She is going to run the A2L for this lock.

3:30 pm local

Took 75 seconds to overfill CP3 by increasing LLCV from 20% open to 50% open. Attached is 1 hr plot in seconds showing TC temp fall, and the last several fills.

From Stefan's offline request, I ran bruco on two times,

Nov. 07, 2016, 19:30:00 (GPS time : 1162582217):

on DARM:  https://ldas-jobs.ligo-wa.caltech.edu/~youngmin/BruCo/PRE-ER10/H1/Nov07/H1-DARM-1162582217-600/

on MICH: https://ldas-jobs.ligo-wa.caltech.edu/~youngmin/BruCo/PRE-ER10/H1/Nov07/H1-MICH-1162582217-600/

on PRCL: https://ldas-jobs.ligo-wa.caltech.edu/~youngmin/BruCo/PRE-ER10/H1/Nov07/H1-PRCL-1162582217-600/

on SRCL: https://ldas-jobs.ligo-wa.caltech.edu/~youngmin/BruCo/PRE-ER10/H1/Nov07/H1-SRCL-1162582217-600/

Nov. 07, 2016, 16:30:00 (GPS time : 1162571417):

on DARM: https://ldas-jobs.ligo-wa.caltech.edu/~youngmin/BruCo/PRE-ER10/H1/Nov07/H1-DARM-1162571417-600/

The PMC length noise no longer shows up in DARM. Even for the 1 kHz and 4 kHz peaks there is a factor of a few safety margin. Increasing the PMC gain slider from 0 dB to 16 dB (actually from 0 dB to 12 dB), we see no significant change in DARM. The 4 kHz peak starts touching the noise floor with a 0.3 coherence.

Readjusted the REFSIGNAL (diffraction power) and AC offset for the ISS second loop. New values in SDF (down).

Sheila has mentioned Operators should take a look at squashing down some of the 2nd Harmonics of the Violin Modes.  Using Nutsinee's procedure, I went about taking a First Look.   Attached you will see a power spectrum during our current 10+hr lock.  On here we get the following which are above a 10/23/16 reference:  (freq & wiki notes)

• 1003.78 (ETMx, No Filter Bank Mode?)
• 1005.94 (ETMx, No Filter Bank Mode?)
• 1009.44 (ETMy, Mode10)
• 1009.48 (ETMy, Mode10)

Decided to look at ETMx's 1005.94.  On its Damping Filter medm, we had a filter bank already set up for this:  MODE10.

1005.94Hz

• MODE10
• Gain:  -200  (this is a change)
• -60deg (no change)
• 100dB (no change)
• FM7 (1005.938) (change)

This squashed this line.  This has been entered in the Violin Mode wiki.

Addressed the next biggest line of 1003.78 for ETMx.  This is taken care of in MODE9.  A positive gain rung it up, so tried some negative gains which was fine.  Then I tweaked phase from -60deg and went to 0deg.  This was fine.  Unfortunately, when I tried a gain of +60deg, this rung it up.  And it looks like it excited the neighboring line of 1003.667.   I've been trying to now damp out the latter (1003.667), but it is going reeeealllly slow.

Since I wasn't successful with the 1005.94, I will not make a note of what I attempted and won't update the wiki.

Repeating the same idea as we did for frequency noise in aLog  31176
we measured the sensitivity of REFL_A_RF45_I, POP_A_RF9_I and POP_A_RF45_I to PRC length noise, and then used this transfer function to project the noise into DARM.
(REFL_A_RF9_I is used for the CARM loop -so there is no interesting signal there.)

Around 40Hz the three projections basically agree, and are a factor of 2 below the noise floor. Also, it seems that REFL_A_RF45_I would actually have a lower noise floor than POP_A_RF45_I. We should consider using it for PRCL.

FInally, we should implement a PRCL_feed-forward path.

The templates for the measurment are here:

/ligo/home/controls/sballmer/20161107/PRCLNoiseProjection.xml
/ligo/home/controls/sballmer/20161107/REFLPOPV4.xml
 

J. Kissel, D. Tuyenbayev

Following preliminary results from Darkhan on the individual actuation strength of the UIM and PUM stages for H1SUSETMY (see, thus far LHO aLOG 31275), and the current delightfully long lock stretch with them in place, I'm bringing this study to a close. I've turned off the temporary L1 and L2 calibration lines at 33.7 and 34.7 Hz, respectively. We do not intend on turning on these lines again for the duration of the run.

These lines were turned OFF at Nov 07 2016 21:21:49 UTC.

J. Kissel

While opening the PCALX overview screen in hopes of moving around the roaming high-frequency PCALX calibration line, I found the OFS railed. A trend shows that it had been railed since 2016-11-01 at 19:04 UTC, just after maintenance day. Regrettably, due to our problems getting the IFO back up after last Tuesday’s maintenance (see LHO aLOG 31119), that means we did not getting any good data after changing the roaming line to 1001.3 Hz on Oct 31 2016 15:44:29 UTC (see LHO aLOG 31024). 

I've "power-cycled" the OFS loop, by turning OFF then ON the H1:CAL-PCALX_OPTICALFOLLOWERSERVOENABLE switch, and that restored the servo's nominal behavior.

We should stick a DIAG_MAIN monitor of the OFS PDs for both PCALs to monitor for OFS servo malfunctions like this.
Channel to watch: H1:CAL-PCALX_OFS_PD_OUTPUT (the channel comes pre-calibrated into [V], with a range of +/- 10 [V])
Test: If a ~120 sec average of the channel is more than +/- 8 [V], then throw an error. (The mean should typically by around 5 [V])

While trending and thinking about this aLOG, I'd briefly changed the line frequency to 4001.3 Hz, but after realizing we had no good 1001.3 Hz data, I've changed it back to 1001.3 Hz. We'll stay like this for a hours and then resume the sweep at the highest frequency points.

As such, I erase the last 1001.3 Hz start time with the new start time from today:
Frequency    Planned Amplitude        Planned Duration      Actual Amplitude    Start Time                 Stop Time                    Achieved Duration
(Hz)         (ct)                     (hh:mm)                   (ct)               (UTC)                    (UTC)                         (hh:mm)
---------------------------------------------------------------------------------------------------------------------------------------------------------
1001.3       35k                      02:00                   39322.0           Nov 11 2016 21:37:50 UTC
1501.3       35k                      02:00                   39322.0           Oct 24 2016 15:26:57 UTC    Oct 31 2016 15:44:29 UTC      ~week @ 25 W
2001.3       35k                      02:00                   39322.0           Oct 17 2016 21:22:03 UTC    Oct 24 2016 15:26:57 UTC      several days (at both 50W and 25 W)
2501.3       35k                      05:00                   39322.0           Oct 12 2016 03:20:41 UTC    Oct 17 2016 21:22:03 UTC      days     @ 50 W
3001.3       35k                      05:00                   39322.0           Oct 06 2016 18:39:26 UTC    Oct 12 2016 03:20:41 UTC      days     @ 50 W
3501.3       35k                      05:00                   39322.0           Jul 06 2016 18:56:13 UTC    Oct 06 2016 18:39:26 UTC      months   @ 50 W
4001.3       40k                      10:00
4301.3       40k                      10:00       
4501.3       40k                      10:00
4801.3       40k                      10:00  
5001.3       40k                      10:00

It seems that ETMs and ITMs display approx 3-4urad swings in PIT at times. Is this normal? BS is < or = 2urads.

YAW seems to be about 2rad deviation across the board.

Doing a PRCL noise injection (into PR2) I noticed that H1:LSC-POP_A_RF45_PHASE_R was ~10deg off. Since changing this phase also affects the SRCL sensing matrix, I updated that one too

Old values:

H1:LSC-POP_A_RF45_PHASE_R 77.3
POP_A_RF9_I to SRCL input matrix (H1:LSC-PD_DOF_MTRX_5_1):  -0.025
POP_A_RF45_I to SRCL input matrix (H1:LSC-PD_DOF_MTRX_5_3):  0.08

New values:

H1:LSC-POP_A_RF45_PHASE_R 86.5
POP_A_RF9_I to SRCL input matrix (H1:LSC-PD_DOF_MTRX_5_1):  -0.0242
POP_A_RF45_I to SRCL input matrix (H1:LSC-PD_DOF_MTRX_5_3):  0.08 (unchanged)

WeeklyXtal - normal 

WeeklyLaser -  BOX RH levels have come down a bit since last week. 

WeeklyEnv - normal

WeeklyChiller - normal

Lots of stuff going on in the attached ITMY spectra of FASTIMONs at all 3 stages (M0, L1, L2) taken just now with the IFO in an 11+ hour lock.  Tried looking for old vs new differences to possibly account for the extra "swinging" misbehavior of ITMy as observed just this weekend (alogs SUN 31247, SAT 31230 31225, Fri 31226, and Kissel's coil check last Wed 31136).  I checked a few locked stretches from earlier last week compared to now - indeed there is a noisier peak/shelf from 6.06Hz to 7.6Hz on L2 in the current lock (all 4 channels LL, LR, UL, LR).  I can't correlate any activity in the alog to why ITMy, but maybe I missed something subtle that someone did.

Since the IFO is locking well right now, I saved new OBSERVE.snap files for all suses except PIs.  I suppose I could do those.

I've since switched the SDF overviews back to the DOWN/SAFE for those that show differences in the event someone finds them useful for the next locking transitions.

This morning H1's Intent Bit was taken out of UNDISTURBED.  I quickly asked around for any activities going in the Control Room and no one admitted to anything.  I tooke it back to UNDISTURBED and about 30sec later we dropped out again!

For the 2nd drop, I happened to be watching the Guardian Overview & noticed the message:  "EXC:  pemmx excitation!" on the DIAG_EXC Guardian Node.  The Log for this node said we had this excitation at:

• 16:24:09UTC  (8:24:09amPST)
• 16:25:37UTC  (8:25:37amPST)

WHAT IS THIS??  

Is this an automated excitation?  

If this is an acceptable excitation, can we remove this as a channel SDF monitors to knock us out of UNDISTURBED?

Patrick, Kiwamu,

In this morning, Patrick found that the CO2Y was not outputting a laser power. In the end we could not figure out why it had shut off. The laser is now back on.

[Some more details]

I thought this was a return of the faulty behavior that we were trying to diagnose in the early October (30472). However, the combination of looking at the front panel of the laser controller and trending the warning/alarm states did not show us something conclusive. So no conclusion again.

When I went to the floor and checked the front panel, no red LED was found. The only unusual thing is the GATE LED which was found to be off. Pressing the red gate button then brought the GATE LED back in green as expected. This could be an indication of the IR sensor momentarily went to the fault state and came back normal leaving the laser shut off. In this scenario, the IR sensor does not latch any LEDs and for this reason I thought this could be it. Then looking at the trend at around the time the laser went off, I did not find any alarm flags raising at all. Even if it is a fast transient in the IR sensor, I would expect to see it in the trend. So these two observations together can't support the IR sensor scenario. Another plausible scenario would be somebody accidentally hitting the gate button resulting in no laser output.