C. Cahillane

I have attached remade systematic error and uncertainty spectrograms for all of O1, as well as some a specific calibration at GPSTime = 1135136350.

These plots include uncertainty from detrended time-dependent kappas.

I have also included the uncertainty components plots for ease of viewing what contributes to uncertainty.

For LLO, see LLO aLOG 25914

Here are trends of the BRS raw balance position: a 12 day (right) and 30 days, left.  The driftmon has a range of +-16000 so at -13000 and still trending we don't have much room.  At the current rate, we'll reach the limit in about three days.

A test version of MEDM is currently installed in the control room to address CDS Bugzilla 789.  Although this wasn't really intended, the simple act of compiling the MEDM software installs it.  If it causes no harm, I'll leave it in place, if there's problems the original can be reinstalled in a few minutes.

This is to support testing of the historical MEDM screen software.

I restarted the HWSX sensor with a new template file that excludes the very high variance centroids from the measurement. This should result in a much less noisy measurement of the wavefront error.

The new Python version of the HWS code does this automatically by weighting each data point in the HWS image by the inverse of its variance when calculating beam properties.

Restarted web screen capture for h0 to pick up revised FMCS overview and fan sensor detail screens.  These now show all values since the new vacuum controls were installed.

One of the lockloss classes from tonight has been some kind of angular instability that we see very strongly on the AS camera right when we start to power up.  Not sure what it is, but it's the kind of thing that could be a BS angular instability, since the Michelson fringe separates, and the 2 bright spots orbit around each other for a second or so before we lose lock.  It looks primarily like pitch according to the oplevs, but there are certainly some yaw components in there.

Attached is a plot showing the lockloss, including the power at the AS port and the oplev (or wit) signals from each of the IFO optics.  If we call the frequency of the AS DC power fluctuations 2f, then it looks like perhaps BS and the ITMs are moving in pitch at 1f.

We tried once turning off the CHARD, MICH and SRC1 loops just before powering up.  We were able to make it to 3W and sit for a few moments, but then lost lock on the way to 5W, although this was a fast lockloss, probably just because we didn't have enough loops on.  We'd like to try powering up with all the loops on to 3W, to confirm that we can't even do that (we had always been going straight for 5W when we saw the instability). We'd also like to try with only 1 loop off at a time - MICH seems the most suspicious loop, but CHARD does seem to get noisy when the rotation stage is moving. 

As a side note, I've added tried to add a convergence checker to the Engage_SRC_ASC state, so that you no longer have to wait by hand before going to Part1.  You should be able to safely select Part1, and the guardian log will tell you what loop(s) aren't converged yet. The wait seems to not be working consistently yet, so maybe we can't depend on it yet, unfortunately.

Today we have seen at least three examples that might make us want to return to trying 90 MHz centering.  The first two screenshots attached show locklosses where we lost sideband buildups, which is usually a sign of misalignment of the BS or SRC.  (We are currently using a combination of AS36I A+B for SRM control 26785 and AS36BQ  for BS control).   You can see that the BS yaw control signal drifts along with the sideband powers, and that there is clearly also a signal in the 90MHz Yaw signals, which might indicate we could use these sensors to prevent this kind of run away and lockloss.  

The third one shows the lock that CHris and TJ left overnight last night, and you can also see sideband powers drifting a bit over the first  couple hours of the lock, which is also tracked by some signal in 90 MHz yaw.  

Jenne, Sheila, Chris, TJ, Evan

It seems that tonight we have been sabotaged by some code that we have been using for a long time (this haas only happened once that we caught it, although we have a lot of unexplained locklosses tonight).

In the attached screenshot you can see that the DRMI guardian was sitting at DRMI_3F_LOCKED (130) when it decided to go to LOCK_DRMI_1F (30).  There is a decorator in DRMI_3F_LOCKED that apparently returned LOCK_DRMI_1F, because it though DRMI was unlocked (it was fine as you can see from the power build ups in the top row). 

The code that checks for DRMI lock is: 

All rotating vacuum pumps in the LVEA are now off.

HAM11 and HAM12 annulus ion pump currents displayed on MEDM shown in red are, in fact, on-scale on local controllers @ 10mA

C. Cahillane, J. Driggers, S. Dwyer

There was an issue where during lock acquisition at the stage ENGAGE_SOFT_LOOPS, there was a filter (FM2) that was occasionally not being switched 'OFF' automatically by guardian for the filter modules ASC-DSOFT_P and ASC-CSOFT_P. 
In the Guardian code ISC_library.py, there is a function called FM_limit_checker_decorator(FM, sign, action, onstate, offstate) which takes in a filter module FM and changes the state to onstate under certain conditions and to offstate otherwise.  (action specifies the filter 'FM2', sign affects the conditions)

The issue was that FM_limit_checker_decorator always read in FM+'_OFFSET' value, even when the offset filter was flipped off.  I adjusted the FM_limit_checker_decorator code to check if the offset filter was flipped off before populating the FM+'_OFFSET' value.  This is why the code worked when the offset was 0, but could fail if the offset had value but was flipped off.

Jamie, TJ, Nutsinee

Two new TCS guardian nodes have been created. They handle CO2X and CO2Y output power (by adjusting the rotation stages). MIN_POWER outputs minimum power to the optics (0 W). PRE_HEATING outputs 0.1W for CO2Y and 0.35 W for CO2X. And NOMINAL_LOCKED_CO2_LEVEL is outputing 0W at the moment but can easily be changed in the future. NOMINAL_LOCKED_CO2_LEVEL (CO2 output = 0W) is to be used at 20W IFO power.

I have tested PRE_HEATING and NOMINAL_LOCKED_CO2_LEVEL when everything is in a good state (CO2 laser on, no interlock tripped) and they seem to work as I hoped. Once I have a chance to test these states when things go wrong (no laser, interlock tripped) and see that they behave as expected I will make ISC_LOCK talk to it. The state is left at PRE_HEATING at the moment since we mostly stay at 2 W and 10W nowadays.

Replaced the 1A fuses for CP7 and CP8 with a 2.5A.

1/2 open LLCV bypass valve, and the exhaust bypass valve fully open.
Flow was noted after 66 seconds, closed LLCV valve, and 3 minutes later the exhaust bypass valve was closed.

Made measurements of the oscillator power noise with a few photodiodes.

PowerNoise.png shows the free-running oscillator relative power noise
measured before the acousto-optic modulator.  This is more than 10 times
noisier than when the laser was installed in the H1 enclosure.  The
other trace in the plot is the out of loop of the relative power noise.
It is also about a factor of 10 higher than it should be.

    Whilst the power stabilisation was locked, I looked at the AC coupled
output of the photodiode and did not observe any oscillations.  The maximum
peak-to-peak variations were ~40 mVpp.

The X1 PT140 Pirani gauge is reading above the software interlock threshold to turn on the Cold Cathode gauge. Per Chandra's request I have bypassed the software interlock by forcing the variables in Beckhoff on h0velx (see attached screenshot).