40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 176 of 341  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  6429   Tue Mar 20 09:59:01 2012 steveUpdateIOOLaser tripped off

Today is janitor day. It still does not explain why the 2W Innolight tripped off about an hour ago. All back to normal.

.......................................................I asked Keven later, he admitted hitting the emergency shut off next to the chemical storage cabinet.

  6440   Fri Mar 23 01:59:59 2012 kiwamuUpdateIOOREFL beam currently unavilable

[Suresh / Kiwamu]

Currently the REFL beam is bypassed by additional mirrors and blocked by a razor blade dump.

Therefore the signals associated with the REFL ports (e.g. REFL11, REFLDC and etc.) are unavailable.

Just be aware of it.

  6441   Fri Mar 23 05:10:46 2012 SureshUpdateIOOBeam Profile measurements: Errors too large to yield good fits.

[Kiwamu, Suresh]

   Today we attempted to measure the beam profile of the REFL beam under two conditions:

              (a) with PRM aligned and ITMs misaligned 

              (b) with PRM misaligned and ITMs aligned

 

The raw data is shown below.  In each of the above conditions we measured in both the vertical (v) and horizontal (h) directions.   The measurements in the vertical direction were better than the ones in the horizontal direction because the optics had a horizontal oscillation which gave larger errors in measurement.

rawdataplot.png

 

Looking at the general trend of these lines it is clear that modes are not matched since the beam reflected by the PRM has a different divergence than that reflected from ITMs.  The beam is also astigmatic as the vertical and horizontal directions have different divergences.

I could find beam parameters only for the Blue line above (Profile in the vertical direction while PRM was aligned).   The fit is quite sensitive to the data points close to the waist, so we need to make better (lower St.Dev.) measurements near the AP table closer to the beam waist.  The intensity with only one ITM aligned is too low and also contributes to the errors.   The beam size is close to 6mm in the horizontal direction, this coupled with yaw oscillations give large errors in this measurement.

Here is the only reliable fit that could be obtained, which is for the prompt reflection from the PRM in the vertical direction

PRM-to-REFL-profile.pdf

