40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 212 of 341  Not logged in ELOG logo
ID Date Author Type Category Subject
  6500   Fri Apr 6 19:40:57 2012 Mike J.SummaryGeneralLaser Emergency Shutoff

I accidently shut off the laser at 19:34 with the emergency shutoff button while trying to tap into a video line for the Sensoray device.

  6499   Fri Apr 6 19:04:35 2012 JenneUpdatePEMSTS releveled, GUR2 plugged in

[Den, Jenne]

We were wondering why the STS-2 signal was funny.  When I went to look at it, the X-axis indicator was pointing ~45deg from the x-axis, so that it was pointing between the arms of the IFO.  Also, the bubble in the level was totally stuck on one side.  We locked the masses, and I put the seismometer back to the correct orientation, and then leveled it.  We unlocked the masses and turned the power back on, and hit the auto-zero button a few times.  Right now the X-axis signal is fine, but Y and Z are still railed, but it's been like 24 seconds, not 24 hours since we last hit auto zero, so there's still some time to wait.

Also, GUR2 was unplugged on both ends of the cable.  We plugged it back in.  However, it looks like the *seismometer* labeled #1 is now plugged into *channels* GUR2, and the seismometer labeled #2 is plugged into channels GUR1.  Recall that Den has only modified X, Y, Z for GUR1 channels, not any other channels in the breakout box.

  6498   Fri Apr 6 16:35:37 2012 DenUpdateComputersc1ioo

c1ioo computer can not connect to the framebuilder and everything is red in the status for this machine, C1:FEC-33_CPU_METER is not moving.

EDIT by KI:

 We rebooted the c1ioo machine, but none of the ftont end model came back. It looked like they failed the burt process for some reasons according to dmesg.

Then we restarted each front end model one by one, and every time after immediately we restarted it we hit the 'BURT' button in the GDS screen.

Everyone came back to the normal operation.

  6497   Fri Apr 6 16:22:15 2012 DenUpdateEnvironmentseism box

I've changed R2 resistor in the seism box for the VERT 1 channel from 464 Ohm to 1051 Ohm to reduce the gain of this channel by a factor of 2. This should help the GUR1Z signal not to be corrupted inside the AA box, so we can use it in the adaptive filtering.

  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

 

  6495   Fri Apr 6 14:39:21 2012 JamieUpdateComputersRAID array is rebuilding....

The RAID (JetStor SATA 416S) is indeed resyncing itself after a disk failure.  There is a hot spare, so it's stable for the moment.  But we need a replacement disk:

    RAID disks:  1000.2GB Hitachi HDT721010SLA360

Do we have spares?  If not we should probably buy some, if we can.  We want to try to keep a stock of the same model number.

Other notes:

The RAID has a web interface, but it was for some reason not connected.  I connected it to the martian network at 192.168.113.119.

Viewing the RAID event log on the web interface silences the alarm.

I retrieved the manual from Alex, and placed it in the COMPUTER MANUALS drawer in the filing cabinet.

  6494   Fri Apr 6 11:32:09 2012 JenneUpdateComputersRAID array is rebuilding....

Suresh reported to Den, who reported to me (although no elogs were made.....) that something was funny with the FB.  I went to look at it, and it's actually the RAID array rebuilding itself.  I have called in our guru, Jamie, to have a look-see.

  6493   Fri Apr 6 11:14:34 2012 JenneUpdateAdaptive Filteringstatic and adaptive

Quote:

I've run static and adaptive filters simultaneously. AA32 filters rotate the phase of the witness signals GUR1X and GUR1Y and now the performance of the static filter is worse. Next time I'll recalculate Wiener filter coefficients taking this into account. But still 2 filters together can deal with a stack better.

static_oaf.pdf

 This is super awesome!  I'm totally excited!!

  6492   Fri Apr 6 10:31:07 2012 DenUpdateAdaptive Filteringstatic and adaptive

I've run static and adaptive filters simultaneously. AA32 filters rotate the phase of the witness signals GUR1X and GUR1Y and now the performance of the static filter is worse. Next time I'll recalculate Wiener filter coefficients taking this into account. But still 2 filters together can deal with a stack better.

static_oaf.pdf

  6491   Fri Apr 6 09:57:24 2012 DenUpdateAdaptive Filteringstatic starts to work

I made static filter to work to evaluate the actuator TF.. Here is the result of static filtering:

static1-crop.pdf

 What I did:

 I did offline simulation of the MC_F Wiener filtering using 2 witness signals - GUR1X and GUR1Y. I've downsampled the data from 2048 to 128 Hz and applied the Wiener filter with 10000 for each witness channel:

