Summary: I fit the peaks in OMC mode scan data that was taken with the full IFO locked, plots attached.  Using the carrier peak heights we can estimate the contrast defect; the result for this data is ~150ppm.  It's hard to tell if the sidebands are imbalanced, but the +/-9MHz sidebands don't agree very well in the higher order modes.

Details: Before we handed off to DC readout on Tuesday, I collected a few quick scans of the OMC to measure the sideband & higher-order-mode content at the dark port.  The analysis of this data follows Koji's work for a similar measurement for L1.

The settings for the scans were a 50-second ramp in PZT2_EXC, 100V amplitude with a starting voltage of zero (i.e., sweeping the entire range of the PZT).  All of the switchable whitening stages for the DCPDs were turned off.  The data were collected with DTT, 256Hz bandwidth (sampling rate about 512Hz).  Text files of the data are here: DARM offset on, DARM offset off.  The alignment of the IFO was a little shaky so there is some variation in peak height, but overall the peak structure is very similar from one scan to the next, and the data quality is good enough to resolve peaks out to eighth-order modes.

The mode identification was made based on the expected mode frequency from the known OMC FSR (261.72 MHz) and HOM spacing (57.33 MHz [1]), using a polynomial fit to the voltage of the peaks.  The fit was initialized with one slope parameter using the four TEM00 peaks of the 45MHz sidebands, and refined to a 3rd-order polynomial using the carrier peaks TEM0-9 (these peaks were well-separated from other features in the scan and were easily distinguished using a linear voltage-to-frequency function).  The HOMs for the sidebands (both 45MHz and 9MHz) were then identified using this 3rd-order polynomial.  All the identifiable peaks were ultimately fit using 3-parameter lorentzian functions (after subtracting away the contribution from larger, nearby peaks) to precisely fix the peak height and position.

The first two plots attached show the expected mode location of the sideband and carrier modes out to high order.  Not all of these modes have a matching peak; the choice of which peaks to fit was made using this plot, based on their separation from other peaks and how accurately the peak location matched the prediction.  For example the HOMs of the +45MHz (USB) sideband are degenerate with the -45MHz sideband above order 2, and were ignored.  Also the -45MHz (LSB) sideband modes above 4th order do not fall on a recognizable peak.  The +/-9MHz sidebands (usb and lsb) are distinguishable out to eighth order, although lsb0 is degenerate with CR9, and the lsb1 is degenerate with USB0.

The second two plots show the peaks that were retained for the lorentzian fits; their heights are given in the tables below.  The sum of the fit of the peaks is shown by the orange line.

The final two plots compare the reconstructed peak location, using the 3rd-order polynomial calibration of voltage to frequency, to the expected frequency.  In general the agreement is very good, although in the data with the DARM offset off, the 2nd order lsb (-9MHz) mode is about 1MHz away from where it should be (about 0.14 volts).

Some modes are fit twice (separated by 1 FSR), I have included both peak heights in the table, and averaged them in the sum.  This gives a sense of the accuracy of any one measured peak height - for the smaller modes or modes sensitive to alignment, the variation from one sweep to the next can be tens of percent.  (Sometimes these variations from one FSR to the next are consistent across different sweeps, sometimes not.)  We might try this again when the IFO is more stable.

Carrier Peaks (CRn)

-45MHz sideband (LSBn)

+45MHz sideband (USBn)

-9MHz sideband (lsbn)

+9MHz sideband (usbn)
 

Note that the HOM content of the -9MHz sideband is 3x larger than the +9MHz sideband.  Not sure if this tells us something about the sideband imbalance.

Contrast Defect

Using this data we can calculate the contrast defect in a couple of ways.

First, following Valera's method from the L1 measurement (with some advice from Koji), we assume the higher-order carrier modes (with a DARM offset ON) are due to the contrast defect, minus some misalignment and mode-matching into the OMC.  The alignment for this measurement was good (the power in the carrier TEM00 mode did not change after the OMC was locked and the dither alignment turned on), so I won't correct for misalignment.  Correcting for OM1/OM3 transmission (0.95/0.99), we calculate the contrast defect as the ratio of the carrier TEMnm modes to the carrier power incident on the BS that transmits through the SRM:

Sum of carrier TEM(nm > 00) with DARM offset = 2.62mA.

Carrier power available at the dark port is a function of input power, IO efficiency, recycling gain, and SRM transmission --> Pin * E_IO * Gprc * Tsrm = 2.8W * 0.88 * 33 * 0.37 = 30.1W

Correction for OM1/OM3 transmission, and DCPD responsivity --> 2.61mA / (0.95 * 0.99 * 0.75A/W) = 4.62mW of carrier light into HAM6

