40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 186 of 354  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  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.

  6709   Tue May 29 21:05:30 2012 yutaUpdateIOOPMC, MC alignment are shit

Quote:

  [Keiko, Jenne]

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

 [Suresh, Jenne, Yuta]

We measured the MC spot positions twice tonight. Procedure for measuring them is in elog #6688.
The results were;

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
    3.3359    3.9595    2.3171   -7.7424   -0.8406    6.4884

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
    3.2681    4.0052    2.2808   -7.3965   -0.7624    7.1302

The spot moved by about 0.5 mm since May 25, but we concluded that this displacement is negligible and difficult to be fixed by aligning PSL beam.

We'll align Y arm and X arm next.

  6715   Wed May 30 15:51:22 2012 yutaUpdateIOOMC beam spot oscillation

[Koji, Suresh, Jenne, Yuta]

Background:
  We noticed that the beam spots on MC mirrors are oscillating in ~ 1 Hz yesterday. It means MC mirrors are actually oscillating. This was observable even if the WFS servo is off.

What we did:
  1. By measuring the spectra of OSEM sensor outputs, we found that MC3 is the one that is oscillating.

  2.  Oscillation at ~ 1 Hz only happened when the local damping using OSEMs are on (see Attachment 1; REF is when the damping is on).

  3.  We found that this oscillation came from insufficiency in phase margin in SUSPOS loop. So, we increased the gain, C1:SUS-MC3_SUSPOS_GAIN, from 95 to 200. It helped a little, but oscillation is still there.

  4.  We measured openloop transferfunctions of SUSPOS, SUSPIT, SUSYAW, SUSSIDE loop, and concluded that diagonalization some how went wrong. The amplitude of the oscillation (peak height in the OSEM spectra) changed by pushing the MC SUS connectors.

Plan:
  - Fix the connectors so that we don't have to push them any more.
  - Redo the diagonalization of the MC suspensions.

  6718   Wed May 30 19:27:38 2012 yutaUpdateIOOMC beam spot oscillation

[Koji, Yuta]

We found that C1:SUS-MC{1,2,3}_TO_COIL_3_4_GAIN was somehow changed to -1, and feedback signal for SIDE was fedback to LLCOIL, which is apparently not correct.
We checked the snapshots on May 25 and confirmed that it was used to be 0, so we fixed it.
We suspect that it happened during the beam spot measurement, because the measurement changes the TO_COIL matrix gains.

Now, we don't see any MC beam spot oscillation.

Quote:

[Koji, Suresh, Jenne, Yuta]

Background:
  We noticed that the beam spots on MC mirrors are oscillating in ~ 1 Hz yesterday. It means MC mirrors are actually oscillating. This was observable even if the WFS servo is off.

 

  6719   Wed May 30 20:12:15 2012 ranaUpdateIOOMC beam spot oscillation

This is a common occurrence when diagnostic scripts are written without the ability to handle exceptions (e.g. ctrl-c, terminal gets closed, etc.).

The first thing to do is make sure that the "new" script you are writing doesn't already exist (hint: look in the old scripts directory).

If you are writing a script that touches things in the interferometer, it must always return the settings to the initial state on abnormal termination:

http://linuxdevcenter.com/pub/a/linux/lpt/44_12.html

  6726   Thu May 31 02:27:24 2012 yutaUpdateIOOscript for reliefing MC WFS

I wrote a simple script for reliefing MC WFS servo. The script is located at /opt/rtcds/caltech/c1/scripts/MC/reliefMCWFS.
It simply uses ezcaservo to minimize the offset of the WFS feedback signal using MC alignment sliders.

    ezcaservo -r C1:SUS-MC${optic}_ASC${dof}_OUT16 -s 0 -g 0.0001 -t 10 C1:SUS-MC${optic}_${dof}_COMM


I put "MC WFS relief" button on the WFS medm screen (/opt/rtcds/caltech/c1/medm/c1ioo/master/C1IOO_WFS_MASTER.adl).

  6727   Thu May 31 04:03:17 2012 yutaUpdateIOOscript for MC beam spot measurement

