Preliminary results from MCMC fitting of the sensing function measurements taken on Nov 12 to a 5 parameter model are given below:

  gain    : 1.160e+06     (nonlinear fit was 1.153e6, 0.6% different from MCMC)
  f_c     : 342.3340 Hz   (... 346.7 Hz, difference is 1.3%)
  delay   : -8.809e-08 s  (... -2e us, this value from nonlinar fit was ignored,
                               uncertainty on the value from the nonlinear fit was +/- 3.3 us)
  f_s     : 8.19 Hz       (... 7.389 Hz, difference is 9.8%)
  1/Q     : 0.0474        (... 0.0454, difference is 4.2%)

Values of the nonlinear fit were reported in LHO alog 31665.

The fitted sensing function and the corner plots are attached.

These are preliminary results, the uncertainties on the parameters have not been analyzed at the moment.

TITLE: 12/01 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Cheryl
CURRENT ENVIRONMENT:
    Wind: 7mph Gusts, 5mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.42 μm/s
QUICK SUMMARY:

Received status about how the night/morning went from Cheryl.  

16:35:  Since we are not LOCKED, performing memory upgrade for h1guardian0 (WP6366, via Carlos).

Will get back to locking afterward and investigate around DC Readout and wait for assistance.

State of H1: losing lock at LOW_NOISE_ESD

Activities:

• started shift with H1 unlocked
• some tweaks to alignment and locked up
• broke lock after LOW_NOISE_ASC multiple times
• violin modes were rung up
• relocked and worked on damping violins
• made some headway with ETMX mode4, see alog 32059
• tried to get to NLN and lock loss at LOWNOISE_ESD_ETMY both times
• handing off to Corey

• After numerous lock losses that came with many saturations, I relocked and I spent some time looking at the violin modes since all were very rung up.
• It was near impossible to damp ETMX mode4, so I turned it off and focused on modes 2 and 3, with some success.
• I returned to damping mode4, and after turning off a filter in mode2, I could damp mode4.
• When I turned off mode2 FM5, N505.710, immediately the mode2's signal decreased in amplituded, and mode4 started to decrease.

ETMX changes:

ETMY changes:

ITMX changes:

Bounce Mode Damping: I increased the gains

After relocking, the ETMX changes didn't work exactly as they did in my lock - picture attached.

• Attachment 1: ETMX mode 4 damping
• Attachment 2: same settings on relocking

TITLE: 12/01 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
    Wind: 6mph Gusts, 4mph 5min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.47 μm/s
QUICK SUMMARY:

• after handoff I had to "fix" the fast shutter
• the "fix" was not overly obvious, test failed, init -> test failed, auto mode -> init -> test failed
• I tried something else
• I ran the ISC_LOCK down script with Down as the chosen state, and when that was done, the fast shutter was ok again
• alignment's great, and H1 is in ENGAGE_SRC_ASC

TITLE: 12/01 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Cheryl
SHIFT SUMMARY: Having troubles relocking, seems 4.7khz violins are acting up
LOG:

IFO was locked when I got here. Jeff was working on tamping down second harmonic violins. Eventually got that taken care of got to observing. After an hour (after everyone else went home) started getting ETMY saturations. Guess I didn't notice the 4.7khz modes ringing up. Haven't been able to relock since, nothing I've tried has gotten these violins to quit playing. ISC_LOCK also keeps failing to go to and come out of down, I've had to select down after each lockloss and then manually go ready. Don't know if that is a problem.
 

Just had a lockloss. It started with a long string of continual EY saturations, some broad "low frequency" noise (roughly 10-50 hz) appeared in the live DARM spectra, then a lump appear around 50 hz. This eventually became a sharp peak at about 47 hz that would get large for a few seconds, then settle down a little. Attached spectra show a measurement just before the lock loss (red) with the 47 hz feature, a measurement with the low frequency stuff before the 47hz peak came up (brown), and a measurement 2 hours ago (green). 47 hz sounds familiar, but I know not from whence.

