Jim did the hard work and I did the brain thing. We could only get our level rod to just past half way to the west side from the East door and Jim was really stretching. We found the vertical level runout from the East side to the center portion of the table to be about 0.047" or about 2.4mm over the whole table. May have been good enough (per comm RAbbott) but you're talking about SEI & HCR here. We weren't about to be satisfied. The elevation was about 1/64" low and that is close enough. So to level the table we moved one stack of 20kg 2x2" (diagonally NW to SE) to get our calibration. We then move 10kg 24" ultimately to put us very level. I redlined a pdf and added this to the DCC, D1200524, to show the as-built of the masses. Final position: -200.45mm Gz level to +-0.1mm over the span of the Optical Table per D1200524. Attached is my log book page for this survey. The numbers there are in local elevations. At HAM1 subtract the 14.1mm vertical offset to get to the Gz: -186.35-14.1 = -200.45mm
PeterK and RickS We intended to make weekly PSL performance assessment measurements this morning, but we found that the FSS had not locked since about 4 PM yesterday afternoon. After 6 hours of so of investigating, we found that there was a mouse in the RF distribution rack (one that likes Swiss chocolate!). It seems that the 80 MHz RF distribution is being reconfigured. After restoring the RF drive to the VCO and FSS AOM, the FSS locked right up, the ISS locked, and the system appears on cursory inspection to be operating as expected.
Both HAM2 and HAM3 chambers are now fully controlled (HEPI+ISI).
Those chambers feature:
- Standardized ISI damping loops (defined in: SeiSVN/seismic/HAM-ISI/H1/
- Standardized ISI blend filters (SeiSVN/seismic/HAM-ISI/Complementary_Filters_HAM_ISI/HAM-ISI_Generic_Comp_Filters.mat)
- Hybrid aLigo/eLigo blend filters are available (SeiSVN/seismic/HAM-ISI/Common/Blend_filters/Filters_HAM_ISI_Blend_Hybrid_24_Jul_2013.mat)
- All 3 levels of ISI isolation loops (UGF=10Hz, 25Hz, 35Hz - LHO aLog # 5355). Performance is mostly limited by the blend filters. Level 2 controllers give similar amount of isolation as Level 3. Level 2 controllers are prefferred for now - ISI Perfomance can be found in LHO aLog #7414
- HEPI position blend filters (IPS signals are multiplied by 1, L4C signals are multiplied by 0)
- HEPI position loops. UUG = 2 Hz. Should be set to 5Hz soon. HEPI position loops performance plots, and controllers, can be found in LHO aLog #8037.
Trun on Process:
Prepare:
Damp ISI:
Turn on HEPI:
Engage the isolation loops, on the ISI
I took performance spectra on the ISI, in air, earlier this week.
HEPI was running with 2Hz UUG IPS position loops. The ISI had Level 3 isolation loops running, with the hybrid aLigo + eLigo on RX/RY blend.
Performance plots are attached for reference.
Betsy, Travis
This afternoon, we connected the 5 ETMx SUS cables and the ringheater cable to the inside of the feedthru flange. We then had issues with signal faults. We investigated and found the out-of vac cables not plugged in well at the outside of the feedthru. Apon fixing, all looked well with the signals. The suspension is still not fully suspended although we pulled out all of the extra teflon stopping brackets and prepped it for full unlock after SEI is done float/balance, after IAS is done figuring out where to put us.
Note - Yesterday (Oct 16) we discovered that we had incorrectly pugged the cables into the internal side of the feedthru. This was due to the fact that the cable connectors were mounted in the table bracket slightly incorrectly. We remedied this yesterday.
** LVEA has been laser safe throughout the day ** Praxair delivered to CP8 this morning. The CP8 value on the HOVE overview screen remained near 104 through the lunch hour and now sits at 101. ** Roofers have worked all day on the LVEA roof except for a period this afternoon when the storm was active. ** See John's entry about water leaks in the LVEA this afternoon because of the storm. ** Alexa and Sheila have worked in the HAM6 bay through the day. ** Betsy entered the chamber at EX late this morning. The ETMX speedometer needles on SUS_OSEM_OVERVIEW are now active. ** The cartridge is bagged on the LVEA test stand. ** Lots of dust alarms through the day at a number of locations. In most cases the alarms correlated with human activity in the affected areas. We saw alarms this afternoon from the beer garden dust monitor (5) near 30,000 and it wasn't clear from the cameras if there was activity near BSC3 that was the cause. Patrick is checking the area to see if there might be a water leak nearby. ** The EX dust monitor went white this afternoon. Filiberto was in the VEA; he tightened the cable on the rack side and the monitor turned back on. ** Rick has been working on the ref cav this afternoon
Dan saw the same problems on h1ldasgw0 as he saw on h1ldasgw1 a few weeks ago. He upgraded solaris and rebooted to fix the QFS file system. h1fw0 got into a stuck state, unable to unmount or remount the NFS file system, I had to reboot it using the front panel reset button (it got stuck rebooting too). Unfortunately I accidentally restarted the DAQ in the process.
The data gap on h1fw0 is:
Oct 8 13:44
Oct 8 15:17
h1fw1 was running the entire time, except for the DAQ restart.
(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.
Open light values have been measured on RM1 and RM2
| OPTIC | OSEM | Open Ligh Value (cts) | Gain | Offset | Serial Number |
| RM1 | M1UL | -32768 | -0.916 | 16384 | 1105240 a |
| M1LL | -32768 | -0.916 | 16384 | 1105240 b | |
| M1UR | -22268 | -1.347 | 11134 | 1105240 c | |
| M1LR | -29171 | -1.028 | 14586 | 1105240 d | |
| RM2 | M1UL | -26656 | -1.125 | 13328 | 1105238 a |
| M1LL | -32768 | -0.916 | 16384 | 1105238 b | |
| M1UR | -32708 | -0.917 | 16354 | 1105238 c | |
| M1LR | -32768 | -0.916 | 16384 | 1105238 d |
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
I used the script "[OSEM2EUL, EUL2OSEM, SENSALIGN, DRIVEALIGN] = make_sushtts_projections" in /HTTS/Common/MatlabTools/ to generate the matrices for RM1 and RM2
They have been automatically filled with fill_matrix_values.m
The values are
OSEM2EUL:
0.2500 0.2500 0.2500 0.2500
10.3681 -10.3681 10.3681 -10.3681
-10.3681 -10.3681 10.3681 10.3681
EUL2OSEM matrix :
0.2500 10.3681 -10.3681
0.2500 -10.3681 -10.3681
0.2500 10.3681 10.3681
0.2500 -10.3681 10.3681
Safe snapshot has been saved for both RM1 and RM2