wiener_filtering.pngcoeffs.png

                                            Result of the filtering                                                                                     Filter coefficients for gur1x and then gur1y

xTF.pngyTF.png

                                         Gur1x -> MC_F transfer function                                                                          Gur1y -> MC_F transfer function

Then using vectfit I approximated obtained transfer functions in the region 0.5 - 20 Hz. I used a window function and then weights to get a more precise result in this range using only 8 poles and zeros.

xfitting.pngyfitting.png

I obtained the zpk-model for each witness channel and entered it into the FOTON splitting it into 2 parts before that because FOTON does not like too long filters. These zpk-models are at the C1:OAF-STATIC_STATMTX_8_8 and C1:OAF-STATIC_STATMTX_8_9 filter banks.

GUR1X:

z =

  7.527339430029315 +31.603999069997801i
  7.527339430029230 -31.603999069997823i
 27.897703898191267 + 0.000000000000071i
 -6.437806394766186 + 9.893955654289517i
 -6.437806394766159 - 9.893955654289510i
  1.114401249545640 + 5.479278396987240i
  0.176877296954015 + 0.000000000000006i
  1.114401249545616 - 5.479278396987245i


p =

 -0.407251778925379 + 6.263247012022007i
 -0.407251778925379 - 6.263247012022007i
 -0.230672968859081 + 6.846868757063707i
 -0.230672968859081 - 6.846868757063707i
 -2.871419857491615 +13.707864827517826i
 -2.871419857491615 -13.707864827517826i
 -2.134260618362721 +18.319129999777648i
 -2.134260618362721 -18.319129999777648i


k =

     4.113285626223658e-04

GUR1Y

z =

 17.961416874092624 +13.631821252434328i
 17.961416874092642 -13.631821252434353i
 -8.788634771726304 + 7.653357335975781i
 -8.788634771726285 - 7.653357335975777i
 -0.037906973323273 + 5.133348020858679i
 -0.164348392996182 + 3.588803405511463i
 -0.164348392996187 - 3.588803405511474i
 -0.037906973323277 - 5.133348020858679i


p =

 -0.027577318242359 + 5.174655410828068i
 -0.027577318242359 - 5.174655410828068i
 -0.500384298611703 + 6.310552036591990i
 -0.500384298611703 - 6.310552036591990i
 -0.237055716999485 + 6.881204941979009i
 -0.237055716999485 - 6.881204941979009i
 -1.408223271160550 +14.874570175309771i
 -1.408223271160550 -14.874570175309771i


k =

    -2.723835471763049e-04

 Then I approximated the reversed actuator TF  and placed it to the C1:OAF-SUS_MC2_OUT filter bank. The gain to the static filter output is -1.

P.S. Also the static matrix was filled with 1 for some reason. Here is the script to fix it if if will be bad again

for i in {1..8}
do
    for j in {1..28}
    do
        element="C1:OAF-STATIC_STATMTX_"$i"_"$j"_GAIN"
        ezcawrite $element 0
    done
done

 

 

  6490   Thu Apr 5 18:24:55 2012 DenConfigurationAdaptive Filteringoaf starts to work

Today I tried to make the lms filter to work online. I played around with the signals (GUR1_X and MC_F) to pre-whiten them and in the end the following configuration worked out:

1. mu = 0.03, tau = 1e-5, downsample=8, nCoeff = 4000, delay = 5 (sample-and-hold delay is not included in the new code, it should be added here!)

2. witness pass: AA32 = cheby1("LowPass", 4, 1, 32) AND 0.1:0

3. witness adaptation path: AA32 AND AI32 = cheby1("LowPass", 4, 1, 32) AND 0.1:0

4. error path: AA32 AND 0.1:0 AND anti_1Hz. Before I added anti_1Hz filter oaf did nothing. This filter tries to approximate the actuator transfer function. Note, it is not in the witness adaptation path. This is some sort of whitening.

5. correction path: AI32, gain = -1

Convergence time ~ 5 mins. The performance of the filter is far not perfect compared to the offline implementation. But it deals with a stack though.

oaf2.pdf

  6489   Thu Apr 5 07:19:16 2012 kiwamuUpdateLSCDRMI locking

 I tried locking the DRMI to the signal-extraction condition with the new trigger by AS110.

A first thing I tried was : flipping the control sign of the SRCL while keeping the same control setups for the PRCL and MICH.

Occasionally the DRMI was "sort of" locked and hence I believe this setup must be a good starting point.

As a next step I will try some different gains and demodulation phase to make it more lockable.

 


