The DAQ Wiki pages say to use port 8088 for restarting the Frame Builder. I tried this to no avail.

op440m:daq>telnet fb 8088
Trying 192.168.113.202...
Connected to fb.martian.
Escape character is '^]'.
^]
telnet> quit
Connection to fb.martian closed.
op440m:daq>telnet fb 8087
Trying 192.168.113.202...
Connected to fb.martian.
Escape character is '^]'.
daqd> shutdown
OK
Connection to fb.martian closed by foreign host.

Apparently, 8087 is the right port. Various elog entries from Joe and Kiwamu say 8087 or 8088. Not sure what's going on here.

After figuring this out, I activated the C1:GCV-XARM_COARSE_OUT_DAQ and C1:GCV-XARM_FINE_OUT_DAQ and set both of them to be recorded at 2048 Hz. We are loading filters and setting gains into these filter modules such that the OUT signals will be calibrated into Hz (that's why we used the OUT instead of the IN1 as there was last night).

Actually both port 8087 and 8088 work to talk to the frame builder.  Don't let the lack of a daqd prompt fool you.

Here's putting in the commands:

rosalba:~>telnet fb 8088 Trying 192.168.113.202...

Connected to fb.martian (192.168.113.202). Escape character is '^]'.

shutdown

0000Connection closed by foreign host.

rosalba:~>date Mon Jan 24 10:30:59 PST 2011

Then looking at the last 3 lines of restart.log in /opt/rtcds/caltech/c1/target/fb/

daqd_start Fri Jan 21 15:20:48 PST 2011

daqd_start Fri Jan 21 23:06:38 PST 2011

daqd_start Mon Jan 24 10:30:29 PST 2011

So clearly its talking to the frame builder, it just doesn't have the right formatting for the prompt.  If you try typing in "help" at the prompt, you still get all the frame builder commands listed and can try using any of them.

However, I'll edit the DAQ wiki and indicate 8087 should be used because of the better formatting for the prompt.

Apparently, 8087 is the right port. Various elog entries from Joe and Kiwamu say 8087 or 8088. Not sure what's going on here.

The following code is incredibly useful when creating  MATLAB plots as it adds the filename of the script to the plot itself. I think it should be used for all MATLAB plots that go on the elog.

For example, I have no idea where the data/script is that was used to generate these plots.

orient landscape

xposn = 0.0;

yposn = -0.13; % you sometimes have to tweak this value depending on the page size and the number of subplots


text(xposn,yposn,[filename('fullpath'), '.m'], ...

     'Units', 'normalized', ...

     'Interpreter', 'none', ...

     'FontSize', 6)

print('-dpdf', [filename('fullpath'), '.pdf'])

The following is a message from the LIGO 40m Chief Recycling Officer:

Please get up off your (Alignment Stabilization Servo)es and recycle your bottles and cans!  There is a recycling bin in the control room.  Recent weeks have seen an increase in number of bottles/cans thrown away in the regular garbage.  This is not cool. 

Thank you,

---L4mCRO

Long time ago, I looked at the manual of the video switcher.
http://media.extron.com/download/files/userman/Plus_Ultra_MAV_C.pdf
Here is the summary. This will be the basic of the more sophisticated switching program which may have GUI.

In principle, you can manually control the matrix via telnet. At the console machines, you can connect to the matrix using telnet

telnet 192.168.113.92

This opens TCP/IP port 23 of the specified machine. You will receive some messages.
Then type some command like:
--------------------

• 1*2!       (connect input#1 to output#2)
• 1,           (save the current setting into preset1)
• 1.           (restore the setting from preset1)

--------------------

Basicaly that's all. There are many other features but I don't think we need them.

We can create a simple program with any of the language as any of the language has the capability of the TCP/IP connection.
e.g. C, Perl, Python. Tcl/Tk
Any of them are fine.

Now what we have to think about is how to implement the interface in the epics screen (or whatever).
It needs some investigation how the people is thinking as the ideal interface.
But, first of all, you should make the above three operations available as a simple UNIX command like:

videoswitch -i 192.168.113.92 1 2
videoswitch -i 192.168.113.92 -store 1
videoswitch -i 192.168.113.92 -recall 1
(There is no such command yet. These are showing what it should be!)

This can be done by a single day work and our life will be much better.

I have made a small python script to handle the video matrix.

It is too far from the perfection, but I release it as it is already useful in some extent.

The script is in the /cvs/cds/rtcds/caltech/c1/scripts/general directory.

usage:

videoswitch.py in_ch_name out_ch_name


in_ch_name is one of the followings

MC2F, IFOPO, OMCR, FI, AS_Spare, ITMYF, ITMXF, ETMYF, ETMXF,
PMCR, RCR, RCT, PSL_Spare, PMCT, ETMXT, MC2T, POP, IMCR, REFL,
MC1F, SRMF, AS, ETMYT, PRM, OMCT, Quad1, Quad2, Quad3

out_ch_name is one of the followings

Mon1, Mon2, Mon3, Mon4, Mon5, Mon6, Mon7,
ETMY, MC1, PSL1, PSL2, ETMX, MC2, CRT9,CRT10,Projector,
Quad1_1, Quad1_2, Quad1_3, Quad1_4,
Quad2_1, Quad2_2, Quad2_3, Quad2_4,
Quad3_1, Quad3_2, Quad3_3, Quad3_4


For some purposes I looked back the data of some channels which don't exist any more.  Here I explain how to do it.

If this method is not listed on the wiki, I will put this instruction on a wiki page.

(How to)

   (1) Edit an "ini" file which is not associated to the real-time control (e.g. IOP_SLOW.ini)

   (2) In the file, write a channel name which you are interested in. The channel name should be bracketed like the other existing channels.

               example:  [C1:LSC-REFL11_I_OUT_DAQ]

   (3) Define the data rate. If you want to look at the full data, write

              datarate = 2048

        just blow each channel name.

        Or if you want to look at only the trends, don't write anything.

   (4) Save the ini file and restart fb. If necessary hit "DAQ Reload" button on a C1:AAA_GDS_TP.adl screen to make the indicators green.

   (5) Now you should be able to look at the data for example by dataviewer.

   (6) After you finish the job, don't forget to clean up the sentences that you put in the ini file because it will always show up on the channel list on dtt and is just confusing.

        Also don't forget to restart fb to reflect the change.

I have made a python script to generate the button designed by Jeff Kissel for his ISI screen.

It is currently located at the following location:
/cvs/cds/rtcds/caltech/c1/medm/c1lsc_tst/master/KisselButtonGenerator/generate_KisselButton.py
but should be relocated to somewhere appropriate.
It also uses fragmented medm files named "MATRIX*.adl_parts".

# Jamie, could you suggest the right place?

The parameters are assigned at the beggining of the script.
This script print the result to stdout. So you need to redirect the output into a file.
e.g.
> ./generate_KisselButton.py >tmp.adl


The script should be modified such that it accepts the command line options.
It needs more python learning for me.

# Number of the column
mat_h = 20;

# Number of the row
mat_v = 10;

# horizontal pixel size of the rectangular display for each matrix element
button_width = 8;

# vertical pixel size of the rectangular display for each matrix element
button_height = 8;

replace_dict = {
# Title
    '${DISPLAY_LABEL}':'ITMX_INMATRIX', 
# Path of the MEDM file to be open by clicking the button
    '${DISPLAY_NAME}':'/cvs/cds/rtcds/caltech/c1/medm/c1sus/master/C1SUS_ITMX_INMATRI
X_MASTER.adl',
# The channel name of the matrix element
# ($V and $H are replaced to the numbers i.e. "_3_4")
    '${MATRIX_CHAN}':'C1:SUS-ITMX_INMATRIX_$V_$H'
    };

Now the Kissel-button generator takes the command line arguments and options.
The script is fully documented by the usage message of the script itself.
It still needs the external supporting files "MATRIX*.adl_parts".

Now the LSC screen has these buttons for the input and output matrices.
The command lines to generate those buttons are listed at the end of this entry as the examples.

>pwd
/opt/rtcds/caltech/c1/medm/c1lsc_tst/master/KisselButtonGenerator


>./generate_KisselButton.py -h
usage:
generate_KisselButton.py [options]  end_row end_column matrix_ch_name

This generates an MEDM screen of a button with the style designed by
Jeff Kissel for his ISI screens. This button has a display of a matrix
elements. If the matrix element is non-zero it glows in green. Otherwise
its color is dark. Usually the button created by this script
is to be copy-pasted to other screens.

Three arguments have to be given:
  end_row         the number of the row at the end
  end_column      the number of the column at the end
  matrix_ch_name  the channel name of the matrix to be monitored
                  e.g. give C1:LSC-OUTPUT_MTRX for C1:LSC-OUTPUT_MTRX_1_1, ...

There are options prepared in order to control the parameters of the button.

example:
generate_KisselButton.py 6 6 C1:LSC-OUTPUT_MTRX
      6x6 matrix for C1:LSC-OUTPUT_MTRX


options:
  -h, --help          show this help message and exit
  --sr=START_ROW      specify the starting row number for the button array.
                      [default: 1]
  --sc=START_COLUMN   specify the starting column number for the button array.
                      [default: 1]
  --bw=BUTTON_WIDTH   specify the pixel width of the small button. [default:
                      8]
  --bh=BUTTON_HEIGHT  specify the pixel height of the small button. [default:
                      8]
  --dl=DISPLAY_LABEL  specify the button label. [default: channel name]
  --sn=SCREEN_NAME    specify the file name of the screen opened when one
                      click the button. The relative or absolute path can be
                      included. [default: a name guessed from the channel
                      name. e.g. C1LSC_OUTPUT_MTRX.adl for C1:LSC-OUTPUT_MTRX]


>./generate_KisselButton.py --bw=3 --bh=4 --dl="RFPD InMTRX" 16 8 C1:LSC-PD_DOF_MTRX > rfpd_mtrx.adl

>./generate_KisselButton.py --sc=21 --bw=6 --bh=4 --dl="DCPD InMTRX" 27 8 C1:LSC-PD_DOF_MTRX > dcpd_mtrx.adl

>./generate_KisselButton.py --bw=4 --bh=4 --dl="Trig MTRX" 11 8 C1:LSC-TRIG_MTRX > trig_mtrx.adl

>./generate_KisselButton.py --bw=4 --bh=4 --dl="Out MTRX" 9 10 C1:LSC-OUTPUT_MTRX > output_mtrx.adl

I used scripts/SUS/freeswing-all.csh to give the optics a kick and then turn off their watchdogs and collect the free swinging data.  Final script end time = 993173551. Start taking data ~ 993173751

I had to fix up the script a little: it had amateur stuff in there, such as undefined variables.

It still doesn't work that well. On the new Ubuntu workstations, pianosa, it fails by just not setting some of the EPICS variables using the EZCA stuff.

On Allegra, it failed on ~1 out of 10 commands by returning "epicsThreadOnce0sd epicsMutexLock failed" ???

On Pianosa, it sometimes says, instead, "epicsThreadOnceOsd: pthread_mutex_lock returned Invalid argument.".   Ah...now I understand?

So finally, I had to run the script on op340m to get it to actually run all of its commands. That's right; I used a 15 year old Solaris 9 Blade 150 because none of our fancy new Linux machines could do the job reliably.

Fixing our EZCA situation is a pretty high priority; if the locking scripts fail to run ~1 command every hour its going to completely derail the lock acquisition attempts.

If you want to use the IFO tonight, just run the script again on op340m again when you're done.

Chris Wipf tells me that the EPICS Mutex Jumbo Mumbo can be overcome by upgrading our EPICS. We should get one of Jamie's assistants to get this going on one of the Ubuntu workstations.

IMPORTANT ELECTRONICS SAFETY LESSON TO FOLLOW

Yesterday, I fried the +15 V power supply rail on one of the Eurocrate extender cards while I was checking out the binary switching in the 1X5 rack.  I will describe what I did it in the hopes that everyone else will be less stupid than me.

I wanted to monitor the voltage across a resistor on the suspension OSEM whitening board.  Since I knew that both sides of the resistor would be at non-zero voltage (including possibly at the power-supply rail), I used a battery-operated scope with floating inputs, so that the scope would not try to pull the probe shield to ground.  That should be OK, although not recommended, as you'll see, because you must be very careful to make sure that the scopes inputs are indeed floating.

Let's call the original signal 'A'.  The trouble came when I then connected another signal (B), whose shield was connected to the ground on the whitening board, to the scope.  Apparently the grounds on the scope inputs are connected, or were in the configuration I was using.  When I connected the signal B, B's ground shorted A's shield to ground, which had been sitting at the +15V rail.  That short circuit then fried the +15V supply line on the extender card I was using (escaping magic smoke was detected).  Thankfully this only blew the extender card, and not the Eurocrate or the Eurocrate power supply or the whitening board or the scope etc, all of which would have been much worse.

The moral of the story is to be very careful when connecting power supply voltages to the shield or ground of a scope.  In short, don't do it.  I didn't ultimately need to, since I could have found other ways to measure the same signal.

Please ask the owner unless  it is rotten. Do not put food into garbage can inside. Take them outside so you are not inviting ants !

I found baked allen keys on the top of the clean optics cabinet.  Somewhat heavy box that can come down in an earthquake on our heads.

NOTHING SHOULD GO ON THE TOP OF THE CABINETS OR RACKS except  small plastic boxes that storing our clean clothing.

Alberto is visiting us from Australia. He brought some terrific presents. It is going to be very demanding task to wait for the rest of the 40m team

to return from Wales to taste coffee:  PNG Peaberry of Wagonga, Monsooned Malabar of Jindebah and Signature Blue Blend of Cosmorex.

Since we are using Wiener filtering in our project, we studied the derivation of Wiener-Hopf equations. Whatever we understood we have written it as a pdf document which is attached below...

Each bottle has matched seals. They are not interchangeable.

It is critical that the solvent do not reach the rubber bulb. Practice with the pipet.

In case of solvent touching the suction bulb: do not let the solvent go back into the bottle! Remove bulb, let it dry out and rinse pipet.

It is essential that the solvent bottle must be rinsed and refilled if it's content met with the rubber bulb.

Use glass syringe with SS needle in critical application: Hamilton ~0.1 ml

I found the manual for the Low Noise Preamplifier Model 1201 at this link and I attached it.

The one we have in the lab (S/N 48332) miss the battery packs and miss also the remote programming options input/output. Its inside battery compartment is empty and I found 2 unscrewed screws with washers and nuts inside the preamplifier box. The battery cable are disconnected and they have 2 green tape labels (-) and 2 red tape label (+).

 We are at 30 Torr of 7 hours of pumping with 2 roughing pumps.

Kiwamu will take over the rest of the roughing today. He will keep an eye on  the pumping speed to be  ~1-2 Torr/min  and open up the manual RV1 valve if needed.

The present status is #3023 of  "chamber open to vacuum open" mode and waiting the P1 pressure to drop to 500 mTorr

He will do the following to stop pumping at P1 = 500 mTorr

1, close V3

2, close RV1 with torque wheel

3, turn off PR1 & 3

4, disconnect metal hose between RV1 and PR3

 I will start the Maglev tomorrow morning.

Now that we are in a moderately stable condition, its time to design the optical lever feedback transfer functions. We should think carefully about how to do this optimally.

In the past, the feedback shape was velocity damping from 0-10 Hz, with some additional resonant gain around the pendulum and stack modes. There were some low pass filters above ~30 Hz. These were all hand tuned.

I propose that we should look into designing optimal feedback loops for the oplevs. In principle, we can do this by defining some optimal feedback cost function and then calculate the poles/zeros in matlab.

How to define the cost function (? please add more notes to this entry):

1) The ERROR signal should be reduced. We need to define a weight function for the ERROR signal: C_1(f) = W_1(f) * (ERR(f)^2)

2) The OL QPDs have a finite sensing noise, so there is no sense in suppressing the signal below this level. Need to determine what the sensing noise is.

