We didn't get any new Mpc tonight, but we definitely have a record for mph.  The attached plot shows the wind reaching 45mph while we were locking. Previously, we were having dificulty locking with wind speeds between 20-30 mph.  Margartia's plots show  that previously the wind would have caused difficulty locking something like 15-10% of the hours in a year, while now the wind should only interfere with locking about 0.7% of the year.  

Now the wind is gusting up to 60 mph, and we are still able to lock ALS, the problem now seems to be with DRMI, which can acquire lock but looses it after less than a minute.  

This is a lot of progress. Last spring, we were struggling just to have the seismic system not tripped with winds of about 30 mph, so it has taken a lot of work from a lot of people to be able to lock under these conditions.  Some of the major steps were: fixing watchdogs, improving the seismic performance, high bandwidth tidal from ALS, green WFS, windy blends,  L2P on ETMX, switching the ALS fiber AOM drive to the imc VCO, and lastly, we've added the Oplev damping back for ETMX tonight once the gusts were above 50 mph.  We could think about high bandwidth green WFS instead.  

Sheila, Ed, Ross, Evan

This morning we had another incident where we seemed to have glitches in the channel H1:ALS-Y_REFL_CTRL_OUT_DQ that could have been the cause of ALS locklosses, similar to what was described in alog 15242 and alog 15402.  Some screenshots are attached.  There is a distinctive pattern in the REFL CTRL signal, and the error signal (ALS-Y_REFL_ERR_OUT_DQ) has a large glitch, as well as the transmitted green light (ALS-C_TRY_A_LF_OUT_DQ).  Today these things were happening only every 10-15 minutes, but that is often enough to prevent locking.  As before this problem went away after a while, without us doing anything to fix it.  Several screen shots are attached. These glitches sometimes show up in the X arm, but that could be because the DIFF control imposes them on the X arm even if the originate in the Y arm.  The glitches still happen when we had tidal off, and COMM unlocked, so I would not think that there was anyway a glitch that originated in the X arm could have been imposed on the Y arm.  There are no coincident gliches in the Optical levers or in the Fiber control or error signals. 

It would be good to know how often these glitches happen, how intermitent the problem has been over the last several months, and how often they coincide with a lockloss.  Ed and Ross started to look into this, and started a script to identify these glitches in a way that is easier than looking though a time series.  I made an attempt to use omega scan on ligodvweb, but I ran into trouble producing a plot.  

I am wondering if anyone from Detchar has tools that could be helpful (and maybe used from the control room?) in finding times when these glitches have happened.  

The optimal location for  a single version of Krishna’s BRS (intermediate frequency tilt sensor), or, if it would be better to have two of them, depends on the tilt spectrum in the beam direction. We suspected that wind-induced tilt is worse at EY than EX, where the BRS is currently located, because, for typical wind storm directions, the building is being pushed roughly along the beam axis at Y-End and roughly perpendicular at X-End (the tumble weeds usually roll down the Y-Arm). But we aren’t sure whether a single sensor at EY would make sense (e.g. if EY is 10x worse than EX) or if two BRSs would be better.  Since we have only the one BRS, we used the 0.03-0.08 Hz band of STS seismometers to compare the two stations. This frequency band was selected as a proxy for tilt because this band is below the microseismic peak frequency and, in windy conditions, ground motion in this band is usually dominated by tilt. Figure 1 shows the strong correlation between the 0.03-0.08 Hz seismometer band and the tilt measured by the BRS at EX for one wind storm. Each of the small points in the plots in this log represent a 60s average of the wind speed and a 60s fft of the ground motion.

Figure 2 shows 4 months (Aug 15, 2014 - Dec 15, 2014) of the 0.03 to 0.08 Hz beamline seismic band at EY and EX plotted against wind speed measured at EX.  The large red and blue dots show the median of minute points in 2 MPH bins. Dipongkar has plotted the median because large earthquakes, which also appear in this band, would bias the mean. Roughly speaking, for a particular wind speed, the signal at EY is twice the signal at EX when averaged over many storms in 4 months. This data suggests to me that we may want a second BRS at EY rather than moving the sensor from EX to EY, because the difference is, on average, only a factor of 2.

The differences between the stations can change for different wind storms, possibly because of different wind directions. Figure 3 shows the effects of individual storms (each storm is a different color, the same color on both plots) at the two stations. One of the storms produced about 5 times more beam-line tilt at EY than at EX.

Caveat: Getting this data is very time-consuming, so we are putting in this log even though we have obtained only 4 months of data. Dipongkar will continue to increase coverage to include the spring windy period and we will update if necessary.

Robert Schofield, Dipongkar Talukder

Scott L. Ed P. Joe D.

Starting at X-1-7 double doors and moving north towards single door.

Vacuumed tube supports and sprayed bleach/water mixture on soiled areas of floor. Cleaned D I water tank and vacuum machines. We have started cleaning the machines every time we fill the D I tank. 
Sampled dirty sections posted here.
We are installing support tube caps on previously cleaned supports.
Started tube washing after lunch and cleaned 28 meters to the north.
Continuous monitoring of beam tube pressures by control room operator during cleaning operations.   

This is a slightly edited version of the original sample aLOG done by Andres Ramirez with actual current values:

