1/2 turn open on LLCV bypass valve - took 30 sec. to overfill CP3 to the point that LN2 was flowing out both exhaust lines

Keita, Sheila, Jenne, TJ, Kiwamu,

We had one lockloss today due to an unstable behavior in the 3rd loop. Looking at the data, we figured that this was caused by the dynamic power normalization (H1:PSL-PWR_SCALE_OFFSET) which introduced glitches to the TR signals through the (discretized) normalization. These glitches then propagated to the 1st loop through the 3rd loop and eventually caused the lockloss. This is actually something Jenne and I thought we fixed two days ago by editing the LASER_PWR guardian (not aloged). We checked that the guardian code had been appropriately edited; it seems that the edition has not been effective for some reason. We restarted the node to enforce the edition. So the dynamic normalization should not happen when LASER_PWR reaches the requested stable state. Hopefully this will be the last time to talk about this issue.

The attached shows time series data, showing the glitches by the dynamic normalization.

Shelia Dwyer, Craig Cahillane

We have changed the CSOFT and DSOFT input matrix in an attempt to isolate the CSOFT and DSOFT error signals from one another.

In aLOG 27944, Shelia mentions separating the HARD and SOFT signals in the input matrix.  This aLOG is dedicated to the common and differential mode separation.

To get solely common and differential modes, we must have our X arm and Y arm signals scaled by factors u and v to be of the same order:

CSOFT = u * X_sig + v * Y_sig
DSOFT = u * X_sig - v * Y_sig

We worked on finding u and v by making ~ 1 μ radian alignment changes in the X and Y ITMs and measuring the combination of TRX A and TRX B signals that is insensitive to HARD, according to aLOG 27944. The same was done for the TRY A and TRY B output signals:
Measurements

        X_sig (X Combo)    Y_sig (Y Combo)
Yaw     0.03975           -0.0781
Pitch   0.0302             0.106

We then found and normalized u and v by the same scalar, separated out the TR? A and TR? B components of the HARD insensitive signals, and put them in the input matrix for both Pitch and Yaw:

        u (Yaw X)     v (Yaw Y)     u (Pitch X)   v (Pitch Y) 
TR? A  -0.3521        0.0848        0.9420        0.0201
TR? B   0.8187       -0.4456        0.1936       -0.2733

In the actual input matrices we have flipped every sign in the numbers above in order to have a positive gain in the CSOFT and DSOFT control loop filter banks.

The code that calculates the above matrix lives in

/ligo/home/sheila.dwyer/Alignment/DSOFT/sens_TMS.m

To see if reducing h1fw1's disk loading would make it more stable, Thursday at 11:30PDT we changed h1fw1's daqdrc file to stop it writing science frames on the next daqd restart. Despite h1fw1 having restarted itself six times already Thursday morning, it then went into a period of stability from 09:53 through to 23:15, at which time it restarted and stopped writing science frames. What happened next was interesting, here is the timeline:

Thu 23:15PDT h1fw1 writes last science frame

Thu 23:20PDT h1fw1 restarts daqd

Thu 23:30PDT h1nds1 restarts

Thu 23:39PDT h1nds0 stops working, but its process still exists so monit does not restart it

Fri 05:02PDT h1fw1 restarts, test has failed at this point

The interesting points are: h1nds1 restarted once 10 minutes after the config change. Perhaps not surprising because it uses h1fw1's frames. At 23:39PDT h1nds0 stopped serving data. This is totally surprising, there is no link between h1nds0 and h1fw1 that we know of.

Since Guardian is the sole NDS client for h1nds0, several Guardian nodes reported nds problems while h1nds0 was in its frozen state. DIAG_MAIN for example reported nds failures from Thr 23:40PDT through Fri 10:54PDT.

J. Kissel for the Wind Team

I took the opportunity to grab some pictures of the X-End building exterior and brand new wind fence pathfinder. Winds were roughly 25 mph, so I also grabbed a video. It's too big for the aLOG, so I've posted it to youtube.

