Here's the new end table layout, for the transmitted IR stuff.

Masha, Eric, Yaakov, Liz and Sasha received 40m specific basic safety training.

I aligned X arm so that the beam spot comes roughly on the center.

1. Use ITMX and ETMX (mainly ITMX) to make beam spot come on center of the optic using eyeball.

2. Use ETMX and BS to maximize TRX power (reached ~ 0.85)

3. Aligned green optics on X end. Transmission of X green measured at PSL table is now 255 uW and TEM00 has the most power.

It was not easy to increase X green transmission more because beam spot on green transmission PD is wiggly when X end table is opened. When closed, wiggliness is about the same for Y green and X green.
Turning off HEPA on the X end didin't helped, but there must be something bad in the X end table. If we couldn't figure out why, let's wait for PZTs to come for end tables.

Considering the laser power is different(X end 1 W, Y end 700 mW), X green transmission should reach ~400 uW. But I think we should go on to X beat search.

I placed green shutter for X end back for convenience. I put some spacers to adjust its height and avoid beam clipping.


[Steve, Yuta]

What causing wiggly X green transmission was the air flow from the air conditioner. When we turned it off, beam spot motion became quiet. Air flow from HEPA was not effecting much.

I've reinstalled the beatbox in the 1X2 rack.  This improved version has the X and Y arm channels stuffed, but just one of the DFD channels (fine) each.

I hooked up the beat PD signals for X and Y to the RF inputs, and used the following two delay lines:

• X: 140' light-colored cable on spool
• Y: 30m black cable

The following channel --> c1ioo ADC --> c1gcv model connections were made:

• X I  --> SR560 whitening --> ADC 22 -->  X fine I
• X Q --> SR560 whitening --> ADC 23 --> X fine Q
• Y I --> SR560 whitening --> ADC 24 --> Y fine I
• Y Q --> SR560 whitening --> ADC 25 --> Y fine Q

The connections to the course inputs on the ALS block were grounded.  I then recompiled, reinstalled, and restarted c1gcv.  Functioning fine so far.

[Yuta, Jenne]

We locked both arms using the ALS system simultaneously!  Hooray!

Video of spectrum analyzer during lock acquisition of both beats is attached.

Jamie is super awesome, since he fixed us up a beatbox speedy-quick.  Thanks Jamie!! 

 Details:

1:  Aligned PSL green optics

     1.1:  We added an amplifier of ~20dB after the X beat PD (more Xgreen power on the PSL table so the signal was ~3dB higher than Y, so required less amplification).  The ~24dB amplifier is still in place after the Y beat PD.  Both beat signals go to a splitter after their amplifiers.  One side of each splitter goes to one of the channels on the beatbox.  The other side of each splitter goes to a 3rd splitter, which we're using backwards to combine the 2 signals so we can see both peaks on the spectrum analyzer at the same time.

2:  Found both beat notes

     2.1:  Y beat was easy since we knew the temps that have been working for the past several days

     2.2:  X beat was more tricky - the last time it was locked was the end of February (elog 6342)

         2.2.1:  We found it by adjusting the PSL laser temp nearly the full range - DC Adjust slider was at 8.8V or so (Y beat was found with the slider at ~1.1V tonight)

          2.2.2:  We then walked the beat around to get the PSL temp back to "normal" by moving the PSL temp, then compensating with the Xend laser temp, keeping the beatnote within the range of the spectrum analyzer.

          2.2.3:  Fine tuned the temps of all 3 lasers until we had 2 peaks on the analyzer at the same time!!

               2.2.3.1:  Yend - measured Temp=34.14 C, thermal Out of Slow servo=29820

               2.2.3.2:  Xend - displayed temp=39.33 C, thermal Out of Slow servo=5070

               2.2.3.3: PSL - displayed temp=31.49 C, Slow actuator Adjust=1.100V

3:  Locked both arms using ALS!!

     3.1:  We were a little concerned that the Xarm wasn't locking.  We tried switching the cables on the beatbox so that we used the old channels for the Xarm, since the old channels had been working for Y.  Eventually we discovered that the input of the filter module for ETMX's POS-ALS input was OFF, so we weren't really sending any signals to ETMX.  We reverted the cabling to how it was this evening when Jamie reinstalled the beatbox.

          3.1.1:  We need to sort out our SUS screens - Not all buttons in medm-land link to the same versions of the SUS screens!  It looks like the ALS screen was modified to point the ETMY button to a custom ETMY SUS screen which has the ALS path in the POS screen, along with LSC and SUSPOS.  There is no such screen (that I have found) for ETMX.  The regular IFO_ALIGN screen points to the generic SUS screens for both ETMY and ETMX, so we didn't know until Yuta searched around for the filter bank that the ALS input for ETMX was off.  We just need to make sure that all of the screens reflect what's going on in the models.

     3.2:  See the video attached - it shows the beat peaks during locking!!! (how do I embed it? right now you have to download it)

          3.2.1:  First you will see both peaks moving around freely

          3.2.2:  Then X arm is locked briefly, then unlocked

          3.2.3: Y arm is locked, steadily increasing gain

          3.2.4:  X arm is locked, so both arms locked simultaneously

          3.2.5:  Yuta clicked a button, accidentally unlocking the Xarm

