(Sheila, Alexa)
See D1201448 for reference.
We inserted ALS-L1 (ROC=75mm), which we had temporarily removed. Then, with the Mode Master (silicon detector), we spent the day mode matching the telescope along the green path (ALS-L6 and ALS-L7), which were placed for the OAT configuration and not the nominal configuration.
First, we examined the beam profile with the table in the OAT configuration and the mode master 28.5inches from ALS-M11. Image 'OneArmTextEndX' portrays the result. We subsequently removed ALS-L6 (ROC=-100mm) from the path and took another beam profile with the mode master in the same position. Image 'OneArmNoLens' portrays the resullt. We used this data to determine the seed waist of the beam. This seed waist matched that of the optical layout. We proceeded to create an "a la mode" matlab script to determine the proper positions of L6 and L7 with the target waist size of 2.2mm at 184.6inch from M11. Note: the target wasit size was determined via T1200200; the location was determined by measuring the distance from the TransMon secondary mirror to the chamber viewport (TransMon layout (D0902163, D1201457) and assuming the TransMon chamber was 2ft from the ALS table. We determined that L7 was 7inch from M10 and that L6 was 37inch from L7. This gave us a 99% overlap.
In this nominal configuration, we placed the mode master 660mm from M11 (we wanted to better stablize the MM). We noticed that the MM kept giving different results. Images 'ISCEXMM660mm2M11...' are snaptshots of four runs of the beam profile with everything in the exact same position. We were a bit unsure why the MM kept giving such different results. The waist size seemed close enough to 2.2mm; however, the location was drasitically off. We concluded for the day in this puzzled state...(more work tomorrow)
I have also attached the matlab script.
We realized that the MM has a diveregence minimum of .25mr, meanwhlie our beam has a divergence of around .18mr. This could explain the bad M^2 and the strange waist projections. However, using the waist measured at the MM lens (x_waist ~ 4.5mm, y_waist ~ 5.4mm), and the target waist of 2.2mm at 184.6 inches, the overlap for x was 99% and for y was 95.5%. I have attached the updated MatLab script.
(Note: the Rayleigh range is 28m)
We have concluded ISCTEX ready to be moved to EX.
The dust monitor software has been moved to met_one_227b_comp_ctrl-1.0.0 for device support and dust_met_one_227b_comp_ctrl-1.0.0 for the IOCs. The targets in /ligo/lho/h0/target were backed up to /ligo/lho/h0/target_archive and updated. The sitemap has been updated to link to modified medm screens. The primary change is that the software now controls the timing and puts the dust monitor into 'standby mode' between samples. The sample time and hold time durations can be set from EPICS. I also added code to attempt to reconnect on TCP/IP disconnects. The IOCs are running in 'screen' on a new virtual machine that Cyrus created, h0epics. I updated the H0EDCU_DUST.ini file to remove the MODE, TEMP and RELHUM channels and add ACTSAMPLETIME, HOLDTIMEMON, SAMPLETIMEMON, STATE and ISENABLED channels. Dave has rebooted the DAQ and these changes are now in place. Each dust monitor location is now enabled/disabled by toggling the on/off switch on the medm screens. I tried to update the alarm configuration file to use the ISENABLED channels to mask the dust monitors that are not running, but could not seem to get this to work. The wiki pages have been updated. This should complete WP 4172.
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
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