3) The feedback signal at high frequencies (30 Hz < f < 300 Hz) should be low passed to prevent adding noise to the interferometer via the A2L coupling. It also doesn't help to reduce this below the level of the seismic noise. The cost function on the feedback should be weighted apprpriately given knowledge about the sensing noise of the OL, the seismic noise (including stack), and the interferometer noise (PRC, SRC, MICH, DARM).

4) The servo should be stable: even if there is a negligible effect on the ERROR signal, we would not want to have more than 10 dB of gain peaking around the UGFs.

5) The OL QPDs are dominated by drift of the stack, laser, etc. at some low frequencies. We should make sure the low frequency feedback is high passed appropriately.

6) Minimize transmitted power rms in single arm lock etc.

GOAL1:  Stable lock of DRMI

GOAL2:  Measurement of the LSC input matrix in the DRMI configuration

 /- - Daytime works - - /

  + Measurement of the arm lengths (Jenne / Kiwamu / volunteers)

  + Optimization of the oplev control loops (Paul)

  + Inversion and installation of the SUS input matrices (Jenne)

  + Tuning of the SUS damping gains (Steve)

  + Measurement of the modulation depths (Mirko)

  + Preparation of the green broadband PD (Katrin)

  + Fixing the Y arm green lock servo (Katrin / Kiwamu)

  + Installation of RFPDs (Anamaria)

  + Minimization of the AM sidebands (Anamaria / Keiko)

  + Preparation of a script for measuring the LSC input matrix (Keiko)

  + MC WFS (Suresh)

  + Online adaptive filtering (Mirko / Jenne)

  + Modification of C1ASS (Kiwamu)

  + Fixing IPPOS (volunteers) 

  + Auto alignment of PRCL and SRCL (volunteers)

  + Loss measurement of the arm cavities (volunteers)

  + Fixing the ETMX SIDE slow monitor (volunteers)

 /- - Nighttime works - - /

 + Locking of DRMI

 + Characterization of DRMI and complete the wiki page

 It turns out that this is complicated, since there are so many people working with the IFO this week.  What I would like to do is put in the new input matricies, and then do a free swinging test, to see if the suspensions are really diagonalized in the way that we want them to be.  I can't do this during the day, since it will interfere with Paul's OpLev work.  And at "night", I can't, since we'll be doing locking.  So, this may be a late-night task.  I'll write a script this afternoon that will put in all of the new input matricies, and then run the freeswing and the restore watchdogs scripts.  Whomever is the last one to leave for the night can run the combo script.