The fit function I used is  Beam Dia = Waist { Sqrt [ 1+  ((z + z0)/zr)^2). The fit parameters we get for this data are

z0 = 7.7 m 

Waist = 2.4 mm

zr = 6.9 m

 

Will make another attempt later today...

 

 

 

 

  6444   Mon Mar 26 15:15:16 2012 kiwamuUpdateIOOexpected beam profile of PRM reflection

I have estimated how the mode profile of the PRM reflection should be, as shown in the plot blow.

A conclusion here is :

   we should be able to constrain the PRM curvature situation if measurements are precise and accurate enough with a level of less than ~ 100 um

 

In the calculation two cases are considered :

      (1) PRM has the correct curvature of  +122 m. This is shown as solid curves in the plot.

      (2) PRM has a wrong curvature of - 122 m (mirror is flipped) This is shown as dashed curves in the plot. 

expected_edit.png

The plot above shows beam radii of the PRM reflections for vertical and horizontal profiles in each case.
The x-axis is distance from PRM in meter and the y-axis is the beam radii in mm.
As for the initial beam parameter, I used the measured values (see the wiki), which are that of after the beam exits from the mode matching telescope and before it goes to PRM.
 
(1) If PRM has the correct curvature, the reflection after it passes MMT1 will have ~ 1.6 mm beam radii.
This is intuitively correct because the beam profiles should match to that of the MC exiting beam  (see the wiki), which has waist size of 1.5 - 1.6 mm if everything is perfect.
(2) When PRM is flipped, the beam starts converging at the beginning as PRM act as a convex mirror, resulting in smaller beam sizes after it comes out from the telescope.
Roughly speaking the waist sizes will be different by ~ 5 mm between those two cases, so our measurement should be more precise and accurate than this number.

Note:

 I have omitted the effect from the PRM thickness. Therefore PRM is dealt as just a curved reflector with RoC of +/- 122 m in the calculation.

 

  6445   Mon Mar 26 16:25:44 2012 kiwamuUpdateIOOexpected v.s. measured beam profile of PRM reflection

[Suresh / Kiwamu]

 We did the 2nd round of the PRM reflection mode scan on Friday.

It seems that the PRM curvature maybe correct if we look at the vertical mode, however but the horizontal mode doesn't seem to agree with any of the expected lines.

In order to increase the reliability of the measurement, we need to confirm the beam profile of the incident beam by looking at the IP-POS beam.

Right now Suresh and Keiko are mode-scanning the IP-POS beam.

 

 


The plot below shows both the expected beam profiles (see the detail in #6444) and the actual data. 

PRMreflection.png

This plot is the same as one shown in the previous entry (#6444) with newly added actual data.
The errorbar in each data point is the standard deviation obtained by 100 times of averaging.
In this plot I made the error bars 10 times bigger in order to let them visible in the plot, so the actual deviation is much lesser than they appear.
 

(Discussion)

 The vertical profile (shown in red) seems to be close to the curve for the correct PRM case.
However the horizontal profile has a bigger waist size of about  2 mm.
While measuring the waist size Suresh and I have noticed that the rotational angle of the scan head affects the measurement by 10% or so.
Of course in each data point we tried making the incident beam normal to the scan head by rotating the scan head.
But this 10% is not big enough to explain the discrepancy in the horizontal mode.
There are some possible scenario which can distort the beam shape in the horizontal direction:
  • Clipping at some optics. (Since the beam shape looked very Gaussian, the amount of the clipping could be very slight ?)
  • Astigmatism at some optics. (Possibly in the telescope ?)

(Some distances)

DSC_4001_small.jpg
 

(Some notes)

We did the following things prior to the measurement.

  • Put a boost filter in the PRM_OLYAW to suppress the beam jitter below 1 Hz.
  • Checked the MC WFS servo loop although it looked healthy.

Quote from #6444

I have estimated how the mode profile of the PRM reflection should be, as shown in the plot blow.

A conclusion here is :

   we should be able to constrain the PRM curvature situation if measurements are precise and accurate enough with a level of less than ~ 100 um 

 

  6446   Mon Mar 26 18:04:43 2012 kiwamuUpdateIOOmode scan at the REFL port

For those who are interested in the actual data, I attache the actual data in zip file together with a python plot code.

The distance was set such that the 1st steering mirror (the one at the very left in the previous cartoon diagram #6445 ) in the REFL path is positioned at zero.


mode_profile.png

 

- - - Fitting results (chi-square fitting done by gnuplot):

All values are in unit of meter

# PRM (v) (Last tree points are excluded as the beam were clipped at the aperture of the beam scan)

w0          = 0.0015114        +/- 2.192e-05    (1.451%)
z0           = -4.46073         +/- 0.05605      (1.256%)

# PRM (h)

w0           = 0.00212796       +/- 1.287e-05    (0.6049%)
z0           = -2.53079         +/- 0.1688       (6.668%)

# ITM (v) (Last two points are excluded as the beam were clipped at the aperture of the beam scan)

w0           = 0.00190696       +/- 4.964e-05    (2.603%)
z0           = -8.09908         +/- 0.1525       (1.882%)

# ITM (h)

w0           = 0.0032539        +/- 4.602e-05    (1.414%)
z0           = -1.89484         +/- 1.524        (80.42%)

 

  6447   Mon Mar 26 23:47:54 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam

[Keiko, Suresh]

   Keiko and I measured the IPPOS beam profile.  The fit parameters  are :

  Vertical Horizontal
Waist (mm) 2.77 2.48
Rayleigh length (m) 23.5m 15.87
Waist location (m) 0.81 m 1.85

BeamProfile_IPPOS.png

 

The data files are attached. 

  6448   Tue Mar 27 02:05:40 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam

Quote:

[Keiko, Suresh]

  Vertical Horizontal
Waist (mm) 2.77 2.48
Rayleigh length (m) 23.5m 15.87
Waist location (m) 0.81 m 1.85

BeamProfile_IPPOS.png

 

 

If we assume the nominal wavelength of the IR light to be 1064nm and constrain the Rayleigh length to be zr = (pi w0^2)/lambda we obtain the following fit parameters: (these are compared with the beam profile measurements of June/18/2010 available in the wiki )

  Vertical

Vertical 

06/18/2010

Horizontal

Horizontal

06/18/2010

waist (radius) (mm) 2.77 2.81 2.47 2.91
Rayleigh length (m) (computed) 22.62   18.14  
Waist location w.r.t. to MM2 * 3.37 5.36 4.15 1.96

* I updated the waist waist location coz because I missed-out the distance in air from the vacuum port to the optic on the IPPOS table.

 

BeamProfile_IPPOS.png

 

 

  6449   Tue Mar 27 02:18:31 2012 keikoUpdateIOOBeam Profile measurement: IPPOS beam

Keiko, Rana, Suresh

Related to the beam profile of IPPOS today, we tried to measure the beam size at the ETMY point in order to estimate the input beam mode. We measured the beam size hitting at the suspension frame by a camera image, with two situations to see two "z" for beam profile.

(1) Input beam is slightly misaligned and the injected beam hits the end mirror frame. Assuming z=0 at the input mirror, this should be z=40m.

(2) Input beam hits the centre of the end mirror, and ITMY is slightly misaligned and the beam hits the end mirror frame after the one-round trip. Assuming z=0 at the ITM, this position should be z=120m.

text9149.png

The injected beam at the end point and the one round trip ligt at the end point should be the same size, if the input mode matches to the cavity mode. You can see if your injected light is good for the cavity or not. We compared and assumed the above two beam sizes by looking at the photo of the beam spot.

(1) first_cap.png (2) second_cap.png

 Assuming the zoom factor difference by the part below the beam (shown with allow in the photos. Arbitrary unit.), the beam in (2) is smaller than expected (roughly 40%?).

However this is a very rough estimation of the beam sizes! It is difficult to assume the beam size shown on the photos! It looks smaller only because the power of (2) is smaller than of (1). I don't think we can say anything from this rough estimation. One may be able to estimate better with CCD camera instead of this normal camera. 

 

  6450   Tue Mar 27 02:46:28 2012 kiwamuUpdateIOOREFL beam available

The dump and some temporary mirrors were removed and now the REFL beam is available again.

I locked PRMI with REFL signals, it locked as usual.

Quote from #6440

Currently the REFL beam is bypassed by additional mirrors and blocked by a razor blade dump.

  6451   Tue Mar 27 11:54:18 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

I'd like to know what we expect for these numbers.  I've added to Kiwamu's drawing some more distances, so I can calculate the expected beam size at the IPPOS port.

IPPOS_distances.pdf

 

Quote:

Quote:
 

  Vertical

Vertical 

06/18/2010

Horizontal

Horizontal

06/18/2010

waist (radius) (mm) 2.77 2.81 2.47 2.91
Rayleigh length (m) (computed) 22.62   18.14  
Waist location w.r.t. to MM2 * 3.37 5.36 4.15 1.96

 

  6452   Tue Mar 27 16:06:59 2012 keikoUpdateIOOBeam Profile measurement: IPPOS beam

I changed the ETMY CCD camera angle so that we can see the suspension frame in order to repeat the same thing as yesterday. The ETMY camera is not looking at the beam or mirror right now.

  6453   Tue Mar 27 17:19:02 2012 KojiUpdateIOOBeam Profile measurement: IPPOS beam

The mode looks quite terrible in the plot, but in reality it is an illusion of the plot.

The actual TEM00 content in this beam is ~99.7%


mode_coupling.pdf

Based on the above document, you can calculate power coupling between two elliptic gaussian modes.

Give the parameters of one beam as

zRy1 = pi*(2.77e-3)^2 / 1064e-9
z1y = 3.37
zRx1 = pi*(2.47e-3)^2 / 1064e-9
z1x = 4.15

Then, assume a round beam for the other.

zRx2 = zRy2 = zR
z2x = z2y = z0

Then run the optimizer to find the maximum for the quantity |C|^2

|C|^2 max: 0.9967
zR = 20.19
z0 = 3.804

  6454   Tue Mar 27 17:38:03 2012 JenneUpdateIOOAnother possibility / thought

I'm meditating over the mode matching from the mode cleaner to the ITMs, and I had another thought:

Have we changed the pointing of the MC significantly enough that we are no longer on the center of the MMT mirrors?  To be this significant, we would probably also have had to scoot the Faraday a bit too, since it's skinny like a straw.  It looks like our measurements of the input beam have been the following:

MC waist, 21 May 2010

After MMT2, 18 June 2010 (a few days before this, we flipped the MMT2 mount to 'perfect' the mode matching up to 99.3%, so I don't think the MMT has moved since then.)

After MMT2, 26 March 2012

There's a big o' ~2 year gap between our measurements, and we've been in and out of the vacuum a few times since then.  I'll flip through the elog, but does anyone have any memory of us moving the Faraday after June 2010?  When was the last time we made sure that we were at least close to the center of the MMT mirrors? 

  6455   Tue Mar 27 17:52:08 2012 KojiUpdateIOOAnother possibility / thought

It is quite likely that we touched the Faraday in Nov 2010.

In this entry http://nodus.ligo.caltech.edu:8080/40m/3874 I wrote that I removed the MCT optics in the chamber.
This is the pickoff between the IMC and the Faraday. This causes the beam shift. Therefore, the Faraday had
to be moved.

There were intensive in-chamber activities from Nov to Dec 2010. I am sure that almost everytime we went into
the chamber, we checked the spot position on the MMT mirrors as well as the TT and PZT mirrors.

Does the miscentering of the spots on the MMT mirrors cause the mode matching significantly changed?

  6456   Tue Mar 27 18:03:46 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

This is wrong!  See following elog for corrected plot (and explanation)

I'm not done meditating on what's going on, but here's what I've got right now:

BeamProp_usingMeas2012MMTnumbersLowRes.png

This is a beam profile, using the distances from the combined Kiwamu / Jenne sketch earlier today. 

0 meters along the horizontal axis is meters from the Mode Cleaner waist. (Yes, I was bad and forgot to label it.  Get over it.)

The pink and green dots to the left of the plot are the MC fitted waist measurements that we made in May 2010.

The pink and green dots in the ~center of the plot are the fitted waist measurements that Suresh and Keiko took yesterday, of the IPPOS path, so after the MMT.

The black dot is where we would like our non-astigmatic beam to be.  This is the calculated waist size of the cavity mode, using the new ~37.76m distance, after we moved the ETMs to their current positions.  The black dot indicates 3.036 mm at the ITM (averaged between the BS-ITMX and BS-ITMY distances).

The moral of the story that I'm getting from this plot:  something funny is going on.

The distances Kiwamu quoted on the sketch are very close to the ones that I used for designing and checking the MMT in the first place, which were based off of measurements using rulers etc to measure distances.  Steve said he looked at photos today, and agreed that Kiwamu's numbers looked reasonable also.

Something that we haven't done lately is measure the position of each optic from every other optic, along the beam path.  I propose we come up with a clever way to put a target on top of / next to mirrors, and then a way to hold the laser distance measure-er at an optic, so that we can go thorough systematically and measure the actual path that our beam is seeing.  Maybe this is too much work, and not worth it, but it would make me happier.  In my head, these 'fixtures' are just small pieces of cleaned aluminum, one that can sit on a mirror mount, and one which we can use to align the laser ruler to approximately the front of an optic.  Nothing fancy.

  6457   Tue Mar 27 21:20:32 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

Quote:

The moral of the story that I'm getting from this plot:  something funny is going on.

 Yup, something funny was going on.  Nic's MM code that I used, "a la mode", calls for the focal length of the optics, whereas the code that I wrote and used for ages called for the radius of curvature.  f = R/2.  Fixing that factor of 2 I get something more like:

BeamProp_usingMeas2012MMTnumbersLowRes.png

This is obviously much better, in that the beam profile goes through (within some error) both of the measured sets of points - the MC waist measured in May 2010, and after the MMT measured yesterday.

So, what does it all mean?  That I'm not sure of yet.

  6458   Tue Mar 27 21:37:51 2012 keikoConfigurationIOOBeam Profile measurement: IPPOS beam

 From the mode measurement I and Suresh have done yesterday, I calculated what beam size we expect at ETM ((1) upper Fig.1)  and at ETM after one bounce ((2) lower Fig.1).

expsche.png

Fig.1 (Yarm)

In case of (1), we expect approximately w=6300 um (radius), and w=4800 um for one-bounce spot (2) from the measured mode, see Fig.2.

drawing.png

Fig.2

This roughly agree with what we observed on CCD camera. See, pic1 for (1) and pic2 for (2). The spot at the ETMY (1) is larger than the one-bounced spot (2). From the monitor it is difficult to assume the radius ratio. The observed spot of (2) is a bit smaller than the prediction. It could happnen when (A) the ETMY (as a lens) is slightly back of the ideal position (= the distance between the ITM and ETM is longer than 40m) (B) the real waist is farer than ITM position toward MC (I assumed roughly 5 m from Jenne's plot, but could be longer than that).

P3270007-s.jpg  P3270008-s.jpg

pic1 (left): beam spot hitting on the suspension frame. pic 2 (right): the one-bounced beam spot hitting on the suspension frame.

 

  6459   Tue Mar 27 23:37:35 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam

Quote:

Quote:

The moral of the story that I'm getting from this plot:  something funny is going on.

 Yup, something funny was going on.  Nic's MM code that I used, "a la mode", calls for the focal length of the optics, whereas the code that I wrote and used for ages called for the radius of curvature.  f = R/2.  Fixing that factor of 2 I get something more like:

.....

So, what does it all mean?  That I'm not sure of yet.

 In an attempt to estimate the errors on the fit parameters I upgraded my Mathematica code to use the function 'NonlinearModelFit', which allows us to define weights and also reports the errors on the fit parameters.   The plots have been upgraded to show the error bars and residuals.

Beam-Profile_IPPOS_wError.png

 

The parameters determined are given below and compared to the earlier measurements of 06/18/2010

Vertical Profile:

Parameter Estimate Standard Error 95% Confidence interval 06/18/2010 measurement
Waist (mm) 2.768 0.005 2.757 -- 2.779 2.81
Waist location from MMT2 (m) 5.85 0.12 5.625-- 6.093 5.36

 

 

Horizontal Profile:

Parameter Estimate Standard Error 95% Confidence Interval 06/18.2010 measurement
Waist (mm) 2.476 0.009 2.455 -- 2.496 2.91
Waist Location from MMT2 (m) 4.935 0.145 4.645 -- 5.225 1.96

 

There is a significant change in the beam waist location (as compared to previous report) because I corrected a mistake in the sign convention that I was using in measuring the distances to the waist from the zero-reference.
 

  6460   Wed Mar 28 01:17:29 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

As I was a little dissatisfied with the inaccuracy in the distance numbers in Kiwamu's sketch, I went back to the 18 Dec 2010 table layout drawing for more accurate numbers.  These are now included in this round of plots.

Also, I include astigmatism due to the incident angles on MMT1 (~3.5 deg) and MMT2 (~1 deg).

First plot, IPPOS path, using the recent (fixed) measurements from Suresh to fix the beam width.  Note that the old 2010 measurements of the MC waist are consistent with this measurement.

Second plot, Main IFO path all the way to the ITM (average) position, using the 2010 MC waist measurements to fix the beam width.

Third plot, Main IFO path all the way to the ITM position, but with PRM flipped (negative RoC), using the 2010 MC measurement to fix beam width.

With the PRM correctly oriented (2nd plot), I get beam waists of (x = 2.529 mm, y = 2.646 mm), which corresponds to a mode matching to the arm cavity of (eta = 97.43%, PRM correct).

With the PRM flipped (3rd plot), I get beam waists of (x = 3.176 mm, y = 3.3 mm), which corresponds to a mode matching to the arm cavity of (eta = 99.55%, PRM flipped).

 

First plot:

BetterDistances_IPPOSLowRes.png

Second plot (this is how the MMT was designed to be, before the ETMs were moved, which made the ideal waist larger):

BetterDistances_MainIFO_PRMnormalLowRes.png

Third plot:

BetterDistances_MainIFO_PRMflippedLowRes.png

For both the 2nd and 3rd plot, we can't look at the post-MMT waist measurements, since that distance on the plots is after the PRM, which is a curved optic.  So the fact that the post-MMT measurements match the correct-PRM plot better than the flipped-PRM plot can't be taken to be meaningful.

Moral of the story:  I'm not sure how to interpret any of this to tell us if the PRM is flipped or not, since the measurements are all of the beam profile before the beam sees the PRM.  We'd have to measure the profile after the PRM somehow in order to get that information.  We have okay but not great mode matching to the arm if the PRM is correct, but I don't know that we readjusted the MMT after we moved the ETMs.  I don't remember recalculating any optimal telescope lengths after the arm length change.  If we need better mode matching, I can do that calculation, although given how much space we don't have, it would be hard in practice to move the MMT mirrors by much at all.

  6461   Wed Mar 28 18:26:47 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

More calculations....

Game Plan:  Using MC waist measured beam as the starting point of beam propagation, move MMT mirrors around until the beam profile fits with the IPPOS measurements from Monday.

Plot 1:  Allow MMT mirrors to move as much as they want to.  Note that the Y-beam goes through the IPPOS measured point. (This implies we put the MMT in the wrong place by ~half a meter.  Unlikely)

Plot 2: Using MMT locations from plot 1, what does the beam look like at the ITMs? 

Plot 3:  Allow MMT mirrors to move as much as 2cm.  Note that the Y-beam doesn't quite go through IPPOS measured point.

Plot 4: Using MMT locations from plot 3, what does the beam look like at the ITMs?

For all of the above, I was optimizing the propagation of the Y-beam profile.  Since the X-beam profile measurement is so different, if I want to optimize to X and let the MMT mirrors move as much as they want, MMT1 ends up inside the MC.  Unlikely.  So I'm just looking at Y for now, and maybe Suresh or someone needs to rethink the error bars on their measurements or just remeasure.

Plot 1:

OptimizedMMT_halfMeterChange_IPPOSviewLowRes.png

Plot 2:

OptimizedMMT_halfMeterChange_IFOviewLowRes.png

Plot 3:

OptimizedMMT_pt2cMeterChange_IPPOSviewLowRes.png

Plot 4:

OptimizedMMT_pt2cMeterChange_IFOviewLowRes.png

  6462   Wed Mar 28 20:54:02 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

I fitzed by hand with the numbers for the incident angles on MMT1 and MMT2, and then let the code optimize the position of MMT1 and MMT2.

Here I have set the incident angle for MMT1 = 25deg, and MMT2 = 12deg (should be 3.5deg, 1deg by design).  The length of the telescope doesn't want to change by more than 7mm, but the position of the telescope wants to change by 1.3meters.  Is it possible that the distances on the Monday IPPOS measurements aren't actually correct?

MMT_moved_by_1pt3meters_MMT1th_25_MMT2th_12_LowRes.png

  6476   Mon Apr 2 18:58:32 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

Suresh noted that I never wrote down the waist positions of the beam propagated through the MMT (based on where we think it is from ruler-based measurements).  This uses the MC waist measured beam as the starting point, and just propagates through the MMT, out to the IPPOS port.

Yq:

  Properties:
                    q: 2.2488 +23.8777i
               lambda: 1.0640e-06
            waistSize: 0.0028  (at z = 13.2676 meters)
               waistZ: 2.2488    (relative to z = 13.2676 meters)
      divergenceAngle: 1.1910e-04
    radiusOfCurvature: 255.7849
            beamWidth: 0.0029
        rayleighRange: 23.8777

So, to sum up, the vertical beam waist is 2.8438 mm at 11.0188 meters from the MC waist.

 

Xq:

  Properties:
                    q: 5.1953 +24.7342i
               lambda: 1.0640e-06
            waistSize: 0.0029   (at z = 13.2676 meters)
               waistZ: 5.1953    (relative to z = 13.2676 meters)
      divergenceAngle: 1.1702e-04
    radiusOfCurvature: 122.9525
            beamWidth: 0.0030
        rayleighRange: 24.7342

So, to sum up, the horizontal beam waist is 2.8943 mm at 8.0723 meters from the MC waist.

In pictorial form,

NonOptimized_propagatedWaistPlotted_LowRes.png

  6477   Mon Apr 2 23:06:38 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam: Mystery deepens

Quote:

I fitzed by hand with the numbers for the incident angles on MMT1 and MMT2, and then let the code optimize the position of MMT1 and MMT2.

Here I have set the incident angle for MMT1 = 25deg, and MMT2 = 12deg (should be 3.5deg, 1deg by design).  The length of the telescope doesn't want to change by more than 7mm, but the position of the telescope wants to change by 1.3meters.     Is it possible that the distances on the Monday IPPOS measurements aren't actually correct?

 

I am trying to track down possible errors in our measurements. 

So as a first step I am recomputing the IPPOS waist location with respect to the MC waist, using the same optical layout diagram as the one used by Jenne in her calculations.  Pic of Jenne's lab notebook showing location of optics is attached.  

IPPOS: measurement elog 6459: Vertical Std.Error Horizontal Std.Error
Waist  2.768 mm 5 microns 2.476 mm 10 microns
Waist location from MC waist  12.411 m  17 mm  9.572 m 54 mm

Std Dev of residuals from fit function

  37 microns   54 microns

 Let us compare it with the old measurement of the IPPOS beam from June/18/2010.

IPPOS: measurement June 18th 2010 Vertical Std.Error Horizontal Std.Error
Waist  2. 812mm 8 microns 2.909 mm 20 microns
Waist location from MC waist  9.265 m  224 mm  5.869 m 415 mm

Std Dev of residuals from fit function

  ~ 25 microns   ~25 microns

Note that there is a discrepancy of about 3.2 m in the waist location for the vertical profile and about 3.5 m for the horizontal profile between these two measurements. 

Let us compare these measurements with what is expected from calculations.  Jenne uses the known parameters of MC waist and the locations of the MMT optics to compute the parameters for the IPPOS beam:

IPPOS: Jenne's Calculations elog 6476:

Vertical Std.Error Horizontal Std.Error
Waist  2.844 mm   2.894 mm  
Waist location from MC waist  11.019 m   8.072 m  

 As the 2010 measurements are reported wrt to MMT2 and calculations are wrt MCwaist, I have used the distance between the MCwaist to MMT2 = 3.910 m to shift the reference from MMT2 to MC waist. Refer to the attached diagram from Jenne's notes for this MMT2 <--> MC waist distance.

There is a discrepancy of 1.5 meters between the calculations and recently measured waist location.  The discrepancy with the 18Jun2010 measurement is much larger, about 3 meters in both v and h.

Are such variations to be expected between two successive measurements?  I looked at another case where we have two measurements of a beam to see what to expect.

I looked at the REFL (Reflection from PRM) case, where we repeated a measurement, to see how much variation could happen in w0 and zr, between repeated measurements. This was a particularly bad case as our first attempt had problems due to OL servo loop oscillations in the PRM suspension damping.  We fixed that later and measurement 2 has smaller residuals. And I think we are doing okay in IPPOS case as seen by the reduced scatter of the residuals.

 These are the fits from the REFL beam measurement 1

REFL: Reflection from PRM: measurement 1 Vertical Error Horizontal Error
Waist 1.662 mm 4 microns 2.185 mm 4 microns
Waist location from MMT2 after reflection at PRM 1.781 m 17 mm 4.620 m 53 mm
Std.Dev. of residuals from fit function   61 microns   98 microns

 I have also recomputed the fits to the data from REFL beam measurement 2.  They match the earlier fits reported by kiwamu in his elog 6446

REFL: Reflection from PRM: measurement 2 Vertical Error Horizontal Error
Waist 1.511 mm 3 microns 2.128 mm 3 microns
Waist location from MMT2 after reflection at PRM 1.281 m 9 mm 3.211 m 37 mm
Std. Dev of residuals from fit function   58 microns   61 microns

 

Note that between these two measurements the beam waist location has shifted by 0.5 m for the vertical and about 1.3 m for the horizontal cases.  So variations of 1.5 m in the waist locations are possible if we are not careful.  But this is a particularly extreme example, I think we are doing better now and the measurement is unlikely to change significantly if we repeat it.

Some notes:

Fits for IPPOS and both REFL measurements 1 and 2 are attached. 

The zero reference for the z axis of the IPPOS beam plot is at a distance of 6.719 m from MC waist for a beam propagating towards the IPPOS QPD.

The zero reference for the z axis of the REFL beam plots is at a distance of 5.741 m from the MMT2 in the direction of a beam reflected by PRM and propagating towards the REFL port.

 

  6496   Fri Apr 6 15:06:05 2012 DenUpdateIOO1 Hz resonance

I think we can try to damp 1 Hz resonance more. In September it was not seen because of the digital noise. After we've figured it out, 1 Hz resonance began to be more clear (blue line).

psd_mcl.jpg

Now applying oaf we reduce the effect of the stack and the 1 Hz resonance is even more clear:

mcl.jpg

 

  6516   Tue Apr 10 17:02:29 2012 JenneUpdateIOOMode matching recollections and conclusions

...Mostly just recollections at this point.

I re-looked at the mode matching's sensitivity to misplaced optics.  Here is the plot that the original MMT code from 2010 spits out:

IMMT_positionSensitivity_plotted10Apr2012_LowRes.png

What this plot is telling us is that we should lose no more than 0.1% of mode matching "goodness" if we messed up the curved optic's positions by up to 2 cm.  If we can't place optics to within 2 cm, we might as well go back to optics kindergarten, because that's pretty lame.

UPDATE: Here is a histogram using the new code, which definitely includes the non-unity index of refraction for the transmissive optics and the Faraday.  The only optics which are permitted to move are the 2 curved optics, and they are allowed a stdev of 20mm.  Again, we shouldn't be doing worse than ~99% mode matching, even if we're 2cm off from the MMT positions that we measured with a ruler.  This histogram only has 300 iterations, since it takes quite a while (~0.5sec) to calculate each iteration.  Note this is mode overlap using the measured MC waist, propagated through optics, compared to the ideal arm mode.  This is completely ignoring the IPPOS measurements so far.

Histogram_20mmStDev_MMTmovesOnly_LowRes.png

 

UPDATE 2: Allowed 5 degrees of incident angle motion for both curved optics, which changes the astigmatism of the beam downstream.  Still, no big change from ~99% mode matching efficiency.  Again, this doesn't include any information from the IPPOS measurements.  3000 iterations this time around, since I didn't need my computer.  Curved optics still allowed to move back and forth by 2cm. 

Histogram_20mmStDev_MMTmovesAndTilts_LowRes.png 

More meditations and conclusions to follow...  currently running hist code to allow tilt of optics, to account for astigmatism changes also. 

Suresh and I are going to do some beam measurements tomorrow with the beamscanner, and then we will do a few measurements with the razor blade technique, to confirm that we're doing things okey dokey.

  6522   Wed Apr 11 18:19:51 2012 JenneUpdateIOOMode matching recollections and conclusions

Another histogram.  This one allows the MMT mirror positions to move, the MMT incident angle for both curved optics to change, and the MC waist size and position to change.  The error quoted for the MC waist size measurement from 2010

was +\- 0.01mm, and the MC waist position was +\- 28mm.  

This histogram is showing that we're pretty sensitive to the MC waist measurement, which is used to define the beam.  We can be up to ~2% off in our ideal mode matching to the arms if we're using the incorrect initial beam for the telescope design.

ModeMismatch_MMTpos_MMTang_MCw0_MCwz_change_LowRes.png

  6526   Thu Apr 12 01:17:56 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam: Possible Clipping

[Suresh, Jenne]

  The input beam is most probably being clipped at the Faraday Isolator.  

Evidence: 

a)  The beam scan of the IPPOS beam showed a nongaussian beam in the horizontal direction.  This was visible in the beam scan since it overlays a gaussian-fit over the data.

b)  I was able to remove this departure from gaussian profile by introducing an offset of 5 into the C1:IOO-WFS2_YAW_OFFSET.  

c)   We made a few measurements of the beam diameter as a function of distance at an offset of 7.  At a distance of beyond 3 m the deviation from gaussian profile was once again apparent. 

d)  We increased the offset to 14 to remove this deviation. 

e)  When we measured the beam diameter again with this new offset the horizontal diameter and vertical diameters dropped by 2.sigma.  Indicating there the beam was clipped till then.

f)   We increased the offset to 16 and the beam diameter did not change further (within 1.sigma). Implying no more clipping, hopefully. 