Notes on the fence:
- There we no tumbleweeds gathered around the fence
- The material seems to be holding up well (not stressed/stretched too much where it's attached to the fence), and 
- pressing on the back of the material opposite the wind direction it feels like a fully extended sail, but not near any yield point.
- The tops of the posts are rattle a little bit.

The final, as built, design of the fence:
- 3 posts, 24 ft as-purchased; 20 ft is above ground and 4 ft are in concrete in the ground.
- Posts cover 30ft left-to-right, spaced 15 ft apart.
- 6 ft gap between ground and fence material, and material spans the posts left-to-right and is 6 ft tall (so there's room to extend the material upward).
- The material is 30% coverage, or 70% porous. 

Also, 
SEI aLOG 1024 shows the first bit of wind modeling that's being done at Stanford by a summer undergrad Ian Gomez. If you're really cool, you can check out more preliminary results (at this point, just pretty pictures) in the Stanford Engineering Test Facility's eLogBook: ETF eLOG 2593.

My thoughts, after seeing these initial results -- which (rightfully so) start off with a flat bit of ground and a simple box for a building -- that those simple models will get us pretty far for the Y-end where the topography is pretty darn flat. However, the topography is more interesting at the X-end, and my hope would be that by the end of the summer, Ian's models might get just sophisticated enough to predict wind flow around the X-end building. 

You'll recall from the single-PEM-anemometer comparison between X-end and Y-end during wind storms (see LHO aLOG 17574), that Y-end moves about a factor of 2 more than X-end. The topography may have a good bit to do with it.

The plan is to overfill CP4 this afternoon up to 100%, disconnect the flow meter from the exhaust pipe, then time how long it takes to pour LN2 out the exhaust (just like we do for a CP3 overfill), and then reconnect the flow meter, while leaving CP4 in manual mode over the weekend. I will monitor it from home. 

NOTE:  CP4 overfill will generate an alarm

Team PI

The presence of multiple mode lines, with frequency separations of less than 1 Hz, in the trans-QPDs or OMC-DCPDs data impacts on our ability to extract a high quality error signal for the purpose of PI damping. In order to deal with this issue, we are systematatically studying the behaviour of iWave in the presence of multiple lines. We present the result of this study for the case where both lines have about the same amplitude (see the image #2)  and their frequency seperation equals one the following values: [-2,  -1, - 0.5, - 0.25, - 0.125, 0.125, 0.25, 0.5, 1, 2] Hz .

These results show that the amplitude and frequency estimate from iWave suffer modulations whose depth is inversely proportional to the frequency separation of the lines. We can also see that polarity of the frequency modulation matches the frequency difference. Thus, we can in principle distinguish between the cases where the line lies either to the right or to the left of the PI-mode of interest. The idea is to then characterise these modulations so that we can use them as error signals to control the frequency of a dynamic notch filter that is made out of iWave.  The iwave notch filter is designed to remove the problematic line with minimal distortion of the background. To do this, we explore the Q-factor parameter space of iWave. The results from this study (see below) suggests that an iWave tau parameter value of 2 seconds is sufficient for separations greater than 0.0625 Hz. We see that the output of the iWave notch filter (the green line) only contains the primary 15540 Hz mode line. The next step is to use amplitude and frequency modulation error signal from iWave to control the frequency of the notch filter. If this control strategy works, we can then combine these filters into a single multi-line iWave block.

Attempted to bring the interferometer back to 40W in an attempt to leave it at 40W over night.

- Slightly tweaked the yaw offsets of the QPDs to improve the PR gain, but ran out of patiance at a recycling gain of 28 - I think there is more to be had with better alignment..

 (The offsets I used were in the control filter modules: H1:ASC-DSOFT_Y_OFFSET=0.08, H1:ASC-CSOFT_Y_OFFSET=0.04)

- Then the OMC DCPDs started saturating - for now I just turned off the PD whitening.

- Added the input matrix from alog  to Guardian - but Guardian still does not turn the SRC1 loop on when it gets there.:

for SRC1_P:
AS_A_RF36_I : -0.5
AS_B_RF36_I : +1.0

for SRC1_Y:
AS_A_RF36_I : -1.5
AS_B_RF36_I : +0.34

However, the soft loops ran away several times during powerup - not sure what changed.

SUMMARY:  Had the Control Room to myself in the evening.  Unfortunately, H1 was a bit finicky (see Locking & Initial Alignment notes below) & drove me crazy for an hour or two, but eventually it went to 20W.  Will probably leave it here for the night.  Violin modes (& harmonics) are rung up.

Config Changes noted for EY on the CDS Overview:

ISI:  If we want to address this with reboot, take ISI to a non-sensor correction state first.  Then load new filters.  But can leave until the morning for Jim to take care of this.

Commissioning:

Soft Loop investigations at the beginning of the shift. (Jenne, Sheila)

Locking Notes:

Switched the input matrix values back for the TMS Soft Loops which Sheila alogged about earlier.  Tried locking, but DRMI did not look good.

Initial Alignment Notes:

Went through a couple of alignments and both times had issues with INPUT_ALIGN.  For the first time, the MC would not hold lock (so I skipped it).  For the second time, the Xarm flashes were good, but it would not lock.  I doubled the XARM gain, but I couldn't drop it back down without the Xarm breaking lock (aligned while keeping the gain at the doubled value of ~0.15).  Then moved on.

After the first Initial Alignment, could not make it past LOCKING_ALS.  Eventually went for the 2nd Initial Alignment (& had INPUT_ALIGN issue noted above, but atleast made it through the step).  Went for locking and this time had none of the LOCKING_ALS issues!

[Puzzled about what the deal is with INPUT_ALIGN!  Atleast in my attempts, it seemed to definitely affect whether I could get past LOCKING_ALS.]

Leaving H1 at the INCREASE_POWER (@20W) Guardian state for the night.

We measured the ASC PIT Sensing matrix in the REFL sensors.

We drove cHard, cSoft, Inp1, PRC1, & PRC2 loops at around 8 Hz and then took data of the CHARD and REFL WFS signals. We started at 1150766030 and stopped at 1150766330. Coherence was > 0.98 for all elements of the matrix. But why? What's the point of all this? Well, we are trying to make a clean CHARD signal by mixing the REFL WFS signals. However, we have 5 DOFs that show up in REFL, but only 4 sensors.

Therefore this problem is not a pure matrix inverse. Moreover, we would like to maximize the SNR of CHARD in the CHARD_IN1 so as to reduce the CHARD controls noise injected into DARM. IF the REFL signals all had the same noise performance or if they were uncorrelated with each other, this would not be a problem.

The first attached image shows the spectra and coherence during the sensing matrix drive time.

The second image shows the co-Herence during the ~20 Mpc stretch from around 1 PM today. Of course, the ASC noise was really bad then, but its sort of always is, so...

A more complete alog is coming later, but we have an expirimental ASC input matrix for the soft loops in the guardian right now, which is insenstitve to the hard loops.  We need to work on decoupling common and differential for this matrix to work.  You can revert to the old matrix by on lines 1950 in the ISC_LOCK guardian if necessary. 

Conor, Jeff, Jim, Krishna

After generating a model that can do offline sensor correction, I played around with the plant inversion, unit conversion, and high-pass filtering in the BRS sensor correction path.

Two major points became apparent: 
1) The BRS plan inversion is effectively providing some noise gain below 8mHz. By moving the poles in this filter close to the high-Q zero, a free 10dB can be won at low (f<5mHz) frequencies.

2) To improve correction at 10mHz, the STS2 needs some plant inversion. Instead, we can AC-couple the BRS at the same frequency and Q as the STS2. This means moving the poles 
in the filter 'GND_SENSCOR_ETMY_STS_Y_ROTVEL' FM3 until they match the STS2. The manual says 8.33mHz, Q = 0.707, but I found better subtraction performance with 7mHz, Q = 0.7. 
I had to push the pole in FM1 'acc_to_vel' from 2mHz to 1mHz to avoid phase loss. Additionally, FM2 'match', is now -0.774, about 15% lower than before.

These changes make some small gains at low frequencies, for a total of about 4x RMS improvement at 1mHz. The offline sensor correction goes from the Blue to the Red traces 
in attachment 1 (BRS_sensor_correction.png). 

The coherence tells a nice story: Nearly all coherence is subtracted from 0.1Hz down to ~30mHz (where BRS sensor noise becomes significant). At higher frequencies, they remain as 
coherent as before since the wind drives translation as well as tilt, and we're only subtracting tilt. At low-f, the GND sensor is dominated by BRS noise and they become coherent again.

Sensor correction was trained using 5 hours of consistent wind (attachment 3) GPS time: 1150459291  -- 20 June 2016 ~17:01 UTC

Stefan, Kiwamu,

With Keita's instruction in hand (27931), we have closed the 2nd and 3rd ISS loops at the same time. We confirmed that the 3rd loop still suppresses the arm transmission signals.

A next challenge will be to power up the PSL power with both loops closed.

The first attachment is a measured transfer function of the 3rd loop when the 2nd loop was closed. The PSL was set to 20 W. Note that we accidentally had a wrong sign for the control gain in this measurement, so the phase should be read with an extra 180 deg added. As expected the transfer function looks identical to what Keita measured before without the 2nd loop (27898). The second attachment shows the setting we used to close the 3rd loop. As suggested by Keita, we took out FM9. A good gain was found to be 60 dB larger than it was for the 3rd-loop-only configuration. The sign of the gain needed to be negative. We tried closing the 2nd and 3rd loops twice today, one time without an issue, the other time we unlocked the interferometer seemingly due to DAC saturation for the 3rd loop. Once the loop is closed the DAC counts for the 3rd loop is roughly 1000 cnts level -- no problem at all from the range perspective so far.

We then did one quick test where we stepped up the PSL power just by 1 W (i.e. 20 -> 21 W) to see how the ISS system reacts against it. This unlocked the interferometer; seemingly the second loop unlocked first by hitting the trigger upper threshold which subsequently unlocked the first loop whose diffraction power went up to 40 % on a time scale of a couple of seconds.

Untimately we need to engate the 2nd and the 3rd ISS loop at the same time. Toward this goal, I first tried to engage the 2nd loop but without the 3rd loop, and measure the 3rd loop open loop transfer function while the 3rd loop was open, but the IFO didn't cooperate at 20W today.

I instead measured the 1st loop and the second loop sensing by injecting into the 1st loop error point via the second loop board while the input side of the 2nd and the 3rd loop were both open.  I measured between 6Hz and 0.4Hz, and it was mostly flat as it should be. At 2W, the ratio of the second loop sensing to that of the 1st loop sensing was:

Sens2(2W)/Sens1 = -0.4.

At P Watts, this will become -0.2*P.

Let's say that the 2nd loop works at 25 Watts with the same setting as in O1. And we already know that the 3rd loop (without 2nd loop) works with the 3rd loop filter gain of -1. A good starting point would be to engage the 2nd loop at 25 Watts without the 3rd loop, disable FM9 (boardComp) of the 3rd loop filter, set the gain to -1*(-0.2*25) = 5 and engage the 3rd loop.

The 3rd loop digital gain needs to be changed as the power goes up because the sensing for the second loop is not normalized by power. The analog gain control slider is downstream of the 3rd loop summation point and cannot be used as a poor man's power scaling for the sensing.

The ITMX PI path was measured during maintenance day driving from CDS and measuriung the quadrant outputs to the ESD. WP#5931
Specifically driving H1:SUS-ITMX_PI_OMC_DAMP_MODE1_DAMP_EXC with 80k counts, and measuring P2-P5 of D1600122 directly with an SR785.
In this case a splitter was created and used to allow the cable and ESD load to be included in the measurement.  This configuration resulted in a 1.6% drop in drive amplitude of the LL quadrant fairly uniformly across all frequencies.

There is some confusion with the channel naming, on the chassis front panel left and right are switched relative to the model naming.  The model names appear consistent with wiring diagram D1500464.
Otherwise these channels behave well.  

Nergis, Peter, Stefan,

Currently, as we transition from 10W to 57W input power, our recycling gain drops from about 34 to 27. It seems like we need to tune the common TCS:

Attached are 3 plots:

Plot 1: DC signals:

PR_GAIN and normalized arm power (both blue)
AS_DC A and B (green and red)
POP_DC A and B (cyan and purple)
REFL_DC A and B (yellow and black)

Note the interesting behaviour of the REFL DC, all while AS_DC is linear in power.

Plot 2:

Arm and power recycling cavity powers, as well as test mass pitch control signals. The test masses have to compensate for radiation pressure, making the pitch control signal proportional to the arm cavity power.

Plot 3: RF signals:

Power and signal recycling cavity sideband buildups.

This is a quick summary of today's TCS joy. I ran another differential lensing test today. I went to the other side of the differential lensing (CO2X goes higher power).

The highest cavity pole was 352 Hz in this test.

• CO2 X 500 mW --> 700 mW --> 500 mW
• CO2 Y 230 mW --> 80 mW --> 230 mW

This time, I also took many measurements of the intensity and frequency noise couplings periodically throughout the test using Evan's automated measurement script (20470). I will analyze and post them later. The second attachment is trend of some relevant channels.