An RCG problem with 2.8.4 and later for models using the ramped mux matrix resulted in some of h1lsc's slow channels being channel shifted in the DAQ. This only affects 16Hz slow channels, fast data is stored correctly.

The build release pointer were changed from 2.8.5 to 2.8.3, the h1lsc model was recompiled and installed, the pointers were then reset back to 2.8.5.

h1lsc model was restarted. Due to a change with its INI file, the DAQ was also restarted.

We verified the slow data is  being stored correctly.

WP4832 Cyrus, Jim, Arnaud, Dave

We restarted the h1susquadtst front end in the LVEA. We took the opportunity to remove the RFM 5565 card from the CPU (a remnant of the H2 one-arm-test). The two models running on this front end (h1iopsusquadtst and h1susquadtst) were added to the DAQ and the DAQ was restarted.

On Monday I took Arnaud's h1susquadtst.mdl model and removed all IPC parts. Some inputs on the lower stages were reconfigured to match an ITMY suspension.

Yesterday, somebody started implementing DC-coupled PR3 OL servo actuating on M2 stage, so I made it usable.

Right now it's only for PIT (H1:SUS-PR3_M2_OLDAMP_P), and the filter is a simple 1mHz pole with 0dB DC gain, a 0.6Hz-ish elliptic low pass, and a 74dB gain (this gain is the inverse of the measured DC gain from the M2 OLdamp filter output to the OL PIT,  about +2E-4 rad/count).

With all filters on, the filter gain is equal to the DC gain, and the UGF is equal to 1mHz multiplied by the filter gain.

For the moment the filter gain is set to -10, so the UGF is 10mHz.

To turn it off, turn the filter output off, not the input.

To change the set point, change the filter offset.

WP4834 Jim and Dave

We replaced the 16bit DAC card in h1oaf0 (PCIX card on PCIe adapter) with a PCIe DAC card. This is the second DAC card in h1oaf0, the first is an 18bit DAC. Procedure was:

• stop running models
• take unit out of Dolphin fabric (local command)
• power down CPU
• power down IO Chassis
• replace card
• power up IO Chassis, power up CPU

This does not close out the WP, we have SUS EY and SEI EX still to complete.

The ODC model seems to be down, which took down the mode cleaner guardian since it is writing to some ODC channels.  I commented these out with Jamie's approval, since we don't want the ODC to take down the IFO if its not running.

Trying to get this in before the SEI T&C call. Pictures are from open loop measurements of ITMX. Foton pics are comparing T240 blends and X loops from ITMY and ITMY.

During the relative power noise measurement, the output of the photodiode was 9.715 V - 9.725 V, or a photocurrent of 49 mA.  The measurement is close to the reference measurement.  A little better above 3 kHz and below 10 Hz.  A little worse in most places elsewhere.  In all places much better than the laser requirement.

The frequency noise measurement was done with the common gain set at 30 dB and the fast gain at 15 dB.  The error signal displays a step function behaviour from 2 Hz to about 20 Hz.  This was evident in the previous two scans performed.  We know that the frequency servo needs some maintenance, as the unity gain frequency was previously measured to be around 200 kHz.  The reference cavity transmission was about 1.84 V when this measurement was performed.

Nothing out of the ordinary for the beam pointing measurement.

During the mode scan measurement the following messages were displayed.
[========================                          ]  48%  5m12s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[========================                          ]  48%  5m10s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[========================                          ]  49%  5m08s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[=========================                         ]  49%  5m06s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[=========================                         ]  49%  5m04s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[=========================                         ]  50%  5m02s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[=========================                         ]  50%  5m00s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[=========================                         ]  50%  4m58s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[=========================                         ]  51%  4m56s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[==========================                        ]  51%  4m54s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[==========================                        ]  51%  4m52s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[==========================                        ]  52%  4m48s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
[==========================                        ]  52%  4m46s / 10m00sNo significant mode found! The roundtrip gouy phase might be wrong.
on during data acquisition.
Traceback (most recent call last):
  File "/opt/rtcds/userapps/trunk/psl/common/scripts/noisereport_v0_7/framebuilder.py", line 245, in get_online_data
    raise FramebuilderError()