I wrote a wrapping script for measuring MC beam spot. We had to run several scripts for the measurement (see elog #6688), but now, you only need to run /opt/rtcds/caltech/c1/scripts/ASS/MC/mcassMCdecenter.

The measured data file will be stored in /opt/rtcds/caltech/c1/scripts/ASS/MC/dataMCdecenter/ directory, with a timestamp.
The calculated beam spot position data will be logged in /opt/rtcds/caltech/c1/scripts/ASS/MC/dataMCdecenter/logMCdecenter.txt file.
I had to edit sensemcass.m file, in order to write the result into the log file. In this way, we can keep track of the beam displacement.

Currently, the calculation script is written in the MATLAB file(sensemcass.m), which isn't very nice.
To run a MATLAB file from the command line
, you have to write something like this;

matlab -nodesktop -nosplash -r "sensemcass('./dataMCdecenter/MCdecenter201205210258.dat')"

 

  6728   Thu May 31 10:31:19 2012 JamieUpdateIOOMC beam spot oscillation

Quote:

This is a common occurrence when diagnostic scripts are written without the ability to handle exceptions (e.g. ctrl-c, terminal gets closed, etc.).

The first thing to do is make sure that the "new" script you are writing doesn't already exist (hint: look in the old scripts directory).

If you are writing a script that touches things in the interferometer, it must always return the settings to the initial state on abnormal termination:

http://linuxdevcenter.com/pub/a/linux/lpt/44_12.html

This is very good advice.  However, "trap" is bash-specific.  tcsh has a different method that uses a function called "onint".  Here's a description of the difference.

A couple notes about bash traps:

  • You can give a name instead of a number for the signal.  So instead of trap 'do stuff' 1 you can say trap 'do stuff' SIGHUP
  • The easiest signal to use is EXIT, which covers all your bases (ie. anything that would cause the script to exit prematurely.
  • You can define a function that gets executed in the trap

So the easiest way to use it is something like the following:

#!/bin/bash   # define cleanup function  function cleanup {      # do cleanup stuff, like reset EPICS records to defaults      ....  }  # set the trap on EXIT  trap cleanup EXIT  # the rest of your script below here
...
  6739   Fri Jun 1 08:17:47 2012 steveUpdateIOOPMC trends

Quote:

IOO Angle & IOO Position QPDs centered.

 PMC trend of 400 and 1200 days

The Innolight 2W based PSL- IOO was implemented in the ~ summer of 2010

  6756   Tue Jun 5 20:42:59 2012 SureshSummaryIOOTip-Tilt Cabling

I have made a preliminary sketch of the cabling involved in connecting the Tip-tilt coil drivers.   This is a preliminary document. 

40m_Tip-tilt_cabling.png

 

 

  Required parts Quantity Solution
1) DAC Card inserted into C1IOO machine 1 buy or borrow from Cymacs
2) SCSI cable from DAC to D080303 box 1 buy or find at the 40m
3) D080303 box (SCSI to IDC breakout box) 1 Jay may have had spare, if not we have to make one
4) 40 pin IDC cables from D080303 to AntiImaging filter 2 Jay may have kept some stock if not make them
5) 10 pin IDC cables from Anti Imaging filters to Whitening filters 2 make
6) sma to lemo cables from Whitening to coil drivers 4x4=16 buy
7) 15pin IDC to 25pin DSub cables from drivers to feedthroughs on the chambers 4  (length?) make
8) 25pin DSub feedthrough on OMC chamber 1 check in 40m stock else buy
9) 25pin DSub  Kapton strip cable from OMC wall to table top 1 check if any spare are available in aLIGO stock
10) 25pin DSub Kapton strip cable from post to tip-tilt 4 aLIGO team said they have a few to spare if not buy
10) Quadrapus cables on the tip-tilts 4 Jamie is negotiating with aLIGO cable team

 

  6759   Tue Jun 5 22:39:06 2012 JenneSummaryIOOTip-Tilt Cabling

2 questions (so far) regarding your diagram / doc:

We are using 3 of the feed-throughs on the BS chamber, and 1 on the OMC chamber, even though we have 2 TTs on the BS table, 1 on the OMC table, and 1 on the IMC table? Just wanted to check.

Does your list / table at the bottom include all of the cables we already have, as well as the ones we need?  (Or maybe we just have nothing so far, so this is a moot question).

  6762   Wed Jun 6 01:23:32 2012 SureshSummaryIOOTip-Tilt Cabling

Quote:

2 questions (so far) regarding your diagram / doc:

We are using 3 of the feed-throughs on the BS chamber, and 1 on the OMC chamber, even though we have 2 TTs on the BS table, 1 on the OMC table, and 1 on the IMC table? Just wanted to check.

Does your list / table at the bottom include all of the cables we already have, as well as the ones we need?  (Or maybe we just have nothing so far, so this is a moot question).

 The scheme currently is to run a 25pin Kapton strip cable from BS to IMC table inside the chamber.  However we cannot do the same for the OMC table since it will cross the bellows which we often remove.  So we need to supply the one tip-tilt on the OMC table from outside.  I could not spot a spare unused feedthough on the OMC chamber.  We will have to swap one of the blank flanges for one with a few feed throughs.

We do not have any of the cables.   So everything listed has to be arranged for.   The pics are from the existing coil driver system on the SUS machine.

 

  6767   Wed Jun 6 15:16:00 2012 yutaUpdateIOOMC WFS offsets adjusted

MC reflection (C1:IOO-MC_RFPD_INMON) got worse when WFS servos were on. After aligning MC optics, it will be ~0.5 but if I turned on WFS, it became ~0.8.
I measured the beam spot positions on MC optics. They seemed like the same from the measurement yesterday.