4:  The transmission of the X arm was not so great, and both of our green beams (although X green especially) were no longer nicely aligned with the cavities.  Yuta tried to align the X arm to the X green, but it's bad enough that we really need to start over with the whole IFO alignment - we leave this until tomorrow.  Since we didn't have any good IR transmission, we didn't bother to try to find and hold the Xarm on IR resonance using ALS, so we didn't measure a POX out of loop residual cavity motion spectrum.  Again, tomorrow. 

Are these correct?

1. It is a nice work.

2. This is not locking, but stabilization of the both arms by ALS.

3. We now have the phase trackers for both arms.

4. There is no coarse (i.e. short) delay line any more.

5. The splitters after the PDs are reducing the RF power to Beat-box.
Actually there are RF monitors on Beat-box for this purpose, but you did not notice them.

6. c1ioo channel list
https://wiki-40m.ligo.caltech.edu/CDS/C1IOO%20channel%20list
has to be updated.

7. Video can be uploaded to Youtube as Mike did at http://nodus.ligo.caltech.edu:8080/40m/6513

Answers to questions from Koji.

Are these correct?

1. It is a nice work.

Correct, of course!

2. This is not locking, but stabilization of the both arms by ALS.

Correct.

3. We now have the phase trackers for both arms.

Correct.

4. There is no coarse (i.e. short) delay line any more.

Correct. No coarse, only fine delay line (30m) with the phase tracker.

5. The splitters after the PDs are reducing the RF power to Beat-box.
Actually there are RF monitors on Beat-box for this purpose, but you did not notice them.

Oh, yes. But distance between beatbox and spectrum analyzer in the control room is longer than distance between BBPD on PSL table and the spectrum analyzer. We were too lazy to do cabling, but maybe we should.

6. c1ioo channel list 
https://wiki-40m.ligo.caltech.edu/CDS/C1IOO%20channel%20list
has to be updated.

Yes, we will.

7. Video can be uploaded to Youtube as Mike did at http://nodus.ligo.caltech.edu:8080/40m/6513

We didn't, but we can.

...Perhaps related to the fact that Jamie is copying a lot of stuff over the network to back up Ottavia before converting her to Ubuntu, perhaps totally independent. 

After restarting the daqd, c1lsc was the only computer whose mx_stream came up on its own.  I restarted c1sus. c1ioo, c1iscey, c1iscex by hand.

[Yuta, Jenne]

