Jenne, Georgia, Craig, TVo, Hang

We parked the IFO at ENGAGE_SOFT_LOOPS and tried to center the spots on the ITMs.

Specifically, we put dither lines in yaw on the ITMs and turned off the Y2L FF gains. The lines were demodulated from DARM for us to monitoring the spots on the ITMs. We then opened the PRC1 loop (locking PRM pointing to ASC POP QPD) and used the pr3spotmove.py script at /ligo/home/controls/sballmer/20160927/ to minimize the dithering line. 

We could put the spots more centered on the ITMs in the yaw direction, however the recycling gain dropped significantly to only 28. The power on arm transmission was also low, 1020 for TR_X_NORM, and 1060 for TR_Y_NORM. We tried to open the soft loops and move the soft dofs around yet did not succeed in getting the PRG back (we might not tried hard enough though).

The slider and osem values for this config (spots roughly zeroed on the ITMs with low PRG). Also the ASC_POP_A_YAW_INMON value was -0.37 currently (originally +0.22).

Today we were struggling to lock ALS_COMM.  This has been an issue for a while, but has not been a showstopper until today.  

First off, COMM was causing the IMC to lose lock.  Yesterday I lowered the IMC gain by 6 dB.  This seems to have enhanced the ALS_COMM locking issue by increasing the relative additive offset on the IMC servo board, i.e. I decreased the IMC IN1 gain but not the IN2 gain.  

I lowered IMC IN2 by 6 dB (from -6 to -12 dB) in the guardian, this helped alleviate the additive offset issue.

I spent some time trying to understand the COMM locklosses we've been seeing.  One place we were losing lock in HANDOFF_PART2 when trying to turn up the CARM Servo Board IN2 gain from -31 to 17 dB, basically where we transition to COMM control.  I believe this was caused by the COMM VCO railing while we are trying to transition.  I altered the ALS_COMM guardian to check if the VCO is railed in the PREP_FOR_HANDOFF state, and if it is, set the VCO frequency to whatever the current beatnote is and try again.  

This has helped some, but not all of our COMM locklosses.  In HANDOFF_PART1 we are still seeing locklosses directly after engaging the IN2 input on both servo boards.  This was because the COMM output to Sum Node B IN1 was railed.  This is mysterious because there was no monitor within the COMM PLL itself which indicated anything is railed.  In any case, resetting the COMM VCO solves the issue, so I coded it up into guardian.  

The biggest unsolved mystery: COMM PLL -> DIFF noise, even when COMM is not locked. 

After these hacks, LOCKING_ALS has not yet caused a lockloss after seven attempts.  This is like putting vodka in your gas tank... it'll work, but who knows for how long.

I have made the spot position calculation script compatible with the new data directory structure that Craig implemented recently, which helps keeps the data more organized.

There were 5 A2L measurements taken on Saturday (alog 43787), which I show in the attachment that is zoomed in.  The other attachment is the same data, but including all test mass spot position measurements since the beginning of O1.  We have never been this far out in ITM yaw before.  We are about 2cm from the center on the ITMs.  The SOFT degrees of freedom mostly move the spots on the ETMs, which seem like they're reasonably close to the center. I'm not 100% sure why the 5 measurements aren't all consistent with each other, but Sheila and Georgia reported that the script wasn't working as well as they had hoped.  We'll check on this next time we're locked.

A note, ITMX's coils weren't balanced at the time of this measurement, so it's values should be taken with a bit of a grain of salt, but this still seems consistent with Gabriele's conjecture that we are quite far off in yaw, giving us some coupling that could be causing problems for the HARD yaw loops.