# filename      MC1pit  MC2pit  MC3pit  MC1yaw  MC2yaw  MC3yaw  (spot positions in mm)
./dataMCdecenter/MCdecenter201206052111.dat     3.234388        4.234564        2.654212        -6.656221       -0.677541       4.506170       
./dataMCdecenter/MCdecenter201206061420.dat     3.300867        4.567555        2.692971        -6.484464       -1.705443       4.423250

So, I ran /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets to adjust the WFS offsets.

C1:IOO-MC_RFPD_INMON is now ~ 0.5 and  C1:IOO-MC_TRANS_SUM is now ~ 2.7e3 with WFS on.

  6770   Wed Jun 6 19:46:46 2012 SureshSummaryIOOTip-tilt assembly: current status and work remaining

 

Recent History

The lower blades which I had given to the Physics Workshop for making a vacuum relief hole (using a sinker-EDM process) came back about ten days ago.   Merih Eken <meken@caltech.edu>,  the supervisor at the Physics Dept workshop, handled this matter for us.  The blades were sent to a local EDM machineshop and returned in about three working days ( a weekend intervened). 

IMG_0685.JPG  IMG_0687.JPG

Bob cleaned and handed them over to me yesterday evening.  

Current status

Today I have reassembled the four tip-tilts.  I have repacked them in clean bags (double bagged) shifted them to Clean Optics Cabinet (near the ETMX chamber).  The four tip-tilts are in the bottom-most shelf in the cabinet.  There are also some tip-tilt spares in a separate envelope.

Note:  The mirror holder is now held tightly by the eddy current dampers.  This was done for safety of the wires during transportation from LHO.  The eddy current damper in the front of the mirror has to be retracted to allow the mirror holder to swing free.  It has be to about 1mm away from the suspended mirror holder

Work Remaining

1) We need to install the quadrapus cables.  The connector placement on the BOSEM side will have some issues.  It is best to loosen the BOSEM seating as well as the connector seating screws and then push the cable connector into place.  Caution:  when the connector seating screws on the BOSEM are loosened the flexible ckt could be damaged by the loose connector.

2) Insert the mirrors into the mirror holders and balance the suspension such that the mirror's hang vertical and do not have a large yaw offset.

3) Adjust the wire suspension point height so that the flags are in the center of the BOSEM aperture.  Else they will strike against the

4) We need to adjust the position of the BOSEMs such that the shadow sensor signals are at 50%.  This ensures that all the magnets hang at an appropriate distance from their respective coils.

5) To do (3) we need to set up a shadow sensor read-out set-up for one tip-tilt (four sensors)

 

  6791   Mon Jun 11 09:37:16 2012 steveUpdateIOOPMC locked

Quote:

Quote:

IOO Angle & IOO Position QPDs centered.

 PMC trend of 400 and 1200 days

The Innolight 2W based PSL- IOO was implemented in the ~ summer of 2010

 The PMC was locked and the MC followed intantly

  6868   Mon Jun 25 15:07:49 2012 yutaUpdateIOOMC beam spot trend

I adjusted MC WFS offsets using /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets.
Beam spot positions on MC mirrors came back to where it was past few weeks. See the trend below. Trend sometimes shows huge jump, but it's just a bad measurement caused by unlock of MC during the measurement.