(Time series)

DRMI_2012Apr4_edit.png

 The picture above is time series of some signals when the DRMI was barely locked.
The red arrows indicate the durations when the DRMI was sort of locked.
 (Green curve) REFLDC becoming a high value state, which indicates that the carrier is anti-resonant.
 (Red curve) ASDC becoming dark, which indicates the MICH is in the vicinity of the dark condition.
 (Brown curve) AS110 becoming a high value state, which means the 55 MHz sidebands got amplified by the SRCL.
 (Blue curve) POP22 becoming a high value state, which indicates that the 11 MHz sidebands are resonating in the PRC.
 
According to the measurement of AS110 when PRMI was locked (#6488), the AS110 signal went up to ~ 1 counts or so.
On the other hand when the DRMI was locked the AS110 went to up more than 10 counts as shown in the plot above.
Therefore at least some kind of signal amplification is happening for the 55 MHz sidebands in the SRC.
Looking at the AS CCD, I found that the beam looked like a TEM01 mode (two beam spots at top and bottom) every time when the DRMI was locked.
 
(settings)
  • REFL33I => PRCL  G = -0.2
  • AS55Q => MICH    G = -6
  • AS55I => SRCL     G = 1   (G = -50 for the signal recycling condition)
  • AS55 demod phase = 17 deg
  6488   Thu Apr 5 06:27:51 2012 kiwamuUpdateLSCAS110 sideband monitor installed

[Jenne / Kiwamu]

 We have installed a broad band PD in the AS path in order to monitor the 110 MHz signal associated with the SRC.

The PD is currently connected to the POP110 demodulation board and it seems working fine.

I know this is confusing but right now the signal appears as "POP110" in the LSC front end model.

 


  • Installed a 50% BS at the AS path
    • The AS beam is split to two path - one goes to AS55 and the other goes to the OSA.
    • The new BS is installed on the way of the OSA branch therefore AS55 isn't affected by the new BS.
  • Installed a PDA10A
    • This is a silicon diode with a bandwidth of 150 MHz, and is fast enough to detect the 110 MHz signals.
    • The 110 MHz signal seems going up to approximately -40 dBm according to a coarse measurement with an RF spectrum analyzer.
    • Also a SMA-style high pass filter, HPF-100, was attached to the output to cut off unnecessary sidebands (e.g. 11, 22 MHz and etc.)
  • Put a long BNC cable, which goes from the PD to LSC rack.
    • The end of the cable at the LSC rack was directly connected to the POP110 demod board.
    • The actual POP110 signal path is currently terminated by a 50 Ohm load and therefore this signal  is unavailable.
  • Adjustment of the demodulation phase
    • The demod phase was adjusted to be 7 deg in the EPICS screen. This phase minimize the Q-signal.
    • Locking PRMI with sidebands resonating makes the AS110 signal ~ a few counts and this level is still noticeable.
    • Perhaps we may need to put an RF amplifier to get the signal bigger.
  6487   Thu Apr 5 01:07:08 2012 Mike J.UpdateComputersHysteresis Plots

Here are the hysteresis plots from the most recent model, which uses a modified harmonic oscillator equation y''=-(Frequency)2*y-Hysteresis.  The hysteresis constant seems to change both the amplitude and equilibrium point of the pendulums, which is akin to changing the length of a pendulum without changing the frequency. This does not make sense. Perhaps the hysteresis value should be moved to the "spring" constant for the pendula and not restricted to a position-biasing value.

SHO_hyst_plot.png

  6486   Wed Apr 4 23:57:35 2012 keikoUpdateLSCRAM simulation for Full ifo

 I'm still wondering whether iteration version or simple version is closer approximation to the real situation. Sorry for few explanations here. I will try to present those on Friday.

 

Anyway, here is the results for both:

%*.*.*. Original matrix w/o RAM .*.*.*

REFL f1 : 1.000000        0.000000    -0.000003    -0.000005    0.000007 

  AS f2 : 0.000002        1.000000    0.000009    -0.003522    -0.000002 

 POP f1 : -3954.521443    -0.000965    1.000000    0.019081    -0.000152 

 POP f2 : -32.770726    -0.154433    -0.072594    1.000000    0.024284 

 POP f2 : 922.393978    -0.006608    1.488319    0.042948    1.000000 

 

*** Iteration *** 

%*.*.*. Resulting matrix w/ RAM .*.*.*

REFL f1 : 0.039125    -0.000000    0.003665       0.000005    -0.000007 

  AS f2 : 0.000010    1.000431    0.000009       -0.003500    -0.000002 

 POP f1 : 156.420221    -0.000246    15.586838    0.019406    -0.000154 

 POP f2 : 1.255806    -0.154275    0.047313       1.000008    0.024285 

 POP f2 : -34.814720    -0.006600    -1.884850    0.042950    1.000000 

Offsets converged to:

PRCL =  2.1e-15, MICH = 1.1e-17, SRCL = -3.8e-15, CARM = 2.2e-16, DARM = 0 

(POP CARMs became so much smaller compared with the other matrix below, because the offsets are added al of 5 DoFsl at once here.)

 

*** no iteration, offsets added for each DoF separately ***

REFL f1 : 0.020611        -0.000000    0.003600    0.000005    -0.000007 

AS f2   : 0.000002        1.000000    0.000009    -0.003522    -0.000002 

POP f1  : 1842.776419    -0.000198    21.533358    0.019404    -0.000132 

POP f2  : -32.700639    -0.153095    -0.072481    0.999995    0.024360 

 POP f2 : 922.393862    -0.006435    1.488298    0.042949    0.999982 

Added offsets:

PRCL =  7.5e-15, MICH = 6.25e-16, SRCL = -1.4e-14, CARM = 4.5e-16, DARM = 0

* So far, I used to add all the offsets at once. This time I add CARM and get the CARM row, add PRCL and get the PRCL row... and so on.

Quote:

Koji and Jamie suggested me to include the coupling between DoFs when I calculate the last matrix. So far, I just add all the pos-offsets of 5 DoFs and re-calculate the matrix again. However, once I add one DoF pos-offset, it could already change the LSC matrix therefore different pos-offset to the other four DoF, we must iterate this process until we get the equilibrium pos-offsets for 5 DoFs.

I also noticed an error in the optical configuration file. AM mod levels were smaller than that supposed to be because of the hald power going through the AM-EOMs in the MZI paths. Also I have put PM-Mods in the MZT path which gives the smaller mod indexes. So, smaller mod levels were applied both for PM and AM. As PM-AM ratio is still kept in this, so the matrices were not very wrong, I assume. I'll modify that and post the results again.

 

  6485   Wed Apr 4 21:43:16 2012 Mike J.UpdateComputersBetter Hysteresis Model

A better hysteresis model based on the simple harmonic oscillator equation. Useless variables have been removed and output can now be saved to workspace for plotting. The model is at "/users/mjenson/matlab/SHO_hyst.mdl".

Attachment 1: SHO_hyst.png
SHO_hyst.png
  6484   Wed Apr 4 13:25:29 2012 jamieConfigurationPEMPEM_SLOW (i.e. seismic RMS) channels aquiring

Quote:

I've added the PEM_SLOW.ini file to the fb master file, which should give us the slow seismic RMS channels when the framebuilder is restarted. Example channels:

[C1:PEM-RMS_ACC6_1_3]
[C1:PEM-RMS_GUR2Y_0p3_1]
[C1:PEM-RMS_STS1X_3_10]
etc.

 The framebuilder seems to have been restarted, or restarted on it's own, so these channels are now being acquired.

Below is a minute trend of a smattering of the available RMS channels over the last five days.

2012-04-04-132346_1182x914_scrot.png

  6483   Tue Apr 3 22:50:37 2012 keikoUpdateLSCRAM simulation for Full ifo

Koji and Jamie suggested me to include the coupling between DoFs when I calculate the last matrix. So far, I just add all the pos-offsets of 5 DoFs and re-calculate the matrix again. However, once I add one DoF pos-offset, it could already change the LSC matrix therefore different pos-offset to the other four DoF, we must iterate this process until we get the equilibrium pos-offsets for 5 DoFs.

I also noticed an error in the optical configuration file. AM mod levels were smaller than that supposed to be because of the hald power going through the AM-EOMs in the MZI paths. Also I have put PM-Mods in the MZT path which gives the smaller mod indexes. So, smaller mod levels were applied both for PM and AM. As PM-AM ratio is still kept in this, so the matrices were not very wrong, I assume. I'll modify that and post the results again.

  6482   Tue Apr 3 15:50:58 2012 keikoUpdateLSCRAM simulation for Full ifo

Oops, Yesterday's results for DARM was wrong!

I got more convincing results now. 

 

> (B) Are pos-offsets degrade the CARM and DARM so much (See, the quoted result below), is that true? 

 

Here is the new results. It does change CARM a lot, but not DARM:
 
Matrix1 (normalised so that the diagonals are 1):
REFL f1 : 1.000000    0.000000    0.000008    -0.000005    0.000003 
  AS f2  : 0.000001    1.000000    0.000005    -0.003523    -0.000001 
 POP f1 : -3956.958708    -0.000183    1.000000    0.019064    0.000055 
 POP f2 : -32.766392    -0.154433    -0.072624    1.000000    0.024289 
 POP f2 : 922.415913    -0.006625    1.488912    0.042962    1.000000 
(=Matrix 2)
 
Position offsets:
only CARM, 4.6e-16 (this number changed because I increased the resolution of the calculation)
 
Matrix3 (normalised by matrix 1):
REFL f1 : 0.039780    -0.000000    0.003656    0.000005    -0.000003 
  AS f2  : 0.000008    1.000017    0.000005    -0.003499    -0.000001 
 POP f1 : 159.146819    -0.000138    15.605155    0.019393    0.000055 
 POP f2 : 1.277223    -0.154415    0.047344    1.000008    0.024289 
 POP f2 : -35.422498    -0.006633    -1.886454    0.042963    1.000000 

 

  • CARM got a small position offset which degrades CARM signal 2 orders of mag (still the biggest signal in the sensor, though).
  • DARM was not so bad, and probably the change of the DoF mixture is mostly not changed.
  • Matrices don't change only with 1e-4 RAM. It changes with position offsets.
  • I'll see how the matrix changes without position offsets but only with RAM effects, changing RAM levels.
  • Again, above is C1 configuration, 1e-4 RAM level of PM level.

 

 

Quote:

I add a flow-chart drawing what the scripts do and how the scripts calculate the LSC matrix.

flowchart.png

 

(1) First, you calculate the LSC matrix WITHOUT RAM or anything, just for a reference. This is the first matrix shown in the quoted post.

(2) The script calculates the LSC matrix with RAM. Also, the PDH signals for all 5 DoF are calculated. The PDH signals have offsets due to the RAM effect. The operating position offsets are saved for the next round.

(3) The script calculates the LSC matrix again, with RAM plus the offset of the operation points. The matrix is shown in the last part of the quoted post.

 

Now I am going to check (A) LSC matrices (matrix 2, the second matrix of above chart) with different RAM levels (B) Are pos-offsets degrade the CARM and DARM so much (See, the quated result below), is that true? 

 

  6481   Tue Apr 3 14:17:18 2012 keikoUpdateLSCRAM simulation for Full ifo

I add a flow-chart drawing what the scripts do and how the scripts calculate the LSC matrix.

flowchart.png

 

(1) First, you calculate the LSC matrix WITHOUT RAM or anything, just for a reference. This is the first matrix shown in the quoted post.

(2) The script calculates the LSC matrix with RAM. Also, the heterodyne signals for all 5 DoF are calculated. The signals have offsets due to the RAM effect. The operating position offsets are saved for the next round.

(3) The script calculates the LSC matrix again, with RAM plus the offset of the operation points. The matrix is shown in the last part of the quoted post.

 

Now I am going to check (A) LSC matrices (matrix 2, the second matrix of above chart) with different RAM levels (B) Are pos-offsets degrade the CARM and DARM so much (See, the quated result below), is that true?

Quote:

Original matrix without RAM:

REFL f1 : 1.000000    0.000000    0.000008    -0.000005    0.000003 

  AS f2 : 0.000001    1.000000    0.000005    -0.003523    -0.000001 

 POP f1 : -3956.958708    -0.000183    1.000000    0.019064    0.000055 

 POP f2 : -32.766392    -0.154433    -0.072624    1.000000    0.024289 

 POP f2 : 922.415913    -0.006625    1.488912    0.042962    1.000000 

 

(MICH and SRCL uses the same sensor, with optimised demodulation phase for each DoF.) 

Operation position offsets are:

PRCL   -3.9125e-11 m

SRCL    9.1250e-12 m

CARM  5.0000e-15 m  

and no position offsets for DARM and MICH (because they are differential sensor and not affected by RAM offsets).

 

Resulting matrix with RAM + RAM offsets, normalised by the original matrix:  

REFL f1 : 0.001663    -0.000000    0.003519    0.000005    -0.000003 

  AS f2 : 0.000004    0.514424    0.000004    -0.001676    -0.000001 

 POP f1 : 7.140984    -0.001205    15.051807    0.019254    0.000417 

 POP f2 : 0.029112    -0.319792    0.042583    1.000460    0.024298 

 POP f2 : -0.310318    -0.014385    -1.761519    0.043005    0.999819 

 

 

 

  6480   Tue Apr 3 14:11:33 2012 keikoUpdateLSCRAM simulation for Full ifo

Quote:

Quote:

 I also would like to extend this script to use the DC readout, but don't know how to calculate the postion offset for AS_DC because the error signal is not zero-crossing for AS_DC anymore. Do you have any suggestions for me?

 I don't think I understand the question. AS_DC should not have a zero crossing, correct?

 That's right. I calculate the offset of the operation point (when you have RAM) from the zero-crossing point of the PDH signals. I don't know how to do that for AS_DC, because it doesn't cross zero anymore anytime.

  6479   Tue Apr 3 12:42:19 2012 Mike J.UpdateComputersHysteresis Model

Here's my first hysteresis model in Simulink. It's based on the equation y=Amplitude*sin(frequency*t+phase)+(hysteresis/frequency2) as a solution to y''+frequency2*y+hysteresis=0. All values in the model are variables that should be manipulated through the model workspace or external code.

Attachment 1: hysteresis1.mdl
Model {
  Name			  "hysteresis1"
  Version		  7.6
  MdlSubVersion		  0
  GraphicalInterface {
    NumRootInports	    0
    NumRootOutports	    0
    ParameterArgumentNames  ""
    ComputedModelVersion    "1.9"
    NumModelReferences	    0
... 734 more lines ...
  6478   Tue Apr 3 01:52:15 2012 ZachUpdateLSCRAM simulation for Full ifo

Quote:

 I also would like to extend this script to use the DC readout, but don't know how to calculate the postion offset for AS_DC because the error signal is not zero-crossing for AS_DC anymore. Do you have any suggestions for me?

 I don't think I understand the question. AS_DC should not have a zero crossing, correct?

  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.

 

Attachment 1: 40mOpticsLocations.pdf
40mOpticsLocations.pdf
Attachment 2: Beam-Profile_IPPOS_wError.pdf
Beam-Profile_IPPOS_wError.pdf
Attachment 3: Beam-Profile_PRM_1_wError.pdf
Beam-Profile_PRM_1_wError.pdf
  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

  6475   Mon Apr 2 18:24:34 2012 keikoUpdateLSCRAM simulation for Full ifo

 I extended my RAM script from DRMI (3DoF) to the full IFO (5DoF).

Again, it calculates the operation point offsets for each DoF from the opt model with RAM. Then the position offsets are added to the model, and calculates the LSC matrix. RAM level is assumed as 0.1% of the PM modulation level, as usual, and lossless for a simple model.

 

 

Original matrix without RAM:

REFL f1 : 1.000000    0.000000    0.000008    -0.000005    0.000003 

  AS f2 : 0.000001    1.000000    0.000005    -0.003523    -0.000001 

 POP f1 : -3956.958708    -0.000183    1.000000    0.019064    0.000055 

 POP f2 : -32.766392    -0.154433    -0.072624    1.000000    0.024289 

 POP f2 : 922.415913    -0.006625    1.488912    0.042962    1.000000 

 

(MICH and SRCL uses the same sensor, with optimised demodulation phase for each DoF.) 

Operation position offsets are:

PRCL   -3.9125e-11 m

SRCL    9.1250e-12 m

CARM  5.0000e-15 m  

and no position offsets for DARM and MICH (because they are differential sensor and not affected by RAM offsets).

 

Resulting matrix with RAM + RAM offsets, normalised by the original matrix:  

REFL f1 : 0.001663    -0.000000    0.003519    0.000005    -0.000003 

  AS f2 : 0.000004    0.514424    0.000004    -0.001676    -0.000001 

 POP f1 : 7.140984    -0.001205    15.051807    0.019254    0.000417 

 POP f2 : 0.029112    -0.319792    0.042583    1.000460    0.024298 

 POP f2 : -0.310318    -0.014385    -1.761519    0.043005    0.999819 

 

As you can see in the second matrix, the CARM and DARM rows are completely destroyed by the RAM offsets! The signals are half reduced in the DARM case, so the mixture between DARM and MICH are about 50% degraded.

 I also would like to extend this script to use the DC readout, but don't know how to calculate the postion offset for AS_DC because the error signal is not zero-crossing for AS_DC anymore. Do you have any suggestions for me?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  6474   Sat Mar 31 08:01:07 2012 kiwamuUpdateLSCDRMI measurement

I have measured the sensing matrix of the DRMI although the lock still doesn't stay for a long time.

As for the noise budget, it looks very tough as there are more glitches than that in the PRMI.

In this weekend I will take some more trials in the DRMI lock until I am satisfied.

  6473   Fri Mar 30 17:37:09 2012 steveUpdateGeneralcutting green welding glass for beam dumps

Quote:

Schott, green welding glass, shade 14, 3 mm thick  was measured in the beam path of 1.2W, S polarization of 1064nm at ~1 mm diameter size as MC reflected path.

Absorption 95%, R 5% at incident angle 25-50 degrees. It looks like the perfect material for beam trap.

 

 The CIT Chemistry Glass Shop cuts turned out to be sloppy using diamond disc blade  cutter.

East coast Precision Glass & Optics  offered scribed cut and polished side. Their quote price was high and time consuming.

The GLASS HOUSE  shop in Pasadena 626 / 796-9151 on Walnut did a good and cheap job. Oscar the cutter will finish the rest of the cutting by next Friday, April 6

He used scribed cutting technic and his 1" x  0.5"  pieces are good. Bob will pick up them up.

Attachment 1: IMG_0096.JPG
IMG_0096.JPG
  6472   Fri Mar 30 10:24:14 2012 steveUpdateSUSnew OSEM locking plunger

Quote:

Quote:

Our existing 300 series SS plungers from McMastercar #8476A43 are silver plated as Atm2 shows.

Problems:  1, they become magnetized after years being close to the magnets

                     2, they oxidize by time so it is hard to turn them

                    

I looked around to replace them.

Titanium body, nose and beryllium copper spring. None magnetic for UHV enviorment.

Can be made in 7 weeks at an UNREASONABLE $169.00 ea at quantity of 50

 In order to get a better price from Vlier's Tom Chen I changed Ti body back to SS304L-siver plated and music wire spring. The price is still ~$120 ea. at quantity 50

I will talk to Mike G about modifying the  McMaster plunger with a hex nut.

 Conclusion: There is no need to silver plate the SS plunger at the torque level we hold the OSEMs

Mike Gerfen will be done with 50 pieces by April 4 and he will give them to Bob for cleaning. They should be cleaned and baked in a jig so the springs would be compressed for better venting.

Attachment 1: new_OSEM_locker_screw.jpg
new_OSEM_locker_screw.jpg
Attachment 2: IMG_0109.JPG
IMG_0109.JPG
Attachment 3: IMG_0111.JPG
IMG_0111.JPG
  6471   Fri Mar 30 10:20:51 2012 kiwamuUpdateLSClocking last night

I was trying to make the DRMI lock more robust.

Increasing the gains of the oplev on SRM helped a lot, but the lock is still not solid enough for measurements.

According to some line injection tests, the SRCL and MICH signals show up in AS55Q with almost the same amplitudes.

I tried to diagonalize the input matrix (particularly MICH-SRCL in AS55) based on the result of the line injection tests, but I ran out the time.

Work continues.

  6470   Fri Mar 30 09:37:13 2012 steveUpdateSAFETYsafety audit 2012 CORRECTIONS

Quote:

Correction list by visiting safety committee, Haick Issaian is not shown:

1,  update laser, crane operator list and post it

2,  check fire extinguishers monthly, date and initials must be on the tags

3,  move drinking water tower so it does not block fire extinguisher

4,  post updated crane doc at cranes

5,  post present phone lists at IFO room phones

6,  emergency laser shutoff at the south end must be mounted without C-clamp

7,  use heavy cable tie to insure position of  mag-fan on cabinet top

 

Additional to do list:

a,  safety glasses to be cleaned

b, let the electrical shop fix Rack-AC power to optical tables at the ends

c, measure transmission of  laser safety glasses

d, update  IFO outside door info signs

e, update laser inventory and post it

f,  schedule annual crane inspection and renew maintenance contract

g, PSL enclosure  inner shelf needs a good clean up so it is earthquake safe

 

 Completed with the exception of d and g

  6469   Fri Mar 30 08:58:37 2012 steveUpdateSAFETYSafety glasses checked

Bob cleaned all safety glasses in 10 % Liquinox soap in water solution first.  The  transmittance of glasses were checked at 100 mW 1064 nm S polarization, beam diameter  0.5 mm at 0-20 deg incident.

Coherent FieldMate power meter measured T= < 1 mW of all glasses.

Attachment 1: safety_glasses_checked.jpg
safety_glasses_checked.jpg
  6468   Thu Mar 29 20:13:21 2012 jamieConfigurationPEMPEM_SLOW (i.e. seismic RMS) channels added to fb master

I've added the PEM_SLOW.ini file to the fb master file, which should give us the slow seismic RMS channels when the framebuilder is restarted. Example channels:

[C1:PEM-RMS_ACC6_1_3]
[C1:PEM-RMS_GUR2Y_0p3_1]
[C1:PEM-RMS_STS1X_3_10]
etc.

I also updated the path to the other _SLOW.ini files.

I DID NOT RESTART FB.

I will do it first thing in the am tomorrow, when Kiwamu is not busy getting real work done.

Here's is a the diff for /opt/rtcds/caltech/c1/target/fb/master:h

controls@pianosa:/opt/rtcds/caltech/c1/target/fb 1$ diff -u master~ master
--- master~	2011-09-15 17:32:24.000000000 -0700
+++ master	2012-03-29 19:51:52.000000000 -0700
@@ -7,11 +7,12 @@
 /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini
 /opt/rtcds/caltech/c1/chans/daq/C1MCS.ini
 /opt/rtcds/caltech/c1/target/gds/param/tpchn_c1mcs.par
-/cvs/cds/rtcds/caltech/c1/chans/daq/SUS_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/MCS_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/RMS_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/IOP_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/IOO_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/SUS_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/MCS_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/RMS_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/IOP_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/IOO_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/PEM_SLOW.ini
 /opt/rtcds/caltech/c1/target/gds/param/tpchn_c1rfm.par
 /opt/rtcds/caltech/c1/chans/daq/C1RFM.ini
 /opt/rtcds/caltech/c1/chans/daq/C1IOO.ini
controls@pianosa:/opt/rtcds/caltech/c1/target/fb 1$

 

  6467   Thu Mar 29 19:13:56 2012 JamieOmnistructureComputersWireless router for GC

I retrieved the newly "secured" router from Junaid.  It had apparently been hooked up to the GC network via it's LAN port, but it's LAN services had no been shut off.  It was therefore offering a competing DHCP server, which will totally hose a network.  A definite NONO.

The new SSID is "40mWiFi", it's WPA2, and the password is pasted to the bottom of the unit (the unit is back in it's original spot on the office computer rack.

  6466   Thu Mar 29 18:42:11 2012 keikoUpdateLSCPOP22/POP110 amplifires

Adding two amplifiers on POP22/110, I checked the signals going to the dmod board of 22 and 110.

The signal flows: Photodetector of POP --> Amp1 --> Amp2 --> RF splotter --> bandpass filter for 22MHz / 110MHz --> 22MHz / 110MHz demod board.

 

 

 

 Here is the picture of RF spectrum just after the bandpass filter of 22MHz going to the 22MHz demod board. The signal peak at 22MHz is about -40dBm. There is a structure slightly lower than 22MHz.

P3290004.JPG

The below is the RF spectrum for 110MHz branch. The peak at 110MHz is about -15dBm. The peak on the left of 110MHz is 66MHz peak.

P3290005.JPG

 

Quote:

Yesterday I and Kiwamu connected two amplifiers (mini-circuit, ZFL-1000LNB+) for POP22/110. Dataviewer can see some signals. I'll test the signal levels and freq components before the rack just in case. [Kiwamu, Keiko]

 

  6465   Thu Mar 29 13:23:05 2012 JenneOmnistructureComputersWireless router for GC

Quote:

I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.

The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.

 This router was confiscated by the GC guys this morning around ~10am.  They barged in and said that someone at the 40m had connected a new router, and we had magically taken down half of the GC network.  The cable was plugged in to the wrong port on the back of the router. 

Junaid / Christian said that they would "secure" the router, and then reinstall it.  Apparently just having a password didn't satisfy them.  This was the compromise, versus them just taking the router and never bringing it back.

 

Attachment 1: IMG_0079.JPG
IMG_0079.JPG
  6464   Thu Mar 29 11:29:27 2012 keikoUpdateLSCPOP22/POP110 amplifires

Yesterday I and Kiwamu connected two amplifiers (mini-circuit, ZFL-1000LNB+) for POP22/110. Dataviewer can see some signals. I'll test the signal levels and freq components before the rack just in case. [Kiwamu, Keiko]

  6463   Wed Mar 28 21:15:53 2012 ranaOmnistructureComputersWireless router for GC

I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.

The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.

  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

Attachment 1: MMT_moved_by_1pt3meters_MMT1th_25_MMT2th_12_LowRes.png
MMT_moved_by_1pt3meters_MMT1th_25_MMT2th_12_LowRes.png
  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

  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.

  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.
 

  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.

 

Attachment 1: expsche.png
expsche.png
Attachment 3: mmtdrawing.png
mmtdrawing.png
Attachment 4: drawing.png
drawing.png
Attachment 5: drawing.png
drawing.png
Attachment 8: drawing.png
drawing.png
  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.

  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.

  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?

  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? 

  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

  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.

  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

 

ELOG V3.1.3-