Laser Status: 
SysStat is good
Front End power is 31.8W (should be around 30 W)
FRONTEND WATCH is GREEN
HPO WATCH is RED

PMC:
It has been locked 13 day, 4 hr 37 minutes (should be days/weeks)
Reflected power is 2.2 Watts  and PowerSum = 22.6 Watts.
(Reflected Power should be <= 10% of PowerSum)

FSS:
It has been locked for 0 h and 4 min (should be days/weeks)
TPD[V] = 1.4V (min 0.9V)

ISS:
The diffracted power is around 7.2% (should be 5-9%)
Last saturation event was 0 h and 6 minutes ago (should be days/weeks)

NOTES: ISS diffracted power was up to ~11% this morning. Since we prefer it in the 7-9% range at this time I've adjusted the refsignal from -1.08 to -2.03 to yield ~ 7.5%

In order for the remote on off switch to work we had to remove the sequencing module and set the jumper to the proper pins.  We then connected a BNC to 9pinD cable to the Beckhoff interface.  For EX Stuart A was able to switch the unit on and off with little trouble using a command line.  The MEDM will follow.
 
EY was not nearly as successful.  After moving the jumper Stuart was able to turn the unit on but not off.  After turning it on you could hear and audible sound as though a relay was continuing to switch.  The unit would not turn off.   I was able to operate the unit using my DVM set to continuity by touching the center pin and the shell.  The ESD would turn On and OFF.  Not sure if it is an ESD sequence module of the Beckhoff chassis.  Will investigate further Tuesday.

All Watchdog tripped on the M7.5 earthquake (~ -20 hr) but survived the M4.8 at ~ -12 hr.

PSL frequency noise is better than indicated in DBB (diagnostic breadboard) scans.

JasonO et al. have been running weekly DBB scans  (see this link) that indicate that the PSL frequency noise is well above requirements.

However, spectra of MC_F, the IMC control signal that drives the VCO indicate that the frequency noise is much better than what is reported by the DBB.

Attached below is a recent DBB report and spectra of MC_F taken during a recent full interferometer lock.

I took a look at the ISS this morning and found the dfifracted power up around ~11% + with a ref signal of ~ -1.8. It's been adjusted to ~ 7% at a refsignal of -2.02. Also, FSS TPD[V] are down to 1.4 from 1.6. There maybe the need for incursion on maintenance day to do touch ups and discovery.

[Evan, Koji]

M7.5 - 55km SE of Kokopo, Papua New Guinea 2015-03-29 23:48:31 (UTC)

The EQ knocked off most of the HEPI/ISI/SUSs. The ground motion calmed down after a couple of hours.

The WDs were reset.

Current status:

- All of the HEPIs are in the "ROBUST_ISOLATED" mode.

- All of the HAM ISIs are in the "ISOLATED" mode.
  All of the BSC ISIs except for the BS ISI are in the "FULLY-ISOLATED" mode.
  BS-ISI is in the "ISOLATED_DAMPED" mode. (As it was like this, I left it so. If it is necessary to go to "ISOLATED", please do so.)

- All SUSs except for PRM and SRM are in the "ALIGNED" mode.
  PRM and SRM are in the "MISALIGNED" mode.
  WDs of the TTs were restored too.

An attempt to measure the amount of misalignment that is currently present  in the PSL-to-IMC coupling.

First I centered the direct reflection from the IMC onto the WFS A and WFS B sensors.  There was about 30% reduction in the RIN.  See attached png and xml files: IMC_jitter_centering.*

Next, I  injected an excitation in to the PSL_PZT pitch and yaw  at 7.33 Hz .  I then took a PSD of the IM4_TRANS_SUM signal to measure the power fluctuations in at 7.33 Hz and 14.66 Hz (P1f and P2f) respectively. 

Attached files show these peaks in the IM4_TRANS_SUM spectra.  Attached also are the xml files which have the data and an excel file which has the computation of the amount of misalignment.

In summary: 

       1)  Pitch misalignment is 0.6% of the IMC cavity beam divergence

       2) Yaw misaligment is 1.2% of the IMC cavity beam divergence.

An attempt to see how the misalignment could have arisen:

I  tried to vary several offsets to see whether this coupling from jitter to RIN could be changed.  The ones I tried are

a) Common mode offset in the MC servo board: To see if a length offset is causing this H1:IMC-REFL_SERVO_COMOFS

b) Slow offset in the MC servo board H1:IMC-REFL_SERVO_SLOWOFS

c) Slow out offset in the MC servo board H1:IMC-REFL_SERVO_SLOWOUTOFS

d) DOF1 to DOF3 offsets in both both pitch and yaw in the MC WFS servo loops.

None of these by themselves had a significant impact on the jitter to RIN coupling.  More investigation required.

And now for those nay sayers :-)  Things I did not do!! 

1)  I returned all offsets to where they were.

2) The MC2 spot is centered and the IM4_TRANS spot has not moved from before to after my WFS centering => output beam has not shifted

3) The WFS outputs were not off loaded: the IMC alignment slider values have remained the same

4) No other Pico motors other than that of IMC WFS A and IMC WFS B were touched.

So in essence if something broke, its not coz of me!!  :-p

(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

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).