EDIT:  As of this time (~11:45am), ITMY has its new input matrix.

 Here I note the procedure for the demodulation board orthogonality check for the future reference.

1. prepare two function generators and make sure I an Q demodulation signals go to the data acquisition system.

2. sync the two generators

3. drive the function generator at the modulation frequency and connect to the LO input on the demod board

4. drive the other function generator at the modulation frequency + 50Hz  the RF in

5. run "orthogonality.py"  from a control computer scripts/demphase directory. It returns the amplitude and phase information for I and Q signals. If necessary, compensate the amplitude and phase by the command that  "orthogonality.py" returns.

If you want to check in the frequency domain (optional):

1. 2. 3 are the same as above.

4. drive the function generator at the LO frequency + sweep the frequency, for example from 1Hz to 1kHz, 50ms sweep time. You can do it by the function generator carrier frequency sweep option.

5. While sweeping the LO frequency, run "orthogonality.py"

6. The resulting plot from "orthogonality.py" will show the transfer function from the RF to demodulated signal. The data is saved in "dataout.txt" in the same directory.

 I copied the Kissel button generator scripts folder into scripts:

/opt/rtcds/caltech/c1/scripts/KisselButtonGenerator/

Maybe this isn't the most intuitive place ever, since it's a script that only has to do with medm screens, but at least it's better than hidden in the depths of Koji's LSC medm path.....