I've made my spot position plotting scripts much simpler to use, and put them in the svn folder that holds the A2L scripts.

The script to open, modify if needed, and run is /opt/rtcds/userapps/release/isc/common/scripts/decoup/BeamPosition/Run_A2L_plotter.m

This script calls 2 sub-scripts.  The first one (GetA2Lspots.m) will go through the data in ..../scripts/decoup/rec_LHO/ and pull out any measrements that have been taken since the last time this was run.  It will calculate the resulting beam spot positions for the test masses, and save the data.  The second sub-script (PlotTestMassSpotPositions.m) is just a plotter, for which you can change some parameters (start and stop time for the time axis, etc) in the Run_A2L_plotter script.  Or you can just run each script individually, using the Run_A2L_plotter as an example. 

I haven't yet added a few fancy options that I'd like, such as the option to plot the O1 or O2 average spot positions, but the basics are there.

I didn't check in our A2Ldata.mat file, but the scripts are all in the /opt/rtcds/userapps/release/isc/common/scripts/decoup/BeamPosition/ folder.

J. Kissel, E. Merilh, J. Warner, T. Hardwick, J. Driggers, S. Dwyer

Prompted by DetChar worries about glitching around the harmonics of violin modes, Ed, Jim, and I went on an epic campaign to damp the ~1kHz, 2nd harmonic violin modes. These are tricky because not all modes had been successfully damped before, and one has to alternate filters in two filter banks to hit all 8 modes for a given suspension. 

We've either used, or updated Nutsinee's violin mode table, with the notable newly damped entries being 
994.8973    ITMY     -60deg, +gain      MODE9: FM2 (-60deg), FM4 (100dB), FM9 (994.87) 
997.7169    ITMY       0deg, -400gain   MODE9: FM4 (100dB), FM6(997.717)                 VERY Slow
997.8868    ITMY       0deg, -200gain   MODE10: FM4 (100dB), FM6(997.89) 

Also, we inadvertently rung up modes around 4735 Hz, so we spent a LONG time trying to fight that. We eventually won by temporarily turning on the 4735Hz notch in FM3 of the LSC-DARM2 filter bank and waiting a few hours. I had successfully damped the ETMY mode at 4735.09 Hz by moving the band-pass filter in H1:SUS-ETMY_L2_DAMP_MODE9 's FM10 from centered around 4735.5 to centered around 4735 Hz exactly, and using positive gain with zero phase. However, there still remains a mode rung up at 4735.4 Hz but it's from an as-of-yet unidentified test mass, and we didn't want to spend the time exploring. These 4.7 kHz lines have only appeared once before in late October (LHO aLOG 31020).

Attched is a before vs. after ASD of DELTAL_EXTERNAL. I question the calibration, but what's important is the difference between the two traces. Pretty much all modes in this frequency band have been reduced by 2 or 3 orders of magnitude -- better than O1 levels. Hopefully these stick through the next few lock losses and acquisitions.

Thanks again to the above mentioned authors for all their help!

Sheila D., Evan G.

We investigated whether 1080 Hz glitching seen throughout ER10 and into the start of O2 is due to jitter noise. 

It has been seen in various runs on Hveto that a large number of the 1080 Hz glitches are vetoed with channels like H1:IMC-PZT_PIT_OUT_DQ (see, for example, here). Note that the auxiliary channel has glitches over a broad range of frequencies that are used to veto the 1080 Hz glitches.

To test if jitter really could be a culprit, we inject a broadband excitation into IMC PZT YAW and use IMC WFS A DC segment 1 and IMC WFS B DC segment 1 as witnesses for the jitter coupling. In the witness channels, the noise goes up by a factor of 2-4. At the same time, the broad noise feature in DELTAL_EXTERNAL at 1080 Hz basically remains unchanged (see attached figure). It is possible there is some underlying jitter noise at these frequencies (because the DARM spectrum goes up a little at nearby frequencies), but the primary cause of the 1080 Hz doesn't seem to be caused by jitter noise.

