(The log is messing up with me and my entry from last night got deleted this morning when I tried to add a plot - new failure mode for me)

Commissioning Team 

Sensitivity status

We achieved  36 Mpc  on Friday, improving the sensitivity over the previous day by: 
Adding cut-offs in the ASC DHARD dofs
Switching off completely the ETMX ESD driver after switching to the low noise ESD on ETMY
Adding MICH and SRCL feed-forward subtraction (still not optimal, but somewhat effective, see  Evan's entry 
We had one single lock lasting for about 2h, while making measurements/tests, so data are not clean (see range summary). We collected only a few minutes of clean data (March 27, 23:50-23:55 UTC, if I remember correctly - Evan please check this). The second plot shows the progression of sensitivity this week, starting from 16 Mpc (not shown in this plot), to the red curve from last night. 

We noticed that the high frequency part of the sensitivity is slightly worse than the previous day, without any apparent reasons beside different initial alignment. 

Also, we learned a few things about data quality based on the analysis of the long lock from the night before. Sheila and Kiwamu tracked down the  ISS glitching problem , which is now fixed (not permanently - need some automatic way of keeping the ISS happy). Also, Josh et al. pointed out that the long lock the other night showed  ETMY L3 DAC glitches , and this needs to be fixed. This adds to the already reported  whistles , that also need attention.


Other news

Daniel and Evan attempted to make the ETMX ESD driver remotely switchable in the afternoon, but this first attempt failed (not a big deal yesterday as we had only one long lock)
On a positive side, adding a digital limiter to the ESD correction signal seems to have solved the problem with the EY ESD driver switching off after each unlock (see   this entry and comments  


Problems in the evening

The last thing we wanted to get done on Friday to conclude this great week was to close the beam diverters on the transmon. At the same time, some of the low noise steps done outside the Guardian (like the BS M2 coil driver switch to low noise) were added to the Guardian code. These two (apparently innocent) goals created a couple of unexpected problems (see  entry 17547  and  entry 17548 ), but I believe at this point Sheila and Jamie fixed both. Also, the wind started blowing hard right after dinner (see  Dan and Evan's entry ). 

For the records, the prophetic words of wisdom that Daniel told us right after the 36 Mpc lock were: "Go home, it can only go down-hill from here". 

On my drive in I saw a kiddie pool flying across Jadwin Ave, so I knew it would be a good day to work on ALS.  The gusts today are up to 45- 50 mph; I can hear the building shake when one hits. While the changes I've made so far aren't enough to lock the IFO under these conditions, there is a lot of progress.

• I've switched back to using the IMC VCO to drive the fiber AOM. 
• Comon tidal feedback is disabled for now (the UGF is set to 0 Hz). This is not needed with the omc vco driving the fiber aom, at least not for locks of tens of minutes
• We are now locking ALS COMM first then DIFF, instead of doing them in parallel as we have been.  Locking ALS COMM was not a problem today once first two things were done, but DIFF locking was trickier since the PLL was not staying in range for verry long at all.  With the IMC VCO driving the fiber AOM, locking COMM means that at low frequecies the Y arm is following the X arm because of tidal.  (COMM means that the IMC VCO follows the X arm, using the IMC VCO to drive the fiber AOM means that with Y arm tidal running the Y arm follows the  X arm.)  Once COMM is locked like this the DIFF PLL stays in range long enough to grab a lock with DIFF.  
• I increased the bandwidth of the X arm  green WFS DOF1 P (to the ETM), the gain changed from -0.003 to -0.01.  This goes unstable with a gain of -0.02, but we could think about adding the PUM to increase the bandwith so that we can supress the motion at the 0.45 sus resonance.  The higher gain is OK when using all the X arm green WFS loops, so I've left it in.  
• With the higher bandwidth ETM WFS and the pitch oplev damping engaged (gain -4500, described in alog 16968), we can keep ALS locked for about 10 minutes although the noise is clearly quite high.  

One more thing, this morning I opened the X end beam divereter and re did the inital alignment.   Now both beam divereters are open. The inital alingment has it's own problems when the wind is this high. 

The problem experienced yesterday in the ISC_LOCK guardian was caused by an errant instantiation of an ezca object in the main importable part of the bs_m2_switch.py module.  This extra ezca instance created a separate EPICS interface that interfered with the one provided by guardian.  Avoid doing this, since, as was shown, it causes problems.

It's understandable why one would think this is necessary, though, because of the somewhat obscure way that guardian provides the ezca interface to the usercode.  Guardian puts a special ezca instance into the main "built-in" namespace which makes it universaly available to all usercode.  When writing usercode modules, though, it's unclear how to emulate this for the purposes of testing, or to make a module usable in other contexts.

I've added the following code to the bottom of the bs_m2_switch.py module.  This makes the module directly executable from the command line, outside of the context of guardian.  The "__name__ == '__main__'" conditional defines code that will only be executed when the code is directly executed, rather than imported by something else.  It then instantiates an ezca object into the "__builtin__" namespace in a way that mimics what guardian does.  The primary function defined in the module (m2_switch()) is then callable in the same way it would be in guardian:

if __name__ == '__main__':
    import __builtin__
    from ezca import Ezca
    __builtin__.ezca = Ezca()
    m2_switch()

This should be considered as a prototype for all other similar modules that people want to be executable outside of guardian.

In general, though, I would encourage programers to make states dedicated to the execution of this kind of logic, which can then executed on their own via e.g.:

  guardian ISC_LOCK BS_M2_SWITCH

model restarts logged for Fri 27/Mar/2015
2015_03_27 13:26 h1fw1

one unexpected restart.

Commissioning Team

We will write a more meaningful entry later, but here is a list of things we did/tried this afternoon, so we don't forget:

• Added cut-offs on ASC DHARD (made the noise better < 20 Hz)
• Completely switched off ESD driver on ETMX after lock acquisition (some small improvement seen around 50 Hz)
• Attempt to make the ESD driver remotely switchable (failed)
• MICH subtraction (it turned out that previously we were actuating not only on L2 as we thought, but on M0 as well)
• SRCL subtraction  (~ 3 reduction in SRCL coupling around 40 Hz)
• Charge measurement
• Low noise MCs SUS (implemented, but not tested yet; we still haven't tried again to switch the SRM to low noise (it unlocked the other day)
• Closing end beam diverters (still work in progress, attempt from full lock failed)

We collected a ~ 2h lock with range around 36 Mpc (not clean data).

Using the latest BRUCO results, I've annotated a hi-res spectrum from last night's lock.  Peaks, bumps, and so on are labeled with the largest coherent channels.

There are a few peaks, at 46, 166, 420, and 689Hz, that are coherent with PRCL/SRCL, and they have changed since the blue reference (Mar 19th at 18:00).  This might be due to the POP --> POPAIR switch.

The source of the 300Hz lines has been identified, it's the BS violin modes.  The frequency is given in Mark Barton's table of predicted violin resonances (thanks Jeff!).

We turned off all the ring heater power supplies yesterday; this got rid of a line at ~74Hz but didn't change the 55Hz line and its harmonics.  These lines are certainly due to some electronics in the EX racks.

Features coherent with the IMC WFS and the PSL persicope are probably the same thing (input beam jitter), hopefully from the same source (PSL PZT mount).

J. Kissel, J. Warner, J. Romie, H. Radkins, N. Kijbunchoo, K. Izumi, G. Moreno

SUMMARY: We just finished ~7 HOUR lock stretch at our best sensitivity ever, between 32 and 34 [Mpc]!

We've all been pleasantly surprised this morning to see that the lock stretch that Sheila Evan, Dan and Lisa started last night lasted the entire night. Unfortunately, as of ~10 minutes ago (~8:40a PDT, ~15:40 UTC), there are GIANT glitches and non-stationarity that keep popping up, spoiling the sensitivity. There's no one in the LVEA, so we're not at all sure what's caused the sudden change in behaviour. Wind seems fine at ~5 [mph], ground motion is still pretty low, the 1-3 [Hz] hasn't even come up yet.

Anxious to explore things, Jim installed some low-pass filters in the HAM5 and HAM6 ISIs at around 8:45 to try to reduce scattering / acoustic coupling to the ISI, and Kiwamu began exploring MICH coupling to DARM. 

But, as I write this log, we lost lock. However, for DetChar purposes, one can assume the detector was undisturbed from March 27 9:00 UTC to March 27 ~15:00 UTC.

The whistles in DARM are still quite prominent in this lock. As briefly summarized in this alog, they happen whenever the PSL VCO frequency crosses 79.2 MHz. This points to the likely cause. This is a reliable enough indicator that we can get some statistics. In the first hour of the current lock (Mar 27 9 UTC to 10 UTC), the whistles happen at a rate of 4 per minute.

Below are four spectrograms. The first two show some whistles identified this way. A new feature is that there seems to be a second oscillator very close by, or maybe some harmonic of the beat note. The next two spectrograms show a minute with several whistles, and the next minute where none occurred. Even when none go through zero frequency, you can still see the beat note hovering up near Nyquist.

Here is a plot of coherences with some PEM accelerometers.  We have been thinking that the noise around 200-250 Hz was due to the PSL periscope PZT, based on coherences like the one in the lower left plot.  However, there is suscpicously similar coherence between the ISCT6 accelerometer and DARM.  Indeed, the coherence between these two accelerometers is high in this frequency range, suggesting that some cross talk could be the dominant signal in these accelerometers.

The right two panels show that the accelerometers which have coherence with DARM around 13 Hz and 16 Hz are also coherent with each other, but not nearly as much.  

Dan, Evan, Kiwamu, Lisa, Sheila (and earlier advice from Keita)

Today we turned on the DARM boost filter described here, to increase the suppression in the 1-6Hz band.  The boost itself was no problem, but we realized that changing the phase of the open-loop gain around 10Hz changes the sign of the ETMY and ITMX bounce modes in the DARM error signal, which means the sign of the damping loops need to change as well.  This led to a few hours of bounce mode excitement, but the new signs and phases are now in the Guardian.

The first plot is a comparison of the OMC TRANS intensity noise before and after the boost filter was engaged.  The RMS before the boost was 2e-2 /rt[Hz], now it is 3e-3 /rt[Hz].  The OMC TRANS camera is much calmer.

The boost filter also reduced the coherence between the OMC length error signal and DARM.  Yesterday, Keita pointed out that the OMC length loop was far, far too coherent with DARM between 1-6 Hz, and this noise was being upconverted around the dither line at 3.3kHz.  The upconversion mechanism is not clear; if the OMC length is properly servoed the dither should not generate any RIN (or, very little) and should not upconvert any low-frequency RIN noise to sidebands around the dither frequency.  But, that's what's happening.  The new boost filter reduces the coherence at low frequency (second plot) and reduces the sidebands at 3.3kHz (third plot), but the coherence at low frequency and at 3.3kHz is not zero (second, fourth plots).

As a precaution against OMC LSC --> DARM coupling, we have reduced the gain of the OMC length loop even further: the OMC LSC boost is now off, and there is a 30Hz rolloff filter (FM3) in the OMC length loop.  The UGF is a little more than 10Hz, as described by the green trace from the first figure in this entry.

Keita also recommended changing the dither frequency and changing the dither amplitude and OMC LSC loop gain.  We haven't had a chance to do these things tonight.  We need to investigate why this noise is being upconverted - note that the amplitude of the 3.3kHz dither line in the OMC RIN increased after the OMC LSC boost was turned off (third plot).

The good ETMY and ITMX bounce mode damping settings with the DARM boost ON are (in M0_DARM_DAMP_V):

The good settings with the boost OFF are:

This switching is handled by the Guardian.

By the way, an ongoing mystery is the source of a 300Hz line in DARM that is very large at the beginning of a lock but steadily decays to the level of the noise floor over a timescale of ~10-20min.  The rate of decay is somewhat matched to the BS butterfly mode and the earlier twin peaks noise, but the line is present when we're locked on RF readout, so it doesn't seem to be coming from the OMC.  We've checked the IOP inputs that are sampled at 65k and we don't see a line at 16384+/-300Hz that could be aliased, but we should check again at the very start of a lock when the 300Hz line is very prominent.

Dan, Sheila

The attached screenshot shows a one second trend of the beckhoff channel that is the fast shutter trigger readback, along with two RCG channels, the first is AS_C sum, this PD should be the source for the fast shutter trigger, and ASAIR_LF,  which should see similar power fluctuations.  

The beckhoff channel seems to be 0.2 seconds ahead of the RCG channels.  This timing difference sometimes makes it appear as though the fastshutter shut first, causing the lockloss, as in the second attached screenshot. 

We would like to prove definteively that the shutter is only shutting when it should, but we don't have a readback that we trust.