FramebuilderError

Received 408 secs data, 214.7 MB.
Generated raw data pack "../../../../../../../../ligo/lho/data/psl/psl_noisereports/2014-09-09/dbb_msc-001.zip".
Generated report "../../../../../../../../ligo/lho/data/psl/psl_noisereports/2014-09-09/dbb_msc-001.pdf".

This is the first time I've seen such messages.  Doing a visual comparison between the modescan from today and last week's scan, there are no noticeably different peaks present in the normalized power vs. frequency plot.  The reported higher mode power is nominally the same at 4.5%, although the number of higher order modes counted is lower in this week's scan (53 vs. 58).  The relative misalignment reported for this week's scan is lower.

A repeat of the modescan measurement did not encounter the same problem(s).  The problem must have been related to something in the data acquisition system.  The second report generated didn't look all that different from the first report.

The ISS relative power noise measurement was done with the gain slider set to 10 dB and REFSIGNAL to -2.03 V.  The diffracted power is reported as ~9.5%.  The output AC levels of both photodiodes A and B is 2.03 V and 2.07 V respectively.  The offset slider is set to 4%.  The out of the loop measurement looks good.  Almost flat from ~1 kHz to 30 Hz.  The low frequency part of the spectrum is better than the reference measurement from about 40 Hz down.  The position plot at the end of the report looks like something is clipping.  We might want to look at this when we have an appropriate time.

I measured the Michelson contrast in the daytime today. It was 99.1 %. No ring heater or CO2 lasers were engaged during the measurement.

I used ASAIR_A_LF to observe the DC light at the dark port.

• bright fringe = 1156 counts
• dark fringe = 5.0 counts
• contrast = (1156 - 5) / (1156 + 5) = 0.9914

Lisa, Sheila, Alexa, Nic, Jamie, Kiwamu

We managed to lock the PRMI on the sidebands tonight. We estimated the servo gain settings from the gains in the carrier-locked condition. The lock was stable and lasted for more than 40 min.

Also, we saw an angular drift in pitch of PR3 when the carrier was locked. This behavior was consistently observed.

(Carrier lock)

We intensively worked on the carrier-locked PRMI in the daytime and we could repeatedly lock the PRMI on the carrier. The script which Alexa wrote is now interpreted in a guardian code by Sheila. It uses the variable finesse technique. The code is available but it is still a working progress. 

At about 3 pm local, we noticed that the motion in the Michelson was too large for us to keep locking the PRMI. At that time, Fil and Aaron were working around the beer garden, but this may not be a direct cause of the Michelson fluctuation because we did not see a significant improvement after they left. At this particular point, we could not keep closing the Michelson locking loop because of too large angular motion in the Michelson. This large motion gradually disappeared some time later and we could get back to the locking activity in the evening.

(PR3 tends to drfit in pitch)

When we locked the carrier-PRMI, we noticed that the power build-up degraded on a time scale of approximately 10 minutes or so. After some investigation, we identified it to be PR3 which drifted only in pitch by about 0.5 urad. We repeated the same observation a couple of times. PR3 always tends to drift to the negative side in the oplev counts. After a unlock event, it tends to go back to the original angle on a similar time scale. This indicates some kind of thermal issue. In fact, I did not observe a similar effect when the PRMI was locked on the sidebands. Sheila implemented an oplev servo on PR3 to mitigate the issue. In parallel, we should start working on some ASC loops.

Also, the BS oplev showed an approximately 0.5 urad drift once, but this did not seem to correlate with the power degradation. Perhaps this was simply some readout noise or something.

(Carrier lock without the variable finesse technique is difficult)

I still don't understand why this is so difficult, but locking the carrier-PRMI without the variable finesse turned out to be difficult. Since we already knew the right gain settings based on the variable finesse condition, we tried locking the PRMI directly. However, I succeeded in locking it only once. Plus, the lock did not last more than 20 seconds or so. Probably this was because I did not have the power normalizations which make the servo loops less sensitive to the angular fluctuation in the PRMI. This needs further investigations.

