40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 166 of 330  Not logged in ELOG logo
ID Date Author Type Category Subject
  8283   Wed Mar 13 08:34:33 2013 yutaUpdateLockingTWO arms TWO colors

- I took the shutter from AS table to use it for the PSL green. It was sitting near MC REFL path unused (elog #8259).

- If X green lock is not tight, maybe temporarily increasing loop gain helps. This can be done by increasing the amplitude of the frequency modulation or increasing green refl PD gain. Also, if X green beam spot is too wiggly compared with Y green, it is maybe because of air flow from the air conditioner (elog #6849). I temporarily turned it off when I did X green steering last summer.

- X green transmission on PSL table reached ~270 uW last summer (elog #6849, elog #6914). Y green transmission is now ~240 uW and ~2700 counts at maximum. So, X green transmission should reach ~3000 in counts.

- Did you have to re-align TRX path? We moved the harmonic separator on X end table horizontally to avoid IR TRX clipping before beam centering on X arm (elog #8162). I wonder what is the current situation after the beam centering.

  8282   Wed Mar 13 03:12:47 2013 Manasa, JenneUpdateLockingTWO arms TWO colors

[Jenne, Manasa]

2 colors 2 arms realized!

1. Spot centering:

We spot centered the IR in both arms.
- Use TT1 and TT2 to center in Y arm (I visually center the spots on the ITM and ETM and then use TTs iteratively)
- Use BS-ETM to center in X arm

Spot positions after centering
               X arm            Y arm
         itmx    etmx        itmy    etmy
pitch    -0.86    0.37        1.51    0.05
yaw      0.01    -0.1        0.08    0.10

2. TT1 drifting in pitch (Bistable)
During the arm alignment routine for spot centering, we observed that TRY dropped (from TRY = 0.9 until the arm lost lock) every 40minutes or so. The arm was relocked by moving TT1 in pitch. The (locking - unlocking due to drift - relocking) cycle was monitored and we observed that it was bistable i.e. if TT1 was moved up in pitch (0.2 on the slider) to relock for the first time ; the next time it lost lock, TT1 had to be moved down by nearly the same distance to relock the arm.
Moving TT2 or the testmasses did not help with relocking the arms; so TT1 seems to be the one causing all th trouble atleast for today.

3. ALS - green alignment

We then moved on to Ygreen.  We used the out of vac steering mirrors to center the beam on the 2 irises that are in place on the table, which was a good starting place.  After doing that, and tweaking a small amount to overlap the incident and reflected beams on the green steering mirrors, we saw some mode lock.  We adjusted the end table steering mirrors until the Ygreen locked on TEM00.  We then followed Rana's suggestion of locking the IR to keep the cavity rigid while we optimized the green transmission.  Yuta, while adjusting ITMY and ETMY (rather than the out of vac mirrors) had been able to achieve a green transmission for the Yarm of ~2700 counts using the GTRX DC PD that's on the table. We were only able to get ~2200, with brief flashes up to 2500.

After that, we moved on to the X arm.  Since there are no irises on the table, we used the shutter as a reference, and the ETM optic itself.  Jenne looked through the viewport at the back of the ETM, while Manasa steered mirrors such that we were on the center of the ETM and the shutter.  After some tweaking, we saw some higher order modes lock.  We had a very hard time getting TEM00 to stay locked for more than ~1 second, even if the IR beam was locked.  It looks like we need to translate the beam up in pitch.  The leakage of the locked cavity mode is not overlapped with the incident beam or the promptly reflected beam.  This indicates that we're pretty far from optimally aligned.  Manasa was able to get up to ~2000 counts using the same GTRX PD though (with the Ygreen shutter closed, to avoid confusion).  Tomorrow we will get the Xarm resonating green in the 00 mode.

We need to do a little cleanup on the PSL green setup.  Yuta installed a shutter (I forget which unused one he took, but it was already connected to the computers.), so we can use it to block the PSL green beam.  The idea here is to use the 4th port of the combining beam splitters that are just before each beat PD, and place a PD and camera for each arm.  We already have 2 PDs on the table connected to channels, and one camera, so we're almost there. Jenne will work on this tommorrow during the day, so that we can try to get some beat signals and do some handoffs in the evening.

  8281   Wed Mar 13 02:48:13 2013 JenneUpdateIOOMC all better

Koji reminded me (again....this is probably the  2nd or 3rd time I've "discovered" this, at least) that the script


exists, and that we should use it sometimes.  See his elog 7452 for details. 


Notes about using this script:

* Only use it after MC has been very well aligned.  MC REFL DC should be less than 0.5 when the MC is locked (with the DC value ~4.5 with the MC unlocked, as usual).  This is hard to achieve, but important.  Also, check the MC spot centering.

* With the WFS servo off, but the MC locked and light on the WFS diodes, run the script. 

  8280   Tue Mar 12 14:51:00 2013 SteveUpdateComputersbuy warranty or not ?

 Details of the warranties are posted on wiki power supply cost, warranty described, cost

.......I’ve also attached a warranty renewal quote.  A 1 year warranty renewal is usually $.... per year, but we gave you special pricing of $.... / year if you renew both units.  This pricing is also special due to the fact that both warranties expired awhile ago.  We usually require that the warranty renewal begin on the date of expiration, but we will waive this for you this time if both are renewed.


JetStor SATA 416S, SN: SB09040111A3 – expired 04/24/2012 (3 years old)


JetStor SATA 516F, SN: SB09080016P – expired on 08/21/2012........


. Are we keep it for an other 2 years? buy warranty or buy better storage.


  8279   Tue Mar 12 14:02:22 2013 JenneUpdateAlignmentBeam drift - mystery partially solved?

Steve just told those of us in the control room that the custodian who goes into the IFO room regularly steps on the blue support beams to reach the top of the chambers to clean them.  Since we have seen in the past that stepping on the blue tubes can give the tables a bit of a kick, this could help explain some of the drift, particularly if it was mostly coming from TT2.  The custodian has promised Steve that he won't step on the blue beams anymore.

This doesn't explain any of the ~1 hour timescale drift that we see in the afternoons/evenings, so that's still mysterious.

  8278   Tue Mar 12 12:06:22 2013 JamieUpdateComputersFB recovered, RAID power supply #1 dead

The framebuilder RAID is back online.  The disk had been mounted read-only (see below) so daqd couldn't write frames, which was in turn causing it to segfault immediately, so it was constantly restarting.

The jetstor RAID unit itself has a dead power supply.  This is not fatal, since it has three.  It has three so it can continue to function if one fails.  I have removed the bad supply and gave it to Steve so he can get a suitable replacement.

Some recovery had to be done on fb to get everything back up and running again.  I ran into issues trying to do it on the fly, so I eventually just rebooted.  It seemed to come back ok, except for something going on with daqd.  It was reporting the following error upon restart:

[Tue Mar 12 11:43:54 2013] main profiler warning: 0 empty blocks in the buffer

It was spitting out this message about once a second, until eventually the daqd died.  When it restarted it seemed to come back up fine.  I'm not exactly clear what those messages were about, but I think it has something to do with not being able to dump it's data buffers to disk.  I'm guessing that this was a residual problem from the umounted /frames, which somehow cleared on it's own.  Everything seems to be ok now.


Manasa just went inside to recenter the AS beam on the camera after our Yarm spot centering exercises of the evening, and heard a loud beeping.  We determined that it is the RAID attached to the framebuilder, which holds all of our frame data that is beeping incessantly.  The top center power switch on the back (there are FOUR power switches, and 3 power cables, btw.  That's a lot) had a red light next to it, so I power cycled the box.  After the box came back up, it started beeping again, with the same front panel message:

H/W monitor power #1 failed.

DO NOT DO THIS.  This is what caused all the problems.  The unit has three redundant power supplies, for just this reason.  It was probably continuing to function fine.  The beeping was just to tell you that there was something that needed attention.  Rebooting the device does nothing to solve the problem.  Rebooting in an attempt to silence beeping is not a solution.  Shutting of the RAID unit is basically the equivalent of ripping out a mounted external USB drive.  You can damage the filesystem that way.  The disk was still functioning properly.  As far as I understand it the only problem was the beeping, and there were no other issues.  After you hard rebooted the device, fb lost it's mounted disk and then went into emergency mode, which was to remount the disk read-only.  It didn't understand what was going on, only that the disk seemed to disappear and the reappear.  This was then what caused the problems.  It was not the beeping, it was the restarting the RAID that was mounted on fb.

Computers are not like regular pieces of hardware.  You can't just yank the power on them.  Worse yet is yanking the power on a device that is connected to a computer.  DON"T DO THIS UNLESS YOU KNOW WHAT YOU"RE DOING.  If the device is a disk drive, then doing this is a sure-fire way to damage data on disk.


  8277   Tue Mar 12 11:49:18 2013 JenneUpdateIOOMC weird again

[Manasa, Annalisa, Jenne]

The MC wasn't locking on TEM00 this morning, and the WFS kept pulling the MC out of alignment.  The MC was realigned, and the WFS spots are back to being roughly centered (all of this only touching the MC sliders), but the WFS keep doing bad things.  They're okay, and improve the alignment slightly at first, but as soon as the FM1 integrator comes on, the MC alignment immediately starts going bad, and within a second or so the MC has unlocked.

The WFS are off right now, and we'll keep investigating after LIGOX.

  8276   Tue Mar 12 00:58:05 2013 ManasaUpdateAlignmentYarm - Spot positions centered

[Jenne, Manasa]

Spot centering on Y arm - DONE!

Alignment procedure
1. I went back to the IFO alignment slider positions from Friday. The Y arm was flashing in HOM because the earthquake this morning tripped all suspensions and the slider values were not real. X arm did not have any flashes.

2. Y arm aligned using TT1 and TT2. Spot centering measured using Jenne's A2L_Yarm script.

Spot positions:
           ITMY    ETMY
Pitch    6.48    4.39
Yaw     -7.42    -3.135

3. I started centering in pitch. I used the same in-vac alignment method (down on TT1 and up on TT2 in pitch) and measured spot positions.

4. When the spot positions were centered in pitch, I started with yaw alignment.

5. I had to use TT1 to center on ITMY and move TT2 and ITMY to center on ETMY.

6. Spot positions after centering:

                          ITMY    ETMY
Pitch    -1.22    -1.277
Yaw       0.42    -0.731

7. I wanted to go back and tweak the pitch cenetering; but framebuilder failed and dataviewer kept loosing connection to fb

AS seems clipped. Although it could be because of the misaligned BS.

IPANG was centered on the QPD, but it is so clipped, that I'm not sure we can trust it.  Max sum right now is -4, rather than the usual -8 or -9.


Once fb is fixed, we should align the X-arm which will be followed by green alignment.

Over the last few weeks, it has been observed that there is some strong seismic activity that starts at around 9PM everyday and goes on for a couple of hours. It seems unlikely that it is our geologist neighbour (Jenne met with the grad student who works on the noisy experiment).

  8275   Tue Mar 12 00:45:50 2013 JenneUpdateIOOMC weird again

~20 minutes ago, maybe right around the time the fb's RAID died (elog 8274) the mode cleaner started behaving weirdly again.  The reflected value is very high, even with the WFS on.  Earlier this evening, I saw that with the WFS off, the MC reflection was high, but the WFS brought it back down to ~0.7 or 0.8.  But now it's ~1.3.  With the WFS off, the reflected value is ~1.1.  I don't really understand.

Also, the PMC has been drifting in alignment in pitch all day, but a lot more later in the day. The PMC trans is 0.800 right now, but it was as high as 0.825 today, and spent most of the day in the high 0.81xxx range today.

I would provide plots, but as mentioned in elog 8274, we can't get data right now.

  8274   Tue Mar 12 00:35:56 2013 JenneUpdateComputersFB's RAID is beeping

[Manasa, Jenne]

Manasa just went inside to recenter the AS beam on the camera after our Yarm spot centering exercises of the evening, and heard a loud beeping.  We determined that it is the RAID attached to the framebuilder, which holds all of our frame data that is beeping incessantly.  The top center power switch on the back (there are FOUR power switches, and 3 power cables, btw.  That's a lot) had a red light next to it, so I power cycled the box.  After the box came back up, it started beeping again, with the same front panel message:

H/W monitor power #1 failed.

Right now the fb is trying to stay connected to things, and we can kind of use dataviewer, but we lose our connection to the framebuilder every ~30 seconds or so.  This rough timing estimate comes from how often we see the fb-related lights on the frontend status screen cycle from green to white to red back to green (or, how long do the lights stay green before going white again).  We weren't having trouble before the RAID went down a few minutes ago, so I'm hopeful that once that's fixed, the fb will be fine. 

In other news, just to make Jamie's day a little bit better, Dataviewer does not open on Pianosa or Rosalba.  The window opens, but it stays a blank grey box.  This has been going on for Pianosa for a few days, but it's new (to me at least) on Rosalba.  This is different from the lack of ability to connect to the fb that Rossa and Ottavia are seeing.

  8273   Mon Mar 11 22:28:30 2013 Max HortonUpdateSummary PagesFixing Plot Limits

Quick Note on Multiprocessing:  The multiprocessing was plugged into the codebase on March 4. Since then, the various pages that appear when you click on certain tabs (such as the page found here: https://nodus.ligo.caltech.edu:30889/40m-summary/archive_daily/20130304/ifo/dc_mon/ from clicking the 'IFO' tab) don't display graphs.  But, the graphs are being generated (if you click here or here, you will find the two graphs that are supposed to be displayed).  So, for some reason, the multiprocessing is preventing these graphs from appearing, even though they are being generated.  I rolled back the multiprocessing changes temporarily, so that the newly generated pages look correct until I find the cause of this.

Fixing Plot Limits:  The plots generated by the summary_pages.py script have a few problems, one of which is: the graphs don't choose their boundaries in a very useful way.  For example, in these pressure plots, the dropout 0 values 'ruin' the graph in the sense that they cause the plot to be scaled from 0 to 760, instead of a more useful range like 740 to 760 (which would allow us to see details better).

The call to the plotting functions begins in process_data() of summary_pages.py, around line 972, with a call to plot_data().  This function takes in a data list (which represents the x-y data values, as well as a few other fields such as axes labels).  The easiest way to fix the plots would be to "cleanse" the data list before calling plot_data().  In doing so, we would remove dropout values and obtain a more meaningful plot.

To observe the data list that is passed to plot_data(), I added the following code:

      # outfile is a string that represents the name of the .png file that will be generated by the code.
      print_verbose("Saving data into a file.")
      outfile_mch = open(outfile + '.dat', 'w')

      # at this point in process_data(), data is an array that should contain the desired data values.
      if (data == []):
          print_verbose("Empty data!")
      print >> outfile_mch, data

When I ran this in the code midday, it gave a human-readable array of values that appeared to match the plots of pressure (i.e. values between 740 and 760, with a few dropout 0 values).  However, when I let the code run overnight, instead of observing a nice list in 'outfile.dat', I observed:

[('Pressure', array([  1.04667840e+09,   1.04667846e+09,   1.04667852e+09, ...,
         1.04674284e+09,   1.04674290e+09,   1.04674296e+09]), masked_array(data = [ 744.11076965  744.14254761  744.14889221 ...,  742.01931356  742.05930208
             mask = False,
       fill_value = 1e+20)

I.e. there was an ellipsis (...) instead of actual data, for some reason.  Python does this when printing lists in a few specific situations.  The most common of which is that the list is recursively defined.  For example:

a = [5]
print a

[5, [...]]

It doesn't seem possible that the definitions for the data array become recursive (especially since the test worked midday).  Perhaps the list becomes too long, and python doesn't want to print it all because of some setting.

Instead, I will use cPickle to save the data.  The disadvantage is that the output is not human readable.  But cPickle is very simple to use.  I added the lines:

      import cPickle
      cPickle.dump(data, open(outfile + 'pickle.dat', 'w'))

This should save the 'data' array into a file, from which it can be later retrieved by cPickle.load().

There are other modules I can use that will produce human-readable output, but I'll stick with cPickle for now since it's well supported.  Once I verify this works, I will be able to do two things:
1) Cut out the dropout data values to make better plots.
2) When the process_data() function is run in its current form, it reprocesses all the data every time.  Instead, I will be able to draw the existing data out of the cPickle file I create.  So, I can load the existing data, and only add new values.  This will help the program run faster.

  8272   Mon Mar 11 19:01:21 2013 JenneUpdatePEMproposed seismometer locations

This is my interpretation of where Steve is proposing to place the seismometers (he wrote ITMX southwest, but I'm pretty sure from the photo he means southeast).

I think his point is that these locations are on the less-used side of the beam tube, so they will not be in the way.  Also, they are not underneath the tube, so we will not have any problems putting the covers on/taking them off.




  8271   Mon Mar 11 17:18:00 2013 ManasaUpdateEnvironmentEarthquake: Suspensions tripped and MC realigned

I found all suspensions including the MC suspensions tripped this morning after the earthquake.

I damped all the optics and realigned MC mirrors to lock at refl 0.57.

PRM and SRM tripped a couple of times due to the aftershocks that followed; but were damped eventually.

  8270   Mon Mar 11 16:29:29 2013 SteveUpdatePEMproposed seismometer locations

Granite base 20" x 20" x 5"  locations are on the CES side of our IFO arms:  as shown ETMY_ south-west, ETMX_north-east, ITMX_south-east . No height limitation. This side of the tube has no traffic.

SS cover McMaster#  41815T4  (H) SS container cov

Attachment 1: ETMY_sw.jpg
Attachment 2: ITMX_se.jpg
Attachment 3: ETMX_ne.jpg
  8269   Mon Mar 11 15:52:46 2013 JenneUpdateIOOMC spots centered, WFS realigned

Looking more into the MC, it appears that no spot centering was done after the power attenuation optics were removed (see elog 8142).  Since Manasa had changed the zig-zag steering after putting in the attenuation optics (elog 7843) the pointing was not correct for the nominal MC.  This is (likely) why Yuta and Manasa found some significant decentering.  If Manasa's tweaks when preparing for vent were primarily in yaw, then this is most definitely what happened.  A note, this is why we should change to inserting the attenuation optics before the PMC, but even so, one should adjust the angle of the PBS, NOT the zig zag optics, to get the input pointing back to the same place.  This is also why it is useful to ensure the attenuation optics do not block the PSL pointing QPD pickoff, so it is easier to adjust the PBS to get back to the original pointing.

In any case, I touched the last zig-zag mirror in yaw today (the top of the knob was moved away from me) to recenter the spots.


With the MC unlocked, I centered the WFS.  Now the MC is back to its normal working condition....WFS are on, autolocker is on, reflected DC power is low, etc., etc.

  8268   Mon Mar 11 14:10:05 2013 JenneUpdateEnvironmentMC suspensions moved by this morning's earthquakes

None of the suspensions All suspensions were tripped (edited by Manasa; see elog 8271) by this morning's earthquakes, but the MC suspensions are in a different place than they were a day ago.  The big symptom here is that the MCWFS are pulling the mode cleaner slightly out of alignment.  When it first locks, the reflected light is ~0.5, but when the WFS are engaged it goes up to ~0.8.  I'm going to put the MC optics back where they were (according to SUSpit and SUSyaw), and tweak up the MC from there. Probably other optics are affected, but I was going to work on continuing to center the beam on the Yarm optics, so I'll deal with the rest of the IFO in a minute.

Note re: lower plot - the mxstream was down on c1sus and c1ioo, so no fast channels on those computers were recorded for almost a day.  (The plot is one day 4 days long).  I was going to plot the seismic blrms along with the suspension pointing values, but there's no data saved, so there's no point.  Jamie tells me he thinks this spontaneous loss of the mxstream is fixed in the next RCG upgrade, and that we can talk about upgrading the RCG after the LSC meeting, so this data loss is no longer an issue.



EDIT:  Plot with 4 days of trend, rather than just 1.  The MC alignment (as measured by MC refl) has been very bad for several days.  I'm going to move the suspensions back to their last good place.  Also, Manasa realigned the MC after the EQ, so I don't actually know where the suspensions got kicked to this morning.

  8267   Mon Mar 11 12:29:25 2013 ManasaUpdateAlignmentInput beam drift - weekend trend

I centered ipang and ippos on the QPDs (using only the steering mirrors) and wanted to see the drift over the weekend.

1. IPANG has drifted (QPD sum changed from -6 to -2.5); but it is still on the QPD.
2. IPPOS does not show any drift.
3. In the plot: The jump in IPANG on the left occured when I centered the beam to the QPD and that on the right is from the 4.7 earthquake and its aftershocks this morning.

Follow-up questions
1. Do we need to worry about this drift?
2. Which of the two TTs is resposible for the drift?
3. Do the TTs tend to drift in the same direction everytime?

P.S. The TTs were not touched to center on IPANG and IPPOS. The last time they were touched was nearly 6 hours before the centering. So the question of any immediate hysteresis is ruled out.


  8266   Mon Mar 11 10:20:36 2013 Max HortonSummaryComputersAttempted Smart UPS 2200 Battery Replacement

Attempted Battery Replacement on Backup Power Supply in the Control Room:

I tried to replace the batteries in the Smart UPS 2200 with new batteries purchased by Steve.  However, the power port wasn't compatible with the batteries.  The battery cable's plug was too tall to fit properly into the Smart UPS port.  New batteries must be acquired.  Steve has pictures of the original battery (gray) and the new battery (blue) plugs, which look quite different (even though the company said the battery would fit).

The Correct battery connector is GRAY : APC RBC55

Attachment 1: upsB.jpg
Attachment 2: upsBa.jpg
  8265   Sun Mar 10 13:29:29 2013 KojiHowToIOOHow to calculate the accumulated round-trip Gouy phase

How to calculate the accumulated round-trip Gouy phase (and namely the transverse mode spacing) of a general cavity
only from the round-trip ABCD matrix


  8264   Sat Mar 9 19:29:27 2013 KojiUpdatePSLModulation depth

Last night I measured the modulation depth of the MC incident beam.


The beam is taken from one of the  PO beam at the wedge plate before the IMC.
After removing the knife edge to dump this beam, the beam is sent to the west side
of the PSL table and put into the OSA cavity.
[The beam dump was returned after the measurement.]

I had some confusion and after all I use the OSA labeled as AS OSA rather than the one on the PSL table.
[The AS OSA was returned to the AP table.]

The transmission was detected by PDA255 and filtered by ITHACO 1201 preamp with G=10, no HPF, 30kHz LPF.
It was confirmed that the peak amplitudes are not reduced by the LPF filter. The resulting time series
was recorded by an oscilloscope.

Three measurements have been taken. The 11MHz peaks are offset by the carrier peak. They appropriately
removed. The ratio of the sideband and carrier peaks is converted to the modulation depth using the following formula.

P_sb / P_ca = [J1(m)/J0(m)]^2


The modulation depth for the 11MHz: 0.190 +/- 0.003

The modulation depth for the 55MHz: 0.2564 +/- 0.0003

The three scans showed very similar numbers. That's why the statistical error is such small.
I don't think the systematic error is not such good.

This number is much different form the previous meaurement by Mirko.

http://nodus.ligo.caltech.edu:8080/40m/5519 m=0.14 (11MHz) & 0.17 (55MHz)
but the measured voltages and the modulatio depths are inconsistent.

http://nodus.ligo.caltech.edu:8080/40m/5462 m=0.17 (11MHz) & 0.19 (55MHz)

Probably the modulation depths should be checked by the IMC again.
However, it is certain that the 55MHz modulation exists, and even larger than the 11MHz one.

The next is to confirm that the modulation frequency is matched with the IMC FSR.
It is to make sure that the modulation is transmitted to the main IFO without attenuation.

Attachment 1: mod_depth.pdf
  8263   Fri Mar 8 21:00:05 2013 ManasaUpdatePSLPMC fixed



1. Filter module (FM1) on PRCL and MICH show significant delay while enabling and disabling.

2. I tried to fix PMC alignment (PMC trans was 0.76). I was not able to get PMC trans more than 0.79.
PMC has been this way since yesterday.

3. MICH is still bright when locked (ASDC_OUT reads 0.08 for dark and 2.0 for bright). We suspect it is because of the AS55_I error offset that persists even after running LSCoffsets script.

4. PRMI shows some dither at 3Hz when locked.

 [Koji, Manasa]

PMC is fixed with 0.84 in transmission. It was misaligned in pitch (fixing this increased PMC_trans to 0.822 from 0.773) and Koji also touched the wave plate and polarizer (changed PMC_trans to 0.845).

  8262   Fri Mar 8 20:51:00 2013 ManasaUpdateAlignmentInput beam drift - investigation **IMPORTANT**

Checking the drift in input pointing (TT2 is the main suspect)

I have centered IPPOS and the 2/3 part of IPANG that comes out of vacuum to the QPDs to see the drift in input pointing over the weekend or atleast overnight.

If anybody would be working with the IFO alignment over the weekend, do so only after recording the drift in IPANG and IPPOS or if you will be working later tonight, center them ion the QPDs before leaving.

  8261   Fri Mar 8 16:05:56 2013 yutaBureaucracyGeneralaction items for PRMI / ALS-FPMI

We should focus our work both on PRMI and ALS-FPMI (elog #8250).


    - Check out ASS and A2L working -JENNE (ALS done, ASS on going elog #8229)
    - Are all whitening filters for PDs toggling correctly? -JENNE, JAMIE (POX11 was OK, elog #8246)

PRMI locking:
    - Adjust I/Q rotation angles for error signals -JENNE, YUTA (coarsely done elog #8212)
    - Adjust filters -JENNE, YUTA (coarsely done elog #8212)
    - Coil balancing for BS (and ITMs/ETMs) -YUTA (done elog #8182)
    - Calculate sensing matrix for PRMI and convert them into physical units -JENNE, JAMIE
    - Measure sensing matrix for PRMI -JENNE, MANASA
    - Measure 55 MHz modulation depth -KOJI

PRC characterization in PRMI:

    - Measure PR2 loss from flipping -MANASA (on going elog #8063)
    - Measure mode matching ratio -JENNE, YUTA
    - Measure finesse, PR gain -JENNE, YUTA (done elog #8212)
    - Calibrate PRM and/or ITM oplevs -MANASA, YUTA (done elog #8221)
    - Measure g-factor by tilting PRM or ITMs -JAMIE, YUTA (coarsely done elog #8235, use other methods to check)
    - Simulate intra-cavity power dependance on PRM tilt -JAMIE (see elog #8235)
    - Calculate expected finesse, PR gain -JENNE
    - Mode match and align aux laser from POY -ANNALISA (on going elog #8257)

    - Prepare for installation of new end tables on next vent -MANASA
    - Install green DC PDs and cameras on PSL table -JENNE, MANASA
    - Make ALS handing off to DARM/CARM LSC script -JENNE, YUTA
    - Demonstrate FPMI using ALS -JENNE, YUTA
    - Phase tracker characterization -YUTA, KOJI (bad whitening elog #8214)
    - better beatbox with whitening filters -JAMIE, KOJI

    - Update optical layout CAD after PR2 flipping -MANASA
    - IMC REFL demod phase rotation -EVAN, ANNALISA (done elog #8185)
    - Look into PMC drift -JENNE, MANASA
    - Measure RFAM contribution to error signals -YUTA
    - Look into TT2 drift -JENNE, MANASA

  8260   Fri Mar 8 16:02:52 2013 JenneUpdateAlignmentGetting closer to beam centering on Yarm

I'm working on getting the input beam centered on the Yarm optics.  To do this, I measured the spot positions, move the tip tilts, realign the cavity, then measure the new spot positions.  While doing this, I am also moving the BS and Xarm optics to keep the Xarm aligned, so that I don't have to do hard beam-finding later.

Here is the plot of spot measurements today.  The last measurement was taken with no moving, or realigning, just several hours later after speaking with our Indian visitors.  I'm closer than I was, but there is more work to do.


  8259   Fri Mar 8 15:27:42 2013 yutaUpdateGreen LockingPSL green shutter installed

[Manasa, Yuta]

Mechanical shutter for PSL green is installed right in front of PSL doubling crystal.
This is for blocking PSL green when we want to measure the power of green beam from the arms.

The shutter was previously sitting on AS table un-used. Channel name to control this shutter was C1:AUX-SPS_Shutter. This should be renamed as C1:AUX-GREEN_PSL_Shutter.

  We are going to restore both arm green in parallel to PRMI work.

  - Coarsely align IR input pointing and arms using A2L
  - Align X green
  - Install green DC PDs and cameras on PSL table

  8258   Fri Mar 8 13:42:35 2013 JenneUpdateABSLBS installed on ITMY table

Re:  POY beam reduction.

We are able to lock the Yarm with the beam / gain as it is.  I had thought we might need to increase the DC gain in the whitening board by a factor of 2, but so far it's fine.

  8257   Fri Mar 8 12:57:57 2013 AnnalisaUpdateABSLBS installed on ITMY table

 Sendhil and I installed the S polarized BS on the ITMY table to steer the NPRO beam through the AR wedge and align it to the POY beam. 

We took a shutter from the BSPRM table (which was not used) and a beam dump from the AS table (which was used by the auxiliary laser already removed and installed on the ITMY).

To do: do better alignment of the NPRO beam, maybe installing some iris after the BS and before the AS wedge, phase lock the two beams. 

  8256   Fri Mar 8 03:07:19 2013 yutaUpdateLSCcalibrated PRM-ITMY length spectra

Measured free swing PRM-ITMY length was 230 nm RMS.
MI differential length was 85 nm RMS(elog #8248). This tells you that PR2, PR3 are not so noisy compared with usual suspensions.

Openloop transfer function:
  OLTF of PRM-ITMY cavity lock using REFL55_Q_ERR as error signal and PRM as actuator is below.
  UGF ~ 120 Hz, phase margin ~ 50 deg.
  Somehow, phase delay was 460 usec, which is smaller than the empirical value 550 usec.

PRM-ITMY length spectra:
  Below. Calibration was done using calibrated REFL55_Q_ERR and actuator response(elog #8255).

  8255   Fri Mar 8 02:17:04 2013 yutaUpdateLSCcalibration of PRM actuator

[Manasa, Yuta]

We measured AC response of PRM actuator using PRM-ITMY cavity.
Result is

PRM:  (19.6 +/- 0.3) x 10^{-9} (Hz/f)^2 m/counts

It is almost the same as in 2011 (elog #5583). We took the same procedure as what Kiwamu did.

What we did:
  1. Aligned PRMI in usual procedure, mis-aligned ITMX and locked PRM-ITMY cavity using REFL55_Q_ERR. POP DC was about 18 when locked.

  2. Made UGF of PRM-ITMY cavity lock at 10 Hz and introduced elliptic LPF at 50 Hz(OLTF below).

  3. Measured transfer function from C1:LSC_ITMY_EXC to C1:LSC_REFL55_Q_ERR. Dividing this by ITMY actuator response(measured in elog #8242) gives calibration of REFL55_Q.

  4. Measured transfer function from C1:LSC_PRM_EXC to C1:LSC_REFL55_Q_ERR to calibrate PRM actuator.

  Calibration factor for REFL55_Q for PRM-ITMY cavity was (1.37 +/- 0.02) x 10^9 counts/m (plot below). Error is mainly from statistical error of the average.

  Measured AC response (50-200 Hz) of PRM is below.

  - Measure free-run length spectrum of PRM-ITMY cavity and compare with MICH free-run.

  8254   Thu Mar 7 18:48:43 2013 yutaUpdateComputer Scripts / Programsreleasing my secret scripts

I released/updated my secret scripts to real scripts directory.
I checked they run correctly (but maybe not working correctly).

  in ./scripts/general/burtlookup.py

  It returns a value of a specified channel in the past using burt snapshots.
  Help is available.

  in ./scripts/ALS/GRtoggler.py

  Toggles green shutter until it locks TEM00.
  Help is available. Threshold setting is critical.

  in ./scripts/MC/MCbeeper.py

  Beeps when MC is unlocked.

  in ./scripts/pylibs/yutalib.py

  Python library for data loading, saving and plotting.
  I think it's well commented.

  in ./scripts/pylibs/pyezcalib.py

  Python library for ezca stuff.
  It has functions for recording and resetting default channel values in case of interrupt.

  Python scripts for PRC modescan. Not well commented. Not organized.
  See elog #8012

  Python and shell scripts for alignment work. Not well commented.
  See elog #8164

  Python scripts for oplev calibration. Not well commented.
  See elog #8221

  Python scripts for g-factor measurement. Not well commented.
  See elog #8230

  Python scripts for calibrating actuators. Not well commented.
  See elog #8242

  8253   Thu Mar 7 18:41:03 2013 JenneUpdateElectronicsPOX whitening was fine all along

Here are the transfer functions that we took back in 2011 (see elog 4915 and replies) for POX:



The table of all whitening filter zpk values is on the wiki: https://wiki-40m.ligo.caltech.edu/Electronics/WhiteningFilters

  8252   Thu Mar 7 18:12:03 2013 yutaUpdateAlignmentInput beam drift ~ 0.1 mrad/h in pitch

[Jenne, Manasa, Yuta]

We temporarily centered the beam on IPANG to see input pointing drift. From eyeball, drift was ~ 0.1 mrad/h in pitch.

What we did:

  1. Aligned TT1/TT2 and aligned input pointing to Yarm.

  2. Tweaked TT2 in pitch to center the beam on the first steering mirror of IPANG path. We still saw Yarm flash in higher order modes at this point. Before tweaking, the beam was hitting at the top edge.

  3. Centered the beam on IPANG QPD.

  4. Moved IPPOS first steering mirror because IPPOS beam was not on the mirror (off in yaw, on mirror edge). Also, IPPOS beam was coming out clipped in yaw.

  5. Centered the beam on IPPOS QPD. We put lens in the path to focus the beam on the QPD.

  6. Left input pointing untouched for 4 hours.

  7. Restored TT2 again. We tried to align Y arm with IPANG available, but it was not possible without touching TRY path and AS was also clipped.

  Below is the trend of IPANG sum, X, and Y. IPANG Y (IBQPD_Y) drifted by ~0.8 counts in 4 hours. IPANG is not calibrated yet, but Jenne used her eyeball to measure beam position shift on IPANG steering mirror. It shifted by ~2 mm. This means, input pointing drifts ~0.1 mrad/h in pitch.

  Compared with yaw, pitch drift is quite large considering beam size at ETMY(~5 mm). We can monitor input pointing drift in weekends get longer trend.

  - IPANG and IPPOS are both changed from the state before pumping.

  8251   Thu Mar 7 16:55:28 2013 KojiUpdateLockingErudite discussion on PRMI locking

PRMI for the sidebands may have different situation. Investigate our wiki to find our the simulation result.

Also I'm not confident how much is the modulation depth at 55MHz is.

  8250   Thu Mar 7 12:39:12 2013 JenneUpdateLockingErudite discussion on PRMI locking

[Rana, Jenne, Yuta] (late last night)

After some trouble getting the PRMI to lock with REFL55 I&Q last night, we began to think about the size of signals everywhere, and the coupling of the sidebands in the different cavity configurations.  We have determined that it is possible that the Q phase signal is too small everywhere, so the PRMI will never be easy to lock. The Q phase will be smaller than iLIGO equivalents since the modulation frequencies are lower, and we have a small Schnupp asymmetry. The calculations of signals at each port were all done for the DRMI case, where sidebands get recycled more, so signals get larger.  If locking the PRMI is "hopeless" due to very small signals, we should stop trying, move on with other things, and come back to the corner when we have the DRMI ready. In order to figure out if it is reasonable to keep working on the PRMI, we must calculate the size of all of our signals at each port, and convert them into real units (if we expect a 1mVpp signal at REFL11Q, we're not going to successfully lock MICH with that).

So, we should:

* Calculate sideband signals at AS and REFL, for 11 and 55 MHz, for the PRMI case.

* Convert those signals into physical units (Watts -> Amps -> Volts).

* In parallel, work on dual arm ALS, and FPMI locking.

   * Try using ALS CARM for frequency stabilization.

   * Hand off from ALS CARM and DARM to PSL.

* To do ALS-FPMI, we should:

     * Use A2L to center the IR spots on all arm cavity mirrors.

     * Align green beams to the arms.

    * For each arm, determine which frequency (arm green or PSL green) is higher.

          * Lock the arm in green, align Beat PD. 

          * Push ETM, watch beat in the phase tracker.

          * Repeat for other arm.

     * Use ALS input matrix to construct CARM and DARM signals.

         * Check by shaking ALS-CARM, watch both X and Y beat signals - if they move in the same direction, we were right, but if they move in opposite directions we have flipped CARM and DARM.

    * Send the ALS-CARM signal to MC2, or the analog common mode board.

  8249   Thu Mar 7 11:43:15 2013 JenneUpdateElectronicsPOX and POY whitening DC gain left low

Manasa and Jan were having trouble locking the Yarm, and asked me to take a look at it.  After a good long time of trying to figure out what was going on, it finally occurred to me that I did not turn the DC gain on POX and POY back to the nominal 36dB.  As soon as I did that, both arms acquired lock.  Ooops.

  8248   Thu Mar 7 01:43:35 2013 yutaUpdateLSCcalibrated MI differential length spectra

Free swing MI differential length is 86 nm RMS and residual length when locked is 0.045 nm RMS(in-loop).
Looks very quiet. Comparison with PRMI is the next step.

Openloop transfer function:
  OLTF of simple MI lock using AS55_Q_ERR as error signal and ITMs as actuators is below.
  UGF ~ 90 Hz, phase margin ~ 40deg
  I added 16 Hz resonant gain to suppress bounce mode.

MI differential length spectra:
  Below. Calibration was done using calibrated AS55_Q_ERR and actuator response(elog #8242)

  Expected free swing is calculated using

x_free = (1+G)/G * A * fb

where G is openloop transfer function, A is actuator response, fb is feedback signal(C1:LSC_ITMX/Y_IN1) spectrum. I used A as simple pendulum with resonant frequency at 1 Hz, Q = 5. Since free swing RMS is dominated by this resonance, RMS depends on this Q assumption.

  8247   Wed Mar 6 22:11:19 2013 KojiUpdateElectronicsPOX whitening was fine all along

At the time you, den and I worked together, we could not lock the X-arm on TEM00 with the FM1s of the POX11 on.
We could lock the arm only on the higher order mode but he gain was low. Once we turned off the FM1s, we immediately
locked the cavity on TEM00.

Don't you have the direct measurement of the TF with FM1 on and off?

  8246   Wed Mar 6 21:58:39 2013 JenneUpdateElectronicsPOX whitening was fine all along

After my investigations this afternoon (with help from Sendhil and Shivaraj), I do not find any problems with the POX whitening switching.

Earlier this afternoon / evening I was misleading myself into thinking that either the switching component (ADG333ABR) was broken, or that the whitening op amps (LT1124CS8) were broken on the POX I&Q and POY I&Q channels.  I had not realized until Jamie mentioned the possibility, that some of the DC gain stages were on for POX and POY.  POX and POY (I&Q for both) all had +36dB of gain, so when I was injecting my 60Hz sine wave into those channels, the whitening opamps were already saturated, which is why it didn't look like I was getting any gain.  When I set them all to 0dB (which is what AS11 and REFL11, the other 2 PDs using that whitening board, were set to), all 8 channels behaved the same.

The shaped whitening (which is either bypassed or not, depending on the condition of the software "unwhite" switch) is 2 filters in series, each with a zero at 15Hz, and a pole at 150Hz, with DC gain of 0dB.  For a 60Hz sine wave, this gives a factor of ~4 from each stage.  After setting all of the whitening gains to 0dB, I was able to see on all 8 channels of the board an input sine wave, a larger (by 4-ish) sine wave, and then a larger (by 4ish again) sine.  When I looked at the output of the switch of all 8 channels, the signal was either the same as the input amplitude, or the same as after the 2nd whitening stage, depending on the "unwhite" filters.

Before looking at actual signals, Sendhil and I also had checked to see that indeed, the board was receiving the digital signal input to the switch chip, requesting switching based on the state of the "unwhite" filters.

I looked through the elogs, and the only "symptoms" I find are from an IFO check-up session that Koji, Den and I had back in May, where we declared in the elog that POX whitening may or may not be switching.  See elog 6595.  We didn't mention what the actual symptoms we saw were, so unless Koji or Den remember something that I don't, I cannot confirm that we are no longer seeing those symptoms.  However, based on the number of "?" after "POX whitening not toggling the analog whitening", I don't think that we were totally sure that something was wrong in the first place.

Anyhow, the whitening board in the LSC rack labeled "WF1", serving AS11, REFL11, POX11 and POY11 has had a thorough checkup, and I give it a clean bill of health.

  8245   Wed Mar 6 20:21:34 2013 JamieUpdateGeneralBeatbox pulled from rack

I pulled the beatbox from the 1X2 rack so that I could try to hack in some output whitening filters.  These are shamefully absent because of my mis-manufacturing of the power on the board.

Right now we're just using the MON output.  The MON output buffer (U10) is the only chip in the output section that's stuffed:


The power problem is that all the AD829s were drawn with their power lines reversed.  We fixed this by flipping the +15 and -15 power planes and not stuffing the differential output drivers (AD8672).

It's possible to hack in some resistors/capacitors around U10 to get us some filtering there.  It's also possible to just stuff U9, which is where the whitening is supposed to be, then just jump it's output over to the MON output jack.  That might be the cleanest solution, with the least amount of hacking on the board.

In any event, we really need to make a v2 of these boards ASAP.  Before we do that, though, we need to figure out what we're going to do with the "disco comparator" stage back near the RF input.  (There are also a bunch of other improvements that will be incorporated into v2).

  8244   Wed Mar 6 18:51:07 2013 AnnalisaUpdateAlignmentAuxiliary laser installed for FSR and TMS measurement of the PRC

We want to measure the g-factor of the PRC using the beat note of the main laser with an auxiliary NPRO laser.

We are going to phase lock the NPRO to the main laser (taking it from POY) and then we will inject the NPRO  through the AS edge of the ITMY.

Today Sendhil and I installed the auxiliary laser on the ITMY table moving it from the AS table.

We also installed the beam steering optics, except the BS which will launch the beam through the AR edge of the ITMY.

To do: install the BS, take the POY beam and mix it with the auxiliary laser on a photodiode to phase lock the two lasers, do better calculations for the mode matching optics to be used for the auxiliary laser beam.

Attachment 1: IMG_3-6-13.JPG
  8243   Wed Mar 6 18:27:24 2013 JamieUpdateGeneralnow recording input TT channels to frames, but why no autoburt?

I spent some time trying to figure out how to get a record of the pointing of the input pointing tip-tilt (TT) channels.


Currently the TT pointing is done via the offset in the PIT/YAW filter banks, ie. C1:IOO-TT1_PIT_OFFSET, which is an EPICS record.  I added these channels to the C0EDCU.ini, which (I'm pretty sure) specifies which EPICS channels are recorded to frames.

controls@pianosa:~ 0$ grep C1:IOO-TT /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini 
controls@pianosa:~ 0$ 

I then confirmed that the data is being recorded:

controls@pianosa:~ 0$ FrChannels /frames/full/10466/C-R-1046657424-16.gwf | grep TT
controls@pianosa:~ 0$ 


The EPICS records for these channels *should* be recorded by autoburt, but Yuta noticed they were not:

controls@pianosa:~ 0$ grep -R C1:IOO-TT1_PIT_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2013/Mar/6/
controls@pianosa:~ 1$

The autoburt log seems to indicate some sort of connection problem:

controls@pianosa:! 130$ grep C1:IOO-TT1_PIT_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/logs/c1assepics.log
pv >C1:IOO-TT1_PIT_OFFSET< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.HSV< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.LSV< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.HIGH< nreq=-1
pv >C1:IOO-TT1_PIT_OFFSET.LOW< nreq=-1
C1:IOO-TT1_PIT_OFFSET ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.HSV ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.LSV ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.HIGH ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET.LOW ... ca_search_and_connect() ... OK
C1:IOO-TT1_PIT_OFFSET ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.HSV ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.LSV ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.HIGH ... not connected so no ca_array_get_callback()
C1:IOO-TT1_PIT_OFFSET.LOW ... not connected so no ca_array_get_callback()
controls@pianosa:~ 0$ 

This is in contrast to successfully recorded channels:

controls@pianosa:~ 0$ grep C1:LSC-DARM_OFFSET /opt/rtcds/caltech/c1/burt/autoburt/logs/c1lscepics.log
pv >C1:LSC-DARM_OFFSET< nreq=-1
pv >C1:LSC-DARM_OFFSET.HSV< nreq=-1
pv >C1:LSC-DARM_OFFSET.LSV< nreq=-1
pv >C1:LSC-DARM_OFFSET.HIGH< nreq=-1
pv >C1:LSC-DARM_OFFSET.LOW< nreq=-1
C1:LSC-DARM_OFFSET ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.HSV ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.LSV ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.HIGH ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET.LOW ... ca_search_and_connect() ... OK
C1:LSC-DARM_OFFSET ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.HSV ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.LSV ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.HIGH ... ca_array_get_callback() nreq 1 ... OK
C1:LSC-DARM_OFFSET.LOW ... ca_array_get_callback() nreq 1 ... OK
controls@pianosa:~ 0$ 

In fact all the records in the c1assepics log are showing the same "not connected so no ca_array_get_callback()" error.  I don't know what the issue is.  I have no problem reading the values from the command line, with e.g. ezcaread.  So I'm perplexed.

If anyone has any idea why the c1ass EPICS records would fail to autoburt, let me know.

  8242   Wed Mar 6 18:14:33 2013 ManasaSummaryLSCCalibration of BS, ITMX and ITMY actuators

[Yuta, Manasa]

Measured actuator response between 50Hz and 200 Hz in (m/counts).

BS     = (20.7 +/- 0.1)    x 10 -9 / f2

ITMX = (4.70 +/- 0.02) 
x 10 -9/ f2

ITMY = (4.66 +/- 0.02)
x 10 -9/ f2

Actuator response differs by 30% for all the 3 mirrors from the previous measurements made by Kiwamu in 2011.

Calibration of BS, ITMX and ITMY actuators

We calibrated the actuators using the same technique as in Kiwamu's elog.

A) Measure MICH error

1. Locked Y-arm and X-arm looking at TRY and TRX.
2. Misaligned ETMs
3. Measured  MICH error using ASDC and AS55_Q err (MICH_OFFSET = 20 - to compensate for offset in AS_Qerr which exists even after resetting LSC offsets)


B) Open loop transfer function for MICH control

1. Measured the transfer function between C1:LSC-MICH_IN1 and C1:LSC-MICH_IN2 by exciting on  C1:LSC-MICH_EXC.
MICH filter modules used for measurements(0:1 , 2000:1, ELP50). ELP50 used so that actuation signals above 50 Hz are not suppressed.


C) Calibration of BS/ ITMX/ ITMY actuators

1. Measured transfer function between actuation channels on BS/ ITMX/ ITMY and C1:LSC-AS55_Q_ERR.


  8241   Wed Mar 6 16:14:27 2013 SteveUpdateSAFETYsafety training

Chloe Ling, Max Horton and Annalisa Allocca have received basic 40m specific safety training.

Attachment 1: IMG_500.jpg
  8240   Wed Mar 6 11:33:09 2013 steveUpdateSAFETYsafety audit 2013


                                                 Recommended correction list:

1,  refill- upgrade first aid boxes

2,  maintain 18" ceiling to bookshelf clearance so the ceiling fire sprinklers are not blocked: room 101

3,  label chilled water supply & return valves in IFO room

4,  calibrate bake room hoods annually

5,  update safety sign at fenced storage


              40m still to do list:

1,   clean and measure all safety glasses

2,   annual crane inspection is scheduled for 8am March 19, 1013

3,   make PSL encloser shelf earthquake proof


Do you see something that is not safe? Add it to this list please.



Attachment 1: IMG_0010.JPG
  8239   Wed Mar 6 09:44:29 2013 KojiUpdateLSCPRMI locking for g-factor measurement

- What about normalizing POPDC to indicate the carrier recycling gain?

- When you align the PMC, confirm FSS SLOW DC is around zero. Some region of the slow thermal actuation makes the laser source emit at multiple frequencies. In the case, the cavity visibility get worse.

- Do you guys think we can determine if the TT is longitudinally quiet enough? Is there any comparison between the simple Michelson and the PRC motion in m/rtHz?

  8238   Wed Mar 6 08:40:03 2013 SteveUpdateVACfirst scan of this pumpdown

 Pumpdown 75 - Maglev - day 12

Precondition: 66 days at atm, installed TIP-TILTs with coils that  replaced PZT-Jena input steering


Attachment 1: pd75m12d.png
Attachment 2: pd75mRGA12d.png
  8237   Wed Mar 6 02:46:20 2013 ManasaUpdateLSCPRMI locking for g-factor measurement

 [Yuta, Manasa]

PRMI alignment procedure for carrier locking has been kept the same except that a couple of issues that have persisted are now taken care of.

We were able to keep PRMI locked for over a minute (POPDC measures 2200) .

1. Trigger levels to MICH and PRCL for PRMI locking have been changed
Whenever we enabled LSC controls to lock PRMI, ITMY moves haphazard if PRM is not aligned. This is because of the low trigger levels of POPDC which keeps MICH triggered all the time while we align PRM. Increasing POPDC trigger (Upper level : 1000 and Lower level:20) for both MICH and PRCL solved this problem and resulted in a more stable ITMY. Also this has stabilized locking greatly if the alignment is fair enough.

Quoting Yuta's elog "  I found C1:SUS-ITMY_LSC_GAIN is somehow set to be 2.895 recently. I think this should be 1.0. Maybe this is why we had actuation imbalance in ITMs(elog #8212)."
This has been reset to 1.0 and it has not affected PRMI locking.


1. Filter module (FM1) on PRCL and MICH show significant delay while enabling and disabling.

2. I tried to fix PMC alignment (PMC trans was 0.76). I was not able to get PMC trans more than 0.79.
PMC has been this way since yesterday.

3. MICH is still bright when locked (ASDC_OUT reads 0.08 for dark and 2.0 for bright). We suspect it is because of the AS55_I error offset that persists even after running LSCoffsets script.

4. PRMI shows some dither at 3Hz when locked.

  8236   Tue Mar 5 23:37:11 2013 yutaUpdateSUSPRM angular motion spectra

I measured PRM angular motion spectra (in daytime today).
PRM angular motion is ~ 10 urad in RMS when undamped and ~1 urad in RMS when damped.
If PR2/PR3 angular motions are something like this, and their motion are not enhanced when PRC is locked, measured g-factor of PRC looks OK. But considering the error we have, maybe we are not OK yet. We need calculation.


  8235   Tue Mar 5 23:00:08 2013 yutaUpdateLSCYarm and PRC g-factor from misalignment measurement

I fitted intra-cavity power dependance on mirror misalignment plot with parabola to get the g-factor.

  Y arm (tangential) g = 0.44 +0.01 -0.01  (measured value before was 0.3765 +/- 0.003 elog #6938)
  PRC (sagittal)       g = 0.97 +0.01 -0.04 (expected value is 0.939 elog #8068)
  PRC (tangential)   g = 0.96 +0.02 -0.05 (expected value is 0.966 elog #8068)

Error bars are just statistical errors from the fitting. Estimated systematic error is ~0.04 (or more).
Here, I assumed PR2/PR3 to be flat to make the calculation simple. I assumed PRC to be curved PRM - flat ITM cavity, and Y arm to be curved ETMY - flat ITMY cavity.

g-factor calculation:
  Intra-cavity power decrease can be written as

dP/P = (dx/w0)**2 + (dt/a0)**2

where dx and dt are translation and tilt of the beam axis introduced by mirror misalignment. w0 is waist size and a0 is divergence angle (= lamb/(pi*w0)).

  When considering a flat-curved cavity with cavity length L, dx and dt can be expressed as;

(dx)    1  ( L*g     L ) (a2)
(  ) = --- (           )*(  )
(dt)   1-g ( -(1-g)  0 ) (a1)

using misalignments of mirrors(a1,a2). Here, mirror1 is curved, and mirror2 is flat. See Kakeru document /users/OLD/kakeru/oplev_calibration/oplev.pdf for derivation.

  So, power decrease by flat mirror misalignment can be expressed as

dP/P = pi*L/lamb * g/(1-g)/sqrt(g*(1-g)) * a2**2

  For curved mirror is

dP/P = pi*L/lamb * 1/(1-g)/sqrt(g*(1-g)) * a1**2

  We can derive g-factor by measuring dP dependance on a1/a2.

  My script lives in /opt/rtcds/caltech/c1/scripts/dither/gfactormeasurement/plotgfactor.py.
  It least fitts data with parabola (scipy.optimize.leastsq) and gets g-factor value from bisection (scipy.optimize.bisect).

  Below are the plots of fitted curves.


Systematic effect:
  [oplev calibration] We noticed QPD rotation when calibration oplevs (elog #8232). ~5 deg of rotation makes 10% of systematic error to the oplev calibration and this introduces ~0.04 of error to g-factor values. This

  [oplev linear range] Oplev linear range is ~100 urad, so this is OK.

  [assumption of flat PR2/PR3] Result here doesn't tell you g-factor of PRM itself, but some "effective g-factor" of PRM/PR2/PR3 combination. We can compare with FINESSE result.

  [intra-cavity power drift] If there's significant intra-cavity power drift during the measurement, if effects parabola fitting. We can make this affect small by sweeping the mirror alignment in both direction and take average.

By the way:
  I kept getting PRC g-factor of something like 0.999999 because I had power normalization mistake in my calculation. My script worked for Yarm because TRY is already normalized.
  Also, I was multiplying the oplev calibration factor wrong last night (see elog #8230).

  - Compare with FINESSE result.
  - Is this g-factor enough? Is this presicion enough? Calculate from mirror angluar motion.
  - More stable lock of PRMI.
  - Try dithering method to measure g-factor to check consistency and also to study systematic effect.

  8234   Tue Mar 5 18:36:27 2013 JenneUpdateLSCLSC whitening triggering started

More effort at debugging the LSC whitening. 

Today I tried moving things over to the c1tst model, which runs on the y-end computer, but I crashed c1iscey.  I rebuilt the TST model to a known good state, then cycled the power on c1iscey, and the computer came back up fine. 

I have now backed off and am just writing the code inside a little wrapper script, so that I can just compile and test the code completely independent from the realtime system.  Then once I get all the bugs out, I can try again installing on the actual system.

Still, there are no changes to the functionality of the c1lsc model.  There will not be until I get the c-code for matrix parsing debugged.

The logic, in non-diagram form (I'll make a diagram, but so you can read without waiting):

*** C-code

* Inputs is an array of degree of freedom triggers, the same schmidt triggers used for main LSC locking. (This means it also uses the same thresholds as main triggers.  Side note, now that the WAIT command (see below) works, I want to change the filter module triggers to use the same main trigger, and then just wait a specified time before turning on.)

* Parse the LSC input matrix (internal to the c-code).

     * This tells you which photodiode is being used to control which degree of freedom.

* Multiply rows of the LSC input matrix by the degree of freedom triggers (the same trigger as the main LSC triggers, which is a schmidt trigger).

     * This gives a matrix, where non-zero elements indicate that a photodiode is supposed to be used for a degree of freedom, AND that DoF has been triggered (is locked or has flashed).

* Sum along the columns of the matrix.

     * If a column has a non-zero element, that means that that PD quadrature is used, and has been triggered (by any DoF).

* Apply OR to I and Q quadratures of each PD. 

      * Since the phase rotation happens after whitening and dewhitening, if either I_ERR or Q_ERR is requested (used and triggered), we need to turn on the whitening for both channels.  I am hopeful that this doesn't cause problems for cases when we want to use both quadratures of a PD to control 2 degrees of freedom, but I haven't yet put much thought into it.  COMMENTS WELCOME on this point.

*  Output of c-block is array of PD triggers.  So if either AS11I or AS11Q is triggered, output a "1" for the first element, which corresponds to AS11, etc.

*** LSC model

* Give GoTo/From flag for each DoF trigger to the mux of inputs.

* Go through c-code

* Demux outputs into GoTo/From flags, one per PD (one flag for AS11, one for AS55, and one for ASDC...DC elements count separately, even though they're derived from the same physical PD).

* For each PD, trigger flag goes through WAIT c-code

   * This allows you to define a wait time, in seconds, with an EPICS variable. 

   * Starts counting the wait time as soon as it receives a "1".  Resets counter each time it receives a "0".

    * Output of wait function is ANDed with the current (non-delayed) trigger.

         * This allows for cavity to flash, but if it's not still locked after the wait time, don't actually flip any switches.

* Use delayed ANDed trigger to flip the FM1 switch on both the I and Q filterbank for that PD.

ELOG V3.1.3-