Displaying reports 75421-75440 of 83224.Go to page Start 3768 3769 3770 3771 3772 3773 3774 3775 3776 End
Reports until 20:53, Tuesday 08 October 2013
H1 ISC
alexan.staley@LIGO.ORG - posted 20:53, Tuesday 08 October 2013 - last comment - 13:39, Wednesday 09 October 2013(8059)
ISCTEX mode matching

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

Images attached to this report
Non-image files attached to this report
Comments related to this report
alexan.staley@LIGO.ORG - 13:39, Wednesday 09 October 2013 (8063)

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.

Non-image files attached to this comment
LHO General
patrick.thomas@LIGO.ORG - posted 17:56, Tuesday 08 October 2013 (8055)
dust monitor software changed
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.
H1 SEI
hugh.radkins@LIGO.ORG - posted 17:05, Tuesday 08 October 2013 (8057)
WHAM1 Optical Table Level/Elevation checked/set
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
Non-image files attached to this report
H1 PSL
richard.savage@LIGO.ORG - posted 16:50, Tuesday 08 October 2013 (8056)
H1 PSL FSS issue resolved
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.
H1 SEI
hugo.paris@LIGO.ORG - posted 16:04, Tuesday 08 October 2013 - last comment - 16:34, Friday 18 October 2013(8046)
HAM2 & HAM3 - Fully Controlled (HEPI +ISI) - How to use

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//Scripts/Control_Scripts/Version_2/Step_4_Damping_Filters_H1_ISI_.m)
- 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:

  1. Use the command button to shut down any kind of control on both HEPI and ISI.
  2. Make sure the border of the ISI screen is green. If not, check the Watchdogs (model, Dackill, IOP dackill, SUS) and the master switch.

Damp ISI:

  1. Use the command button to turn on the damping loops on the HAM-ISI.

Turn on HEPI:

  1. Make sure that the following are in the correct state for HEPI: Watchdogs (model, Dackill, IOP dackill, SUS, ISI) and the master switch.
  2. Open the IPS screen. Be careful there are 2 of them. One for the vertical sensors, and one for the horizontal sensors. 
  3. In this screen, make sure that the alignment offsets are loaded and engaged. We want them to be set at the opposite of the locked hepi IPS redouts referrenced in LHO aLog# 7180
  4. Open the DC bias screen and make sure that everything is disengaged - it should be.
  5. Repeat (4) for the Sensor Correction screns, the ISC mon, the feedforward (FF) and the Twist.
  6. Make sure that offsets are disengaged ont he OUTF screens. Be careful there are 2 of them as well. 
  7. Push both gain sliders to 1.
  8. Engage the Blend filters named "Pos"
  9. Make sure signals come out of those filters. If not, refer to LHO aLog #7299, and follow Sebastian's instructions
  10. Check the IPS 2CART matrices. For now, they should look like that. If not, use SeiSVN/seismic/HEPI/Common/MEDM_Functions_HEPI/Populate_Matrices_HEPI.m to fill them out. Do not use Populate_MEDM_Screen_HEPI.m instead, as it will reset a lot of the things you just worked on.
  11. Use the "Isolate <Chamber> Lvl1" button of the HEPI command screen, to engage the position loops

Engage the isolation loops, on the ISI

  1. Open the Sensor correction block and make sure that everything is disengaged.
  2. Open the blend filters block. Make sure that filters named "01_28" are selected. These are the generic blend filters mentioned above.
  3. Open the command screen of the ISI ou are working on
  4. Wait for the readouts to stabilize
  5. Use the "Reset CPS offset button" to reset the CPS biases. 
  6. Press the "Store Target offsets" button. This will store the current position so the ISI can be steered back there once the isolation loops are engaged
  7. Use "Turn on Lv. 2 isolation loops for ...." button, and wait for the isolation loops to get engaged.
Images attached to this report
Comments related to this report
hugo.paris@LIGO.ORG - 16:34, Friday 18 October 2013 (8172)

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.

Non-image files attached to this comment
H1 SUS
betsy.weaver@LIGO.ORG - posted 15:51, Tuesday 08 October 2013 - last comment - 10:52, Thursday 17 October 2013(8054)
ETMx SUS cables connected

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.

Comments related to this report
jim.warner@LIGO.ORG - 10:52, Thursday 17 October 2013 (8140)

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.

LHO General
dale.ingram@LIGO.ORG - posted 15:25, Tuesday 08 October 2013 (8053)
Afternoon summary
** 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
H1 DAQ
david.barker@LIGO.ORG - posted 15:23, Tuesday 08 October 2013 (8052)
fw0 back up after solaris upgrade

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.

H1 AOS
stefan.ballmer@LIGO.ORG - posted 15:21, Tuesday 08 October 2013 (8051)
Enable and Run jumpers installed on coild drivers for RM1, RM2, OM1, OM2, OM3
(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.)
H1 AOS
douglas.cook@LIGO.ORG - posted 15:11, Tuesday 08 October 2013 (8050)
BSC9 chamber and monument position investigation
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.
LHO General
john.worden@LIGO.ORG - posted 15:07, Tuesday 08 October 2013 (8049)
Water leaks in the LVEA

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.

H1 AOS
stefan.ballmer@LIGO.ORG - posted 14:59, Tuesday 08 October 2013 (8048)
RM2 (TipTilt serial number 024) has opposite-poled magnets
(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.
LHO VE
john.worden@LIGO.ORG - posted 14:58, Tuesday 08 October 2013 (8047)
Vertex Volume + X Beam Manifold Vented

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

X1 SUS
stuart.aston@LIGO.ORG - posted 14:55, Tuesday 08 October 2013 (8045)
Restarted & BURT restored triple test-stand models ready for OMCS testing
[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.
H1 IOO
paul.fulda@LIGO.ORG - posted 14:27, Tuesday 08 October 2013 (8044)
MC2trans and IM4trans QPD input filter offsets adjused

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

H1 SUS
mark.barton@LIGO.ORG - posted 13:40, Tuesday 08 October 2013 (8040)
MC2 Violin Mode Work

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.

Non-image files attached to this report
H1 DAQ
david.barker@LIGO.ORG - posted 13:33, Tuesday 08 October 2013 (8042)
h1fw0's disk system appears to be faulty

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.

H1 CDS
david.barker@LIGO.ORG - posted 13:31, Tuesday 08 October 2013 (8041)
Tested using MCA time code distribution as IRIG-B source in mid stations

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.

H1 SEI
hugo.paris@LIGO.ORG - posted 12:43, Tuesday 08 October 2013 (8037)
HEPI Controls - HAM2 position loops installed

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

Non-image files attached to this report
H1 SUS
arnaud.pele@LIGO.ORG - posted 20:14, Friday 04 October 2013 - last comment - 14:41, Tuesday 08 October 2013(8007)
OLV RM1 RM2

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

Comments related to this report
arnaud.pele@LIGO.ORG - 14:41, Tuesday 08 October 2013 (8043)

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

Displaying reports 75421-75440 of 83224.Go to page Start 3768 3769 3770 3771 3772 3773 3774 3775 3776 End