This weekend, as part of clipping investigations, I found that I could adjust the pointing of the PSL piezo mirror to minimize the jitter peaks in IMC-REFL_DC ( pitch: 1846 to 2300, yaw: 2043 to 1500) with the IMC off. The figure shows the resulting reduction of peaks in REFL_DC. Shaking of HAM2 was used to enhance some of the peaks, but there was little shaking at the 280 Hz piezo mirror peak. Sheila and I tried to move the piezo mirror to these settings while keeping the IMC locked but we were unsuccessful. It might be worth adjusting the beam on the diode while trying to minimize peaks.

Robert, Sheila

added 125ml to the crystal chiller

nothing added to the diode chiller (no fault on the chiller panel, trend of 14 days shows no "check chiller" faults)

PSL: 
SysStat: All Green, except VB program offline 
Frontend Output power: 34.7W  
Frontend Watch: Red
HPO Watch: Red

PMC:
Locked: 0 days, 0 hours, 0 minutes
Reflected power:   32.7W
Transmitted power: 100.5W 
Total Power:       133.2W 

ISS:
Diffracted power: 2.576%
Last saturation event: 0 days, 0 hours, 0 minutes 

FSS:
Locked: 0 days, 0 hours, 0 minutes
Trans PD: 0.073V

Not much hope here. With any luck I would get all the way to lock PRMI and DRMI but they don't last. Below I attached some plots from the lockloss tool using Sheila's ALS list of channel (/ligo/home/sheila.dwyer/Desktop/Locklosses/channels_to_look_at_ALS.txt). ALS REFL glitched prior to locklosses but why does that matter to DRMI and PRMI that have nothing to do with the arms?

To run lockloss tool using custom channel list do

$ lockloss -c custom_channel_list.txt select

The default channel list doesn't seems to work.

TITLE: 10/31 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Wind
INCOMING OPERATOR: Nutsinee
SHIFT SUMMARY:

Had some trouble with the MC.  Sometimes Clearing History (ASC WFS) would help.  Another time FSS was oscillating, so the Fast Gain was ramped down to it's lowest value and returned to 9.0.  (Sheila mentioned both of these to me.)

For first attempts at locking, simply tried to lock (no initial alignment), and would lock DRMI, but it would drop out shortly after.  Jenne mentioned going to LOCK_DRMI_1F and then looking at ASC ERROR signals on striptool & tweak optics for signals which have big ERROR signals.

LOG:

• Robert continues PSL work on PZT Mirror (trying to damp & stiffen the mount we have).
• 23:10 CP3 Overfill Complete (Gerardo)
• 23:13 IMC not locking (no light on Refl PD)--investigating
• 23:26 PCal team back from EX
• 23:50 Need to steer PSL beam back onto the IMC Refl spot on the wall (Kiwamu, Robert)
• 0:05 Monthly alert siren testing 5-6pm PST
• 0:10 IMC back (Kiwamu, Daniel, 
• 0:49 PI Mode10 took a step up & was at the threshold to get Verbal Alarms...probably not real, but not sure what to do about it.
• 1:04 Transitioned SEI_CONFIG from VERY_WINDY_NOBRSXY -> WINDY (nominal)
• 4:45 Left LVEA after aligning PSL input beam into HAM1 (via spot on PSL Enclosure Wall).  We did this after Robert's PSL work which was damping & stiffening pzt mirror.
• After this had a few issues with the Mode Cleaner locking (as noted above).
• Then the ALS Glitching arose for keeping H1 one down.  
• I've passed on what I got from Sheila to Nutsinee, but if it looks like a tough night, this shift should be cut short so the ALS issue can be addressed by the morning crew.

During locking tonight, had the following ERROR for ISC_DRMI:

EZCA CONNECTION ERROR:  Could not connect to channel (timeout=2s):  H1:LSC-PD_DOF_MTRX_SETTING_1_23

I tried a couple things:  I hit "LOAD", which did nothing.  Then I hit "Execute" which broke the lock.

One thing I did not do was Re-Request the state I was in.  (Nutsinee just let me know that this is what works for her when she has had "CONNECTION ERRORS".

I tuned the periscope a little and tuned and damped the piezo mirror mount. The 280 Hz peak is from the piezo mirror on the table, like the 300 Hz peak at LLO, and not from the top mount on the periscope, which is holding as I tuned it last year.  I am not sure why the piezo mirror mount is suddenly more prominent than it was last year. I would like to check again for some problem like clipping.  In any case, I would like to sub in one of the newer piezo mirror mounts; what I did was pretty jury rigged and I dont expect much improvement, especially since much time was spent trying to re-lock the mode cleaner. We havent had a fully locked interferometer since to evaluate the changes I made.

We are having a recurrence of the glitches that have been described in 30519 25523 22184

This time they are verry intermitent (only seem to happen about once every ten minutes), which would make it diffifcult to trouble shoot right now. 

Matt, Evan

We were perplexed by the steep slope of IMC F below 100 Hz, paticularly since it seemed to vary with PMC gain in the same way as the flat part of the spectrum above 1 kHz.

The attached plot shows the IN1 readbacks (i.e., no digital filtering or compensation applied) for IMC F and IMC L. Evidently, they seem to have the same spectral shape above 10 Hz. Since IMC L does not have any analog whitening, this would seem to indicate that IMC F readback has no analog whitening applied (despite what is implied by the schematic for the MC board).

However, the IMC F filter module (which produces the calibrated IMC frequency control channel that we've been using to estimate the IMC control noise) has a filter consisting of two 10 Hz / 100 Hz p/z pairs, as if to compensate for some kind of analog whitening.

What is actually stuffed into the analog whitening for the IMC F readback on the MC board?

[Also, we don't claim to understand why the TF is 0 dB at the peaks but -5 dB everywhere else.]

Many people over the years have calculated what kind of filter one should create for LSC feedforward use, but the most commonly referenced note on the calculation is an Initial Virgo note by Bas and others (Lisa links to VIR-050A-08 in LLO alog 13242, and I re-attach it here).  I have rewritten the calculation in Advanced LIGO terms in T1600504, which I also attach here. This note does not (yet) include the feature that we have of summing together two feedforward filters for the same degree of freedom - we use this for SRCL such that we can separately adjust the gain of the low frequency and high frequency parts of the transfer function, but it could alternatively be used to sum in the iterative "tweak" filter. 

Jim W, Cheryl, Corey, Nutsinee, Kiwamu,

Over the weekend Jim, Cheryl, Corey and Nutsinee kindly tested various CO2 configuration for me. The data so far indicate that

• Raising CO2X seems to improve some jitter peaks (152, 364, 620 and 1080 Hz) and broadband above 3 kHz.
• Raising CO2Y seems to degrade the sensitivity.

I would like to see some more data points with the CO2X laser higher than 0.4 W while maintaining CO2Y at 0 W.

Some details

The attached are the DARM spectra from various different times. Also, below shows a list of the CO2 settings that people tried during this weekend.

As one can see, having a high CO2X seems to improve the noise curve. We should try putting even more power on CO2X (meaning more than 0.4 W) next time.

Interestingly, the peak at 3340 Hz (SRM resonance, 27488) becomes taller when the TCS tunings become worse. This is consistent with a theory that high frequency part of the SRCL coupling is due to HOMs in the SRC. We might be able to use this peak to evaluate the good ness of the CO2 tunings.

In addition to what are already in integration issue tracker (https://services.ligo-la.caltech.edu/FRS/show_bug.cgi?id=6500), the following changes need to be done. Both are in T0900577.

ilspmc_servo3.pdf (both for PMC and ILS):

After the demod, 5MHz corner of Sallen-Key is unnecessarily high, and AD797 open loop gain is about 12dB or so at 5MHz, so it's not like it works as intended.

We'll add a passive 5MHz pole, and move the Sallen-Key corner down to 170kHz or so by:

• 470pF in parallel with R81
• Change C3 to 6.8nF
• Change C34 to 820pF

ilspmc_fieldbox4.pdf (both for PMC and ILS):

The DAC output for ramp signal is permanently connected to the HV amp with 200Hz pole and a factor of 50 gain.

If DAC output noise is 1uV/sqHz (depends on the DAC output but the digital output is usually zero), the DAC noise in the HV monitor (which has a 1/50 attenuation) will be 1uV/sqHz at DC and it goes down above 200Hz. See attached for the PMC HV monitor signal in-lock.

We'll add zp=100:10 by stuffing the unused whitening pattern on the board:

• Remove J1
• N4 OP27
• R7 140k
• R8 15.4k
• R9 140k
• C2 100nF

These are added to the existing FRS, which already has similar modifications to HV monitor and mixer readback.

Note that only the HV mon modification for PMC board was done, and we intend to do the rest for PMC as well as ILS.

TITLE: 10/31 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Wind
OUTGOING OPERATOR: Ed
CURRENT ENVIRONMENT:
    Wind: 36mph Gusts, 26mph 5min avg
    Primary useism: 0.15 μm/s
    Secondary useism: 0.30 μm/s
QUICK SUMMARY:

• PCal work was finishing up at EX.
• Robert was in the PSL Room taking FLIR photos & other work.  Lost the IMC Refl beam at some point.  Kiwamu is out on the floor to steer the IMC Refl beam onto the wall.
• Avg wind speeds look like they are finally getting below 20mph.

The TCS ITMY chiller water flow dropped several times, starting at 18:00 PDT Sunday 30th through to 08:00 PDT Monday 31st. The attached left hand plot shows a one day minute-trend, the right hand plot is a zoom into the last sharp drop at 07:01 PDT using second trends. The drop looks real and not a digital problem. It has not re-appeared since 8am this morning.

Took 4 minutes 42 seconds to overfill CP3 with LLCV bypass valve 1/2 turn open.

J. Kissel

We're exploring the functionality of the new features of the front-end calibration that calculates the coherence and subsequent uncertainty of the transfer function between each CAL line source and DARM. As such, I plot three, one-hour data stretches from different lock stretches in the past 24 hours.
    Data Set A: 2016-10-31 02:30 UTC
    Data Set B: 2016-10-31 07:00 UTC
    Data Set C: 2016-10-31 10:00 UTC

Note the translation between channel names and to which line they're analyzing:
H1:CAL-CS_TDEP_..._[COHERENCE/UNCERTAINTY]     Frequency        Used In Calculating       
           DARM_LINE1                          37.3             kappa_TST                (ESD Actuation Strength)
           PCAL_LINE1                          36.7             kappa_TST & kappa_PU    (ESD and PUM/UIM Act. Strength)
           PCAL_LINE2                         331.9             kappa_C & f_C            (Optical Gain and Cavity Pole)
           SUS_LINE1                           35.9             kappa_PU                 (PUM/UIM Act. Strength)

where you can refer to P1600063 and T1500377

Recall also, that our goal is to have the uncertainty in the time-dependent parameters (which are calculated from combinations of these lines) to around ~0.3-5%, such that these uncertainties remain non-dominate (lines are strong enough), but non-negligible (not excessively strong). An example total response function uncertainty budget in LHO aLOG 26889, to see at what level the time-dependent parameter estimation uncertainty impacts the total uncertainty. That means the uncertainty in each line estimate should be at the 0.1-0.3% level if possible. So, we can use these data sets to tune the amplitude of the CAL lines, so as to optimize uncertainty needs vs. sensitivity pollution.

There are several interesting things. It's best to look at the data sets in order B, then A, then C.
In data set B -- 
- this is what we should expect if we manage to get a stable, O1-style interferometer in the next week or so for ER10 and O2. 
- With the current amplitudes, the uncertainty on the ~30 Hz lines hovers around 0.1% -- so we can probably reduce the amplitude of these lines by a factor of a few if the sensitivity stays this high.
- The 331 Hz line amplitude should probably be increased by a factor of a few.

In data set C -- (this is during the ghoulish lock stretch)
- One can see when the data goes bad, it goes bad in weird, discrete chunks. The width of these chunks is 130 sec (almost exactly), which I suspect is a digital artifact of  the 13 averages and 10 sec FFTs. The sensitivity was popping, whistling, and saturating SUS left and right during this stretch, at a much quicker timescale than 100s of seconds.

In data set B --
- This is an OK sensivity stretch. The good thing is that the coherence/uncertainty appears to be independent of any fast glitching or overall sensitivity, as long as we stick in the 60-75 Mpc range.
- Interestingly, there's either a data dropout, or terrible time period during this stretch (as indicated by the BNS range going to 0) -- but it's only ~120 sec. If it's a data drop out -- good, the calculation is robust against whatever happens in DMT land. If it's a period of glitchy interferometer, it's very peculiar that it doesn't affect the uncertainty calculation, unlike with data set C.

Based on these data sets, I think it'll be safe to set the uncertainty threshold at 1%, and if the uncertainty exceeds that threshold, the associated parameter value gets dumped from the calculation of the average that is applied to h(t).

So, in summary -- looks like the calculations are working, and their calculated value roughly makes sense when the IFO is calm. There're a few suspicious things that we need to iron out when the IFO isn't feeling so well, but I think we're very much ready to use these coherence calculations as a viable veto for time-dependent parameter calculations.

Jeff, Dave:

Following Jeff's SUS changes last tuesday (25th October) we have accrued enough data to report on changes to the frame size and sus front end cpu usage.

Attached is a two week trend of the full frame size. This is a compressed frame, so its size varies dependent upon the state of the interferometer. Drawing an average by eye, the 64 second full frame size has decreased from a mean value of 1.77GB to 1.67GB. This is a 6% disk/tape saving. It equates to a per-second data rate decrease of 27.7 MB/s to 26.1 MB/s (decrease of 1.6 MB/s).

The removal of filters and reduction of DAQ channel decimation also improved the cpu processing time on most SUS models. The attached plot shows the 16 corner station sus and susaux models. They typically report an improvement in cpu time of 10%.