According to the variable finesse technique, we estimated the right MICH gain with ASAIR_RF45_Q to be -7, and the PRCL gain to be -0.2 with REFL_A_RF45_I. When I obtained the short lock, the gain settings were -9 and -1 for MICH and PRCL respectively. I used a trigger and triggered filters for both loops. It was around 4:23:56 in UTC.

(Sideband lock)

We then moved onto locking of the sideband-resonant PRMI. I simply flipped the sign of the PRCL loop to do this. But, this did not work -- I did not get a short lock. So I suspected some kind of cross-coupling in the sensing matrix and started trying to the other REFL sensor, REFL_A_RF9, which should be less sensitive to the Michelson motion. I measured the difference in the readout gain of the RF9_I and RF45_I by locking the carrier. The RF9 was smaller by 13 dB than the RF45. Taking this into account I tried some gain settings in MICH and PRCL while keep using ASAIR_A_RF45_Q for the MICH control. I attach a trend of some signals below to show the PRMI had been locked for a while, more than 40 min. Note that I did not have to re-align an optic to maintain the lock. I did not see drift in PR3 in this configuration.

The first acquisition was made with a MICH gain of -10 and PRCL gain of 0.7. These numbers are not far from the expected. Once it started locking, I tuned up the alignment, demodulation phases, UGFs and locking thresholds. I attach a screenshot of the whole settings, MICH  and PRCL open loop transfer functions.

It seems that lock acquisition is smoother with a slightly lower gain in MICH. For example, I kept using a MICH gain of about -7 for locking and increased it to the nominal gain of -17 once it was locked.

J. Kissel, S. Sachdev, K. Venkateswara

Krishna discovered that the Beam Rotation Sensor software had stopped outputting data around Sep 4, Thursday, night ~11:30 PM (~1093890000). Unclear why the software had failed, but it meant we had take a trip to the X-end to restart the software.

Instructions to restart the software:
(1) Head into computer users room, and wake the windows laptop sitting on the shelf ~1m up in the last rack on the left.
(2) Note the "rate" number in the upper left corner -- this is actually the DC value to which the BRS has drifted.
(3) Close the running analysis screen, by exiting out of the window (the red x in the upper right corner). This stops the software.
(4) Find (ctrl+F) the line in the code with the comment "DC subtract here," and change the value that's subtracted from "refLP[2]" to the "rate." Subtracting off the DC component of the signal helps reduce the impulse sent to the 1 [mHz] high-pass filter, therefore reducing the ring-down time upon start-up.
(5) Save the updated code (ctrl+S).
(6) Restart the software by hitting the "|> Start" button in the top-middle.
(7) Check that you now see reasonable rotation sensor signals in the raw ADC channel, H1:ISI_GND_BRS_ETMX_RY_INMON.

The DC value we subtracted was 1227 [ct]. The second attachment is pictures of the screen for steps 4&5 then 2&3.

In addition, I was showing Surabhi around the PCal components, so we rung up the BRS. So we spent ~30 minutes damping the suspension with our mass. This was only my second shot at this flying solo, so it took a little while to remember how massive I am. Instructions supplementing the notes from LHO aLOG 13538,
To damp:
- Open up a StripTool watching H1:ISI_GND_BRS_ETMX_RY_INMON close enough to the BRS that you can see it, but still an appreciable distance away (I plug the workstation into the wall socket on the West side of the BSC9, and push it as far North as I can).
- When the tilt signal is just after the maximum on the upper-half of its sign wave, stand close to the North (+X) side.
- The tilt signal is influenced artificially by the 1 [mHz] high-pass filter, which causes the signal to turn up deceivingly fast as one stands near the BRS -- don't wait until the trough to step away from the BRS.  
- As the resonance gets damped, you need to stand near for less and less time
- +/- 500 [ct] amplitude = need to stand on one side for a full half cycle (~30-50 seconds), +/-50 [ct] amplitude = only a few seconds at a time
- +/- 25 counts is good enough. 
- Once the tilt signal is at +/- 50 [ct], I (at ~180 [lbs], or ~80 [kg]) need only stand as close as the Southwest HEPI pier for 5-10 seconds to create the right amount of damping force.