And then the earthquake stopped us from proceeding further. 

We plan to investigate this further to be sure..  Data attached.

 

Subsidiary effects to keep track of:

1) Introducing an offset into the WFS loops decreases the coupling from PSL into MC. 

2) If the beam is being clipped at the Faraday Isolator then the REFL beam would also show lesser clipping with WFS offsets.

  6531   Thu Apr 12 23:12:16 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam: Possible Clipping

WiQuote:

[Suresh, Jenne]

  The input beam is most probably being clipped at the Faraday Isolator.  

Evidence: 

.....

We plan to investigate this further to be sure.. 

.....

 

I tried to determine an optimal WFS2YAW offset to be used so that we may avoid clipping.

Initially, I just measured the beam diameter as a function of offset.  If the beam diameter would become independent of offset if it is not clipped.  However a systematic effect became apparent when I shifted the beam on the detector to a slightly different location.  So I repeated the measurements while recentering the beam to the same location everytime  (centered at -1650+/- 50 for both H and V directions).

I have attached plots of the scans for both cases, with recentering and without.    I have not been able to figure out what is going on since the beam diameter does not become independent of the offset.  While the beam profile becomes more gaussian beyond offsets of about 7 or so, the beam diameter does not seem to follow a clear pattern.  The measurements are repeatable (within one sigma) so the experimental errors are smaller than 1 sigma.