If we can get the IFO locked tonight (it's being very fussy today), we'll walk the PR3 spot, which also moves the spot on the ITMs.  Hopefully this won't require too much moving of the ETM spots, but we can do that as well to keep the arm buildups high.

We prepared filters for digitally compensating the Sidles-Sigg torque to achieve power-independent ASC plant. Currently we only consider DHARD YAW whose measurement seemed to match to the plant (LHO:43763; up to the potentially non-minimum delay at 1.8 Hz, see, e.g., LHO:43822).

The filters are now put in the DC5_Y filter bank, and the subtraction can be realized by routing the DHARD error signal (AS_A_RF45_Q) to DC5 and connecting the output to DHARD Y.

In the filter banks, FM1 is simply a high pass (zero at 0 Hz, pole at 0.1 Hz) to compensating for the offloading to M0. FM2 is the (L3 torque to angle) / (L2 torque to angle) transfer function based on measurements. See the first attached plot. The FM3 is the negative of the Sidles-Sigg torque coupling coefficient = (2*P_arm/c * dy/dth) in [Nm/rad]. Here dy/dth is the angle-to-spot-position conversion factor and for aLIGO Hard mode it is -4.5e4 [m/rad]. We normalize the P_arm to 50 kW. Lastly, FM4 calibrates the torque into appropriate ct going to L2 (numerical value is 1.6e+9) and FM5 calibrates the ct into the filter bank back to DHARD misalignment in rad with a numerical value of [4.5e-12].

To engage the compensation filter we should put a dc gain of (- arm power / 50 kW).

[Nutsinee, Sheila, Terry, Haocun]

We have some issues on locking the OPO with high green power, which can also effect the NLG measurements, etc.

A back-up issue is that we have this asymmetry and "cut-off" of green resonant peak when scanning the cavity. The reason was unclear and one of the postulate is that the crystal temperature increase when closing to the resonance which lengthen the cavity and the pzt is trying to compensate this effect.

At the same time, we found that when the green power is high (REFL>5mW), the control loop doesn't lock at the peak resonance, but having an "offset" which seems can be adjusted by moving pzt manually. I remember this also happened at LLO before..

We suspect these two issues can be related in some way.. Yesterday we took the cavity scan again by using different green power input with error signals. The plot showing is using 3mW, 10mW and 20mW with OPO temp = 23C. Phase matching temp gives similar results. We also moved the crystal position, trying to find some part of crystal giving less absorption, but failed.

The "cut-off" becomes serious with increasing power, and the error signals are totally abnormal when the power is higher than 3mW.

I noted that when increasing the power, (2nd attachment), some higher order modes (or carrier?) gets closer to the 00 mode, but not sure whether this can cause any problem on the error signal.

12:15 - 14:27 UTC Peter working on PSL ISS
14:34 - 16:58 UTC Jeff K. coil balancing ITMX
14:51 UTC Hit "COEFF LOAD" on h1susbs (file diff, no actual filter diff)
15:39 - 20:27 UTC Richard, Filiberto WP 7801, 7802
15:56 - 16:10 UTC Thomas and TJ to look at TCS chillers
16:11 - 17:14 UTC Thomas and TJ walking TCS chiller lines
16:13 - 16:36 UTC Ed installing panel in LVEA chiller closet
16:29 - 16:55 UTC Karen cleaning end Y
16:55 - 17:36 UTC Karen cleaning mid Y
17:19 - 19:08 UTC Gerardo to mid and end X to take measurements
17:39 - 18:31 UTC TJ and Thomas fixing leak on TCSX table
18:02 UTC Haocun to LVEA squeezing table
18:22 UTC Hit 'very large eq' button. 7.0 in Japan
18:29 UTC Cintas through gate
19:08 - 19:25 UTC Gerardo to LVEA to take measurements
19:32 UTC Peter to LVEA to take ISS measurement
20:16 - 20:39 UTC Kyle to mid Y to take measurements on fitting
20:20 UTC Set ISI config to 'windy'. Hit 'recover eq' button.
21:22 UTC Nutsinee to electronics racks
21:41 UTC Craig to PSL racks

In brief

Here are my thoughts:

• it is not possible to close the CHARD YAW loop with any bandwidth larger than ~ 1 Hz
• the only way to increase the bandwidth is to understand the origin of the non-minimum-phase zero (see below and 43822) and fix it
• my guess is a large yaw to length coupling in some suspension (either coil unbalance or beam centering issue) that couples yaw to length and length back to yaw (through the longitudinal lock). I'm hopeful that JeffK's balancing of ITMX will help

On a side comment, it seems that DHARD YAW has a larger bandwidth, although the plant transfer function appears to be very similar. However we don't have a very high resolution DHARD measurement, so maybe the phase rotation is not as severe and we are just marginally stable there.

Why

The measured open loop transfer function shows, as already noted in many places, a large phase rotation at about 1.5 Hz (see 43787, 43790, 43797, 43822). I put together all the measurements we have collected so far of the CHARD YAW open loop gain, factored out the control filter, and fit the plant transfer function.

In MATLAB ZPK format:

The additional phase rotation is described by the non-minimum-phase (right-half-plane) zero at about 1.8 Hz.

When there is such a right-half-plane zero, it is not possible (maybe it's possible, but definitely not easy), to increase the loop bandwidth above the frequency of the zero. Indeed, let G be the open loop transfer function, which has a pair of zeros in the right half plane. The closed loop transfer function is as usual 1/(1+G). If we had to have a bandwidth larger than 1.8 Hz, then we must have | G(1.8Hz) | >> 1, so that the closed-loop transfer function becomes simply 1/G. But then the right-half-plane zero in the OLTF becomes a right-half-plane pole in the closed-loop TF: the loop becomes unstable!

One can plug in the fitted transfer function into MATLAB sisotool and plot all sorts of root locus and Nichols charts, as shown in the attached plots below. The fact that the phase rotates by about 360 degrees in such a short frequency span (between ~1 and ~2 Hz), makes the loop unstable.

Prompted by a discussion with Gabriele, I took some measurements of the first loop power stabilisation.

    isstf.png shows the transfer function using either PDA or PDB (ie, either of the two first loop
photodiodes).  No difference in the transfer function was observed.  The UGF was around 50 kHz.

    PDA.jpg and PDB.jpg show the measured power noise using photodiodes PDA and PDB respectively -
PDB was used as the in-the-loop sensor.  Both show a similar degree of suppression except at low
frequencies.  However it was noticed that whenever the second loop output was enabled, there was no
observed suppression with either PDA or PDB.  Engaging the second loop caused the reported diffracted
power to rail at ~3.3%.  I've since found out about the offset removal for the second loop (thanks Gabriele!).



  Gabriele / Peter

model restarts logged for Tue 04/Sep/2018
2018_09_04 10:52 h1iopsusex
2018_09_04 10:52 h1susetmx
2018_09_04 10:52 h1susetmxpi
2018_09_04 10:52 h1sustmsx

Restart of IOP model to fix a DAC sync issue.

Wed 29/Aug/2018 - Mon 03/Sep/2018 No restarts reported

Found reports of CRC errors on the following terminals on h1ecatx1:

End Link R4_5 (EL6692)
End Link L3_4 (EK1521)
ISC Common L0 (EK1501)

They are indicated by circles on the topology as shown in the first screenshot.

There were also lost frames and Tx/Rx errors as shown in the second screenshot.

I am not entirely clear on what this is a symptom of. Hitting 'Clear CRC' and 'Clear Frames' reset all of the above.

Today, TVo and I found and fixed a leak on the TCSX table on the first T connector in the supply line.

He mentioned to me this morning that he had to add a few liters of water yesterday, so we went leak hunting this morning and found corrosion on the base of the periscope, water spots on the table in the corner, and spots on the floor below the table. No optics had any spots since the leak was coming from a T connector on the supply line behind the periscope. We cut about an inch off of what seemed to be the leaky connector, and then reconnected it and turned the chiller on. No leaks so far, but we will keep an eye on it the next few days to make sure we actually got it.

While we looking for the leak we found that the T connector for the return line had a hose that was about to come off (or possibly wasn't seated well to begin with). We fixed this while we were in there so I can sleep at night.

Before touching anything, this was the state of the first loop power stabilisation with the loop disabled.
 - 0.708 W diffracted
 - AOM modulation input 0.353 V
 - REFSIGNAL on -2.00
 - AOM monitor voltage (on MEDM screen) 0.417 V
 - offset slider 8.00
 - the Transfer 1A and Transfer 1B signals displayed on the MEDM screen were fluctuating wildly
 - the pre-modecleaner transmission seemed quite stable

    The input beam alignment to the AOM looked acceptable compared to the input aperture.  The angle
of incidence of the AOM with respect to the input beam was okay.

    With the offset slider on 0, 0.289 W was diffracted.  On 8, 2.986 W was diffracted.  In both cases
the REFSIGNAL slider was moved all the way to -10.00 to take it out of the equation.  With the REFSIGNAL
slider at -2.00 (the setting it has been in for a while), something like 6.8 W was diffracted.

    My guess is that with the servo settings as they were, the BUF634 high speed buffer that drives the
AOM RF driver was in a state where the in-built thermal protection kicked on and off.  I have no hard
evidence to prove this, other than the observation that as the offset slider voltage increases, the
diffracted power is a little less stable at the milliwatt level (based on a 10 second average) and
the AOM modulation voltage starts varying by 2 mV.

    The offset slider was lowered to 5.60.  The percentage diffracted power needs to be re-calibrated.

    A couple of other observations in passing.  With the AOM monitor reading 0.385 V, a multimeter measuring
the applied AOM modulation voltage read 0.324 V with the offset slider at 5.60.  When the AOM driver was
disconnected, the multimeter read 0.488 V.  There appears to be an offset between the displayed AOM modulation
voltage and the measured one of ~20 mV.

We designed an optimal controller using H-inf synthesis (see, e.g., G1501583, T1800077) for MICH PIT ASC.

In the attached plot we show the comparison for between the original (blue) and the new, optimal control filters (red). The new controller provides 6 dB more suppression in both the microseismic band ~ 0.5 Hz and 4 dB more at the earthquake band ~0.003 Hz. At the same time the high-freq row-off is similar for the two configuration (as we already put a very aggressive LP filter for MICH ASC). At around the ugf ~ 1 Hz we lose only 10 deg of phase which should not affect the loop stability.

The new filters are now put in FM4 & 8. The old FM4 was unused and FM8 was simply a cheby2("BandStop", 4, 20,83,93). We will further optimize the weighting functions as well as our knowledge of the plant to improve the filter performance.

[Keita, Jenne]

The Yarm VCO for green locking was struggling to keep the beatnote in range, so we altered the Tune Voltage limit (H1:ALS-Y_VCO_TUNELIMIT) from 5 to 7, to allow the VCO a little more leeway.  Right now, with green PDH and ALS locked, the Yarm VCO is sitting at a tune voltage of -6.3.  I don't know if this is a repercussion of the ALS lasers being tripped off last night, but the Xarm green PDH locking has been fine all day.  The lasers were both turned on around 9 or 10am, so they should be thermally equilibrated. 

Also, we were occasionally seeing oscillations in the green locking PDH servos, particularly on the Yarm.  We lowered the UGF of the tidal offloading (H1:LSC-Y_ARM_CTRL_UGF) from 0.08 Hz to 0.04 Hz, and that seems to have stopped the oscillations.  We lowered the Xarm UGF so that the 2 arms match.

However, we are still struggling to hold the arms on resonance.  We're just flopping over the resonance pretty quickly.  This is likely related to the ISS problems that we've been having all day.  (Right now the first loop is just off, which is better than having it on and oscillate.)  For the rest of the evening, we can work on things like DRMI ASC commissioning.  In the morning, PeterK will continue his diagnosis and debugging of the ISS first loop.