I ran /opt/rtcds/caltech/c1/scripts/ASS/MC/mcassMCdecenter to measure beam spot whenever I feel like it (see elog #6727).
Beam spot doesn't move so much (~0.2 mm in standard deviation), which means incident beam from PSL table is quite stable.


MCdecenter.png

  6870   Mon Jun 25 16:21:10 2012 KojiSummaryIOOSelection of motorized mirror mounts

I am considering to have 3 to 6 motorized optical mounts at the PSL and end tables for remote beam steering.

Question 1:

Was there any issue on the PI 3-axis PZT on the PSL?
Why was it disabled (even before the PSL upgrade)?


Question 2:

Do we need two mount at a place? Or we do have one instead?

- Comparing the distance of the steering mirrors and that from the steering mirror to the cavity waist, induced shift
is mostly cancelled by angle adjustemnts of a either of the mounts.
i.e. Induced misalignments by the steering mirrors are nearly degenerated.

We need to move two steering mirrors only for the initial installation, but any drift felt by a cavity can be compensated by a single mirror.

Question 3:
Do we like PI-style 2 or 3 axis PZT mount with analog inputs on the HV amp?
Or do we like "Newport Agilis" style controller with USB connection?

Any opinion?

  6875   Tue Jun 26 22:37:43 2012 yutaUpdateIOOenergized OMC stages

[Koji, Yuta]

We checked that PZTs between SRM and OMC (called OMC stage 1 and 2) is working.
Now we need them to be EPICS channels because they are not connected to digital world right now.

Background:
  For the IFO alignment, what we have been doing for last 2weeks is,

1. Align Y arm to Y end green and maximize green transmission
2. Use PZT2 to maximize TRY (PZT1 is not functioning well. PZT1 Y do a little, but X totally does nothing.)
3. Align BS and X arm to maximize TRX
4. Tune BS and ITMX so that reflection from both arms overlap at AS
5. Align X end green to that we can see bright(~250 uW) TEM00 at transmission

  However, we found that something (Y arm axis or Y end green?) has drifted horizontally and can't make Y green transmission and TRY high level at same time. Because PZT1 is not functioning well, it is hard to compensate beam translation.
  So, now what we have to do is to align Y arm to IR incident beam. That means, we either have to realign Y end green or forget about maximizing green transmission. I think I will leave green as it is for a while because calibration of the beatbox is going on and I want to proceed to PRC.
  Anyway, if we align IFO to the IR incident beam, we see clipping in the AS port. From the contrast measurement last night, we thought clipping comes from somewhere between BS and AS port. So, we need PZTs between BS and AS port working.

What we did:
  1. Turned on 24P 24N power supplies(Sorensen DCS33-33E) in AUX_OMC_SOUTH rack to supply power to AUX_OMC_NORTH rack. 18P 18N cables to OMC_NORTH was unplugged and used by the beatbox, so we reconnected them.

  2. Turned on KEPCO high voltage power supply to supply 150 V to the PZT driver, but it was not functioning well. So, we currently use Aligent HP 6209B instead. Its on the OMC_NORTH rack.

  3. PZT driver output to OMC stage 1 was unplugged. So, we plugged them.

  4. Opened PZT driver (LIGO-D060287), put some signal from Piezo_Drive_in(J4 in schematic), and checked beamspot at AS port is moving. The gain from Piezo_Drive_in to the output (hv_out) was ~20.

  5. We could avoid clipping by putting some offset to OMC stage 2 (or 1) in yaw. That means, the clipping comes from after OMC stage 2.

Conclusion:
  If we can control OMC stage 1 and 2, we can avoid clipping. So, we want them to be EPICS channels.

  6876   Wed Jun 27 03:43:52 2012 yutaSummaryIOOhow to improve mode matching to arms

From the mode scan measurements of the arms(elog #6859), ~6% of mode-mismatch comes from 2nd-order mode. That means we have longitudinal mismatch.

Suppose every mirrors are well positioned and well polished with designed RoC, except for the MMT1-MMT2 length. To get ~6% of mode-mismatch, MMT1-MMT2 length should be ~28cm longer (or ~26cm shorter) than designed value.
I don't know whether this is possible or not, but if they are actually longer(or shorter), we should fix it on the next vent.
I found some related elog on MMT (see #3088).

modematchMCtoARM_design.pngmodematchMCtoARM_MMT1MMT2longer.png


RoC and length parameters I used is below. They maybe wrong because I just guessed them. Please tell me the actual values.
Mirror thickness and effect of the incident angle is not considered yet.

== RoCs ==
MC2 19.965 m (???)
PRM 115.5 m (not used in calculation; just used to guess MC parameters)
ITM flat
ETM 57.37 m

== Lengths ==
MC round trip 27.084 m (???)
MC1 - MC3  0.18 m (???)
MC3 - MMT1 0.884+1.0442 m
MMT1 - MMT2 1.876 m
MMT2 - PRM 2.0079+0.4956 m
PRM - ITM 4.4433+2.2738 m
ITM - ETM 39 m

  6877   Wed Jun 27 10:27:09 2012 ranaSummaryIOOhow to improve mode matching to arms

The MC waist is correct as is the arm RoCs. Most likely the error is in the telescope length or its distance from the MC. Jenne probably has all the numbers and can give us a surface plot showing how the MM degrades as a function of those two parameters.

  6884   Wed Jun 27 16:23:12 2012 yutaUpdateIOOAS and REFL on AP table aligned

I touched steering mirrors for AS and REFL at AP table.
AS beam and REFL beam now hits cameras at center and their respective PDs.

What I did:
  1. Aligned Y arm and X arm.

  2. Locked FPMI and aligned BS + X arm by minimizing ASDC (DC output of the AS55 PD, C1:LSC-ASDC_OUT reached ~ -1.43).

  3. Put -2V offset to the OMC stage 2 in yaw to avoid AS clipping. The offset is currently given by SRS DS345 on AUX_OMC_NORTH rack.

  4. Misaligned ETMs, locked MI in the bright fringe. Maximized ASDC (C1:LSC-ASDC_OUT reached ~ 1.22) by aligning 2 mirrors right after the vacuum chamber. This also centered beam spot on the AS camera.

  5. Locked MI in the dark fringe. Maximized REFLDC (DC output of the REFL55 PD, C1:LSC-REFLDC_OUT reached ~ 2.5) by aligning 2 mirrors after the vacuum chamber. Beam spot on the REFL camera was centered, too.

  6892   Fri Jun 29 02:17:40 2012 yutaUpdateIOOprep for the vent - beam attenuating

[Koji, Jamie, Yuta]

We attenuated the incident beam (1.2 W -> 11 mW) to the vacuum chamber to be ready for the vent.
The beam spot on the MC mirrors didn't changed significantly, which means the incident beam was not shifted so much.

What we did:
 1. Installed HWP, PBS(*) and another HWP between the steering mirrors on PSL table for attenuating the beam. We didn't touched steering mirrors(**), so the incident beam to the IFO should be recovered easily, by just taking HWPs and PBS away. The power to the MC was reduced from 1.2 W to 11 mW.

(*) We stole PBSO from the AS AUX laser setup.
(**) Actually, we accidentally touched one of the steering mirrors, but we recovered them. We did the recovery tweaking the touched nob and minimizing the MC reflection. We confirmed the incident beam was recovered by measuring MC beamspot positions(below).

 2. Aligned PBS by minimizing MC reflection, adjusted first HWP so that the incident beam will be ~10 mW, and adjusted last HWP to minimize MC reflection (make the incident beam to the MC be p-polarization).

 3. To do the alignment and adjusting, we put 100% reflection mirror (instead of 10% BS) for the MC reflection PD to increase the power to the PD. That means, we don't have MC WFS right now.

 4. Tweaked MC servo gains to that we can lock MC in low power mode. It is quite stable right now. We didn't lose lock during beam spot measurement.

 5. Measured beam spot positions on the MC mirrors and convinced that the incident beam was not shifted so much (below). They look like they moved ~0.2 mm, but it is with in the error of the MC beam spot measurement.

# filename      MC1pit  MC2pit  MC3pit  MC1yaw  MC2yaw  MC3yaw  (spot positions in mm)
./dataMCdecenter/MCdecenter201206281154.dat     3.193965        4.247243        2.386126        -6.639432       -0.574460       4.815078    this noon
./dataMCdecenter/MCdecenter201206282245.dat     3.090762        4.140716        2.459465        -6.792872       -0.651146       4.868740    after recovered steering mirrors
./dataMCdecenter/MCdecenter201206290135.dat     2.914584        4.240889        2.149244        -7.117336       -1.494540       4.955329    after beam attenuation

 6. Rewrote matlab code sensemcass.m to python script sensemcass.py. This script is to calculate beam spot positions from the measurement data(see elog #6727). I think we should make senseMCdecenter script better, too, since it takes so much time and can't stop and resume the measurement if MC is unlocked.

  6898   Sat Jun 30 18:31:38 2012 steveUpdateIOOinput telescope beam clipping on Faraday

  We could set up a simple pick  off after the Faraday  and bring it  out the north window of IOO chamber. No monitor needed, just take the cover off when you want to see it.

Most people have no idea how to get the MC through the F

  6899   Sun Jul 1 13:20:09 2012 yutaUpdateIOOMC in low power

I modified autolocker for MC in low power mode (/opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m_low_power) to make it work with the current directory structure.
autolockMCmain40m_low_power currently runs on op340m and it is in crontab.

34 * * * *  /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m_low_power >/cvs/cds/caltech/logs/scripts/mclock.cronlog 2>&1


MC intra-cavity power:
  Currently, incident beam to the MC measured at PSL table is ~15 mW. Reflected power from MC (C1:IOO-MC_RFPD_DCMON) is 0.94 when MC unlocked, and is 0.088 when locked.
  That means, considering MC1/3 power transmission is 2000ppm (calculated finnesse=1570), intra-cavity power in MC is ~7 W.

  15 mW * (0.94-0.088)/0.94 / 2000ppm = 7 W

  We can increase the power by factor of ~2, if needed.


MC beam spot positions:

  I aligned MC to maximize transmission (C1:IOO-MC_TRANS_SUM_ERR), and measured the MC beam spot posisions in atm, low power.

# filename    MC1pit    MC2pit    MC3pit    MC1yaw    MC2yaw    MC3yaw    (spot positions in mm)
./dataMCdecenter/MCdecenter201206290135.dat    2.914584    4.240889    2.149244    -7.117336    -1.494540    4.955329    before vent
./dataMCdecenter/MCdecenter201207011253.dat    3.294659    3.416584    2.620511    -6.691800    -3.164084    4.806517    after vent

  They look the same within the error of the measurement, except for the spot positions on MC2, which we don't care.


Autolocker should be refined:
  To make autolockMCmain40m_low_power, I copied autolockMCmain40m and just changed

- lockthresh from 500 to 100
- use mcdown_low_power instead of mcdown
- use mcup_low_power instead of mcup

  The difference between mcdown_low_power and mcdown should be only

- ezcawrite C1:IOO-MC_REFL_GAIN 31 for lowpower, 9 for usual
- ezcawrite C1:IOO-MC_VCO_GAIN 10 for lowpower, -5 for usual

  The difference between mcup_low_power and mcup should be only

- ezcawrite C1:IOO-MC_REFL_GAIN 31 for lowpower, 12 for usual
- ezcawrite C1:IOO-MC_VCO_GAIN 31 for lowpower, 25 for usual

  Currently, they are not like that. Somebody good at shell scripts should combine them and make it into one code with an option something like usual/low-power.

  6910   Tue Jul 3 20:51:06 2012 yutaUpdateIOOMC in vacuum is back

MC came back to the state as it was before the vent.

What I did:
  1. Removed beam attenuating setup on PSL table(see elog #6892).

  2. Removed 100% reflection mirror before the MC reflection PD and put 10% BS back, so that we can have MC WFS. Also, I changed C1:IOO-MC_RFPD_DCMON.HOPR to 5.

  3. Removed autolockMCmain40m_low_power from crontab on op340m, and put autolockMCmain40m again.

  4. Aligned MC and ran /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets to adjust WFS offsets.

  5. Measured beam spot positions. They looked same as before the vent.

# filename    MC1pit    MC2pit    MC3pit    MC1yaw    MC2yaw    MC3yaw    (spot positions in mm)
./dataMCdecenter/MCdecenter201206290135.dat    2.914584    4.240889    2.149244    -7.117336    -1.494540    4.955329    before vent
./dataMCdecenter/MCdecenter201207011253.dat    3.294659    3.416584    2.620511    -6.691800    -3.164084    4.806517    after vent
./dataMCdecenter/MCdecenter201207032009.dat    3.737099    3.994597    3.087857    -6.442053    -0.992543    4.714607    after pumping (now)

  6. I also turned on high voltage power supplies for input and output PZTs

  7. Below is captured Sensoray images of the current state.
ALL_1025408289.bmp


Next:
  I will go on to check if IFO works as it was before or not, but I think we should center MC beam spot positions and see if we can avoid clipping in the near future.

  6982   Wed Jul 18 00:36:22 2012 JenneUpdateIOOWFS oscillating

I was trying to lock and look at the ASS for the Yarm, but the transmitted power was oscillating very near 1Hz.  Eventually I looked at the mode cleaner, and it was also moving around at a similar frequency.  I took spectra of the ETMY SUS damping feedback signals, and they (POS, PIT, YAW) saw this 1Hz motion too (see attached plots...same data, one is a zoom around 1Hz).

As a first place to start, I turned off the WFS, which immediately stopped the MC oscillation.  Turning the WFS back on, the oscillation didn't come back.  I'm not sure what happened to make the WFS bad, but I perhaps had the ASS dither lines on (I've had them on and off, so I'm not sure), although turning off the dither lines didn't make the WFS any better.

As an aside, the MC refl with the WFS off was ~1.5, rather than the ~0.5 with the WFS on, which means that the PSL beam and the MC axis are not well matched.

  6989   Wed Jul 18 14:25:44 2012 JenneUpdateIOOMC spot position measurements

The script ....../scripts/ASS/MC/mcassMCdecenter  takes ~17 minutes to run.  The biggest time sink is measuring a no-offset-added-to-coil-gains set, in between each measurement set with the coil gain offsets.  This is useful to confirm that the nominal place hasn't changed over the time of the measurement, but maybe we don't need it.  I'm leaving it for now, but if we want to make this faster, that's one of the first things to look at.

Today's measurement:

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[3.5716862287669224, 3.937869278443594, 2.9038058599576595, -6.511822708584913, -0.90364583591421999, 4.8221820002404279]

There doesn't seem to be any spot measurement stuff for any other optics, so I'm going to try to replicate the MC spot measuring script for the Michelson to start.

  6992   Thu Jul 19 02:32:45 2012 JenneUpdateIOOWFS don't come on automatically??

The MC unlocked ~20 min ago, correlated with 2 consecutive earthquakes in Mexico.  The MC came back fine after a few minutes, but the WFS never engaged.  I turned them on by hand.  I think that Yuta mentioned once that he also had to turn the WFS on by hand.  There may be a problem in the unlock/relock catching that needs to be looked at, to make sure the WFS come back on automatically.

Also, someone (Masha and I) should look at the seismic BLRMS.  I have suspected for a few days that they're not telling us everything that we want to know.  Usually, if there's an earthquake close enough / big enough that it pops the MC out of lock, it is clear from the BLRMS that that's what happened, but right now it doesn't look like much of anything....just kind of flat for hours.

  7003   Mon Jul 23 17:39:34 2012 JenneUpdateIOOMC_F vs. MC_L

[Rana, Jenne]

We looked at the different outputs of the MC servo board to make sure they make some kind of sense.  As per my elog 6625, the names of the channels were wrong, but we wanted to confirm that we have something sensible.

Currently, OUT1 of the servo board is called "MC_F" and the SERVO out is called "MC_SERVO".  We looked at the spectrum of each, and the transfer function between them.

You can see that in addition to a 2kHz pole, MC_L also seems to have a 10-100 zero-pole pair.

 

Also, while cleaning things up in the models, I fixed the names of these MCL/MCF channels.  OUT1 is now called MC_L, and is connected to ADC0_0, and SERVO is called MC_F and is connected to ADC0_6.  Both MC_L and MC_F go to the RFM, and thence on to the OAF.  MC_L (which used to be mis-named MC_F) still goes both to the MCS model for actuation on MC2, and to the OAF for MC-OAF-ing.  Right now MC_F is unused in the OAF model, but we can change that later if we want.

 

  7035   Thu Jul 26 02:44:17 2012 JenneUpdateIOOCentering the MCR camera

[Yaakov, Jenne]

The short version:

Rana and Koji pointed out to us that the MCR camera view was still not good.  There were 2 problems:

(1) Diagonal stripes through the beam spot.  Yuta and I saw this a week or 2 before he left, but we were bad and didn't elog it, and didn't investigate.  Bad grad students.

(2) Clipping of the left side of the beam (as seen on the monitors).  This wasn't noticed until Yaakov's earlier camera work, since the clipped part of the beam wasn't on the monitor.

The fix for #1 was to partially close the iris which is the first "optic" the beam sees on the AP table after leaving the vacuum. 

The "fix" for #2 was that the wrong beam has been going to the camera for an unknown length of time.  We picked the correct beam, and all is well again.

We moved the 10% BS that splits the main beam into the (MC REFL PD) path and the (MCR camera + WFS) path.  It looked like the transmission through there was close to the edge of the BS.  We didn't think that this was causing the clipping that we saw on the camera (since when we stepped MC1 in Yaw, the beam spot had to move a lot before we saw any clipping), but it seemed like a good idea to make the beam not near the edge of the optic, especially since, being a 2" optic, there was plenty of room, and we were only using ~half of the optic.  We didn't touch anything else in the WFS path, since that looks at the transmission through this BS, but we had to realign the beam onto MC REFL.

The long version:

(1)  The fix for #1 was to partially close the iris which is the first "optic" the beam sees on the AP table after leaving the vacuum.  It looks like that's why the iris was there in the first place.  When we found it this evening, the iris was totally open, so my current theory is that someone was on the AP table doing something, and accidentally bumped the handle for the iris, then left it completely open when they realized that they had touched it.  I think Steve had been doing something on the AP table around then, but since Yuta and I didn't elog our observation (bad grad students!), I can't correlate it with any of Steve's elogs. We were not able to find exactly where this "glow" that the iris is used to obscure comes from, but we traced it as far as the viewport, so there's something going on inside.

(2)  The "fix" for #2 was that the wrong beam has been going to the camera for an unknown length of time.  We picked the correct beam, and all is well again. 

We spent a long time trying to figure out what was going on here.  Eventually, we moved the camera around to different places (i.e. right before the MC REFL PD, with some ND filters, and then we used a window to pick off a piece of the beam right as it comes out of the vacuum before going through the iris, put some ND filters, then the camera).  We thought that right before the MC REFL PD was also being clipped, indicating that the clipping was happening in the vacuum (since the only common things between the MC REFL PD path and the camera path are the iris, which we had removed completely, and a 2" 10% beam splitter.  However, when we looked at a pickoff of the main beam before any beamsplitters, we didn't see any evidence of clipping.  I think that when we had the camera by MC REFL, we could have been clipping on the ND filters that I had placed there.  I didn't think to check that at the time, and it was kind of a pain to mush the camera into the space, so we didn't repeat that.  Then we went back to the nominal MCR camera place to look around.  We discovered that the Y1 which splits the camera path from the WFS path has a ghost beam which is clipping on the top right side (as you look at the face of the optic) of the optic, and this is the beam that was going to the camera (it's a Y1 since we only want a teensy bit of light to go to the camera, the rest goes to the WFS).  There is another beam which is the main beam, going through the center of the optic, which is the one which also reflects and heads to the WFS.  This is the beam which we should have on the camera.  Yaakov put the camera back in it's usual place, and put the correct beam onto the center of the camera.  We did a check to make sure that the main beam isn't clipping, and when I step MC1 yaw, the beam must move ~1.5mm before we start to see any clipping on the very edge of the beam.  To see / measure this, we removed the optic which directs the beam to the camera, and taped an IR card to the inside of the black box.  This is ~about the same distance as to the nominal camera position, which means that the beam would have to move by 1.5mm on the camera to see any clipping.  The MC REFL PD is even farther from MC1 than our IR card, so the beam has to fall off the PD before we see the clipping.  Thus, I'm not worried about any clipping for this main beam.  Moral of the story, if you made it this far:  There wasn't any clipping on any beams going to either the WFS or the MC REFL PD, only the beam going to the camera.

  7069   Wed Aug 1 15:02:29 2012 JenneUpdateIOOIP POS QPD centered

Jamie went out to look at IP POS, and the beam was *way* off.  Even though our alignment is still rough, we're kind of close right now, so Jamie put the beam back on the QPD, but we need to recenter IPPOS after we get good alignment.

  7070   Wed Aug 1 15:14:20 2012 JenneUpdateIOOPSL Pointing QPD signals lost in late-June 2012

I was looking into why we don't have any light on the PSL pointing QPDs, and it turns out that it has been this way since ~June 29th 2012.  I need to look back in the elog to see what was going on on the PSL table that day, but I suspect it has something to do with Yuta and I, working on the beat setup, since this is all very near that area.

Attached is a plot of the loss of signal on the QPDs.

UPDATE:

 We lost IP POS on the same day as we lost the PSL pointing.  See 2nd attachment.  The _S_Calc is the sum, and it almost looks like the light got near the edge of the diode and just kept falling off until it was gone.  The sum started getting lower on May 16th, and then was gone on June 29th.

So far I've gone back as far as Jan 2012, but I still haven't found any data where we *did* have light on IP ANG.  Sad.

UPDATE, UPDATE (like P.P.S.):  June 29th was the day of the vent...see elog 6895.

  7088   Mon Aug 6 09:46:31 2012 steveUpdateIOOpoweroutage turns laser off

. Power outage turned off the PSL Innolight laser on Sunday afternoon.  It  was turned back on and  locked happily right on. The green lasers were not effected.

 

CALIFORNIA INSTITUTE OF TECHNOLOGY

                 FACILITIES MANAGEMENT

            UTILITY & SERVICE INTERRUPTION

 

**PLEASE POST**

 

Building:         CAMPUS WIDE     

 

Date:             SUNDAY, AUGUST 6, 2012          

 

Time:             3:41 PM          

 

Interruption:     ELECTRICAL POWER DISTRIBUTION

  

Contact:          MIKE ANCHONDO, X-4999, OR TOM BRENNAN, X-4984      

 

* THIS PAST SUNDAY AFTERNOON ABOUT 3:40 PM, PASADENA WATER AND POWER

 EXPERIENCED A FAULT ON THEIR POWER DISTRIBUTION SYSTEM.  THIS CAUSED

  A SEVERE VOLTAGE SAG WHICH AFFECTED THE CALTECH CAMPUS. THE FAULT WAS

  NOT ON A CALTECH CIRCUIT.

 

(If there is a problem with this Interruption, please notify

the Service Center X-4717 or the above Contact as soon as possible.

If no response is received we will proceed with the interruption.)

        

                        Jerry Thompson,

                        Interim Director of Campus Operations & Maintenance

 

 

  7121   Wed Aug 8 18:01:58 2012 JenneUpdateIOOMC autolocker threshold changed

Jan and Manasa are going to elog about their work later, but it involved putting a BS/window/some kind of pick off in front of the MC Trans QPD, so the total light on the MC Trans QPD is now ~16000 rather than ~26000 counts.  I changed the threshold in the MC autolocker to 5000, so now the MC Trans PD must see at least 5000 counts before the autolocker will engage the boosts, WFS, etc.  Actually, this threshold I believe should have been some several thousand value, but when I went in there, it was set to 500 counts, for low power MC mode during a vent.  It had never gotten put back after the vent to some higher, nominal value.

  7122   Wed Aug 8 19:54:06 2012 ManasaConfigurationIOOMC trans optics configured

Jan and I wanted to measure the ringdown at the IMC. Since the QPD at the MC trans is not fast enough for ringdown measurements, we decided to install a pickoff to include a faster PD while not disturbing much of the current MC trans configuration. The initial configuration had very little space to accommodate the pickoff. So the collimating lens along with the QPD were moved 2 inches closer to the incoming beam. A 50-50 BS was put in front of the QPD and the steering mirror was moved behind to reflect MC trans output to the new PD. The current configuration is shown below with the MC autolocker threshold mentioned in Jenne's elog

Pic1.png

The hunt for a faster PD wasn't satisfactory and we found a couple of PDs that were good for measurements actually didn't work after installing them. The one currently installed is also not satisfactorily fast enough for ringdown measurements. We'll hunt for faster PDs at Bridge tomorrow and replace PDA400. Also the IMC unlocked from time to time....may be we were noisy and didn't master the 'interferometer walk' very well.

 

 

  7126   Wed Aug 8 22:12:30 2012 ranaConfigurationIOOMC trans optics configured

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

  7127   Wed Aug 8 22:17:43 2012 ManasaConfigurationIOOMC trans optics configured

Quote:

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

  7140   Fri Aug 10 09:54:51 2012 ManasaConfigurationIOOMC trans optics configured

Quote:

Quote:

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

 I double checked the PDA255 found at the 40m and it is broken/bad. Also there was no success hunting PDs at Bridge. So the MC trans is still in the same configuration. Nothing has changed. I'll try doing ringdown measurements with PDA400 today.

ELOG V3.1.3-