The photographs below show the improvement of Horizontal beam profile with WFS2Yaw offset.  These seem to indicate a good gaussian beam for offsets beyond 7 or so.  At offsets more than 12 the MC unlocks.

 

Hor_OSet-2.png Hor_OSet0.png Hor_OSet2.png Hor_OSet8.png
 Offset = -2   Offset = 0   Offset = 2   Offset = 8

 

 

HorizontalNoRecenter.png  HorizontalRecentered.png
  This seems to indicate that the beam diameter does not vary for WFS2Yaw offset > 8  But if we recenter the beam for each measurement this effect seems to vanish

        

 Will continue tomorrow.   Jenne wants to do some IFO locking now.

 

  6575   Thu Apr 26 18:17:56 2012 SureshUpdateIOOMC WFS: Tweaked the WFS offsets

[Jamie, Suresh]

Yesterday Den and Koji reported that the WFS loops were causing the MC to become unlocked.  They had aligned the PMC.   The input beam into the MC seems to be well aligned.  MCREFL DC close to minimum it gets while MC is locked (~0.45 V).

I checked and saw that the WFS heads and the MC2_TRANS_QPD had picked up DC offsets.  To reset them I turned off the MC_autolocker and closed the PSL shutter.

The ADC offsets were set using this script /cvs/cds/rtcds/caltech/c1/scripts/MC/WFS/WFS_QPD_offsets.  (Jamie fixed the paths to ezcaservo to get this script to work)

