Displaying reports 69681-69700 of 77088.Go to page Start 3481 3482 3483 3484 3485 3486 3487 3488 3489 End
Reports until 18:43, Thursday 05 September 2013
H1 SUS
arnaud.pele@LIGO.ORG - posted 18:43, Thursday 05 September 2013 (7647)
ITMX measurements postponed

ITMX main chain tests after its alignement today, won't start before tomorrow, when front ends will be up and running again

H1 General
jeffrey.kissel@LIGO.ORG - posted 17:58, Thursday 05 September 2013 - last comment - 19:32, Thursday 05 September 2013(7646)
Power Glitch takes down all Front Ends
The power glitched visibly in the control room for half a second. We lost the frame builder immediately, and then all the front ends slowly but surely crashed in its wake. And so ends a night of work at LHO. We won't begin to resurrect until the storms planned for this evening pass.

We really should have the front ends and related systems on some sort of UPS. At least to with stand 10 seconds without power.
Comments related to this report
keith.thorne@LIGO.ORG - 19:32, Thursday 05 September 2013 (7648)
You need enough power to keep up all the DC power supplies and the lasers.  We at LLO CDS are all for such backup power.  The issues are the cost and required support.  Of course, we are already very expert at resets here in the stormy south coast.
H1 SUS
mark.barton@LIGO.ORG - posted 17:14, Thursday 05 September 2013 - last comment - 14:26, Friday 06 September 2013(7644)
PRM and SRM model updates

Following on Filiberto's upgrade of the M2 driver boxes on PRM and SRM per alog 7630, I updated the h1susprm and h1sussrm models to match, piggybacking on his work permit 4117:

* I changed the PRM and SRM blocks at the top level to use the MC_MASTER part (as for MC2 which was modified earlier) rather than HSTS_MASTER.

* Per Stuart's suggestion, I terminated the three new outputs MC_X_M*_OUT on the new part (rather than feeding them into an IMC block as for MC2).

