07:00 Karen and Cris in LVEA
08:06 Jeff B. turning off dust monitor 16
08:16 Bubba to LVEA to work on LN2 piping for LTS
08:17 Jeff B. done
08:29 Corey to squeezer bay for 3IFO work
08:35 Rick to end Y to check on Thomas and Sudarshan
08:39 Bubba done
09:12 Jim W. working on SEI BSCs
09:17 Alastair putting 3IFO equipment in cabinets in LVEA
09:47 Corey out of squeezer bay
09:48 Jim W. done
09:54 Robert to IOT2 and PSL enclosure
10:02 Travis back from end Y
10:05 Corey and Andres to LVEA
10:09 Corey back
10:13 Andres back
13:39 Filiberto to end X, not VEA, to read serial numbers and pick up tools
14:18 Filiberto done

Added 889 channels reflecting model changes from yesterday.

Several people reported that the DARM calibrated signals from the OAF model did not look healthy in the past two or three days.  Looking at the data in frequency domain, I confirmed that they have behaved funny. Cosulting with Jeff K, we decided to gradually migrate the functionality from OAF to CAL-CS model (alog 16669) because CAL-CS is going to be the official calibration place in future anyways. We are still in the process of moving from OAF to CAL-CS, but a calibrated DARM signal is now available in CAL-CS. The funny behavior seen in OAF is not seen in CAL-CS so far. The calibration accuracy is not yet examined.

(Bad OAF data)

Looking at the data in frequency domain, indeed they looked funny -- the spectral shape of, for example, OAF-CAL_DARM_DQ was suspiciousely featureless with the noise floor around 100 Hz much higher than it should be by a couple of orders of magnitude. Also it did not show a roll-off shape at 5-ish kHz for some reason. A confusing fact is that it sometimes looks behaving correctly and sometimes doesn't. I did not make a further investigation because we decided to move to CAL-CS.

(CAL-CS)

I copied the DARM-related filters that I had in OAF over to CAL-CS. So it is right now completely a duplication of what we had in OAF. I did not move the DRMI, CARM, or IMC filters yet.

The scripts you need are attached here. The main file is bruco.py

When you call the script, there are some parameters that must be set:

# Command line arguments (with default values)                                                                                                                                                                                                                   

# --ifo=L1                    interferometer prefix                                                                                                                               # --channel=OAF-CAL_YARM_DQ   name of the main channel 

# --gpsb=1087975458           starting time

# --lenght=180                amount of data to use (in seconds) 

# --outfs=8192                sampling frequency of the output results (coherence will be computed up to outfs/2 if possible) 

# --minfs=512                 skip all channels with samplig frequency smaller than this

# --naver=100                 number of averages to compute the coherence 

# --dir=bruco_1087975458      output directory    

# --top=100                   for each frequency, save to cohtab.txt and idxtab.txt this maximum number of coherence channels

# --webtop=20                 show this number of coherence channels per frequency, in the web page summary

1. load a list of all channels saved to the frames at the starting time
2. use only channels with the minimum sampling frequency specified in the options
3. delete from the list all the channels in the exclusion list. This is saved in a file called bruco_excluded_channels.txt. The names in this file can use wildcards
4. bruco loops over all the remaining channels, compute the coherence with the main channels and:
   1. save a plot in the output directory. The top panel of the plot is the coherence in double log scale. The script compute the statistical minimum meaningful coherence based on the number of averages, and plot it a a dashed red line. The bottom panel of the plot shows the noise projection, based on the coherence. Only points above the meaningful threshold are plotted
   2. store the value of the coherence and the channel name, for each bin, if the coherence is within the top values, as listed in the parameters. This information is saved in two files cohtab.txt and idxtab.txt. Although you will never really need to use this, here is how it works. For each frequency bin, cohtab.txt lists the highest coherence values, in descending order. This is a huge nbin x nchannels table. The file idxtab.txt is a matrix with the same size, each entry being a unique id that tells you what channel corresponds to that coherence. The fiel channels.txt contains the list of all channels and their id
5. When all channels have been processed, bruco generates a web page summary, that contains, for each frequency bin, a list in descending order of the most coherent channels. The table is color coded based on the coherence

Here is an example, that I'm running right now with the last night lock:

./bruco.py --channel=LSC-DARM_IN1_DQ --gpsb=1107760396 --lenght=600 --outfs=4096 --naver=300 --dir=/home/gabriele.vajente/public_html/bruco_1107760396 --top=100 --webtop=20 --minfs=32 --ifo=H1 

Beware that the processing of all channels takes many hours, when I run it on one machine in the Caltech cluster.

