(Rich, Stefan)

We installed jumpers in the coil drivers (D1100117) to permanently enable input on/off switch and the run switch. The affected the following coil driver serial numbers:

S1106044 (RM1), S1200612 (RM2), S1106043 (OM1), S1200608 (OM2), S1200614 (OM3)

For proper operation H1:ASC-RM2_BIO_M1_STATEREQ needs to be set to 2, and the anti-dewhitening filters need to be in FM6 of the H1:ASC-RM?_M1_COILOUTF_?? filter modules. (FM1 is reserved for the sim-dewhitenig filter.)

Jason, Tyler and I measured the BSC9 chamber longitudinal position from the face of the gate valve (GV19) nearest to the termination slab and compared it to the drawing position call outs. We found the chamber to be 6.01mm further north than the drawing perfect position. 

We set a new monument on our offset line perpendicular to BTVE-8 and measured longitudinal positions for EX-B1 ,EX-T3, IAM-17.
So far first error found is BX-B1 has a positive error 19.5mm +X which caries over to EX-T2 which we are using to shoot the ETMx from 
When we finish up with the BSC9 chamber centerline we will know more.

Roofing was interrupted this afternoon when a sudden thunderstorm came through. The crew covered what they could before scrambling off the roof. Some water managed to get into the building - primarily along two open edges and a few other locations at screw holes. The worst hit area was the return air plenum at the north west inside corner of the building. The weather has cleared and the roofers should be able to lay membrane material down for the night in case we get more rain.

If you need rain in your garden just start working on your roof! Or wash your car.

(Keita, Stefan)

We noticed that the feed-back gains of RM2 were the opposite of RM1. So went through all 6 tip-tilts that we have at LHO, and determined their magnet polarity:

As viewed from behind (incl magnetic pole facing backward):
Default:
  UL: N, UR: S
  LL: S, LR: N
The following serial numbers are conform with that: 009 (bad wire), 002, 033, 004, 022 (RM1)

Serial number 024 (RM2) is different:
  UL: S, UR: N
  LL: N, LR: S

For now we flipped the digital coil gains of RM2 to account for that.

Venting completed at ~2:45 pm. The purge valve on the X manifold has been dialed back until a door can be removed.

[Jeff B, Stuart A]

After a few power glitches etc, the triple test-stand was in need of some attention prior to hooking-up OMC suspensions for Phase 1b testing.

Logging in remotely, I noticed that the incorrect model was running, x1sushxts27 instead of x1sushxts05, so I re-started the *05 model. I then BURT restored the safe snapshot (/opt/rtcds3/tst/x1/userapps/release/sus/x1/burtfiles/20130911_x1sushxts05_OMC.snap) I had already previously taken of the OMC configuration (see LHO aLOG entry 7728 for further details). 

The triple test-stand should now be ready to accept OMCS for testing.

Before taking the beam jitter measurements last Friday (aLOG post coming soon), I adjusted the input filter offsets for each individual MC2trans and IM4trans DCQPD quadrant such that even with the shutter closed they always read a (small) positive number of counts. This should ensure that the SUM channels never swing through zero. The purpose of this was to avoid the "divide by zero" errors in the pitch and yaw channels, which are normalized by the SUM values.

After adjusting these offsets, the DCQPD SUM dark levels were:

MC2trans DC SUM dark level: ~1.5 counts

IM4trans DC SUM dark level: ~1.3 counts

This is a write up of various measurements of the MC2 violin modes done from 7/29 to 9/12.

Much of the procedure was based on Keiko's LLO alog 5097. All excitations were done at H1:SUS-MC2_M2_DRIVEALIGN_L2L_EXC, and readback at H1:IMC-F_OUT (later H1:IMC-F_OUT_DQ).

For initial mode ID (7/29) I used awggui for excitation, with amplitude of 1000000, and a cheby1("BandPass",1,1,620,680) filter, and searched with DTT in the same range (620-680 Hz). I tried measurement bandwidths of 0.01 and 0.001 Hz but 0.01 Hz turned out to be plenty. For the higher harmonics I scaled the range by 2, 3 and 4. With this approach I was easily able to find all n=1 and n=2 modes, and 3 of n=3, but no n=4.