The WFS sensor head offsets were manually set to adjust the Q and I signals from the sensor head to zero.  (This operation is supposed to be done by a script which is available, but I will check it out before I direct people to it).

Then we noticed that the ASC outputs were turned off.  (Presumably Koji turned them off yesterday, when the MC was repeatedly unlocking due to the WFS loops).

We turned on the ASC outputs and the MC stayed locked with reasonable outputs on the WFS output channels.  (+/-100)

However, engaging the WFS servo increases the MCREFL DC signal to 0.7 V from the 0.45 V value when the servo is not engaged.  This could be because of DC offsets in the WFS servo filters.   I will adjust these offsets to maintain good MC transmission when the WFS servo is engaged.

 

 

 

  6611   Mon May 7 01:07:58 2012 DenUpdateIOOseismic in mcf

I tried to figure out where additional (to seismic) noise enters to MC_F, so the coherence below 1 Hz is low (~0.2-0.5). I've examined noise in the path

PD -> DEMOD -> MC BOARD -> FSS -> PZT Controller -> LASER

  • I terminated ADC and measured its noise
  • connected MC BOARD OUT to ADC, terminated INPUT1 of the MC BOARD and measured noise
  • connected DEMOD Q OUT to MC BOARD INPUT1, terminated PD INPUT on the DEMODULATOR and measured noise
  • connected PD to DEMOD, blocked the beam incident to the PD and measured noise