We tried excitations in IMC PZT PIT, but this also does not have any effect on the 1080 feature or the glitch level.

The free memory size on the guardian machine is about 4GB. At the current rate of usage we predict a reboot is needed before next Tuesday. At the next opportune time, we will increase the memory size from 12GB to 48GB and perhaps schedule regular reboots on Tuesdays. 

Plot of available memory for the month of November is attached (Y-axis mis-labelled, actually MB).

J. Kissel, S. Aston, P. Fritschel

Peter was browsing through the list of frame channels and noticed that there are some differences between H1 and L1 on PR2 (an HSTS), even after we've both gone through and made the effort to revamp our channel list -- see Integration Issue 6463, ECR E1600316, LHO aLOG 30844, and LLO aLOG 29091.

What difference he found is the result of the LHO-ONLY ECR E1400369 to increase the drive strength of the lower states *some* of the HSTSs. This requires the two sites to have a different front-end model library part for different types of the same suspension because the BIO control each stage is different depending on the number of drivers that have been modified;
At LHO the configuration is
    Library Part        Driver Configuration            Optics
    HSTS_MASTER.mdl     No modified TACQ Drivers        MC1, MC3
    MC_MASTER.mdl       M2 modified, M3 not modified    MC2
    RC_MASTER.mdl       M2 and M3 modified              PRM, PR2, SRM, SR2

At LLO, the configuration is
    Library Part        Driver Configuration            Optics
    HSTS_MASTER.mdl     No modified TACQ Drivers        MC1, MC3, PR2
    MC_MASTER.mdl       M2 modified, M3 not modified    MC2, PRM, SR2, SRM
    RC_MASTER.mdl       M2 and M3 modified       none

This model's DAQ channel list for the MC and RC masters is the same. The HSTS master is different, and slower, because these SUS are used for angular control only: 
                           HSTS (Hz)        MC or RC (Hz)
    M3_ISCINF_L_IN1        2048               16384

    M3_MASTER_OUT_UL       2048               16384
    M3_MASTER_OUT_LL       2048               16384
    M3_MASTER_OUT_UR       2048               16384
    M3_MASTER_OUT_LR       2048               16384

    M3_DRIVEALIGN_L_OUT    2048               4096

Since LLO's PR2 does not have any modifications to its TACQ drivers, it uses the HSTS_MASTER model, which means that PR2 alone is going to show up as a difference in the channel list between the sites that seemed odd Peter -- that L1 had 6 more 2048 Hz channels than H1. Sadly, it *is* used for longitudinal control, so LLO suffers the lack of stored frame rate.

In order to "fix" this difference, we'd have to create a new library part for LLO's PR2 alone that has the DAC channel list of an MC or RC master, but have the BIO control logic of an HSTS master (i.e. to operate M2 and M3 stages with an unmodified TACQ driver). That seems excessive given that we already have 3 different models due to differing site preferences (and maybe range needs), so I propose we leave things as is, unless there's dire need to compare the high frequency drive signals to the M3 stage of PR2 at LLO.

I attach a screenshot that compares the DAQ channel lists for the three library parts, and the two types of control needs as defined by T1600432.

I have been investigating the spike in the computed value of kappa_tst shown here in the summary pages:
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20161122/cal/time_varying_factors/
A closer look reveals a seeming correlation between the DARM line coherence and the values of kappa_tst (see the attached plot). Currently, kappa_tst computed values are gated with PCALY_LINE1 and SUS_LINE1, the only lines used to compute kappa_tst.

Things to note in the plot:
1) kappa_tst diverges from the expected range about a minute after the DARM line coherence uncertainty skyrockets, just the amount of time it takes to corrupt the 128 running median.
2) kappa_tst as computed by CALCS also diverges when the DARM coherence goes bad.
3) Ungated kappa_pu behaves similarly to kappa_tst, but since it is gated with the DARM coherence, the GDS output is not corrupted.