CD = 4.62mW / 30.1W = 153ppm

Some of this HOM content is from the TEM00 mode that is not mode-matched into the cavity, so this is an overestimate.  The mode-matching from a single bounce into the OMC is ~0.9, so the overestimate may be at the 10% level.

Another approach uses the data without a DARM offset, and assumes all the carrier light at the AS port in this state (2.80mA) is due to the contrast defect.  Here we get:

CD = 2.80mA / (0.95 * 0.99 * 0.75A/W * 2.8W * 0.88 * 33 * 0.37) = 132ppm

The uncertainty of these results is likely tens of percent, due to the assumption of the recycling gain and the variability of the carrier peak heights.  I haven't accounted for the input power lost to the sideband generation, this will increase the contrast defect by a few percent.

[1]  This value for the higher-order mode spacing is slightly different than what Koji measured on the bench (~57.45MHz).  In my initial fits to the carrier modes there was a small discrepancy between HOM frequency and position (~10s of kHz), which grew with mode number.  The peak identification for the carrier modes is unambiguous (since they are so well-separated from each other and the sideband modes), so I tweaked the HOM spacing until the discrepancy was gone.  Essentially I have used the HOM spacing as an additional fit parameter - since we have >10 data points and five fit parameters (4 polynomial terms + HOM spacing) this seemed like an acceptable choice.  The change in mode frequency is at the 2% level for a 9th order mode.

After the earth quake settled I redid the intial alingment, the DRMI alingment was fine, but something was wrong with the ALS COMM open loop gain.  Attached are TFs measured by exciting into the fast path of the CM servo board, the slow path, and the common path.  A few weeks ago, the UGF was about 250 Hz.  

The IMC_LOCK and ITMX SUS and SEI guardain nodes are running the new guardian and cdsutils release candidates.  All upgraded nodes have been test driven and appear to be functioning nominally.

The current guardian/cdsutils release candiates are:

• guardian: r1344 (/ligo/apps/linux-x86_64/guardian-1344)
• cdsutils: r434 (/ligo/apps/linux-x86_64/cdsutils-434)

The following nodes are running the above versions:

• IMC_LOCK
• SUS_ITMX
• SEI_ITMX
• HPI_ITMX
• ISI_ITMX_ST1
• ISI_ITMX_ST2

This has been accomplished by creating the following file in the node run directories on h1guardian0:

controls@h1guardian0:~ 0$ cat /etc/guardian/nodes/SUS_ITMX/local-env
export PATH=/bin:/usr/bin
export LD_LIBRARY_PATH=
export PYTHONPATH=
. /ligo/apps/linux-x86_64/epics/etc/epics-user-env.sh
. /ligo/apps/linux-x86_64/nds2-client/etc/nds2-client-user-env.sh || true
. /ligo/apps/linux-x86_64/cdsutils-434/etc/cdsutils-user-env.sh
. /ligo/apps/linux-x86_64/guardian-1344/etc/guardian-user-env.sh
ifo='ls /ligo/cdscfg/ifo'
site='ls /ligo/cdscfg/site'
export IFO=${ifo^^*}
export NDSSERVER=${ifo}nds0:8088,${ifo}nds1:8088
controls@h1guardian0:nodes 0$ cat /etc/guardian/nodes/SUS_ITMX/run
#!/bin/bash
set -e
exec 2>&1
if [ -e local-env ] ; then
  . local-env
elif [ -e /etc/guardian/local-env ] ; then
  . /etc/guardian/local-env
fi
exec chpst -e env guardian $(cat guardian) "$@"
controls@h1guardian0:~ 0$

The nodes were then restarted with guardctrl as normal:

controls@h1guardian0:~ 0$ guardctrl restart SUS_ITMX

The local-env files can be removed, and the nodes will be restarted to their pre-upgrade versions (guardian: r1102, cdsutils: r366).

I will proceed with a full system upgrade first thing in the morning.

Peter, Sheila

This morning we found that the input alignment PZT on ISCEZ had the output held, this apparently happened Wednesday morning around 10 am.  The attached trend shows the QPD inputs to the servos and the RMS of the PZT drive signal over the last couple of months.  The rms of the PZT drives is checked to see if the QPD servos are locked, the high threshold had been set to 150 previously but based on this trend I lowered the high threshold to 20.  At this level I think an error message would have been generated on Wednesday.  This probably contributed to our alignment problems over the last few days, when the QPDs were mis-centered more than earlier in the week. 

We were attempting to try locking after this, but have been slowed down by a large earth quake near japan.  

no restarts reported. Conlog frequently changing channels report attached.