pd-mcf.jpeg

 MC BOARD noise shows up only below 0.1 Hz and at 10 Hz where the whitening filter starts to work. SNR is ~2 at 4 Hz, so we might want to slightly improve whitening filter. But other then that path PD->DEMOD->MC BOARD is not responsible for additional noises below 1 Hz.

Next I connected SR785 to the laser and measured the closed loop feedback signal while MC was locked.

fb.png     coh_err_fb.png

Coherence between MC BOARD OUT1 and feedback signal is high enough to assume that FSS and PZT controller are also not responsible for additional noise.

From the other hand MC2 SUSPOS measured by OSEMS shows good coherence with GUR1_X

mc2_suspos.jpg

That means that MC2 is indeed driven by seismic motion. In order to figure out if this is the case for MC1 and MC3, I rotated GUR2 by 45 degrees. When it will calm down, I'll measure coherence between OSEMs and seismic motion.

  6612   Mon May 7 12:57:34 2012 DenUpdateIOOWFS noise in MC

I've measured coherence between seismometer signals and OSEMS of MC 1,2,3

gur_suspos_coh.png

GUR1 was rotated on the angle pi / 4 relative to x arm to match suspos axis of MC1 and MC3. Coherence between MC2 and GUR2_X is high, between MC3 and GUR1_X is ~0.2 but is compensated by GUR1_Y, between MC1 and GUR1_Y below 1Hz is ~0.5 and is not compensated by GUR1_X.

Then I measured coherence between GUR1_Y and MC3 OSEMS in 3 regimes :

  • FEEDBACK OFF, WFS OFF
  • FEEDBACK ON, WFS OFF
  • FEEDBACK ON, WFS ON

mc1_gur.png

Once WFS are ON, signal becomes noisy, FEEDBACK is OK. Then I measured coherence between MC_F and GUR2_X with WFS ON and OFF

mcl_wfs.png

Coherence between MC_F and GUR2_X is less when WFS are ON in the range 0.2 - 1 Hz and 4 - 10 Hz. Moreover PSD of MC_F seems to be higher at 10 - 100 Hz. But this may be caused by other reasons.