* I copied the matching M2_COILOUTF filter definitions from the latest copy of L1SUSMC2.txt in the SVN after checking that they corresponded to LLO alog 4495.  (Ideally I would have gotten them from H1SUSMC2.txt, but it appears we've never updated them there. I held off doing that at this time because it will need a separate WP and because there's a risk of breaking the IMC locking if something is counting on the existing poor compensation, but we should get to it soon, after we confirm that it's working for PRM and SRM.)

* I rebuilt and restarted both models. h1sussrm came up with no problems except for a few bad entries in the safe.snap, which I corrected. (There were lines like H1:SUS-SRM_M1_DAMP_L_STATE_GOOD 1 H1:SUS-SRM_M1_DAMP_L_STATE_GOOD 100676356" which were hangovers from a faulty script used at one time. I deleted the first half of each line. The PRM safe.snap had the same issue, but BURT didn't complain (see next item). I fixed it in the same fashion anyway.)

* Initially the PRM model showed a red DC bit and many of the EPICS values were not properly initialized. I realized after posting the initial version of this alog that I hadn't saved after the last edit, so the MC_MASTER block was still called MC_MASTER, so all the channel names were wrong. I saved the model, rebuilt and restarted it and this time the DC bit was green. I'll follow up with Dave Barker tomorrow to see if there's any corrective action needed re the MC_MASTER channels that were being written temporarily. The hourly backup for 16:00 hours is corrupt but the 15:00 and 17:00 ones are good.

* I committed the new models, filters and safe.snap files.

Comments related to this report
mark.barton@LIGO.ORG - 14:26, Friday 06 September 2013 (7665)

My  fix of yesterday for the dud lines in the PRM and SRM safe.snap files wasn't quite right - I had deleted the erroneous second copy of the channel names, but I should have left the "1":

H1:SUS-PRM_M1_DAMP_L_STATE_GOOD 1 100676356
H1:SUS-PRM_M1_DAMP_P_STATE_GOOD 1 113258548
H1:SUS-PRM_M1_DAMP_R_STATE_GOOD 1 113258548
H1:SUS-PRM_M1_DAMP_T_STATE_GOOD 1 113258548
H1:SUS-PRM_M1_DAMP_V_STATE_GOOD 1 113258548
H1:SUS-PRM_M1_DAMP_Y_STATE_GOOD 1 113258548
 

H1:SUS-SRM_M1_DAMP_L_STATE_GOOD 1 100676356
H1:SUS-SRM_M1_DAMP_P_STATE_GOOD 1 113258548
H1:SUS-SRM_M1_DAMP_R_STATE_GOOD 1 113258548
H1:SUS-SRM_M1_DAMP_T_STATE_GOOD 1 113258548
H1:SUS-SRM_M1_DAMP_V_STATE_GOOD 1 113258548
H1:SUS-SRM_M1_DAMP_Y_STATE_GOOD 1 113258548

I committed the new fix.

LHO General
gerardo.moreno@LIGO.ORG - posted 16:18, Thursday 05 September 2013 (7645)
Shift Summary

- 8:40, Corey to squeezer area, to retrive items for Sheila, out by 8:50 am.
- 8:50, Hugh to HAM6, sensor check up, out by 9:20 am.
- 8:50, Apollo to start moving clean room above BSC3, installation aborted, see Bubba's entry.
- 9:10, Filiberto to H1 electronic room, R&R chasis.
- 9:15, Thomas to test stand area, assembly of SLC baffles.
- 9:45, Richard and ken, to outer stations (mids and ends) removal of weather stations from roof.
- 11:20, Betsy and Jason to ITMX test stand, to do stuff.
- 11:32, Dale to test stand to take photos, mission aborted "not as cool", due to metal PUM.
- 14:58, Dale and ??? to "take a look out on the floor", out within 20 min.

Alarms and Reboots:
- End X instrument air alarmed twice, low value of 58.94.
- CDS alarms that should have been disabled, for now, h1oaf, h1lsc and h1asc, as long as is not being used.
- SRM and PRM startup by Mark B @ 15:45.

LHO General
bubba.gateley@LIGO.ORG - posted 15:40, Thursday 05 September 2013 (7643)
Apollo crew
We made an attempt at placing a clean room over BSC 3 only to realize that the work platform configuration was incorrect. This required relocation of the E-module from inside the beer garden to the east side of BSC 3 and some slight modification of the work platform. This also required relocating the gowning room from the west side to the east side of the small clean room currently being ocuppied by SUS.
Tyler assisted Lisa A. with assembly for most of the day. 
H1 CDS
cyrus.reed@LIGO.ORG - posted 15:04, Thursday 05 September 2013 (7642)
Old VME Boot Servers Powered Off
I have powered off the old VME boot servers in the MSR, as they are no longer needed.  The main consequence of this is that the continuous beeping from the failed RAID array has now stopped, so any new beeping or other alert sounds coming from the MSR should be investigated.
H1 AOS
cheryl.vorvick@LIGO.ORG - posted 14:57, Thursday 05 September 2013 (7639)
My TMSX pictures through initial alignment:

As Keita wrote herethe TMSX initial alignment is done. 

I need to catch up on posting my TMSX pictures, so here are my ResourceSpace collections (date in title):

LHO TMSX 4Sept2013 - IAS alignment, upper mass cabling, and pitch balancing

LHO TMSX 30Aug2013 - reattaching ISC cables to ISC table, optics covered with Alpha wipes, and offse

LHO TMSX 30Aug2013 - how to turn the telescope 180 degrees, and move to the test stand from the lab

LHO TMSX 26Aug2013 - upper structure move and first attempt at cable routing

LHO TMSX 21Aug2013 optics contamination and OSEM testing

LHO TMSX 16Aug2013 on test stand - cables and safety hardware

 
H1 AOS
jason.oberling@LIGO.ORG - posted 14:41, Thursday 05 September 2013 (7638)
ITMx Cartridge Alignment
IAS: J. Oberling
SUS: B. Weaver
 
Finished the ITMx cartridge alignment today, position/angle errors are as follows:

We also roughed in the CPx pitch by eye.  We will set up tomorrow to measure the ITMx/CPx gap and finish the pitch/yaw alignment of the CPx.

H1 SUS
jeffrey.kissel@LIGO.ORG - posted 13:47, Thursday 05 September 2013 (7634)
H1 SUS PR3 Phase 3b Acceptance Measurement -- Undamped Top2Top TFs
Checking it off Arnaud's list so I can get on to installing Level 2.1 filters, I've taken final Phase 3b, undamped, M1 to M1 transfer functions of H1 SUS PR3, an HLTS. Now that Hugo's not shaking HPI, all degrees of freedom look gorgeous. We should consider this measurement of H1 SUS PR3 as accepted. As per usual, the individual results and results compared against other similar suspensions are posted below. Everything mentioned below has been committed to the repo as of the post of this entry.

Note, the remaining Phase 3b acceptance measurements for H1 SUS PR3 are:
- Damped transfer functions of M1 to M1 (I didn't take these, because I'm going to be installing new damping filters shortly)
- M2 to M2 and M2 to M3 (I'll be taking these now)
- Spectra of all stages. (These are quick, I'll just take these when new damping filters are installed.)

Details
-------
The data was taken with the following DTT templates:
${SusSVN}/sus/trunk/HLTS/H1/PR3/SAGM1/Data/
2013-09-05_1743_H1SUSPR3_WhiteNoise_L_0p01to50Hz.xml
2013-09-05_1743_H1SUSPR3_WhiteNoise_P_0p01to50Hz.xml
2013-09-05_1743_H1SUSPR3_WhiteNoise_R_0p01to50Hz.xml
2013-09-05_1743_H1SUSPR3_WhiteNoise_T_0p01to50Hz.xml
2013-09-05_1743_H1SUSPR3_WhiteNoise_V_0p01to50Hz.xml
2013-09-05_1743_H1SUSPR3_WhiteNoise_Y_0p01to50Hz.xml

The data from which was exported as:
${SusSVN}/sus/trunk/HLTS/H1/PR3/SAGM1/Data/
2013-09-05_1743_H1SUSPR3_WhiteNoise_L_0p01to50Hz_tf.txt
2013-09-05_1743_H1SUSPR3_WhiteNoise_P_0p01to50Hz_tf.txt
2013-09-05_1743_H1SUSPR3_WhiteNoise_R_0p01to50Hz_tf.txt
2013-09-05_1743_H1SUSPR3_WhiteNoise_T_0p01to50Hz_tf.txt
2013-09-05_1743_H1SUSPR3_WhiteNoise_V_0p01to50Hz_tf.txt
2013-09-05_1743_H1SUSPR3_WhiteNoise_Y_0p01to50Hz_tf.txt

The data was individually processed by:
${SusSVN}/sus/trunk/HLTS/Common/MatlabTools/plotHLTS_dtttfs.m

which produced the following saved data (and the individual plots):
${SusSVN}/sus/trunk/HLTS/H1/PR3/SAGM1/Results/2013-09-05_1743_H1SUSPR3_M1.mat

This saved data was then compared against other measurements using:
${SusSVN}/sus/trunk/HLTS/Common/MatlabTools/plotallhlts_tfs.m

The resulting plot is saved in:
${SusSVN}/sus/trunk/HLTS/Common/Data/
Non-image files attached to this report
H1 SEI
hugh.radkins@LIGO.ORG - posted 13:37, Thursday 05 September 2013 - last comment - 10:19, Friday 06 September 2013(7636)
WHAM6 Corner1 Vertical HEPI Actuator Parker Valve swapped
Hugo & Jim reported a response error of HAM6 V1.  The IPS (Inductive Position Sensor) responded with opposite sign but good amplitude.  We visually checked the IPS and verified its sign was correct.  EE was called in for assistance and the outputs of the Pier Pod was verified to be consistent and correct.  Cables were swapped and we even drove V1 with the V4 Pod.  All suspects eliminated leaving the Actuator itself.  The Parker Valve has been swapped and the Actuator is now in bleed mode.

Old Valve SN: L170 replaced w/ L221.
Comments related to this report
hugh.radkins@LIGO.ORG - 10:19, Friday 06 September 2013 (7654)
The Actuator was put back into run mode at 1405 pdt giving us 165minutes of bleed time.  More than enough for this vertical actuator given the reported experiences at MIT and LLO.

We ran another test and the sign anomaly still exists...?  Don't know what to say about that...
H1 CDS
david.barker@LIGO.ORG - posted 12:40, Thursday 05 September 2013 (7633)
Startup of first version of h1iscex front end model

Chris W created an h1iscex.mdl model this morning. I compiled it against RCG2.7.2 and started it on h1iscex. It is running well.

This system is not in the DAQ at the moment, so its DAQ and DDC bits are showing errors on the overview medm.

H1 CDS
cyrus.reed@LIGO.ORG - posted 12:10, Thursday 05 September 2013 (7632)
Vacuum VME Crate Boot Parameters
What follows are the VxWorks version and boot parameters for all of the vacuum VME crates as of 5Sep2013.  These reflect the change to the new boot server and associated settings, and are needed if replacing a CPU card.



-- h0vemr:

VxWorks (for Motorola MVME162LX) version 5.2.
Kernel: WIND version 2.4.
Made on Fri Apr 2 10:48:41 PST 1999.
Boot line:
ei(0,0)vxboot:/opt/CDS/b/vw/5.2/config/mv162-333-8M/vxWorks e=10.1.0.63:ffff0000 h=10.1.0.100 u=vxboot tn=h0vemr s=/cvs/cds/lho/target/h0vemr/startup.cmd
value = 165 = 0xa5
h0vemr > 

-- h0velx:

VxWorks (for Motorola MVME162LX) version 5.2.
Kernel: WIND version 2.4.
Made on Fri Aug 18 15:16:20 PDT 2000.
Boot line:
ei(0,0)vxboot:/opt/CDS/b/vw/5.2/config/mv162-262-16M/vxWorks e=10.1.0.62:ffff0000 h=10.1.0.100 u=vxboot tn=h0velx s=/cvs/cds/lho/target/h0velx/startup.cmd
value = 166 = 0xa6
h0velx > 

-- h0vemx:

VxWorks (for Motorola MVME162LX) version 5.2.
Kernel: WIND version 2.4.
Made on Fri Aug 18 15:16:20 PDT 2000.
Boot line:
ei(0,0)vxboot:/opt/CDS/b/vw/5.2/config/mv162-262-16M/vxWorks e=10.1.0.61:ffff0000 h=10.1.0.100 u=vxboot tn=h0vemx s=/cvs/cds/lho/target/h0vemx/startup.cmd
value = 166 = 0xa6
h0vemx > 

-- h0veex:

VxWorks (for Motorola MVME162LX) version 5.2.
Kernel: WIND version 2.4.
Made on Fri Aug 18 15:16:20 PDT 2000.
Boot line:
ei(0,0)vxboot:/opt/CDS/b/vw/5.2/config/mv162-262-16M/vxWorks e=10.1.0.60:ffff0000 h=10.1.0.100 u=vxboot tn=h0veex s=/cvs/cds/lho/target/h0veex/startup.cmd
value = 166 = 0xa6
h0veex > 

-- h0vely:

VxWorks (for Motorola MVME162LX) version 5.2.
Kernel: WIND version 2.4.
Made on Fri Aug 18 15:16:20 PDT 2000.
Boot line:
ei(0,0)vxboot:/opt/CDS/b/vw/5.2/config/mv162-262-16M/vxWorks e=10.1.0.64:ffff0000 h=10.1.0.100 u=vxboot tn=h0vely s=/cvs/cds/lho/target/h0vely/startup.cmd
value = 166 = 0xa6
h0vely > 

-- h0vemy:

VxWorks (for Motorola MVME162LX) version 5.2.
Kernel: WIND version 2.4.
Made on Fri Aug 18 15:16:20 PDT 2000.
Boot line:
ei(0,0)vxboot:/opt/CDS/b/vw/5.2/config/mv162-262-16M/vxWorks e=10.1.0.65:ffff0000 h=10.1.0.100 u=vxboot tn=h0vemy s=/cvs/cds/lho/target/h0vemy/startup.cmd
value = 166 = 0xa6
h0vemy > 

-- h0veey:

VxWorks (for Motorola MVME162LX) version 5.2.
Kernel: WIND version 2.4.
Made on Fri Aug 18 15:16:20 PDT 2000.
Boot line:
ei(0,0)vxboot:/opt/CDS/b/vw/5.2/config/mv162-262-16M/vxWorks e=10.1.0.66:ffff0000 h=10.1.0.100 u=vxboot tn=h0veey s=/cvs/cds/lho/target/h0veey/startup.cmd
value = 166 = 0xa6
h0veey > 

H1 SUS
arnaud.pele@LIGO.ORG - posted 11:54, Thursday 05 September 2013 (7631)
BS vertical tf cross coupling

Previous cross coupling of the beamsplitter was due to the status of the ISI (floating at that time). Now the ISI is damped, the extra resonnance disappears. See comment of alog 7305 for details.

H1 SUS
filiberto.clara@LIGO.ORG - posted 10:40, Thursday 05 September 2013 (7630)
PRM and SRM TACQ Drivers
The following units were replaced with modified and retested units per ECR E1200931.
H1 SUS SRM TACQ Driver S1100050 with S1100035 (SUS-C7-U26 HAM5).
H1 SUS PRM TACQ Driver S1000356 with S1100015 (SUS-C4-U19 HAM3).

Test data for these units can be found in dcc.
H1 AOS
keita.kawabe@LIGO.ORG - posted 02:10, Thursday 05 September 2013 - last comment - 13:37, Thursday 05 September 2013(7629)
TMS initial alignment done (Corey, Cheryl, Doug, Jason, Keita)

We're done with the initial alignment using the total station and the red laser. The final fine alignment should be done in chamber with ISCTEX in place.

Angle:

TMS yaw angle was adjusted by pushing the TMS SUS cube, and pitch by adjusting the sliding mass on the ISC table, such that the red laser beam from the total station is centered on the aperture on the ISC table. We used a small target placed in the aperture, but putting a target on the ISC table throws the PIT balance off. In the end we placed the second (dummy) target that is identical to the real target such that two targets are symmetrically placed around the center of the table.

Centering relative to ETM:

TMS centering relative to ETM was measured by the total station after putting the table/tele on the alignment stabilizing tooling such that the set screws barely touch the ISC table, then mounting the large target on the large input aperture of the telescope secondary plate.

TMS was 5 to 6mm lower than the ETM and off to the outside of L shape of the IFO by 1.5mm or 2 according to Jason. So the centering error is 

sqrt(6^2+2^2) = 6.3 mm

in the worst case.

This is very acceptable both for the green and IR beam.

Green:

Outside of the arm on the AR side of the ETM, the green arm mode has the waist radius of about 6mm, the Rayleigh range of about 200m, the divergence angle of about 6mm/200m=30urad, and the waist  is 1500m away from the ETM into the arm (see e.g. T1200200).

If we inject a beam from the center of TMS (6.3mm offset from the arm mode at the ETM) such that there's no lateral displacement at the waist, the misalignment angle would be 6.3mm/1500m = 4.2urad.

The power mismatch would be (4.2urad/30urad)^2 = 2%. This is nothing.

IR:

The requirement for the centering tolerance for the IR beam is much larger than the green, as the only important thing for IR is that both of the QPDs will see the light. Even if the IR beam is half radius off of the center of the QPDs that would be OK. Having said that, just for the completeness I'll show some numbers.

Outside of the arm on the AR side of the ETM, the IR arm mode has the waist radius of 8mm, the Rayleigh range of 200m (same as green), divergence angle of about 40urad,  and the waist is 1500m away from the ETM into the arm.

If the TMS is aligned as described above (no lateral displacement at the waist but 6.3mm offset at the ETM) the power mismatch parameter would be (4.2/40)^2=1%. 

Comments related to this report
cheryl.vorvick@LIGO.ORG - 13:37, Thursday 05 September 2013 (7635)
Pictures:

Pictures 1 and 2 - IAS alignment targets, as used for IAS alignment ------------------------

NOTE: each target required illumination with a flashlight, however, the picture of the small target was erroneously taken illuminating the target from the top when it needs to be illuminated from the bottom of the ISC table.


Pictures 3 and 4 - Cables rerouted above the upper mass ------------------------

These two pictures show that with cable ties, rerouting cables, and changing peek clamp locations on the ISI, the cables coming through the upper mass are no longer touching the upper mass.

Cable ties were used to tension the 4 cables in such a way that they curve away from the cable clamp in the center of the upper mass as they exit through the top of the upper mass.  

Originally the two thicker cables coming from the center of the upper mass were routed in the +X direction and the two thinner cables were routed in the -X direction when exiting the upper mass.  This configuration was swapped so thicker cables are now routed in the -X direction, and thinner cables in the +X direction.  

Inside the upper mass, the thicker cables are on the -Y side of the clamp, and the blades above the upper mass are positioned so that there is more space on the ISI in the -X,-Y direction above the upper mass.  This meant that routing the thicker cables in the -X direction allowed Keita to pull the thicker cables farther in the -Y direction with the peek clamp on the ISI,  and allowed the thinner cables to clear the upper mass.


Pictures 5 and 6  - IAS alignment targets, as used for a rough balancing the table ------------------------

Picture 5 is the small target installed on the table.  This is used to center the red alignment beam (from the IAS total station) as it goes through the ISC table from the telescope.  View the red beam on the underside of the target/ISC table.

Picture 6 is the spare small alignment target positioned on the table to balance out the effect of the real target.  Not quite positioned relative to the wires in the same way as real target, but significantly better than not having it there, and good enough for testing and as a starting point after the flight into the chamber.

Images attached to this comment
H1 SUS
jeffrey.kissel@LIGO.ORG - posted 17:23, Wednesday 04 September 2013 (7627)
This is what happens when....
... you get impatient and drive HEPI in the same band as driving a suspension transfer function with the same type of excitation. 

[J. Kissel, H. Paris, A. Pele]

The full story:
Hugo was finishing up the extremely long (over-night and into-the-day) measurements of HPI-HAM2, and I'd asked him in what frequency band he was currently running. Since he'd said 10 [mHz]-100 [mHz] when I'd initially asked him (and [I didn't realize / he assumed I knew] the measurement would continue on to higher frequency after this band was done), I launched the 5 hour PR3 M1-to-M1 acceptance transfer functions, to set-and-forget and just be done with it.

Once my measurement was finished, I processed it as normal (see 2013-09-04_1062347744_H1SUSPR3_M1_ALL_TFs.pdf), and found that most degrees of freedom looked spectacular as expected. However, the Vertical and Roll DOFs, only in the 0.3 to 4 [Hz] band, showed a frequency comb of exactly 0.5 [Hz]. What?! To DTT!
(The thought-process narration goes through 2013-09-04-1062347744_H1SUSPR3_M1_0p01to50Hz_DTT.pdf, and the panel ordering is "1" = UL, "2" = LL, "3" = UR, "4" = LR)
After checking to see whether 

- Did awg have a problem from poorly cleared test points? No. (See pg 1, panel 1: Looks like the standard Schroeder-phased transfer function excitation)
- Did my euler basis drive saturate the DAC? No. (See pg 1, panel 2: DAC counts are at most +/-1000 [ct], with T2 and T3 having a DC (pitch) offset in place)
- Did the frequency band or amplitude (driving from 0.3 to 4 [Hz] at 0.01 [Hz] resolution) get screwed up some how? No. (See pg 1, panel 3: an expected 150 [uN/rtHz] from DC up to 4 [Hz] in the Euler Basis, where the OSEM Basis, in DAC counts, the drive is split up evenly between the three OSEMs, and "anti-dewhitened" to compensate for the analog dewhitening.)
- Did the matlab analysis tool some how screw up the data analysis, like with data corruption from frame builder or something? No. (See pg 1, panel 4: I've gathered the transfer function soley from DTT infrastructure, replotted and calibrated the TF. Same exact result in that band. The sky-rocketing magnitude above 4 [Hz] is expected -- it's just noisy incoherent signal.) 
- Did the OSEM sensors saturate, i.e. were we swinging wildy out of the linear range from too large a drive? No. (See pg 2, panel 1: time series of sensor response shows no clipping or anything close to a saturation.)
- Is this craziness in the sensor or the actuator? The sensor (See pg 2, panel 2: ASD of the calibrated OSEM and Euler basis signals)

Well shoot.

Then, I went on to "trust but verify" Hugo's statement that he was only driving up to 100 [mHz]. I find that his excitation has *finished* the 10 to 100 [mHz] band, and the script automatically moved on to working it's way through the 700 [mHz] to 10 [Hz] band during the V and R suspension excitations, and in particular, a 0.5 [Hz] comb between 0.5 and 10 [Hz]. This is shown by the HPI excitation signals in Pg 2, panels 3 and 4. And get this, since suspensions still uses a flat drive instead a comb for their Schroeder phased excitation, the drive from HPI is only coherent at the comb frequencies of HEPI. But it *is* coherent (see pg 3)!

ANYWAYS, of course, had I known the frequencies that Hugo was driving, of course I wouldn't have started the measurement. OH WELL. Lesson learned. And a good commissioning exercise. 
Images attached to this report
Non-image files attached to this report
H1 SEI
hugo.paris@LIGO.ORG - posted 16:44, Wednesday 04 September 2013 (7628)
HEPI Overnight Transfer Functions - HAM2 & HAM3

Transfer functions are running overnight on both HEPI-HAM2 and HEPI-HAM3.

H1 SUS
arnaud.pele@LIGO.ORG - posted 13:06, Thursday 01 August 2013 - last comment - 11:49, Thursday 05 September 2013(7305)
BS Phase 3b M1-M1 trasnfer functions

Phase 3b top mass (M1-M1) damped and undamped transfer functions on the beamsplitter under vaccum have been measured two days ago with the ISI floating, using the automated matlab script.

The attached pdf are showing in order the results for :

(1) Comparison between M1-M1 measured damped  (red) and modeled (blue) transfer function for the 6 DOF

(2) Comparison between M1-M1 measured undamped  (red) and modeled (blue) transfer function for the 6 DOF

(3) Comparison between M1-M1 phase 3a undamped (in air april 22nd 2013, orange curve), phase 3b undamped (in vacuum July 30th 2013, blue curve), phase 3b damped (in vacuum July 30th 2013, pink curve), and undamped modeled transfer function (in blue)

(4) Comparison between M1-M1 vertical DOF hanford beamsplitter phase 3b (in vacuum, July 30th 2013, orange curve), and livingston beamsplitter phase 3a (in air, April 16th 2013 black curve) and undamped modeled transfer function (in blue)

Most of measurements are in good agreement with the model. Although, the 1.70 Hz longitudinal mode cross coupling into the vertical degree of freedom, cf 3rd page of (1) and (2)

When looking at the comparison between phase 3a and phase 3b for the vertical DOF (3rd page of (3)), it appears that the cross coupling was not present in April when the suspension was in air.

Livingston beamsplitter seems to also have cross couplings in their vertical degree of freedom, but with roll and pitch mode instead of longitudinal (cf (4))

Non-image files attached to this report
Comments related to this report
arnaud.pele@LIGO.ORG - 15:30, Thursday 01 August 2013 (7321)

After discution with J.Kissel, the cross coupling might come from the top mass touching an earthquake stop. This would be due to the sag of the suspension after the air have been evacuated from the chamber.

arnaud.pele@LIGO.ORG - 11:49, Thursday 05 September 2013 (7625)

BS (in chamber, in vacuum, ISI damped (both stages), suspension undamped, no offsets) vertical degree of freedom transfer function has been re-measured yesterday, and isn't showing any signs of coupling anymore (blue curve of attached plot). In order to understand why an extra resonnance was present previously, a series of tests has been carried out, to try reproducing the coupling.

1) First, a vertical offset (-200000 cts) has been applied to the top mass osems, to push down the suspension by ~1mm, and a transfer function has been taken from 1.5 to 2Hz (green curve of attached plot). The cross coupling was still not present

2) The active control of the ISI has been turned off with the vertical offset still on, and an other tf has been taken from 1.5Hz to 2Hz (Red curve). This time, the cross coupling reappeared

3) To reproduce the theory, the offset has been turned off, with the ISI still undamped, and a last tf from 1.5Hz to 2Hz has been taken, still showing the cross coupling, but with a really poor coherence.

Conclusion : When the ISI is floating, and the BS is being excited in the vertical degree of freedom, stage 2 (Rx dof) of the ISI resonates @ ~1.6Hz which then excites the third longitudinal mode (~1.69Hz) of the suspension, creating the cross coupling between vertical and longitudinal we were seeing in our transfer functions

Non-image files attached to this comment
Displaying reports 69681-69700 of 77088.Go to page Start 3481 3482 3483 3484 3485 3486 3487 3488 3489 End