We tried to find a different place, not in the main green transmitted beam path, to place the trans camera for the green beams.  There is a little bit of leakage through the 3 high reflector mirrors which steer the beams from the direction when they first come out of the chamber over to the main green beat setup.  2 of these mirrors have virtually no space behind them for a camera (the first one the green beams encounters is right next to the EOM mount, and the 2nd one is pretty close to the Input Pointing QPDs.  We can potentially use the beam leaking through the 3rd steering mirror, if the camera is very close to the edge of the table (so that the camera isn't blocking the IR input pointing beams), but the X beam is so dim as to be nearly impossible to see, even when TEM00.  This precludes the point of the camera, which is to see the modes when we're aligning the beams.  (X power on the PSL table is pretty high - 330uW measured today, but those mirrors must transmit the Y beam's polarization more than the X beam's.)

Our other thought was to use one of the secondary beams coming out of the chambers.  This is kind of Mickey Mouse, but we thought that since this is just a camera to see the modes, as opposed to a PD, maybe it's okay.  This is a moot point however, since the secondary and tertiary beams (due to the wedge of the window) are clipped for the Y green.  We closed the PSL shutter then removed the beam pipe between the PSL table and the chamber so I could look inside. 

It looks to me like the main green transmitted beams are exiting through the window several inches from any edge, so they're definitely not clipping.  But the reflection from the window back into the chamber is hitting some optic.  The X green is hitting the face of the optic, while the Y green is hitting the edge of the optic and part of the mount.  The reflections from this mount then go back toward the chamber window and out toward the PSL table.  This isn't a big deal for the camera situation - we'll just use the leakage from one of the steering mirrors somehow, but it does mean that there is some green light reflected back onto an IR mirror, and potentially causing grief.  I didn't look to see if the mirror it's hitting is the 1st in-vac IR steering mirror (I don't think so) or something in the OMC / AS path (I think it's something here), but either way, we could be making trouble for ourselves.  We should try to dump the reflection from the window when we vent.  Jamie has put it on the List.

We replaced the beam pipe between the PSL table and the chamber before opening the shutter on the laser.  We are currently sticking with the plan of putting the camera in the main green trans path for initial alignment, then removing it for the rest of the work.

ottavia has been reinstalled with Ubuntu 10.04 LTS, and has been configured as a CDS workstation.

I have been maintaining a script that takes a stock 10.04 install and configures it as a workstation.  I've attached it here, but it lives at:

/users/controls/workstation-setup.sh

The script is designed to be idempotent, i.e. it can be run on a machine that has already been configured and it will either have no affect or update.

[Yuta, Jenne, Koji]

We stabilized the Xarm using the ALS and took a spectrum of POX as our out of loop sensor.  We used the calibration from elog 6841 to go from counts to meters.

We find (see attached pdf) that the RMS is around 60pm, dominated by 1Hz motion.

In other, related, news, I took out the beam pipe connecting the AP and PSL tables and covered the holes with foil.  This makes it much easier and faster to get to the X beat setup for alignment.  Eventually we'll have to put it back, but while the AUX laser on the AP table is not being used for beating against the PSL it'll be nice to have it out of the way.

X arm finesse is 416 +/- 6, mode-matching ratio is 91.2 +/- 0.3%

I did mode scan for X arm just like we did for Y arm (see elog #6832)

Servo design:
  Servo filters are as same as Y arm.
  UGF and phase margin of X arm ALS are 100 Hz and 14 deg.
  For phase tracking loop, they are 1.5 kHz and 56 deg.

Raw data from the mode scan:



Fitted peaks and finesse:


By taking the average,

F = 416 +/- 6 (error in 1 sigma)
(For Y arm, it was 421 +/- 6. See elog #6832)


Mode matching ratio:
 From X arm 8FSR measurement using phase tracker, peak heights are

TEM00 0.834, 0.851, 0.854, 0.852, 0.876, 0.850, 0.855, 0.878
TEM01 0.031, 0.031, 0.017, 0.017, 0.009, 0.014, 0.009, 0.011
TEM02 0.053, 0.052, 0.057, 0.058, 0.061, 0.060, 0.061, 0.059
TEM03 0.011, 0.010, 0.010, 0.007, 0.006, 0.005, 0.006, 0.005

 So, the mode-matching ratio is

MMR = 89.7%, 90.1%, 91.0%, 91.2%, 92.0%, 91.4%, 91.8%, 92.1%

 By taking the average,

MMR =  91.2 +/- 0.3 (error in 1 sigma)
(for Y arm, it was 86.7 +/- 0.3 %. See elog #6828)


Discussion:
 - Mode matching ratio for both X and Y arm is ~90%, which is not so great, but OK. It seems like there's no huge clipping or mode-mismatch from MC to ITMs. I think we should go next for PRMI investigation.

 - Measured finesse seems too low compared with the design value 450. If we believe power transmission of ITM and ETM are 0.0138 and 1.37e-5, the measured finesse tells you that there's ~0.1% loss(F = 2*pi/(T_{ITM}+T_{ETM}+T_{loss})). We need some evaluation for the linearity of the sweep, before concluding that there's 0.1% loss for each arm. Using FINE_I/Q signal for calibration, or installing frequency divider for monitoring actual beat frequency would help.


Things to do for the beat setup:
 - Amplifiers after beat PDs shouldn't be on the PSL table. Move them near the beatbox.
 - Install DC PD (and camera?) at un-used port of the beat BS for monitoring green transmission power.
 - Make nice MEDM screens for our new phase tracking ALS.
 - Make a script to sweep arm length with ALS and find IR resonance.
 - Look into X end table. Beam spot of the X green transmission is wiggly when X end table is opened and there's air flow.

I was notified by CIT Utilities that there was a power surge or short power outage this after noon.

Lab conditions are normal:  c1ioo is down.  The south arm AC was off......I turned it back on.

I moved amplifiers for beat PD at PSL table to 1X2 rack. Current beat setup from PD to ADC is shown below. Setup for X beat and Y beat are almost the same except for minor difference like cable kind for the delay line.

Currently, DC power for amplifiers ZHL-1000LN+ is supplied by Aligent E3620A.
I tried to use power supply from the side of 1X1 rack, but fuse plug(Phoenix Contact ST-SI-UK-4) showed red LED, so I couldn't use it.
Measured amplification was +25 dB for 10-100 MHz.

Measured gain from RF input to monitor output of the beat box was ~ -1 db for 10-100 MHz.

I made a python script for relocking PMC.
It currently lives in /opt/rtcds/caltech/c1/scripts/PSL/PMC/PMClocker.py.

I think the hardest part for this kind of locker is the scan speed. I could make the scan relatively fast by using pyNDS.
The basic algorithm is as follows.

1. Turns off the servo by C1:PSL-PMC_SW1.

2. Scans C1:PSL-PMC_RAMP using ezcastep.bin. Default settings for ezcastep is

ezcastep.bin C1:PSL-PMC_RAMP -s 0.1 0.01 10000

So, it steps by 0.01 for 10000 times with interval of 0.1 sec.

3. Get C1:PSL-PMC_PMCTRANSPD and C1:PSL-PMC_RAMP online 1 sec data using pyNDS.

4. If it finds a tall peak in C1:PSL-PMC_PMCTRANSPD, kills ezcastep.bin process, sets C1:PSL-PMC_RAMP to the value where the tall peak was found, and then turns on the servo.

5. If tall peak wasn't found, go back to 3 and get data again.

6. If C1:PSL-PMC_RAMP reaches near -7 V or 0 V, it kills previous ezcastep.bin process and turns the sign of the scan.

I tested this script several times. It sometimes passes over TEM00 (because of the dead time in online pyNDS?), but it locks PMC with in ~10 sec.
Currently, you have to run this to relock PMC because I don't know how to make this an autolocker.

I think use of pyNDS can be applied for finding IR resonance using ALS, too.
I haven't checked it yet becuase c1ioo is down, but ALS version lives in /users/yuta/scripts/findIRresonance.py. ALS may be easier in that we can use fast channels and nice filter modules.

Other scripts:
 I updated /opt/rtcds/caltech/c1/scripts/general/toggler.py. It now has "lazymode". When lazymode, it toggles automatically with interval of 1 sec until you Ctrl-c.

 Also, I moved damprestore.py from my users directory to /opt/rtcds/caltech/c1/scripts/SUS/damprestore.py. It restores suspension damping of a specified mirror when watchdog shuts down the damping.

             CALIFORNIA INSTITUTE OF TECHNOLOGY

                 FACILITIES MANAGEMENT

                 UTILITY & SERVICE INTERRUPTION

**PLEASE POST**

Building:         CAMPUS

Date:             Saturday, June 23, 2012

Time:             3:46 P.M.

Interruption:     Electrical Power Disturbance

Contact:          Tom Brennan, x-625-395-4984    

*The City of Pasadena Water & Power Department had a 34,000-volt line event on Saturday June 23 at 3:46 p.m.  This caused a city wide disturbance on the power grid.  The Campus did not lose electrical power.  However, the disturbance may have affected sensitive electronic equipment.

(If there is a problem with this Interruption, please notify the Service Center X-4717 or the above Contact as soon as possible.

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

                        Jerry Thompson,

                        Interim Director of Campus Operations & Maintenance

 LSCoffsets is working again. 

tdsavg (now, but didn't used to) needs "LIGONDSIP=fb" to be specified.  Jamie just put this in the global environment, so tdsavg should just work like normal again.

Also, the rest of the LSCoffsets script (really the subcommand offset2) was tsch syntax, so I created offset3 which is bash syntax.

Now we can use LSCoffsets again.

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

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

Jenne and I renamed the mic channels Den created (elog 6664) to MIC_1, MIC_2, etc from the original accelerometer names to keep things clear. We then added 6 new channels (22-27) for the accelerometers, named ACC_MC1_X, Y, Z, ACC_MC2_X, Y, Z, etc. (See the screenshot below). We also added a DAQ channel block and listed out the IN1 channel of all the sensors. We compiled and started the model, and checked that all the channels were there in DataViewer.

I made a python script for finding IR resonance using ALS. It currently lives in /opt/rtcds/caltech/c1/scripts/ALS/findIRresonance.py.

The basic algorism is as follows.

1. Scan the arm by putting an offset to the phase output of the phase tracker(Step C1:ALS-BEAT(X|Y)_FINE_OFFSET_OFFSET by 10 deg with 3 sec ramp time).

2. Fetch TR(X|Y) and OFFSET online data using pyNDS during the step.

3. If it finds a tall peak, sets OFFSET to the value where the tall peak was found.

4. If tall peak wasn't found, go back to 1 and step OFFSET again.

The time series data of how he did is plotted below.
I ran the script for Y arm, but it is compatible for both X and Y arm.

I thought we rewrite auto lockers once per year, but this time it took us only a month. I wrote it for PMC on May 24. Is it not working?

Could someone make it more clear why some scripts are written on bash, others on sh or python? I think we should elaborate a strict order. Masha and I can work on it if anyone else considers this issue as a problem.

I know.
I just wanted to use pyNDS for this kind of scanning & locking situation.
c1ioo was down for the weekend and I couldn't test my script for ALS, so I used it for PMC.

But I think PMClocker.py can relock PMC faster because it can sweep C1:PSL-PMC_RAMP continuously and can get continuous data of C1:PSL-PMC_PMCTRANSPD.

[Koji, Yuta]

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

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

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

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

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

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

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

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

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

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

This week, the other SURF students and I got acquainted with the caltech campus, LIGO 40m lab and the expectations of the SURF program.  We went to a lot of safety meetings and lectures that established a framework for the jobs we will be doing over the course of the summer.  I went on several tours of the 40m interferometer (one each with Jenne, Jamie and Steve) to get an overview of the layout and specifics of the setup.  I read parts of R. Ward and A. Parameswaran's theses and Saulson's book in order to prepare myself and gain a broader understanding of the purpose of LIGO.

I also began working in Python this week, primarily graphing PSDs of data from the C1:SUS-ETMY_SENSOR_LR, C1:SUS-ETMY_SENSOR_LL, C1:SUS-ETMY_SENSOR_UR, and C1:SUS-ETMY_SENSOR_UL channels.  I will eventually be using Python to generate the plots for the summary pages, so this is good practice.  The code that I have been working on can be found in /users/elizabeth.davison/script5.py.  Additionally, I have been going through the G1 summary pages and attempting to understand the plots available on them and the code that is available.

My plans for the upcoming week begin with modifying my code and potentially calibrating the channel data so that it is in units of length instead of counts.  I will also access the code from the G1 pages and go over it in depth, hopefully gaining insight into the structure of the website.

This week I wrote Matlab code, most of which can be found in /users/masha

First, I wrote a simulation seismicFilter.m which filters noisy seismic noise with a desired signal of non-seismic noise. The signals are purely simulated, so I played around with zero-pole-gain generation of transfer functions to obtain them. The function takes the number of taps, the filter type (Wiener or adaptive nlms) as well as an iteration step size and number of iterations, and generates PSD plots of the witness signal, the desired signal, the estimated (filtered) signal, and the error. I'm not sure that I am properly implementing the Wiener part of the code, and I assume the line "[W, R, P] = miso_firlev(TAPS, noisySeismicSignal1, seismicSignal2); " generates W, a filter with TAPS number of weights, but  then "[y, error] = filter(W, 1, noisySeismicSignal1);" generates an error signal of size TAPS rather than N, the size of the original signal. Perhaps I should calculate error using e(t) = d(t + a) - w(t)*x(t), where "a" is the delay.

I have various screenshots in my directory of what seismicFilter.m generates, and I will take a larger screenshot, as well as generate a learning curve (for error vs. number of taps) when I can use Sasha's computer for a bit, since it both has more computing power and a larger screen.

The funciton filterConvergence.m, meanwhile, is similar, except it takes two file names as real data, and uses realDataFilter.m to run the filtering. Currently, I am working with data from C1:IOO-MC_F_DQ-Online  and C1:PEM-SEIS_GUR1_X_IN1_DQ-Online, and I will include screenshots of these once I get on Sasha's computer.

In order to generate the data, meanwhile, I had to modify the python script, and thus wrote mashaImportingData.py for myself. Likewise, plotSignalFromFile.m visualizes this data, both in the time domain and in the frequency domain.

On the side, I wrote an NLMS filter in adaptiveFilterSimulationNLMS.m, and compared is to Matlab's NLMS filter in NLMStest.m (using generated data) and adaptiveFilterSimulation.m using twn input signals. Right now, it's faster on smaller inputs and smaller tap sizes, but then begins to choke and run slower than the Matlab one when these get to big. In order to improve it, I have to develop a better method of generating the initial weights.

As far as machine learning goes, once I find the number of taps for the convergence of both the Wiener filter and the NLMS filter, I will email Denis for further instructions. At some point, however, I should generate learning sets from the seismometers and the MCL (or the DARM), and thus have to find adequate times at which I can take data (probably not from the DARM, however, because it was rarely on).

Thanks for reading!

I have moved the summary pages stuff that Duncan set up to a new directory that it accessible to the nodus web server and is therefore available from the outside world:

/users/public_html/40-summary

which is available at:

https://nodus.ligo.caltech.edu:30889/40m-summary/

I updated the scripts, configurations, and crontab appropriately:

/users/public_html/40m-summary/bin/c1_summary_page.sh
/users/public_html/40m-summary/share/c1_summary_page.ini

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

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

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

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

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

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

Mike J. came tonight and he fixed Sensoray (elog #6645). He recompiled it and fixed it.

I made a python wrapper script for Sensoray scripts. It currently lives in /users/yuta/scripts/videocapture.py.
If you run something like
  ./videocapture.py AS
it saves image capture of AS to /users/yuta/scripts/SensorayCapture/ directory with the GPS time.
Below is the example output of AS when MI is aligned. We still see some clipping in the right. This clipping is there when one arm is mis-aligned and clipping moves together with the main beam spot. So, this might be from the incident beam, probably at the Faraday.

Currently, videocapture.py runs only on pianosa, since Sensoray 2253S is connected to pianosa. Also, it can only capture MON4. My script changes MON4 automatically.

My goal for tonight was to lock PRMI,
 grasp the current situation by my eye,
  and capture some images using Sensoray.

They are done, but what are we going to do to solve the problem? The beam looks terrible than I had expected.


What I did:
  1. DC output of POP55 PD was plugged out from 1Y2 rack, so we plugged it in.

  2. Aligned POP beam to POP25 PD and moved POP camera position at ITMX table.
 
  3. Mis-aligned PRM and SRM, aligned both arms, aligned FPMI as usual.

  4. Mis-aligned PRM and ETMs, aligned MI and locked MI.

  5. Aligned PRM, and carrier locked PRMI. PRM alignment was not saved since June 7, so slider values which give good alignment was pretty much drifted (~0.4 in C1:LSC_PRM_(PIT|YAW)_COMM).

  6. Took some images of POP, REFL, AS during PRMI lock.




PRMI commissioning plan:
  From the beam shape at POP, REFL, and AS, the problem clearly comes from the mode-matching, including clipping, longitudinal mismatch, and alignment mismatch. Koji's idea of flipped-PRM seems reasonable, so I think we should better measure something to prove this.
  To prove this,

  1. Simulate what the beam look like in POP, REFL, AS if PRM was flipped. Compare them with actual captured images. I need to study on unstable cavities.
  2. Calculate power recycling gain and compare.
  3. Misalign PRM and capture the image of primary, secondary, ... reflections like Koji did in elog #6421. Measure the beam sizes of these reflections using some image analysis(Python Imaging Library? Is there anyone good at this?) and calculate PRM curvature.
  4. Can we do come characterization by making PRM-ITMY cavity? ITMX will be mis-aligned, BS will be the loss port to PRC.
  5. Beamspot on POP, REFL, AS looks woblby when PRMI is locked. Why?
  6. Open the vaccum chamber and see PRM. Simple.

  Any other ideas? I have to lock PRFPMI, at least, by July 13!

To be fair, this is Kiwamu's idea. And nothing is reasonable before it is confirmed quantitatively.

 Cycling the vacuum is easy. Why not vent starting Thursday evening and pop the doors on Friday morning? Inspect on Friday and pump on Monday morning.

[Koji, Jamie, Yuta]

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

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

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

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

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

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

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

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

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

1. Turned off high voltage power supplies for PZT1/2 (input PZTs) and OMC stage 1/2. They live in 1Y3 rack and AUX_OMC_NORTH rack.

2. Restored all IFO optics alignment to the position where I aligned this afternoon (for SRM, I didn't aligned it; it restored at the saved value on May 26).

3. Centered all the oplevs. They can be used for a reference for alignment change before and after the vent.

I will leave PSL mechanical shutter and green shutters closed just in case.

Some MEDM screenshots below.

 Steve, Yuta and Jamie

Jam nuts were checked and oplev servos were turned off. Sus summery is below with strain gauge values. Are the strain gauge values have any meaning when the PZT contorrels are off??????????????????

 The 4 hrs vent plot at 3 torr/min rate.

Nitrogen was used from 1e-6 torr to 35 torr  at intake pressure 14 PSI

The rest was filled with 5 cylinders of Instrument Grade Air at intake pressure 14 PSI

We can start opening chamber at 3 pm today

[Koji, Steve, Jamie, Yuta]

So, PRM was NOT flipped......

We opened the BS chamber and quickly checked the arrow on the PRM pointing HR. It turned out to be correct, the arrow was pointing towards the arm cavity. We opened the ITMX chamber, too, to check PR2 later.
BS chamber and ITMX chamber is now closed with the light door.

But it was a one step forward anyway, because we could prove PRM was innocent.

What to do next:
  We know that the mode-matching of the incident beam and both arms are pretty good. So, dirty modes come from PRC.
  We will check beam clipping, mirrors, suspensions in PRC.
  I expect the chambers to be closed on Monday(July 2) afternoon and start pumping on Tuesday(July 3) morning.

[Yuta, Koji, Jamie]

We went into ITMX chamber to inspect the situation there.  We looked for clipping and flipping at PR2, and found none, although we noticed that the beam at PR2 looks a little clipped.

We then went back into the BS chamber and took a closer look at the beam incident on PRM, and the situation with PR3.  The PRM incident beam looked a little clipped, which we expected from the PR2 observation.  But the beam looks well centered on PRM and PR3.  As best I could tell the beam is reflecting off the front surface of PR3, as expected.

Looking at the beam around MMT1 and PJ2 (the second PZT on BS), we could tell that the beam incident and reflected off of MMT1 looked round, where as the beam incident on PJ2 looked clipped.  Using my tallness super power I was able to reach into the IMC chamber and confirm that the beam going from MMT1 to MMT2 clips fairly badly on the edge of the Faraday.   Koji speculates that this is the result of a misalignment of the PSL output beam into the MC.  In any event, it's not clear how this would be the cause of our PRC woes.

We decided to close up for the night, and let Yuta work on aligning PRMI.  We need to figure out what the heck to do now.

We've been watching the input power reduce, from 18 mW initially when we first went in, to about 5mW now.  It seems to be leveling out now.  It's unclear what would have been causing it.  Drift of the input polarization?

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

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

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

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


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

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

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


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

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

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


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

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

  The difference between mcdown_low_power and mcdown should be only

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

  The difference between mcup_low_power and mcup should be only

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

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

[Koji, Steve, Jamie, Jenne, Yuta]

We opened BS and ITMX chambers, took lots of photos, and closed them with heavy doors.
I turned off high voltage power supplies for PZTs and blocked PSL beam. We are ready for the pumping tomorrow.

Important photos we took:
  - positions of green optics at BS chamber, which was moved on the vent on Aug 2011
  - positions of PZT mirrors and cable connectors at BS chamber, which will be replaced with tip-tilts on the next vent
  - arrow on PR2 pointing HR (it was correct)
  - tried to take photos of clipping IR beam at BS OSEM holder from ITMX chamber
 
 We also took bunch of other photos.


Beam dump needed at BS chamber:
  We also checked some un-dumped beams at BS chamber. We need dumps;
  - behind MMT1, for unwanted transmitted beam
  - behind IPPOSSM3, for unwanted transmitted beam (IPPOSSM3 is the last mirror in BS chamber for IPPOS)

Many photos were taken by many different people....most of the fuzzy ones are by yours truely (doing a reach-around to get to hard-to-reach places), so sorry about that.

I put all the photos from yesterday and today into 6 new albums on Picasa:  https://picasaweb.google.com/foteee

The album titles are generally descriptive, and I threw in a few comments where it seemed prudent.

Big note:  The tip tilt on the ITMX table does, in fact, have the arrow pointing in the correct direction.  Photo is in the TT album from today.

This past Friday I swapped out a burnt resistor on the spare STACIS unit I'm working with and powered it up. Here's the setup:

And here's what happened:

X an Y directions: When I switched from open to closed loop (making the internal geophones provide feedback), the STACIS started making a loud noise- it seemed like it was oscillating uncontrollably.

Z direction: The same thing happened in z until I added some weight to the top of the STACIS- then it quieted down, and seemed to work okay. The geophone signal dropped considerably compared to the open loop signal, which is expected if the feedback is working.

Then I tried driving the PZTs with a signal from the SR785 network analyzer. With an amplitude of tens of mV and frequencies from around .1 to 200 Hz, I could see the accelerometers I mounted on top of the STACIS definitely register motion, which means I was successfully driving the PZTs.

Below are transfer functions of the STACIS as I drove the PZTs from .1 to 100 Hz at 10 mV. The top graph is open loop, the second is closed loop. These were measured with the internal geophones.

In the bottom graph, "A" is closed loop and "B" is open loop, where the transfer functions were taken with the accelerometers instead of the geophones.

Vacuum Normal State is reached in 9 hours.  CC1 =  2e-5 Torr

Aux dry pump #3 is still running.  The RGA is not pumped yet.

We have received the dichroic optics from Laseroptik.  The coatings are:

HR:

• 532nm: T(s+p) > 97%
• 1064nm:  R(p) > 99.9%

AR:

• 532nm: R(s+p) < 1%
• 1064nm: R(p) < 2%

We got two sets with these coatings:

• 6x: 50 x 9.5mm, 2 degree wedge
• 8x: 25 x 6.35mm, 2 degree wedge
• 1x: 25 x 3mm, witness

I'm still having issues with the STACIS oscillating uncontrollably with the slightest extra vibration, but with some more added weight both x and z direction are stable if you don't disturb the setup.

I took more transfer functions of the STACIS. In the last data I took Jenne pointed out that the geophone signals were not correlated well with the driving signal, so I increased the amplitude of the driving signal and am looking in x and y too instead of just z. 

Details of the driving signal: 25 mV, swept sine from 0.1 to 100 Hz from the SR785. 

NOTE: The data below was all transferred from the SR785 using netGPIB, which works fine, if anyone was interested in using it.

Open loop in the y direction, taken with the y geophone (magnitude on top, phase on bottom):

Open loop in the x direction, taken with the x geophone (with some extra weight to try to make the closed loop more stable):

Open loop in the x direction, taken with accelerometer instead of geophone:

I put them in the "visible optics" drawer of the newish, metal optics cabinet with the thin drawers down the Y arm.

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

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

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

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

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

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

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

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

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



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

I got a call from Koji and Yuta that something was wrong with the CDS system.  I somehow had an immediate suspicion that it had something to do with the recent leap second.

It took a while for nodus to respond, and once he finally let me in I found a bunch of the following in his dmesg, repeated and filling the buffer:

Jul  3 22:41:34 nodus xntpd[306]: [ID 774427 daemon.notice] time reset (step) 0.998366 s
Jul  3 22:46:20 nodus xntpd[306]: [ID 774427 daemon.notice] time reset (step) -1.000847 s

Looking at date on all the front end systems, including fb, I could tell that they all looked a second fast, which is what you would expect if they had missed the leap second.  Everything syncs against nodus, so given nodus's problems above, that might explain everything.

I stopped daqd and nds on fb, and unloaded the mx drivers, which seemed to be showing problems.  I also stopped nodus's xntp:

  sudo /etc/init.d/xntpd stop

His ntp config file is in /etc/inet/ntp.conf, which is definitely the WRONG PLACE, given that the ntp server is not, as far as I can tell, being controlled by inetd.  (nodus is WAY out of date and desperately needs an overhaul.  it's nearly impossible to figure out what the hell is going on in there).  I found an old elog of Rana's that mentioned updating his config to point him to the caltech NTP server, which is now listed in the config, so I tried manually resyncing against that:

  sudo ntpdate -s -b -u 131.215.239.14

Unfortunately that didn't seem to have any effect.  This was making me wonder if the caltech server is off?  Anyway, I tried resyncing against the global NTP pool:

  sudo ntpdate -s -b -u pool.ntp.org

This seemed to work: the clock came back in sync with others that are known good.  Once nodus time was good I reloaded the mx drivers on fb and restarted daqd and nds.  They seemed come up fine.  At this point front ends started coming back on their own.  I went and restarted all the models on the machines that didn't (c1iscey and c1ioo).  Currently everything is looking ok.

I'm worried that there is still a problem with one of the NTP servers that nodus is sync'ing against, and that the problem might come back.  I'll check in again later tonight.

After plenty of work, NDS2 can now be used to get site data within MATLAB using the following machines:

• allegra
• megatron
• ottavia
• pianosa
• rosalba
• rossa

What I did

NDS2 was not working on any of the machines, so the first thing I did was simply to install the newest version. I downloaded the latest tarball (0.9.1) from the LDAS Wiki, unzipped and installed it

/users/zach $ tar -xvf nds2-client-0.9.1.tar

/users/zach $ cd nds2-client-0.9.1

/users/zach $ sudo ./configure --prefix=/cvs/cds/caltech/apps/linux64 --with-matlab=/cvs/cds/caltech/apps/linux64/matlab/bin/matlab

/users/zach $ sudo make

/users/zach $ sudo make install

Even with the new version, it still didn't work.

Solution: The main problem was that the cyrus-sasl-gssapi authentication protocol was not installed on these machines, so that even with a kerberos ticket the datalink could not be established. Using information from the LDAS Wiki, I used aptitude to install it as:

$ sudo aptitude install lscsoft-auth

This group installs both the SASL protocol and the package python-kerberos

I also needed to update the kerberos config file for each machine, which is located at /etc/krb5.conf. I found that ottavia had a nice one with many realms, so I copied that one over to the other machines. In any case where there was an old config file overwritten, it is now /etc/krb5.conf.old.

Finally, the matlab path for NDS2 was still set to the old 2010a directory (/cvs/cds/caltech/apps/linux64/lib/matlab2010a) that was created by the NDS2 install when Rana originally did it. The new install I made above created the appropriate 2010b mexa64 files, so I changed the matlab path within matlab to this one:

>> rmpath /cvs/cds/caltech/apps/linux64/lib/matlab2010a

>> addpath /cvs/cds/caltech/apps/linux64/lib/matlab2010b

>> savepath

Now everything works fine on all these machines. As in Rana's original post, you get data in the following way:

$ kinit albert.einstein %then enter password

$ matlab -nosplash -nodesktop

>> d = NDS2_GetData({'H1:LSC-NPTRX_OUT16.mean'},963968415,6000,'nds.ligo.caltech.edu:31200')

d = 

            name: 'H1:LSC-NPTRX_OUT16.mean' 

            chan_type: 'm-trend'             

            rate: 0.0167       

            data_type: 'real_8'     

            signal_gain: 1   

            signal_offset: 0     

            signal_slope: 1     

            signal_units: ''   

            start_gps_sec: 963968415     

            duration_sec: 6000             

            data: [100x1 double]           

            exists: 1

>> quit % since you've seen that the data is really here

$ kdestroy % so that no one uses your credentials

Some thoughts

• I would like to extend this to the 32-bit machines, but I have to figure out the best way to install the proper NDS2 client without interfering with the 64-bit version. I think it is just a matter of specifying the matlabroot in the .../linux/ instead of .../linux64/
• It would be nice to find a way that the nice tool gps('MM/DD/YYYY XX:XX:XX UTC'), which calls the ligotool executable tconvert, can be automatically usable when calling NDS2 functions. Right now, there seems to be an issue preventing that: even though tconvert can be run in the terminal, gps() returns an error and even directly running unix('tconvert now') or !tconvert returns the same error. I have emailed Peter Shawhan to see if he has any advice.

I aligned FPMI and greens. There's no recognizable difference between before and after the vent.

What I did:
  1. Aligned Y arm to maximize Y green transmission.
  2. Used PZT1/2 to maximize TRY. But since PZT1 doesn't work so much, I had to align Y arm, too (mostly ETMY). This decreases green transmission, but I will leave it.
  3. Aligned BS and X arm to maximize TRX
  4. Fine tune them to minimize ASDC during FPMI lock, without decreasing TRX
  5. Aligned X end green to get TEM00 transmission.

Now, TRY and TRX are both  ~0.89.
Green transmission from Y and X arm are ~123 uW and ~275 uW respectively. Their max we got so far was ~200 uW and ~255 uW.
I still see clipped beam at AS, which I think is from the Faraday edge, as we found in elog #6897.
Below is the Sensoray capture of some ports, and MEDM screen shots to compare with before vent(see #6893).
There are two AS captures, one is without MI lock and the other is with MI lock. Note that PRM/SRM is misalined.




Next:
 - I will check ALS
 - I keep Y end green optics untouched since elog #6776, to use it as a reference. We need to realign them if tip-tilts are installed in vacuum, or PZTs are installed in both ends.