First attachment is a time series of our trial and error attempts at figuring out the above procedure.

I was skeptical about my  previous mode matching model , which indeed was not right. 
I didn't have the correct SR2-SR3 and SR2-SRM3 distances ( E1200616 ) calculated according to the H1 SR3 and SR2 ROCs. 

Based on lessons learned from L1, we expect the matching to the OMC X/Y in single bounce to be determined by the different ITMs ROC, while the overall scale is set by the combination of PR3(SR3) ROC + PR2-PR3(SR2-SR3) distance. 

The "theoretical numbers" for the PR2-PR3(SR2-SR3) distance calculated on the base of the measured PR3(SR3) ROCs should give us a mode matching close to optimal.

Indeed, the theoretical numbers for the mode matching are closer to perfect mode matching, as it should be: 

single bounce X = 96%
single bounce Y = 99.5%

Because of the uncertainty in the PR3 and SR3 ROCs, and in the PR2-PR3(SR2-SR3) distance, the overall matching can be somewhat worse, and the X/Y asymmetry should be amplified by the SR3 ROC/ SR3-SR2 length mismatch. 

For example, a mismatch SR3 ROC / SR2-SR3 length equivalent to 1 cm error in SR2-SR3 length would give us:

single bounce X = 90%
single bounce Y = 96%

A mismatch SR3 ROC / SR2-SR3 length equivalent to 2 cm error in SR2-SR3 length would give us:

single bounce X = 82%
single bounce Y = 90%

And so on. 

However, based on  Koji's calculations, we see pretty much the same mode mismatch X/Y (12%-13%). 

So, the message is that we can't really predict the overall matching to the OMC, given the uncertainty in the recycling cavity parameters. However, we should be able to see an asymmetry X/Y due to the different ITMs ROCs. The measured OMC matching numbers are not unreasonable (12%-13%), but they don't show the X/Y asymmetry that we expected. I am not sure why, but probably we don't care now. We might at some point want to repeat an OMC X/Y scan with dither on to have more precise measurements.

Added 200ml water to diode chiller to silence intermittent alarms.   

LVEA is Laser Hazard

08:50 Hanford Fire Department on site for annual fire extinguisher inspection
10:24 Jason – Alignment of ITMX OpLev
11:08 Bubba & HFD – Fire extinguisher inspection in LVEA
11:05 Mike – In LVEA working on charging experiment
13:00 Filiberto – Pulling cable between HAM2 and HAM3
14:03 Jeff K. – Taking students to End-X
14:40 Add 200ml water to diode chiller
14:42 Jason – Realign PR3 OpLev

After ~3 hours of pumping with an aux. cart, I started IP4 -> I isolated and decoupled the aux. pump cart once the HV and current were at normal values

Note - all IPs are valved-out at this time, Corner Station still being pumped only by YBM and XBM turbos

The new H1 ITMs ROC (ITM03 and ITM11) are similar to the ones in L1, but they are swapped (the wavefront error is larger from X than from Y). 

Based on  T1300954 (table 3) and Hiro's wisdom, the effective ROCs of the H1 optics, as measured in reflection, going through the bulk, are:

R_ITMX (ITM03) = 1939.3 + (-10.92*2*1.457); 
R_ITMY (ITM11)= 1939.2 + (1.56*2*1.457);

By looking at the L1 data in single bounce without TCS (below), one should expect something like ~20% mode mismatch for X and something somehow better for Y.

L1 Mode mis-match:
NO TCS:
ITMX    14.5%
ITMY    22%

Even with an input beam perfectly matched to the PRM, I would expect something like:

modematching asX with OMC = 0.8408
modematching asY with OMC = 0.91229