I took the advantage of the resonated green light this morning and adjusted the camera focus. However, I had a little trouble focusing the End Y camera. Let me know if it is not good enough and I will try to refocus it.

The HAM-ISI MEDM screens were updated to show an orange border when any of the sensors/actuators saturation counters register one saturation, or more.

More detais about this update can be found in SEI aLog #692.

Work was covered by WP #5062, which can now be closed.

I attempted to replace the EPICS gateway machine today as part of maintenance and WP5053, but failed miserably.  The old machine/configuration is now back in place while I figure out why the new machine does not work as expected.  There will most likely be a gap for the vacuum data in the DAQ from appx. 11:40AM local time to 12:45PM (or so), since the DAQ still requires the gateway to get channels in other subnets.  I need to check with Dave that the EDCU actually reconnected to the vacuum channels.

J. Kissel
 
In prep for maintenance activities on the SEI front ends, folks are turning off the SEI system. DARM inputs don't make any sense without a locked IFO, and the optical levers are swinging in and out of range of the QPD (simply because the SEI systems aren't isolated). As such I've done the following:

ETMX:
- turned off optical lever damping (by simply turning OFF the OUTPUT switch)
- turned off the M0 / Top mass DARM ERR damping (by ramping the gain to 0.0 -- it was 0.01)

ETMY
- turned off optical lever damping (by simply turning OFF the OUTPUT switch)
- turn of the DARM violin mode damping (by turning OFF the INPUT and ramping the gain to 0.0 -- the MODE3 bank was ON with a gain of 1.0).
- Zeroed the MODE 1 to Pitch (H1:SUS-ETMY_L2_DAMP_MODE_MTRX_2_1) matrix element.

The summary page with all the coherences is available at this address:

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

I used data from the end of the lock stretch, starting from GPS time 1107840506 and using 600 seconds of data.

The main thing to notice is that DARM is coherent with MICH, PRCL and SRCL over almost all the frequencies, see the first attached plot. This is suspicious, and I'm wondering if there is something wrong with the data I'm using...

There is coherence with EY magnetometers at about 74 Hz, I guess this is the ring heater line.

Restart finished at 0902pst 17Feb.  We'll run this way for an hour or so.

Had stopped running sometime between 1:00 and 2:00 AM last Friday.

The guardian upgrade has started.  All nodes will be moved to the latest guardian and cdsutils releases and restarted.  Will start with all SUS and SEI nodes, then move to ISC.

I've taken a look at DAC MCT glitches as requested by Dan in alog 16707

After running through our usual process to check for DAC glitches coupling into DARM, none of the SUS drive signals seem to be statistically correlated to glitches in DARM when crossing zero or +/- 2^16. I wish I had a smoking gun like we've been able to find with this method in the past, but we've had no such luck.

I wanted to make sure that the triggers indicating these zero-crossings were being generated properly, so I followed up a number of them by hand. They did seem to be reporting the correct times, so it doesn't look like this non-result is a bug in the trigger generation process. I've also generated omega scans for a few times when the ETMX ESD drive signals were crossing -2^16 and didn't see any glitches that looked like the transients we'd normally expect from DAC MCT glitches. This makes me think that the DAC glitches are hiding under the current noise floor (at least in the sense that Omicron doesn't seem to witness them) and will start becoming a more problematic noise source as sensitivity increases.

Is there any way to know when the calibration was last run for the 18-bit DACs? I really would've expected these crossings to cause fairly loud glitches from past experience.

I've attached a normalized spectrogram showing 5 minutes of data from the Feb 13th lock and it looks like there are two separate families of glitches that we can see by eye. One populating the frequency band between ~80 Hz - 300 Hz and one populating the frequency band from ~40 Hz - 100 Hz (which we initially thought might be DAC glitches). I've set some tools running to see if we can identify any of these and we're also doing some by-hand followup of the louder glitches that are likely to show up in omega scans of auxiliary channels.

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

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