There might be some options to tune in the script, to set where the data is saved. Mainly in lines 106-109. The script is now configured for the Caltech cluster, but I imagine it should be easy to point it to different places where the data is.

As suggested by Dan and Lisa, we might try to speed the script up by running it in parallel with condor or reducing significatly the list of channels. Now, bruco automatically selects 2390 channels.

Elli, Evan

Summary

After Peter and Kiwamu's deep insights into the in-vacuum POP signal chain (LHO#16691), we've transitioned control of the DRMI DOFs from POPAIR to POP with DARM controlled on RF.

Details

First I drove a 1000 ct, 89.1 Hz line into the PRM in order to phase POP. I set the demod phase for POP9 to 90°, making the Q signal a factor of 50 smaller than the I signal. For POP45, I set the phase to 66°, making the Q signal 25 times smaller than the I signal.

With the line still on, I looked at the TFs of the POPAIR/POP signals. For 9I, 45Q, and 45I, POPAIR is weaker than POP by a factor of 0.15 ct/ct, with 0° of phase difference. So I took the POPAIR matrix elements, rescaled them by 0.15, put them into the corresponding POP matrix elements, zeroed the POPAIR matrix elements, and then transitioned.

Then Elli and I remeasured the OLTFs of PRCL, MICH, and SRCL. The PRCL gain was a bit low, so we increased it by 10%. The SRCL gain was a bit high, so we decreased it by 20%. Now the UGFs should be roughly the same as for POPAIR.

The new matrix elements are as follows:

• POP9I → PRCL: 0.035
• POP45Q → MICH: 0.081
• POP45I → SRCL: 0.08
• POP9I → SRCL: 0.005

This last matrix element is just a rescaling of the matrix element for POPAIR9I → SRCL (which itself is just a rescaling of REFLAIR27I → SRCL), so it should be retuned to optimize the PRCL/SRCL subtraction.

Hanford tells us that they will not be hauling container loads on Friday 2/13 either on day or swing.  Their operations will remain quiet through the end of Monday 2/16.

Thomas updated the SUS Drift Mon to the a time just at the end of last nights 2hr lock (2/12/15 07:35:00 UTC, 1107761716 GPS).

model restarts logged for Wed 11/Feb/2015
2015_02_11 11:28 h1fw1
2015_02_11 12:23 h1susetmy
2015_02_11 12:31 h1fw1
2015_02_11 13:16 h1susetmx
2015_02_11 13:20 h1susitmx
2015_02_11 13:20 h1susitmy
2015_02_11 13:27 h1broadcast0
2015_02_11 13:27 h1dc0
2015_02_11 13:27 h1fw0
2015_02_11 13:27 h1fw1
2015_02_11 13:27 h1nds0
2015_02_11 13:27 h1nds1
2015_02_11 13:37 h1calcs
2015_02_11 13:40 h1calcs
2015_02_11 13:42 h1broadcast0
2015_02_11 13:42 h1dc0
2015_02_11 13:42 h1fw0
2015_02_11 13:42 h1fw1
2015_02_11 13:42 h1nds0
2015_02_11 13:42 h1nds1
2015_02_11 14:27 h1fw1
2015_02_11 16:52 h1calcs
2015_02_11 17:07 h1iopoaf0
2015_02_11 17:07 h1oaf
2015_02_11 17:07 h1pemcs
2015_02_11 17:08 h1iopoaf0
2015_02_11 17:08 h1oaf
2015_02_11 17:08 h1pemcs
2015_02_11 17:09 h1calcs
2015_02_11 17:09 h1odcmaster
2015_02_11 17:09 h1tcscs
2015_02_11 17:11 h1broadcast0
2015_02_11 17:11 h1dc0
2015_02_11 17:11 h1fw0
2015_02_11 17:11 h1fw1
2015_02_11 17:11 h1nds0
2015_02_11 17:11 h1nds1

three unexpected h1fw1 restarts. New QUAD SUS code. Install of the h1calcs model. Several related DAQ restarts. Power cycle of h1oaf0 to remove ADC noise from PEM.

I ran my brute force coherence script for the almost 2 hours lock of two days ago (the coherence for last night 2+ hours is running, you guys are locking too often!). Basically this script computes the coherence of the LSC-DARM_IN1 signal with *ALL* available channels. Some channels are supposed to be coherent (for example DARM_OUT), so I have a list of excluded channels. For the moment being I used the same list as for LLO, then I'll see if I need to fine tune it.

The full report is available here:

https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1107680416/

Some preliminary comments:

• noise below ~40 Hz shows a lot of coherence with LSC-ASAIR_A_LF_OUT and other DC channels at AS. I guess this is normal, since these channels are sensing the main beam before the OMC, and the DARM signal is read after the OMC. It is just abuit strange that the power before and after the OMC is fluctuating in a coherent way, but this might simply mean that the low frequency DARM is very noisy and the TEM00 fluctuations dominate over the HOMs. This hypotesis seems to be confirmed by the coherence with signals like SUS-ETMX_L1_WIT_L and similar
• noise below 100 Hz is very coherent with SUS-ETMX_L2_OLDAMP_P_OUT. If I interpreter correctly this name, it should be an optical level damping on ETMX. This coherence is basically enough to explain all the noise up to 50 Hz and most of the noise up to 100 Hz
• In the low frequencies (below 40 Hz) there is coherence with many angular signals at AS port, but interestingly the coherences with those channels have a very similar shape of the coherence with LSC-POPAIR_A_LF. I can't be sure, but maybe this is an indication of large RIN at low frequency?
• Between 40 ans 200 Hz there is some coherence with the MICH control, for example LSC-MICH_IN1_DQ. In the same region (50-300 Hz) there is even more coherence with SRCL control: LSC-SRCL_OUT.
• Above 100 hz there is significant amount of coherence with ISS signals: PSL-ISS_SECONDLOOP_SUM14_REL_OUT

Basically, so far there is nothing new with respect to what Dan reported.

The attached plots are taken direclty from the report, and they show the coherence with some of the channels I discussed above. The top panel shows the coherence, in log scale for both x and y axis. The dashed red line in this panel corresponds to the level of coherence you expect for completely uncorrelated signals, given the resolution and the number of averages. Any coherence at this level or below is completely accidental. The bottom panel shows the spectrum of DARM signal and the noise projection for the auxisliary channel, based on the coherence. It gives a good indication of how significant the coherence is, but of course must be taken "cum grano salis".

The data was transferred to the new hardware per WP 5044. There is a gap in the data from around 8:15 am to 12:10 pm on Feb. 11.

 Evan, Dan, Jeff, Peter, Daniel, Lisa 

 2+ hours lock on DC readout, this time for real! 

* Feb 12, 5:33 UTC lock on DC readout, engaged ISS loops shortly afterwards

* Feb 12, 7:00 UTC improved low frequency noise by turning off ETMs optical lever damping