Starting guardian upgrade tests on the ITMX SUS and SEI systems (SUS_ITMX, SEI_ITMX, HPI_ITMX, ISI_ITMX).

Evan, Peter, Lisa

Today Evan recovered the DRMI alignment after yesterday modifications of the input pointing . We could go back to about x25 times single arm build-up, and we observed again as  the other night  that we need more gain than before in the TR CARM input to make the transition from ALS COMM, and that the CARM TF is  pretty bad . A  previous measurement  showed a reasonable ugf @ 200 Hz and 30 degrees of phase margin. The same gains now cause the loop to oscillate at ~350 Hz, because of a bump in the TF which flattened the response from 200 to 300 Hz. Lowering the gain brings us too close to instability on the other side (~100 Hz), and we lose lock when trying to reduce the CARM offset.
So, unless something else is wrong, as far as we can tell we need to go through again the painful CARM loop tuning that happened a couple of weeks ago to move on. 

I have been bothered by the problems we had  the other night  during the locking sequence, while trying to lock with the same parameters that worked very well the day before. Also, there have been several instances in the past in which some tuning parameters where good one day, and totally wrong the day after. I have been saying that it has all to do with being in different "alignment" states, but the changes we were seeing seemed too big to make sense even with this typical excuse. 

However, I think it does make sense, at least for some of the lock acquisition failures. Because we use the transmission DC signals as error signals for CARM, we somehow "force" ourselves to move to some fixed build-up value, and we tune our locking parameters accordingly. However, if for example we are not properly aligned, "forcing" ourselves to some pre-defined CARM offset means that we are essentially moving higher up in the sequence than we should be, similarly to the case in which we had high loss in the arms . Attached is one example of what I mean.  

The first plot shows a successful locking sequence, while the second one shows a failed one. In the first plot, for a power build up of X24 single arm, REFL_DC is still 20 and REFL_9I is ~1800. In the second plot, for a similar power buildup, REFL_DC had already started to decrease (17) and REFL 9I is much higher than before, ~ 2500. That would correspond to a much higher build-up (~100) in our "baseline" working sequence, and consequently a different locking tuning (gains, filters, etc). So, it is not surprise that we break lock.

So, the current plan of improving the initial alignment and closing WFS along the sequence is indeed a good one, and most likely all we need.

no restarts reported. Conlog frequently changing channels report attached.

Lisa, Peter, Sheila

Today we tried to investigate the difficulties with locking last night.  We noticed that the spot position on IM4 had moved durring the low pass filter installation yesterday (alog 16719).  We also noticed that the MC WFS were off all day yesterday (IMC-WFS_GAIN was 0 most off the day).   We moved the PZT offset with the MC locked and the WFS on to bring the position on IM4 Trans back to what it was before the low pass swap.  

We then redid the intial alingment, but haven't gotten a good DRMI alingment before running out of time.  (DRMI has locked with the arms off resonance, but the laingment wasn't good.)

We've had another rotation stage failure.  

We noticed the same behavior on thusday night.  We can type in a requested power, the code calculates an angle, but hiting the go to power button doesn't cuase anything to happen.  On thursday as well as the first time that this happened today (around 23:00:12 UTC on Feb 14th) typing the calculated angle into the requested angle box and going there worked.  Patrick looked at trends from thursday night, and it looked like I had not changed the requested power before hitting go to power, but today I am sure that I did, and we have the same behavoir.  

After that happened, I tried to adjust the power using the requested angle, which then stopped working, so I couldn't move the rotation stage without first going to home.  Now that I've gone to home both buttons seem to be working. 

model restarts logged for Fri 13/Feb/2015
2015_02_13 02:28 h1fw1
2015_02_13 09:32 h1fw1
2015_02_13 21:45 h1fw0

all unexpected restarts.

Evan, Kiwamu, Dan, Peter, Lisa

