- We tried locking with the air conditioning switched off at the X-end

- TRX path is unaltered (IR still goes through the center of the harmonic separator.

[Koji, Manasa]

We looked at the MC modulation frequency on the spectrum analyzer and observed beat notes between MC modulation freq (29.5MHz) and modulation frequencies (11.06 MHz and 55.3MHz).

Beat notes were suppressed by changing the carrier frequency from 11.065910 MHz to 11.066147MHz. 

Detailed discussion and data will be posted in the next elog.

 All safety glasses were cleaned in soapy water by Bob. I measured their transmission at 1064 nm, 150 mW,  beam diameter 1.5 mm  They are in working order, no transmission.

 Inventory:

10 pieces of KG-5, fit over, from Laser Safety

 4 pieces of KG-5, std size, from Drever Lab, best visibility

 1 piece of KG-5 coated for visible, std size, from Kentek

15 pieces of green-plastic LOTG-YAG, fit over, from UVEX

 7 pieces of green-plastic B-D+S 137, std areo fit, from Sperian

 3 pieces of green-plastic, old Thorlab, fit over

 2 pieces of green-plastic, fit over, from Laservision

 8 pieces of braun- plastic, fit over, for green & IR protection, from UVEX & Thorlabs

Jamie has informed me of numpy's numpy.savetxt() method, which is exactly what I want for this situation (human-readable text storage of an array).  So, I will now be using:

      # outfile is the name of the .png graph.  data is the array with our desired data.
      numpy.savetxt(outfile + '.dat', data)

to save the data.  I can later retrieve it with numpy.loadtxt()

The two acrylic optical table enclosures were moved from the carpenter shop to CES. I need to order windows. The latest quotes from Laseroptik  are posted at the wiki / aux_optics page.

Things to do: order windows, draw and order window flange, install surgical tubing seals, buy and line enclosures with IR shield films.

We're still good with the IFO alignment after 7hours.

I found the green still locked in the same state as last night; but no IR (so the arms are stable and the TTs should definitely take the blame).

From last night's observation (elog about drift in TT1), I only moved TT1 in pitch and gained back locking in IR for both the arms

- 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.

[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.

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

..../scripts/MC/WFS/WFS_FilterBank_offsets

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. 

 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.

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.

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.

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.

[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.

[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

Notes
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.

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

Mystery
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).
 

~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.

[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.

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.")
      print_verbose(outfile)
      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
      outfile_mch.close()

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
  742.03433228],
             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:

INPUT:
a = [5]
a.append(a)
print a

OUTPUT:
[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().

Next:
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.

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.

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.

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

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.

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.

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

Observation
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.

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

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

T1300189

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

Method:

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

Measurement

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.

 [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).

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.

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

CDS:
    - 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)

ALS:
    - 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

Others:
    - 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

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.

[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.

Next:
  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

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.

 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. 

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).

[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.

Result:
  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.



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

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


burtlookup.py
  in ./scripts/general/burtlookup.py

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


GRtoggler.py
  in ./scripts/ALS/GRtoggler.py

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


MCbeeper.py
  in ./scripts/MC/MCbeeper.py

  Beeps when MC is unlocked.


yutalib.py
  in ./scripts/pylibs/yutalib.py

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


pyezcalib.py
  in ./scripts/pylibs/pyezcalib.py

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


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


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


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


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


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

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

[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.

Result:
  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.


Discussion:
  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.

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

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.

[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.

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.

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.

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?

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.

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).

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.

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

Frames

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 
[C1:IOO-TT1_PIT_OFFSET]
[C1:IOO-TT1_YAW_OFFSET]
[C1:IOO-TT2_PIT_OFFSET]
[C1:IOO-TT2_YAW_OFFSET]
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
C1:IOO-TT1_PIT_OFFSET 16
C1:IOO-TT1_YAW_OFFSET 16
C1:IOO-TT2_PIT_OFFSET 16
C1:IOO-TT2_YAW_OFFSET 16
controls@pianosa:~ 0$ 

BURT

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.

[Yuta, Manasa]

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

BS     = (20.7 +/- 0.1)    x 10 ^-9 / f²

ITMX = (4.70 +/- 0.02)  x 10 ^-9/ f²

ITMY = (4.66 +/- 0.02) x 10 ^-9/ f²

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.

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

                                                 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.