The Kinemetrics dudes are going to visit us @ 1:45 tomorrow (Wednesday) to check out our stacks, seismos, etc.

I put these maps here on the elog since people are always getting lost trying to find the lab.

Here's another useful link:

http://maps.google.com/maps?q=34.13928,-118.123756

Yesterday, I had the great pleasure to solder a tiny 4 x 4 mm op amp with 16 legs (AD8336).

I figured out that the best and fastest way to do it is

1. to put solder with the soldering iron on every contact of the electronic board (top side)
2. heat the bottom side of the electronic board with a heat gun
3. use a needle to test if the solder is melted
4. if it is melted place the op amp on the electronic board
5. apply some vertical force on the op amp for proper contact and heat for 1 to 2 more minutes
6. done

I made a test installation of ligo_viewer in /users/volodya/ligo_viewer-0.5.0c . It runs on pianosa (the Ubuntu machine) and needs Tcl/Tk 8.5.

To try it out run the following command on pianosa:

cd /users/volodya/ligo_viewer-0.5.0c/

./ligo_viewer.no_install

Press "CONNECT" to connect to the NDS server and explore. There are slides describing ligo_viewer at http://volodya-project.sourceforge.net/Ligo_viewer.pdf

Installation notes:

Use /users/volodya/ligo_viewer-0.5.0c.tgz or later version - it has been updated to work with 64 bit machines.