The goal for tonight was to relock the interferometer on DC readout, properly calibrate the spectrum (see  Kiwamu's entry  with today measurements), and in the process see if the  IO periscope PZT filters  had improved the beam jitter noise that we think is responsible for the bump around 100 Hz in the sensitivity.

The only other (known) change with respect to yesterday was the  new DARM filter  designed to give us better phase margin, with the goal (surprise!) of making the locking sequence more robust.

However, we soon realized that we had to retune the transition from ALS COMM to CARM (common mode board input 1 changed from -16 dB to -7 dB) as the current gains were totally wrong (meaning that corresponding OLTF were extremely marginal). We fixed the gains up to the transition to DARM on AS 45 Q, to discover that there was no chance of moving forward with the CARM TF we measured (Evan will post the offending TF later).  

Even if we believe the new DARM filters had little to do with the problem we were seeing, we decided to go back to the old DARM filters and the Guardian CODE which was running last night, as a sanity check. 

Still, we had to keep the low CARM gain to transition to transmission signals for CARM, then we made a couple of attempts to full lock, but we would lose lock before transitioning to AS 45 Q, this time because the DARM gain was wrong..

So, the message is that the problems we see are really easy to identify (loop oscillation, nonsense TFs) and we could keep fixing the locking sequence, but we don't want to make very radical changes in the gain/filter tuning at this time. Old DARM filters and Guardian code are running (as last night). 

This is a brief and preliminary update of the calibration activity from today. I calibrated the ITMX and ETMX reponses using the usual free-swing Michelson fringe.

If I believe the measurement, I must have underestimated the ESD response by a factor of 5.3 (!?) in the previous calibration which is hard to believe for me. I would like to repeat the measuerment perhaps with different conditions (e.g. opelv on/off, L2P off, linearization off/on, different bias, different frequencies and etc) and on ETMY as well.

(MICH free swing)

The method is the same as what Joe described in LLO alog 14135. To obtain the ASQ_pkpk value, I did not run the fancy matlab code or anything, but I just picked up a highest peak value and lowest one in H1:LSC-MICH_IN1_DQ. The alignment was adjusted beforehand by locking MICH. The pk-pk value was measured to be 27.0 counts. Using the relation, d (ASQ)/d(ITMX) = 2 * pi * ASQ_pkpk / lambda, I get

ASQ optical gain = 1.59 x 10⁸ cnts/m

The input power to IMC was at 9.6 W, measured at the periscope bottom PD. ASAIR_ALF could get to 4550 counts at maximum and ASAIR_B_LF 1500 counts when MICH was freely swinging. The below are some dtails:

• ASAIR_A_RF45 whitening gain was set to 30 dB
• Whitening stage 1 and 2 were engaged (probably this was too much as it seemed already limited by some elecronics noise).
• I attach the time series.

(ITMX L2 stage calibration using MICH)

After locking MICH, I shook ITMX L2 stage at H1:LSC-SUS_ITMX_L2_LOCK_L_EXC with a drive level as high as possible without DAC saturation. I did a swept sine measurement to check how high frequency I would be able to get without loosing good signal-to-noise ratio. It seems that exctiation above 20 Hz is hopeless -- the drive signal dives into sensor noise. From this measurement I picked up one frequency point, 13.05 Hz where the ITM response was measured to be

ITMX L2 response = 8.41 x 10^-18 m/cnts @ 13.05 Hz

• L2 coil driver state was set to 2 to get the maximum range.
• No oplev damping loops were engaged.
• MICH loop correction was applied in the estimation of the L2 stage response as was done in Joe's alog 14135. Abs(1/(1+G)) = 0.817 @ 13.05, measured.
• I did not oberve a DAC saturation during the measurement.
• I attach a dtt file of the open loop measurement and ITMX response measurement.

(ETMX calibration using X arm)

Keeping the 9.6 W incident power, I locked the IR laser to the X arm with a UGF of 100-ish Hz. I did a swept sine measurement on ITMX and ETMX at different times but in the same lock strech. On ITMX, the L2 stage was driven again with the same setting as that of the MICH locking. On ETMX, I had set up the suspension filters such that they are the same as the full locking condition (e.g. drive signal goes not only ESD but also L1 stage and so on). Neverthelss, since my swept sine measurement does not go below 10 Hz, the ETMX response essentially represents the ESD response (with a small effect from the L2 stage which is almost two orders of magnitude smaller than the ESD in terms of displacement).

Taking the ratio between the two actuators, I confirmed that the ratio goes as f^2 as expected in a frequency range from 10 to 60 Hz. The ETMX/ITMX ratio was measured to be

ETMX_L3 / ITMX_L2 = 1.70 x 10² @ 13.05 Hz

ETMX_L3 response = 1.43 x 10^-15 m/cnts @ 13.05 Hz. This is almost 5.3 times stronger than what we have in the CAL-CS calibration.

• IM4 and PR2 were controlled by the REFL WFSs in order to maitain the high build up in the X arm all the time during the measurement.
• ETMX oplev pitch damping loops was on at the L2 stage with a gain of -9500.
• The swept sine excitation was injected at SUS_ETMX_L3_LOCK_L.
• The L2P and L2Y were kept engaged on L3 stage on ETMX.
• The L1 coil driver state was set to 2.
• The bias voltage was set to 9.5 V.
• The ESD liearization was on with a force coefficient of -1.8e5.
• I did not see a DAC saturation on ETMX.
• I attach the dtt files.

I set up the BS bounce mode damping loop, tested it and confirmed that it works very fine. One should be now able to lower the peak height of the mode by a factor of 10 or so in a minute.

During the calibration activities in this evening, I ran into a problem with the MICH locking where I was not able to lock it. It turned out that the bounce mode was too high so that the length control saturated the DACs on the BS suspension. I guess that the mode was excited due to several times of locking attempts as I was trying unusual locking settings for the calibration. The below is a screen shot of the bounce mode damping filter:

The design process was essentially the same as similar to what Jeff described for LLO's violin mode damping loos (LLO alog 15000) but I did not try to drive it as hard as DAC saturation. I am leaving the filter enabled for now. If someone find this filter doing something bad, please feel free to switch off at its output (because turning off at the input seems to create a huge impulse response). I did not explore the gain so much.

Replaced hard coded optic and site strings with macros, and fixed sme errors in the on/off indicator, both of which were introduced when copying the DARM_ERR damping stuff from L1:

/opt/rtcds/userapps/release/sus/common/medm/quad/SUS_CUST_QUAD_M0_DAMP_MODE.adl
/opt/rtcds/userapps/release/sus/common/medm/quad/SUS_CUST_L2_DAMP_MODE_FILTERS.adl
/opt/rtcds/userapps/release/sus/common/medm/quad/SUS_CUST_QUAD_OVERVIEW.adl

Attached is a plot of the residual (in-lock) DARM spectrum, calibrated in meters according to the calibration factor that is used in OAF: 2.86e-7 m/cnt for DARM_IN1. The residual is about 7e-14 m-rms. The residual is dominated by the 0.45 Hz quad pendulum mode. We should suppress this peak further. There is a resonant gain filter in DARM, but it is a little too low (0.43 Hz vs 0.45), and just is not enough. However, there is also a dip in the SUScomp filter at 0.45 Hz, which reduces the gain at that frequency by 10-12 dB. This compensates the damped pendulum response -- but what is the point of including here? It's not like we're going to try and have a ~1 Hz bandwidth for this loop. Seems like the thing to do is to remove this feature (some complex pole and zero pairs around 0.4-0.6 Hz) from the SUScomp filter, which will increase the gain at 0.45 Hz by 10-12 dB.

Next would be further squashing the noise from 1-5 Hz. The L1 DARM boosts have more gain in this band, so we could adopt that design. First we should make sure we are not injecting noise at these frequencies from residual OpLev feedback, or quad local (BOSEM) damping.

The piezo low-pass filter box (D1500001) S/N S1500001 was installed.

Measured voltages at the 15-pin analog interface
pin     before   after           signal
1        0.110    0.016          V-MON-X
2        0.206    0.143          V-MON-Y
3        0.109    0.160          V-MON-1
4        0.206    0.143          V-MON-2
5        0.000    0.000          V-MON-3
6        0        4.664          Servo-1 OFF/ON
7        0        4.656          Servo-2 OFF/ON
8                                GND
9        0.160    -0.476         SGS-MON-X
10       1.431    1.173          SGS-MON-Y
11       0.163    -0.472         SGS-MON-1
12       1.430    1.173          SGS-MON-2
13       -13.15   -13.12         SGS-MON-3
14       4.824    4.821          OFL1
15       4.821    4.819          OFL2

DIP switches 1 & 2 were switched from ON to OFF.

To bring the beam back, most of the adjustment was done with the control slider for pitch, which went went a
couple of hundreds on the slider to ~4000.  The yaw slider was adjusted by a few hundred.




Kiwamu, Richard, Peter

I'm always a step behing the on-site commissioners (good job!), but here is the list of coherence for the 2+ hours lock:

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

Here are my main comments on it:

• In the low frequency range (below 20 Hz) there is coherence with some suspension signals from HAM1, HAM2, ITMY, see the first three attached plot for some examples. In particular coherence is high with HAM1/2 at 15 Hz and ITMY at 30 Hz. I'm not very familiar with those systems, so I probably didn't choose very meaningful channels, but if you look into the full table you'll see many of them.
• It's not high, but nevertheless significant: there's coherence between 10 and 100 Hz with PEM-EY_MAG_VEA_FLOOR_*
• Between 40 and 1000 Hz there is broadband, even if not large, coherence with POP_LF, probably due to intensity noise. However, this is the largest coherence in most of this band
• At 75 Hz there is coherence with the magnetometers at the Y end: I guess it's the well known ring heater line
• There is a "bump" of coherence with IMC angular signals between 287 and 300 Hz. This might be one of the beam jitter resonances. There are similar bumps at about 550 Hz and 820 Hz