Then I measured the coherence between IN and OUT signals in WFS_SERVO

wfs_servo.png

One filter bank adds noise to WFS signals and because of that we loose coherence between MC_F and seismic motion.

  6613   Mon May 7 17:28:29 2012 DenUpdateIOOWFS noise in MC

Quote:

One filter bank adds noise to WFS signals and because of that we loose coherence between MC_F and seismic motion.

 This effect is due to C1:IOO-WFS1_PIT_LIMIT=2000. When I turned if off, coherence between C1:IOO-WFS_PIT input and output signals restored

wfs_limit.png

The other thing is that WFS actuate on the angular motion, but this couples to the position motion. We need to diagonalize the actuator.

  6614   Mon May 7 19:39:52 2012 KojiUpdateIOOWFS noise in MC

OK. Then we should make this number bigger such that the coherence is still completely maintained.
Is this set in the auto locker? Or manually set?

Quote:

  This effect is due to C1:IOO-WFS1_PIT_LIMIT=2000. When I turned if off, coherence between C1:IOO-WFS_PIT input and output signals restored

 

  6615   Mon May 7 20:15:37 2012 DenUpdateIOOWFS noise in MC

Quote:

OK. Then we should make this number bigger such that the coherence is still completely maintained.
Is this set in the auto locker? Or manually set?

Quote:

  This effect is due to C1:IOO-WFS1_PIT_LIMIT=2000. When I turned if off, coherence between C1:IOO-WFS_PIT input and output signals restored

 

 

LIMIT is set manually, auto locker does not change it. I've put C1:IOO-WFS1_PIT_LIMIT=4000, it seems to be fine for now.

  6641   Fri May 11 17:21:56 2012 JenneUpdateIOOOAF left enabled - MC unlocked for more than an hour

No leaving the OAF running until you're sure (sure-sure, not kind of sure, not pretty sure, but I've enabled guardians to make sure nothing bad can happen, and I've been sitting here watching it for 24+ hours and it is fine) that it works okay.

OAF (both adaptive and static paths) were left enabled, which was kicking MC2 a lot.  Not quite enough that the watchdog tripped, but close.  The LSCPOS output for MC2 was in the 10's or 100's of thousands of counts.  Not okay.

This brings up the point though, which I hadn't actively thought through before, that we need an OAF watchdog.  An OAF ogre?  But a benevolent ogre.  If the OAF gets out of control, it's output should be shut off.  Eventually we can make it more sophisticated, so that it resets the adaptive filter, and lets things start over, or something. 

But until we have a reliable OAF ogre, no leaving the adaptive path enabled if you're not sitting in the control room.  The static path should be fine, since it can't get out of control on it's own.

Especially no leaving things like this enabled without a "I'm leaving this enabled, I'll be back in a few hours to check on it" elog! 

  6652   Mon May 21 07:45:39 2012 steveUpdateIOOPMC locked

I locked the PMC and the MC followed instantly.

  6660   Tue May 22 13:06:11 2012 JenneUpdateIOOWFS didn't turn off automatically

I just sat down in the control room, and discovered the PMC (and everything else) unlocked.  I relocked the PMC, but the MC wasn't coming back.  After a moment of looking around, I discovered that the WFS were on, and railing.  I ran the "turn WFS off" script, and the MC came back right away, and the WFS came on as they should.

We need to relook at the WFS script, or the MC down script, to make sure that any time the MC is unlocked, no matter why it unlocked, the WFS output is off and the filter histories are cleared.

  6665   Wed May 23 10:40:21 2012 steveUpdateIOOPMC locked

Quote:

I locked the PMC and the MC followed instantly.

 

  6669   Wed May 23 21:32:15 2012 SureshUpdateIOOWFS didn't turn off automatically

Quote:

I just sat down in the control room, and discovered the PMC (and everything else) unlocked.  I relocked the PMC, but the MC wasn't coming back.  After a moment of looking around, I discovered that the WFS were on, and railing.  I ran the "turn WFS off" script, and the MC came back right away, and the WFS came on as they should.

We need to relook at the WFS script, or the MC down script, to make sure that any time the MC is unlocked, no matter why it unlocked, the WFS output is off and the filter histories are cleared.

    The only script that can currently take this action is the MC autolocker.  If that is disabled first and the PMC unlocks later, the WFS will not be turned off.  During the last round of discussions we had about the autolocker script, sometime last Nov, we decided that too much automation is not desirable and that the autolocker should be kept as simple as possible.

 

  6672   Thu May 24 10:10:04 2012 steveUpdateIOOPMC locked

 The PMC  behavior is not changed.

 

  6679   Thu May 24 19:39:18 2012 SureshUpdateIOOMC and WFS alignment adjusted

[Yuta, Suresh]

We found that the MC was not locking and that the alignment between PSL and MC was too poor to obtain a TEM00 mode in the MC.   To correct the situation we went through the following steps:

1) We burt restored the MC alignment slider values to their values at 3:07 AM of today

2) We turned off the MC-autolocker and the ASC signal to the coils.   Then aligned the PSL beam into the MC (with the MC servo loop off) to obtain the TEM00 mode.  We had to adjust the zig-zag at the PSL output by quite a bit to maximise MC transmission.

3) We then centered the spot on the MC2 face and centered the transmitted beam on the MC2_TRANS_QPD

4) Next, we centered the beams on the MC_WFS sensors.

5) Turning on the WFS loops after this showed that everything works fine and WFS loops do not accumulate large offsets.

 

 

  6688   Fri May 25 23:11:50 2012 SureshUpdateIOOMC spot positions measured

[Koji, Yuta, Suresh]

We measured the MC spot positions after re-aligning the MC.  The spot positions are listed below:

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
    3.9073    6.6754    2.8591   -7.6985   -0.9492    7.0423

 

Procedure:

1) In the directory /opt/rtcds/caltech/c1/scripts/ASS/MC  we have the following scripts

      a) mcassUp:    This sets up the MCASS lockins to excite each of the MC mirrors at a different frequency

      b) mcassOn:    This sets the MCASS output matrix to actually send the excitation signals to the mirrors

      c) senseMCdecenter:  This sequentially introduces a 10% offset into the coil gains of each mirror degree of freedom.   It also sends the lockin output data to the screen. 

      d) sensemcass.m :  This is a matlab file which digests the data gathered by the senseMCdecenter script to print a couple of plots and compute the spot positions.

      e) MCASS_StripTool.stp:  This is a set-up file for the StripTool which allows us to see the MCASS-lockin_outputs.  It is nice to see the action of senseMCdecenter  script  at work.

 