Make sure Tcl and Tk development packages are installed. You can find required packages by running

apt-file search tclConfig.sh

apt-file search tkConfig.sh

If apt-file returns empty output run apt-file update

Unpack ligo_viewer-0.5.0c.tgz, change into the created directory.

Run the following command to configure:

export CFLAGS=-I/usr/include/tcl8.5
./configure --with-tcl=/usr/lib/tcl8.5/ --with-tk=/usr/lib/tk8.5/

This works on Ubuntu machines. --with-tcl and --with-tk should point to the directories containing tclConfig.sh and tkConfig.sh correspondingly.

Run "make".

You can test the compilation with ./ligo_viewer.no_install

If everything works install with make install

If Tcl/Tk 8.5 is unavailable it should work with Tcl/Tk 8.3 or 8.4

 This may or may not be general knowledge already, but Jamie and I added a HowTo explaining how to retrieve channel data from the frame builder via NDS, but off site on one's own computer.  See the Wiki page:

https://wiki-40m.ligo.caltech.edu/How_To/NDS

Or, how a lab should look at the end of every day.

Beat that, Bridge kids!

Type: How not to

Please do not leave optical tables open! You will be held responsible for creating dirty optics.

For your mode matching pleasure, I have added a tool called "ModeMatchr" to the SVN under /trunk/zach/tools/modematchr/