* Feb 12, 7:35 UTC still lock on DC readout, starting alignment tests (intentionally changing BS alignment; also reduced the BS optical lever damping gain by a factor of 10

*  Feb 12, 7:48 UTC unlocked by closing the AS beam diverter 

 Positive news of the day 

- Thanks to the  improved bounce mode damping , we can now reliably damp the bounce mode, and it is not a limiting problem anymore;

- ETMX and ETMY optical lever PITCH damping loops have been reduced by a factor of 100; it turned out that these loops were responsible for the huge excess of noise that we saw yesterday below 40 Hz, and that was causing the OMC transmission to shake painfully. Now the OMC is quiet and happy  (the Guardian has been updated to reflect this change). 

- We turned off the QPD alignment of the OMC, and replace it with dither alignment;

- We turned on the ISS first and second loops: the positive news is that we improved the high frequency noise by a factor of 10.



 Negative news of the day 

- While we have improved noise at low and high frequency,  we now have a new bump of noise around 100 Hz which was not there yesterday . 

- Our wonderful BS WFS loops, so effective yesterday, were not working today. However, today the BS alignment was not critical, and we have barely had to touch the BS anyway, but we need to figure out what happened. Right now we commented out the BS WFS in the locking sequence;

- Yesterday the locking sequence was very reliable, and worked 5 times in a raw..today it has been less robust, despite similar environmental conditions..

- The RF of in-vac POP is somehow broken - no signal there. It is probably not a big deal right now at low power. 

- We also closed the OMC REFL beam diverter (level 2 of "Valera's levels of awesome": it works, but it doesn't do anything)  

S. Dwyer, J. Kissel, K. Kawabe

After installation of the infrastructure (LHO aLOG 16655), and copying of LLO's filters (and adjusting for the specific frequency of 9.7305 [Hz]; LHO aLOG 16658), we tried damping the H1 SUS ETMY's highest vertical mode (a.k.a. "bounce" mode). 

For the first attempt, the IFO was locked only using ALS diff, with Sheila in the driver's seat. At the time, the mode had been rung up to ~7e-12 (DARM) [m/rtHz] @ 9.7 [Hz]. We had tried a few configurations of the filter bank, and only adjust the gain. We'd found how to ring *up* the mode with a positive gain, with the +60 [deg] (FM2) and bp9.73 (FM4) filters engaged -- then flipped the gain sign (i.e. flipped the phase 180 [deg]), and immediately could see reduction. We had the gain as high as -64, using ~50% of the DAC range, after which took about ~10 [min] for the mode to cool down to the ALS DIFF noise floor of ~1e-12 [m/rtHz] @ 9.7 [Hz]. 

After a lock loss of two, we were able to get as high the IFO guardian state "RESONANCE," with CARM controlled using digitally normalized RELFAIR9, and DARM has been transitioned to AS45 Q. At this point we saw the mode was still quite run up, so we again turned on the DARM DAMP V filter -- same filter combo, and we could see just as quick a reduction with a gain of -64. This time however, we were using much less of the DAC range, so I went up to a gain of -100, and the mode was quickly damped to the RESONANCE noise floor of ~1e-13 [m/rtHz] @ 9.7 [Hz] within a minute or three. 

With these two victories, I'm reasonably confident that this will be our ticket to future bounce-free success.

Design strings:
FM1 "+60dg"  zpk([0],[2.16667+i*12.8182;2.16667-i*12.8182],1,"n")gain(0.0523988)
FM2 "-60dg"  zpk([0],[1.21667+i*7.1979;1.21667-i*7.1979],1,"n")gain(0.0911865)
FM4 "bp9.73" butter("BandPass", 4, 9.3, 10.4)gain(120, "dB")
with all filters set to an input switching of "zero history" and output switching of "immediately." Attached is a bode plot of the final good set of filters together, FM2 and FM4. Note that these filters were loaded individually from each bank, Keita did *not* load the the whole foton file.

I have measured the violin mode using the most recent lock data (February 10th ~5pm). Due to the lack of precisions in the existing information and the mismatch in values I was not able to identify any of the peak except for the ITMX BR (Back Right) at 499.9 Hz. The violin mode found in the recent lock data are as follow:

499.9, 505.58, 505.71, 505.80, 505.85, 505.92, 506.92, 507.16, 507.20, 507.36, 508.01, 508.15, 508.20, 508.85 Hz 

The (fundamental harmonic) violin mode is expected to be somewhere between 500Hz and 520 Hz. Not every line is present - possibly due to high noise floor.

The violin mode has been previously identified as follow:

Positions of the wire:

BL = Back Left

BR = Back Right

FL = Front Left

FR = Front Right

Where's left and where's right you ask? I'm trying to find the answer myself!

J. Kissel

ETMX UIM Driver's rocker switch tripped last night at 8:44:30 UTC (Feb 06 2015 00:44:30 PST), which cause all OSEM output on the L1 / UIM stage (and the sensor signals as well) to fail. 

I've turned on the rocker switch, and the stage appears functional.

Other points:
-------------
There is no smoking gun for this chassis power outage. There are not enough diagnostic tools in the frames to look at all possible suspects (power surge to the chassis [no power monitors], chassis overheating [no temperature sensors], an inconsequential component on say -- a monitor board -- smoking [only one of the four monitor signals for each channel are stored], too large a current request [the NOISEMON is stored, not the FASTIMON]).

Output request of DAC (from any ISC) does not appear to coincide with trip, but difficult to tell with dataviewer. There is an Longitudinal request to drive really hard, but it's unclear whether it's a the cause of or a result of the driver's power being shut off.

Output request is roughly 42 [mA] (according to FAST_I_MON) on all four coils leading up to trip, switch trips on 3 [A]. Even the sudden, very large output request does not cause any current larger than the 42 [mA] -- as reported by dataviewer / EPICs. Reqrettably, only the severely-high-passed-at-5-[Hz] noise monitor signals are stored in the frames, but I attach the time series of one of the coils anyways to indicate the exact time. It shows a nice smooth ramp down at the time of the chassis power down. 

Serial number of this box is S0900303. I attach pictures of the box after I'd turned it back on. When I first approached the box, the front "power" LED lights were OFF, and the rocker switch was in the opposite (powered off) position. 

I'm not sure if there is good way to make this power shut-down control-room visible. I did notice that all the coil driver monitor signals were frozen at -16 [ct], and that the OSEM sensor speed dials were zero for this stage and this stage alone, which is what immediately clued me in that it was a flaw with the entire coil-driver chassis or satellite amplifier. 

This last happened (according to collective analog CDS crew's memory) on H1 SUS ITMX UIM driver, some time ago, 19 November 2013. See LHO aLOG 8635.