2) So the series of commands to use are

      a) ./StripTool  <-- MCASS_StripTool.stp

      b) ./mcassUp

      c) ./mcassOn

      d) ./senseMCdecenter | tee Output_file

       e) ./mcassOff

      f) ./mcassDown

       g) matlab <-- sensemcass.m  <---- Output_file

 

  6689   Sat May 26 00:08:41 2012 DenUpdateIOOMC_F low frequency noise

 MC_F low frequency noise might be due to local damping electronics. I did not measure OSEM noise, but even without it electronics (AA -> ICS 110 -> ADC) provide sufficient amount of noise. 

These 2 image show electronics noise and coherence between OSEM signal / seismic

osem_noise.png           gur_suspos_coh.png

From these 2 plots we might think that SNR > 10 and coherence OSEM / GUR is high at the frequency range 0.1 - 10 Hz and this is not a big problem.

However, at low frequencies the length of seismic waves becomes large enough and relative oscillations of MC2 and MC13 decrease.

For 1 wave ( u(MC2) - u(MC1) ) / u(MC2) = sin(2 * pi * L  * f  / c), L - distance between MC1 and MC2 where 2 seismometers are located. So MC123 move according to seismic motion and electronics noise is not seen unless we look at MC Length. Here this noise is seen, because mirrors move in a synchronistic manner. 

To check this I measured seismic noise with 2 guralps at distance 12 meters - at MC1 and MC2. Then I've computed the difference between these signals. And indeed at low frequencies, relative motion is much less.

Green, blue - GUR1,2_X

Red - differential motion GUR1_X - GUR2_X

dgur.png

 

The following plot illustrates how electronics noise effects MC_F. Green is the signal to coils. Red - electronics noise. Blue, black, cyan - simulated contribution to MC_F for different seismic waves speed. Most probably seismic waves have waves in the range 50 - 800 m/s, others are deep. The plot shows that electronics noise is big enough to disturb coherence between MC_F and seismic noise. 

mc_noises.png

Here is a rough calculation of the seismic waves speed. The following plot shows the ratio of psd of differential MC2-MC1 motion to MC2 motion.

ratio.png

If seismometers would be very far, ratio would be 1 if we neglect the difference in transfer function SEISMOMETER -> ADC for each channel. The drift of the ratio from 1 to 1.3 demonstrates this effect. Ratio starts to decrease at 15 Hz according to sin (2*pi*L*f/c) ~ 2*pi*L/c * f. So 2*pi*L/c * f_0 = pi/2 => c = 4 * L * f = 600 m / sec.

  6691   Sat May 26 15:59:19 2012 DenUpdateIOOGuralp noise is high

As I've mentioned in yesterday's elog MC mirrors start to move in a synchronistic manner. I've plotted DELTA_GUR = GUR1_X - alpha * GUR2_X, where alpha = const to make the transfer functions SEISMOMETER -> ADC equal for each channel. I've noticed that DELTA_GUR decreases below 10 Hz compared to GUR1_X as theoretically predicted. But starting from 1 Hz DELTA_GUR starts to increase. I decided that this is Guralp noise floor. Today I checked this, this is indeed the case.

In the frequency range 0.01 - 1.5 Hz Gur noise is comparable to the signal DELTA_GUR. For that reason we see low coherence between MC_F and GUR1_X in this frequency range. 

gur_noise.png    MCF_GUR.png

Guralp noise floor was determined by placing 2 seimometers close to each other and subtracting by Wiener filtering.

DSC_4306.JPG

Conclusion: To filter seismic noise out of MC_F we need more sensitive seimometeres.

 

  6700   Tue May 29 10:08:21 2012 steveUpdateIOOcentered IOO monitoring qpds

IOO Angle & IOO Position QPDs centered.

  6702   Tue May 29 14:59:39 2012 JenneUpdateIOOPMC, MC alignment are shit

[Yuta, Jenne]

PMC and MC alignment are both shit, although with the WFS on, the MC is pretty good.  We're leaving it for now, so that (a) we don't mess up Koji's work, and (b) we can work on the Xarm.  Steve is doing Yarm oplev stuff, so we'll do Yarm later.

  6704   Tue May 29 15:48:31 2012 KojiUpdateIOOPMC, MC alignment are shit

The followings are a kind of daily check. Do this without any notice:

- Align PMC.

- Check MC spot position with the script (where is it located?). Ignore MC2 result as it can be arbitrary set.

- If the MC1/MC3 spots have moved it means that the PSL beam has moved. If the beam has moved, we should have some discussion what we should do.

- If the spot positions are about the same as before, align the MC mirrors. This should be done by nulling the WFS feedback. (Someone should make a simple script for this WFS offloading.)

------------

Then, start locking both arms

Quote:

[Yuta, Jenne]

PMC and MC alignment are both shit, although with the WFS on, the MC is pretty good.  We're leaving it for now, so that (a) we don't mess up Koji's work, and (b) we can work on the Xarm.  Steve is doing Yarm oplev stuff, so we'll do Yarm later.

 

  6707   Tue May 29 17:40:45 2012 JenneUpdateIOOPMC, MC alignment are shit

Quote:

[Yuta, Jenne]

PMC and MC alignment are both shit, although with the WFS on, the MC is pretty good.  We're leaving it for now, so that (a) we don't mess up Koji's work, and (b) we can work on the Xarm.  Steve is doing Yarm oplev stuff, so we'll do Yarm later.

 [Yuta, Jenne, Suresh]

We pushed on the MC SUS connectors at the back of the rack, and that helped bring MC3 back to where it should be.  Then we looked at MC RFPD DC, and adjusted the optics with the WFS off, so that the refl is ~0.56.  Then when we turn the WFS on, the alignment doesn't really change, so we have offloaded the WFS. 

Now we're measuring the spot positions to check where the MC is.  Then we'll align the arms, and align the green to the arms.

  6708   Tue May 29 19:50:01 2012 JenneUpdateIOOPMC, MC alignment are shit

Quote:

The followings are a kind of daily check. Do this without any notice:

- Align PMC.

Quote:

[Yuta, Jenne]

PMC and MC alignment are both shit, although with the WFS on, the MC is pretty good.  We're leaving it for now, so that (a) we don't mess up Koji's work, and (b) we can work on the Xarm.  Steve is doing Yarm oplev stuff, so we'll do Yarm later.

 

 [Keiko, Jenne]

PMC aligned.  Suresh is fixing the measure MC spot positions script, then we'll remeasure MC spot positions.

ELOG V3.1.3-