It uses the usual fminsearch approach, but tolerates a fully astigmatic input (i.e., w_0ix ≠ w_0iy, z_0ix ≠ z_0iy) and allows for transforming to an elliptical waist  (i.e., w_0fx ≠ w_0fy, but z_0fx = z_0fy). It would be straightforward to allow for z_0fx ≠ z_0fy, but I have never seen a case when we actually wanted this. On the other hand, the elliptical output ability is nice for coupling to wide-angle ring cavities.

It also does the looping through available lenses for you , and retains the best solution for each lens combination in an output cell, which can then be combed with another function (getOtherSol). fminsearch is incredibly fast: with a 10-lens bank, it finds all 100 best solutions on my crappy MacBook in <10s.

I have also included the functionality to constrain the length of the total MMT to within some percentage of the optimal distance, which helps to sift through the muck .

I have added to ModeMatchr the capability to fix the total MMT distance. This is nice if you are coupling to a cavity some fixed distance away. The blurb from the help:

% Note: for any total length constraint dtot_tol > 0, ModeMatchr will use
% fminsearch to find the best solutions near your nominal dtot, and then
% omit solutions whose dtot lie outside your tolerance. For dtot_tol = 0,
% ModeMatchr actively constrains dtot to your value, and then finds the
% best solution. Therefore, set dtot_tol = 0 if you have a fixed distance
% into which to put a MMT.

To start the optical lever filter design, I looked into the noise on ITMY. It should be similar to the other arm cavity optics since they have the same whitening electronics.