Later (9/5) I went back and did narrow band searches where I had previously found peaks, and where I suspected n=3 and n=4 peaks. I used DTT for excitation, with Gaussian noise of amplitude 5e6 over a range of 1 Hz for n=1, 2 Hz for n=2, etc, with filters like cheby1(BandPass",1,1,644,645). I labelled the four wires "a", "b", "c" and "d" in increasing order of mode frequency. Because the main focus was to find the n=4 peaks, I did 1a, 1b, 1c, 1d, 2a, and then skipped straight to the ones I hadn't found before:3a, 4a, 4b, 4c, and 4d, and this time I found them easily.

On 9/6 I started trying ringdown measurements. I adapted the DTT files from 9/5 as monitors, switching off the excitations (e.g., . To excite the modes I reverted to awggui, with a sine excitation with amplitude 30000 at the previously identified frequencies. I then did a parallel set of Triggered Time Response measurements, with 1 average of 500 s.

On 9/8 I went back and dide mode ID for the ones I skipped on 9/5, 2b, 2c, 2d, 3b, 3c, 3d.

On 9/12 I did ringdown measurements for all 16 modes, except that to work with Keiko's analysis script I used 10 averages of 1/10 the length. Since the Q's for the higher harmonics were expected to be similar but the frequencies were higher,  I used 10*24 s for n=2, 10*16 s for n=3 and 10*12 s for n=4. This was nearly a disaster because I didn't export as I went and DTT has a bug that it doesn't save the separate segments in the .xml file for a triggered time response with averaging. Fortunately the start times were store in the files so I was able to rerun them retrospectively and export them as .txt files.

I adapted Keiko's scripts to process all the files as a batch and save the plots as a PDF (see first attachment) in the manner of the many other SUS scripts such as plotquad_dtttfs.m. The adapted scripts are in ^/trunk/Common/MatlabTools/ViolinModes and the primary script is plot_vm.m. It writes a summary PDF to ^/trunk/HSTS/H1/MC2/SAGM2/Results (or the like, depending on the settings at the start of the script). It also generates a summary table like the following (except that the notes in parentheses have been added by hand):

1a: f = 644.641 Hz, Q = 227793.765
1b: f = 648.734 Hz, Q = 223441.7436
1c: f = 654.758 Hz, Q = 225393.2642
1d: f = 661.492 Hz, Q = 220474.6201
2a: f = 1289.38 Hz, Q = 158588.9576
2b: f = 1297.58 Hz, Q = 160877.9141
2c: f = 1309.7 Hz, Q = 145061.1334
2d: f = 1323.02 Hz, Q = 155196.8117
3a: f = 1934.4 Hz, Q = 169442.0117 (poor S/N)
3b: f = 1946.62 Hz, Q = 142432.5364
3c: f = 1964.75 Hz, Q = 131593.7049
3d: f = 1984.85 Hz, Q = 131407.1051
4a: f = 2579.77 Hz, Q = 1454265.3967 (very poor S/N)
4b: f = 2596.1 Hz, Q = 2302393.4224 (very poor S/N)
4c: f = 2620.29 Hz, Q = 255698.7597 (poor S/N)
4d: f = 2647.04 Hz, Q = 161984.0682 (poor S/N)

All the n=1 and n=2 ringdowns had excellent S/N, as did 3 of the n=3. The n=4 ringdowns ranged from poor to very poor. I tried running the data analysis from T1200418 on the data through n=3 (see second attachment), but the fit is poor and results in unphysical negative values of structural phi.

When the modecleaner is next available, I will redo the n=3 and n=4 modes, experimenting with different actuation frequencies to get higher levels of excitation of the modes.

h1fw0 is regularly crashing, log files suggest the SATABOY file system is sluggish. Dan is coming up to the MSR to investigate.

Providing h1nds1 is the default NDS, most users of the DAQ wont notice this problem.

Vern, Cyrus, Jim and Dave.

The problem: we are running PEM front ends in the mid stations, but dont want to install a complete timing sytem (fanout and IRIG-B units) to service just one front end computer per building.

One possible solution is to use the atomic clock/MCA distribution system to provide a local IRIG-B signal at the mid stations. To test this, we took a Time Code Translator (TCT) which used to be installed at the mid station and fired it up in the MSR. It was connected to the MCA via a short LC-LC single mode fiber optics cable. Its rear IRIG-B (the square wave version) was viewed on a scope by Vern, and then plugged into the front end computer h1susauxb123. When restarted, this machine's GPS time was off by 1year and 1day. Cyrus tracked this to a setting on the TCT card which was not outputting the year info in the IRIG-B code, verified by the scope. This was fixed and when h1susauxb123 was again rebooted it was 16 seconds off. This is the accumulated leap seconds between UTC and GPS time.

Thinking about it, we realized we should have expected this. The LIGO Timing System is GPS based. It is actually GPS time which is provided by the IRIG-B unit. Whereas all commercial timing systems, including  the Symmetricom NTP server and the Timing Solutions MCA, use UTC time encoded into IRIG-B. Therefore the independent Symmetricom/Datum/TimingSolutions will differ from GPS by the leap seconds. We certainly dont wish to maintain a leap seconds lookup table, so we are abandoning the TCT as an IRIG-B source for the mid stations. This closes out WP#4175.

To proceed onwards, Rolf has suggested an RCG code change whereby a front end which is missing an IRIG-B card will use its system time instead. 

When a solution has been found, the timing units in MX can be removed and MY PEM can be constructed.

Position loops were installed on HAM3-HEPI last week. UUG is 2Hz.

I installed the same controllers on HAM2 HEPI this morning. The phase margin is really high (above 60 degrees on every degree of freedom), so we can certainly raise the UUG and thus, push the performance.

Performance spectra were collected. They are attached to this post.

Controllers and simulations are also attached.

Spectra saved under the svn at:
SeiSVN/seismic/HEPI/H1/HAM2/Misc/DTT_Plots/
 - 2013_10_08_HAM2_HEPI_Pos_Loops_Perf.xml
 - 2013_10_08_HAM2_HEPI_Pos_Loops_Perf.pdf
revision# 7617

The ITMx Quad has been fully locked down, protective lens caps installed on the optics, and bagged in C3.  It is now ready for cartridge flight/install into BSC3.

Today, Travis and I loaded the EMT07 PUM into the custom optics air bake oven for it's 34 degC 12 hour cure cycle.  It had it's prisms and discs glued on ~1-2 weeks ago, so this cure cycle is a little late due to manpower constraints.

Alexa and Sheila have turned on the laser in the HAM 6 bay.

The ref cav power has been dropping over the last two weeks.  I lowered the resonant threshold so that we could lock the MC for work in HAM1, but we probaby need to look at the alignment. 

Attached are plots of dust counts requested from 4 PM October 6 to 4 PM October 7.

Open light values have been measured on RM1 and RM2

damping gains have been set to

-30 in long

-0.02 in Pitch

-0.02 in Yaw

the safe snapshot has been commited to the svn

Joe, Pablo, Cheryl, Sheila

We measured the beams coming out of the HAM2 viewport, with the nanoscan head 2 feet 6 inches from the viewport.  (in the first version of this alog I wrote the wrong distance)

For the brighter beam we measured beam diameters: 2549 um horizontal, 2632 um vertical.  after rorating the scan head 90 degrees we measured 2650um vertical, 2561 um horizontal.  

For the dim beam we measured 7160um vertical, 5972 um horizontal after rotating  by 90 degrees we got 6077um horizontal 5865um vertical. 

We also measured the beam in HAM1, in the same location as wensday (we move the BS for the RF PD to 16 inches after M2, we put the nanoscan 40 inches after the BS, there we got 4025 um vertical, 4126 horizontal.  After rotating the head 90 degrees we got 4045 um vertical 4020um horizontal.  

We placed Mode Master downstream of three-mirror Gouy phase matching telescope comprising two tip-tilts and one fixed mirror that is used for REFL WFS. (See the last picture for layout and distances.)

Note that the measured TT1-TT2 distance is about 1cm shorter than nominal described in Sam Waldman's document (http://dcc.ligo.org/T1000247), TT2-M5 distance is about 14mm longer than nominal, both of which should have been quite acceptable.

Anyway, we made this measurement and the beam was much smaller than what was expected. The first plot as well as the table below show the measured VS  the expected mode profile coming out of HAM1 propagated through the telescope with the measured mirror distances.

The total mode overlap between the actual beam and what is expected is somewhere between 0.75 and 0.87 (sort of tedious to do the real calculation so I leave it).

The 2nd plot shows that IF the incoming beam from HAM1 is as expected, in order to explain the measured mode the TT1-TT2 distance labeled as delta1 should be shorter by 4.5cm than was measured for X, or by 5.7cm for Y. This is a huge number, there's no way my distance measurement was that much off.

The 3rd plot  shows the Gouy shift between TTs (i.e. actuation orthogonality) and WFSs for the WFS sled (i.e. sensing), and it seems like both are quite poor for the measured mode, 26deg for actuation and 35 for sensing are sad though not a complete disaster.

Anyway, since it's hard to imagine that the ROC of TT1 (+1.7m), TT2 (-0.6m) and M5 (+1.7m) are grossly wrong, and since it's hard to imagine that the distance measurement has a 5 to 6cm error, this should mean either (or some) of the followings:

1. T1000247 is wrong about the mode coming out of HAM1.
2. IMC mode is not mode matched to the IFO well.
3. Astigmatism of curved optics at an angle (there are 3 such optics on HAM1, more on HAM2), each has small effect but maybe they add up. Neither Sam nor I have included this.

The third one doesn't sound likely, but neither Sam nor I have thought about this.