The RED/BLUE are with loops open. The MAGENTA/CYAN with loops closed. Looks good; the bandwidth is a few Hz and there is not much peaking,

To figure out the contribution from the dark noise I misaligned the ITMY until the sum on the QPD went to zero. Then I took the spectra of the OL{1,2,3,4}_OUT signals (they all looked the same).

To normalize them properly I took OL4, multiplied it by 2 to account for the incoherent sum of 4 channels and then divided by the nominal SUM (which was 14685 counts). I've left the OL3 un-normalized to show the ratio.

From this plot it seems that the dark noise is not a problem at any frequency (no need to amplify for the new ADCs).

I'm going to use the open loop spectra to design the optimal feedback control. The file is saved as /users/rana/dtt/ITMY_OL-120325.xml

Jenne and Yuta's Summer Plan

These are the things that we'd like to accomplish, hopefully before Yuta leaves in mid-July

* Yarm mode scan

  ~ Measure residual motion of Yarm cavity when ALS is engaged

* Xarm mode scan

  ~ Align Xarm IR

  ~ Align Xarm green to cavity

  ~ Do mode scan (similar to Yarm)

  ~ Measure residual motion of Xarm cavity when ALS is engaged

* Hold both arms on IR resonance simultaneously (quick proof that we can)

  ~ Modify beatbox so we can use both X and Y at the same time (Jamie will do this Wednesday morning - we've already discussed)

* PRMI + Arms

  ~ Lock the PRMI (which we already know we can do) holding arms off resonance, bring both arms into resonance using ALS

* PRC mode matching - figure out what the deal is

  ~ Look at POP camera with video capture - use software that Eric the Tall wrote with JoeB to measure spot size

* DRMI glitches

  ~ Why can't we keep the DRMI locked stably?

* DRMI + Arms

  ~ Full lock!!

  ~ Make lots of useful diagnostics for aLIGO, measure sensing matricies, etc.

We've been talking for a while about how we want to store data.  I'm not in love with keeping it on the elog, although I think we should always be able to reference and go back and forth between the elogs and the data.

I have made a new folder: /data    EDIT: nevermind.  I want it to be on the file system just like /users, but I don't know how to do that.  Right now the folder is just on Ottavia. Jamie will help me tomorrow.

In this folder, we will save all of the data which goes into the elog. 

I propose that we should have a common format for the names of the data files, so that we can easily find things.

My proposal is that one begins ones elog regarding the data to be saved, and submit it immediately after putting in the first ~sentence or so. One should then make a new folder inside the data folder with a title "elog#####_Anything_Else_You_Want" Then, data (which was originally saved in ones own users folder) should be copied into the /data/elog#####_AnythingElse/ folder. Also in that folder should be any Matlab scripts used to create the plots that you post in the elog.  One should then edit the elog to continue making a regular, very thorough elog, including the path to the data.  Elog should include all of the information about the measurement, state of the IFO (or whatever you were measuring), etc. 

Riju will be alpha-testing this procedure tonight.  EDIT: nevermind...see previous edit.

Riju, Jenne

We have checked the transfer function of a bandpass filter using AG4395A network analyzer and retrieved the data through GPIB. The RF out signal of AG4395A had been divided by splitter with two outputs of the splitter going to through R and the filter which was connected to the A channel of the network analyzer. The GPIB data came in complex data format, from which the absolute value and phase had to be retrieved. 

The plot for the TF is as following

Clean cabinet S15 doors were left open. You have to lock it up!

This is how to post PDF:

From DTT, print the plot as a postscript file.

Then use ps2pdf to make a archival PDF version (the flag is the key!). Example:

ps2pdf -dPDFX /home/controls/Desktop/darm.ps

 I'm taking full responsibility for this action and I told them after lunch Friday.

HOW NOT TO:

The BS isolation stack  supported by two beam tubes and they can pivot around the pivot point.

I have started making the circuit to measure the transimpedance for the photodiode PDA10CF using Jenne's laser. I will continue it tomorrow.

How NOT to:

The janitor can not clean in areas like this. He may only steps on these cables accidentally as he dust wiping our chambers.

 Sorry for the mess. I fixed it.

Immediate things to do include finishing installation of new TTs and re-routing of oplev paths in the BS chamber, but after all that, we should retry in-air locking.

The last time we (I) tried in-air locking, MICH wouldn't lock since there was only ~ 6uW of light on AS55 (see elog 7355).  That was before we increased the power into the MC by a factor of 10 (see elog 7410), so we should have tens of microwatts on the PD now.  At that time, we could barely see some PDH signal hidden in the noise of the PD, so with a factor of 10 optical gain, we should be able to lock MICH.

REFL should also have plenty of power - about 1.5 times the power incident on the PRM, so we should be able to lock PRCL. 

Even if we put a flat G&H mirror after the PRM to make a mini-cavity, and we lose power due to poor mode matching, we'll still have plenty of power at the REFL port to lock the mini-cavity.

For reference, I calculate that at full power, POX and POY see ~13uW when the arms are locked.

POX/POY power =  [  (P_inc on ITM) + (P_circ in arm)*(T_itm)  ] * (pickoff fraction of ITM ~ 100ppm)

REFL power = (P_inc on PRM) + (P_circ in PRCL)*(T_prm)     =~ 1.5*(P_inc on PRM)

Today I found 3 power cables in the orange Pomona cable tray, put in so that the cables were damaged and therefore dangerous.

Please think about what you are doing before doing it. Damaging these things because your are in a hurry or frustrated will just waste our time and damage our interferometer.

For reference, we only use the thick blue Pomona racks for power cables. We use the orange and black ones for thinner cables. Pay attention and keep the cables organized.

Cable Rack Selection

List of things to do, in order:

* Remove BS heavy door.  Steve, please remove the BS door as soon as you have enough people to do so.  I will be a little late, since I have a dentist appointment, but please don't wait for me.  Jamie and Manasa can help you.  Put on a light door.

* Remove MC light doors, make aluminum foil tube (not light access connector, yet).

* Open laser shutter, lock PMC. (Required slight tweaking of input steering.) Confirm power level into vacuum <100mW.

* Lock MC and check spot positions of MC (quickly.  this shouldn't take all day, hopefully).

-------------------------------  End of work for Monday.  See following elog ------------------------------------------------

* Move TT1 to be as close as possible to the location indicated on the diagram, then align it. 

         * Make sure beam out of Faraday is hitting the center of the optic.

         * Make sure beam reflected off of TT1 hits center of PZT2.  Only use actuators for the final alignment, then confirm that they aren't close to the edge of their ranges.

         * Lock down TT1 with dog clamps.

* Put light access connector on MC.

* Swap PZT2 out with TT2.  Should be at correct spot, according to diagram, and beam should be hitting center of optic.  Alignment only to the ~few degree point here.

* Re-level BS table.

* Fix oplevs that need fixing.  (Manasa should have the plan on one of the diagrams).

* Put target on PRM cage.

* Align TT2 so that beam goes through PRM target.

* Open ITMX heavy door. (Probably Tuesday morning).

* Place freestanding target in front of PR2.  Ensure TT2 is aligned to go through PRM target, and hit center of PR2.  Again, save actuators for fine-tuning.

At this point, I think we should (temporarily) install one of the G&H mirrors as a flat mirror facing the PRM, and see if we can lock that cavity using REFL.  We will want to have already created a model for this case, to compare our observations to.  Or we could align the full PRMI, and try to lock that in air.

 I studied the eigenfrequencies of a mirror support using COMSOL.

 I studied the eigenfrequencies of a mirror mount designed with COMSOL.

I imposed fixed constraints for the base screws and for the screw connecting the base with the pedestal. Note that the central screw is connected to the base only for a small thickness, and the pedestal touches the base only with a thin annulus. This is in way to make a better model of the actual stress.

Shown in fig. 2 is the lowest eigenfrequency of the mount.

I' going to change the base and study the way the eigenfrequency vary, in way to find the configuration which minimizes the lowest eigenfrequency.