40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 263 of 336  Not logged in ELOG logo
ID Date Author Type Category Subject
  3727   Fri Oct 15 06:31:52 2010 kiwamuUpdateGreen LockingPSL beat note setup: part II

 I made some KAIZENs (what does kaizen mean ? ) for the PSL green setup.

I replaced the lenses for the modematching of the two green lights at the PSL table, and the beams now look pretty identical.

Also I tuned the temperature setpoint of the doubling crystal and eventually the green light increased to 14 uW at the PSL table.

Once I finish the modification of the RFPD tomorrow, I am going to search for the beat note signal.

 


( details )

 - In-vac green mirrors

   I found one of the green steering mirror, which stands at the corner of the MC table, was clipping the green light.

  So I steered another mirror, which sends the beam to the clipping mirror after the downward periscope.

 I touched also the last steering mirror in the OMC chamber to correct the alignment.

 

 - temperature of the doubling crystal

   I took a quick temperature scan in order to find an optimum point for the crystal temperature.

  The scan was performed by just turning the heater off after I heated up the crystal up to 40 deg. 

  Using the NewPort power meter I found the optimum point around 37.3 deg. So I set the temperature to that point.

 

 - mode matching lenses

 As written in this entry , Kevin and I had put some lenses to make the two green beam almost the same size at the RFPD.

 But today while I was checking these mode-profiles by using a sensor card, I found they were not so matched.

 Therefore I replaced these lenses to match them more.

The idea of this replacement is t to let them have a long Rayleigh range, such that they can efficiently and easily interfere because of the flatness of their wave fronts along a distant.

 For the green light from the chamber, I put one more lens to form a Keplerian beam shrinker (see here about the Keplerian lens configuration).

 They look pretty identical now.

 

  3726   Fri Oct 15 00:15:52 2010 KojiUpdateIOO2W NPRO laser output power versus temperature

From the plot, you observed the reduction of the output power only by 1% between 25deg to 45deg.
This does not agree with the reduction from 2.1W to 1.6W.
Is there any cause of this discrepancy?

Quote:

 

tempscan.png

 

The measurement was made by attenuating the roughly 2W laser beam by a stack of two Neutral Density filfers and then measuring the transmitted light with the PDA36A photodetector.  This was because both the power meters used in the past were found to have linear drifts in excess of 30% and fluctuations at the 10% level. 

 

  3725   Thu Oct 14 23:33:45 2010 SureshUpdateIOO2W NPRO laser output power versus temperature

Steve measured an apparent power drop in the 2W NPRO output from 2.1W to 1.6W(elog entry no 3698) at 2.1A of diode current in the laser (elog entry:  2822).  It was later noticed that the laser temperature was set to about 45 degC while the initial calibration was done at 25 deg C.  

It was felt that the recent power drop may have something to do with the increase in the operating temperature of the laser from 25 to 45 deg C.  Therefore the laser was returned to 25 deg C and the power output was remeasured and found to be 2.1W as it was at the begining(elog entry:3709)

It was also noticed that returning the laser to 25 deg. C resulted in a loss of efficiency in coupling to the PMC.  We suspected that this might be due to multimode operating conditions in the laser at particular operating temperatures.  In order to see if this is indeed the case the laser power output was observed as a function of temperature.  We do notice a characteristic saw-tooth shape which might indicate multimode operation between 39 and 43 deg C.  It is best to verify this by observing the power fluctuations in the transmitted beam of the stabilised reference cavity.

 

tempscan.png

 

The measurement was made by attenuating the roughly 2W laser beam by a stack of two Neutral Density filfers and then measuring the transmitted light with the PDA36A photodetector.  This was because both the power meters used in the past were found to have linear drifts in excess of 30% and fluctuations at the 10% level. 

 

 

Attachment 2: Scan2010.zip
  3724   Thu Oct 14 22:26:38 2010 KojiUpdateComputersNew Netgear Switch

The network cables for the Martian network were moved to the new Netgear switch from the old one which had the broken fan.
The martian machines look happy so far.

Above the new switch we have the GC network switch. The two fans of it were also broken. The fans were replaced.

They are now quiet and I am quite satisfied.

Quote:

I removed some old equipment from the rack outside the control room and stacked them next to the filing cabinets in the control room. I also mounted the new Netgear switch in the rack.

 

  3723   Thu Oct 14 20:49:50 2010 yutaUpdateComputersautomated Q-value adjuster

Background:
 Now we can use pyNDS(see elog #3722), so I wrote a python script that adjusts Q-value automatically.

What I did:
1. Wrote a python script. /cvs/cds/caltech/users/yuta/scripts/QAdjuster.py

2. Ran this script for every DOF, every MC suspension.

Result:
 Following lines and attached are example output when I ran QAdjuster.py for MC3 POS.

Currently, C1:SUS-MC3_SUSPOS_GAIN is 5

Connecting.... authenticate failed: Unspecified error
Connecting.... done
Current GPS time is 971149410

I kicked C1:SUS-MC3_SUSPOS_OFFSET

Waiting for the ringdown...... 0\

Current GPS time is 971149431

omega_0= 6.326764,
Q= 11.254252,
A= -53.491850,
delta= 5.007821,
ofset= 4349.808434

Q-value was 11.3
Set C1:SUS-MC3_SUSPOS_GAIN = 10.2311380794


 Current Q-values automatically set are as follows.

  MC1 MC2 MC3
POS 4.9 4.8 5.9
PIT 6.8 5.5 4.5
YAW 6.4 5.6 5.3
SIDE 5.8 5.2 5.0


Next work:
 - Modify the script so that it adjusts all the channels automatically. Now, it is one by one, trial by trial.
 - Modify the script so that it automatically turns the offset switch on. Now, it must be turned on beforehand.
 - Write a how-to

Attachment 1: MC3_SUSPOS.png
MC3_SUSPOS.png
  3722   Thu Oct 14 20:31:15 2010 yutaUpdateComputerspyNDS installation

EDIT by kiwamu Dec.7th ;

The Pynds package has been moved to the appropriate place:

/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages

Background:
 We need the python module pyNDS to get the data directly from the server using python.
 Leo helped us install pyNDS today.

Installation:
1. Get pyNDS source tarball from here.
  https://www.lsc-group.phys.uwm.edu/daswg/download/software/source/pynds-0.3.tar.gz

2. All you need is Boost.Python and nds2-client. See README in the pynds-0.3 directory.

3. I installed pyNDS to /cvs/cds/caltech/users/yuta/pynds

4. You have to set environment variable to import the module. For example, run;
  setenv PYTHONPATH /users/yuta/pynds/lib64/python2.4/site-packages:${PYTHONPATH}

Notes:
 RPM will be available soon from Leo.

  3721   Thu Oct 14 14:52:52 2010 Leo SingerConfigurationComputersnumpy, ipython, matplotlib, python-matplotlib installed on rossa

I installed the following packages on rossa:

numpy, ipython, matplotlib, python-matplotlib

  3720   Thu Oct 14 14:09:30 2010 josephbUpdateCDSNDS 2 server status

[Joe, John]

The nds 2 server is about 50% of the way there.  You can connect to it and get channel lists, but its having issues actually serving the data.  The errors we're getting basically say it can't find the source data for the channel

John had to go get lunch at 2pm, but he said he'd log in remotely later and try to configure it properly.

  3719   Thu Oct 14 13:15:14 2010 Leo SingerConfigurationComputersgit installed on rossa

I installed git on rossa using:

$ sudo yum install git

  3718   Thu Oct 14 13:09:01 2010 Leo SingerConfigurationComputersnds2-client-devel installed on rossa

I installed nds2-client-devel on rossa using the following command:

$ sudo yum install nds2-client-devel

  3717   Thu Oct 14 12:53:29 2010 yutaUpdatePSLmesured PMC's visibility vs power relation

Background:
 I measured the PMC's visibility vs incident power relation last week to see the thermal effect, but I didn't calibrated the laser power(see elog #3672).
 So, I calibrated it on Oct 12.

Setup:

 Attachment #1
 The laser grade window PW-1025-UV-1064-45P had power reflectivity of about 0.5% in this setup.

What I did:
1. Calibrated the laser power(Attachment #2).
  To measure the laser power, I put the Ophir power meter at just in front of "PMC REFL PD".

2. For the calculation of the visibility K, I used the following formula;
 K= [1-(R1-R0)/(R2-R0)]*100
where R0, R1 and R2 are the PD outputs in voltage when laser is off, PMC locked and not locked respectively.

3. Plotted the visibility vs the incident power(Attachment #3).

Result:
 Attachment #2
  From the linear fit by least squares, the calibration turned out to be 1.12±0.07 mV/uW. The error of this value is calculated from assuming PD output error~1mV and laser power error~3uW for all measured value.
  The largest error was from the position and the angle of the power meter probe.

 Attachment #3
  I used the same data I took last week(see elog #3672), but better plot.
  I put the error bars for just several points. When the laser power is weak, the errors are large because of the cancellation error. When the laser power is high, the errors are estimated to be so small that you can't see it in the plot(~1%).
  At the several points, I couldn't lock the PMC well and  the power of the reflected light depended on the offset voltage of the PZT.
  The horizontal axis has about 6% error because of the calibration error.

Note:
 Now the condition is a bit different from this measurement(NPRO temperature changed, optics moved slightly), so the visibility may be changed.

Attachment 1: PMCsetup.png
PMCsetup.png
Attachment 2: PDcalib.png
PDcalib.png
Attachment 3: PMCreflect2.png
PMCreflect2.png
  3716   Thu Oct 14 12:45:47 2010 josephbUpdateComputersNDS 2 server installation on mafalda

[Joe, John Zweizig]

John stopped by around noon today to install the NDS 2 server.  He installed it /cvs/cds/caltech/users/jzweizig/nds2-server/.

Once John is done, I will be moving this to a more sensible install location that is not his user directory, but its there for the moment.

We had to install a couple more packages including bzip2, bzip2-devel, gcc-c++, openssl, and openssl-devel. 

We mounted the /frames directory from the fb machine to mafalda by modifying the /etc/fstab file with the line:

fb:/frames              /frames                 nfs     bg,ro           0 0

 

If we change channels recorded by the frame builder, we need to update a channel list file for the NDS 2 server.  There's an excutable located at:

/cvs/cds/caltech/users/jzweizig/nds2-server/bin/buildChannelList

This builds the file list if given a .gwf file.  These are written by the frame builder, and can be found in /frames/full/####, where #### are the first 4 gps digits of the gravity files contained in that directory.

Upon questing about when we get to GPS time 1000000000, he said there's some updates he needs to do so it rather throws away the last 5 digits, rather than keeping the first 4.

An example command run on the fb or mafalda machine is:

/cvs/cds/caltech/users/jzweizig/nds2-server/bin/buildChannelList  /frames/full/9711/C-R-971119728-16.gwf > nds2-mafalda/C-R-ChanList.txt

For a seconds trends file (located in /frames/trends/second/ instead of /frames/full)

/cvs/cds/caltech/users/jzweizig/nds2-server/bin/buildChannelList  /frames/trends/second/9711/ C-T-971106780-60.gwf > nds2-mafalda/C-T-ChanList.txt

For a minute trends file (located in /frames/trends/minute)

/cvs/cds/caltech/users/jzweizig/nds2-server/bin/buildChannelList  /frames/trends/minute/9711/C-T-971106780-60.gwf  > nds2-mafalda/C-M-ChanList.txt

In these cases, John was putting the lists in the /cvs/cds/caltech/users/jzweizig/nds2-mafalda/ directory.

 

Both the  C-raw-cache.txt file and the nds2.conf files need to be configured to point at the correct files in the nds2-mafalda directory.

 

  3715   Thu Oct 14 10:59:10 2010 josephbUpdateComputersUpdated cshrc.40m and Computer Restart Procedures

I started modifying the cshrc.40m file in /cvs/cds/caltech/ so that it starts pointing at the new directories.

# misc aliases
alias target 'cd /opt/rtcds/caltech/c1/target'
alias scripts 'cd /opt/rtcds/caltech/c1/scripts'
alias chans 'cd /opt/rtcds/caltech/c1/chans'
alias c 'cd /opt/rtcds/caltech/c1'
alias s 'cd /opt/rtcds/caltech/c1/scripts'
alias u 'cd /cvs/cds/caltech/users'

I also added "alias screens 'cd /opt/rtcds/caltech/c1/medm'" as a quick way to get to the medm directory.

Once we get multiple compiled versions (i.e. i386, x86_64, Solaris) of the new gds tools from Alex, we'll have to some more serious surgery on this file.

I removed the "New Computer Restart Procedures" and simply moved the changes into the "Computer Restart procedures", found here.  I've removed everything I don't think applies anymore (all the VME FE reboot procedures for example).

  3714   Thu Oct 14 10:29:33 2010 josephbUpdateComputersMafalda ready for NDS2, updated Rosalba, Rossa repos

At John Zweizig's request, I installed a couple of packages from the lscsoft repository, along with libtools, automake, autoconf, and several kerberos packages, including cyrus-sasl, cyrus-sasl-lib, cyrus-sasl-devel, cyrus-sasl-gssapi, and krb5-libs.  All it needs now is John to come down and install the NDS2 server.

I copied the lscsoft.repo file from /etc/yum.conf.d/ on allegra to mafalda, as well as rosalba and rossa, just for completeness.  I also added the epel repository to rossa and installed the yum-priorities package and set the priorities on rossa's repositories. 

  3713   Thu Oct 14 01:09:17 2010 yutaUpdateIOOtried to lock MC but failed

(Rana, Koji, Kiwamu, Suresh, Yuta)

 We attempted to lock the MC and finally got flashes of the MC, but no luck. 

Tomorrow we are going to check every components one by one to make sure if everything is okay or not.


Background:
 MC suspensions are well damped now.
 We need MC locked for the alignment of the in-vac optics.

Issues:

  These are the issues which we are going to fix.
1. DC alignment of the MC2 suspension doesn't seem to be working correctly. (see here)

  We should check the satellite box and the cable connection.

  The coils look like woking fine because we can kick MC2 by using each of the coils.


2. Incomplete modematching.

The spot size of the reflected light from MC1 looked like bigger. 

3. beam axis of the injection light to MC1

  3712   Thu Oct 14 00:54:12 2010 ranaHowToCDSBad PSL Quad, so I edited the SUS MEDM screens

We found today that there was some (unforgivably un-elogged) PSL-POS & PSL-ANG work today.

The wedge splitter at the end of the PSL table is so terribly dogged that it actually moves around irreversibly if you touch the post a little. Pictures have been recorded for the hall of shame. This should be replaced with a non-pedestal / fork mount.

I was so sad about the fork clamp, that I edited the SUS Master screen instead according to Joe-Yuta instructions; see attached.Untitled.png

There's clearly several broken/white links on there, but I guess that Yuta is going to find out how to fix these from Joe in the morning.

  3711   Thu Oct 14 00:53:44 2010 kiwamuUpdateSUSwhat's wrong with MC2

It turned out that the DC alignment of MC2 from epics doesn't helathily work.

For example, the pitch slider does drive the yaw alignment as well.

 

Is this somehow related to the unknown MC2 jump happened around September 10th ?? (see the trend below)

OSMEs.png

  3710   Thu Oct 14 00:04:46 2010 yutaUpdateSUSQ-value adjustment for MC dampings

Background:
 We need MC to be locked soon, so MC suspensions should be damped well(Q~5).

What I did:
1. Set the correct filters and turn all the damping servo on.

2. Kick the optics by adding some offset into the control loop.

3. Measure the Q-value of the ringdown with my eye.

4. If Q-value seems to be around 5, go to step #5. If not, change the filter gain and go to step #2.

5. Done! Do step #1-4 for all MCs.

All parameters I used for the servo are automatically saved here;
  /cvs/cds/caltech/burt/autoburt/snapshots/2010/Oct/13/20:07/c1mcs.epics

Result:
 Q-values of the damping servo for all MCs are set to around 5.
 Attached is the ringdown of MC2 for example.
 As you can see, my eye was very rough......

Next work:
 - Make a script that does steps #2-5 automatically.
    I need pyNDS module installed to get data using Python.
    I already wrote the rest of the script.
    We'll have Leo help us install pyNDS tomorrow.

Attachment 1: MC2ringdown.png
MC2ringdown.png
  3709   Wed Oct 13 21:08:40 2010 kiwamuUpdatePSLNPRO is still alive

 The NPRO at the PSL table still can generate 2W laser !  He is still alive.

  When I reduced the temperature to  25 deg, the output power increased to 2W successfully.

  As Steve wrote down in his last entry (see here), the NPRO output was at 1.6 W currently, which is supposed to be 2W.

We were suspicious about the laser crystal's temperature because the current temperature looks a bit high.

In fact the setpoint of the temperature was 45.9 deg instead of 25 deg that is the previous setpoint.

 

  3708   Wed Oct 13 18:01:43 2010 yutaHowToCDSeditting all the similar medm screens

(Joe, Yuta)

Say, you want to edit all the similar medm screens named C1SUS_NAME_XXX.adl.

1. Go to /opt/rtcds/caltech/c1/medm/master and edit C1SUS_DEFAULTNAME_XXX.adl as you like.

2. Run generate_master_screens.py.

That's it!!

  3707   Wed Oct 13 17:12:33 2010 josephb, yutaUpdateCDSFilter name length problem found and fixed

The missing filter files for ULPOS, URPOS, and so forth for the mode cleaner optics was due to the length of the names of the filters. 

This was not a problem for the c1sus model because it was using its own name as the first 3 letters of its designation.  A filter for the sus model would be called something like BS_TO_COIL_MTRX_0_0, while for the mcs it would be called SUS_MC1_TO_COIL_MTRX_0_0, an extra 4 characters.

However, the c1mcs model used the "top_name" feature which uses a subsystem box within the simlink model to rename all the channels.  Apparently in the filter file, this means it has to add the top name to the front of everything, adding an additional 3 characters.  This pushed things over the length limit.

A hard cap of 18 characters has been added to the FiltMuxMatrix.pm file (located in /cvs/cds/caltech/c1/, so that it will prevent this type of problem in the future by stopping at compile time and presenting a helpful error message.

I also fixed a bug with too many spaces in the feCodeGen.pl file when dealing with top_names and the filtMuxMatrix.pm preventing some .adl files from being generated.

Also of interest, MC3 appears to never have had F2A filters.  For the moment we're running without them, but since they're just a fine tuning it shouldn't affect locking tonight.

 

Improbability factor of mode cleaner suspensions working tonight: ~20

 

  3706   Wed Oct 13 17:04:34 2010 josephb, yutaUpdateCDSburt restore now working with filter settings

Previously, burt restoring was not setting filters on and off, which was required us to constantly go through all the filter banks and turn them on.  We figured it out that the autoBurt.req file doesn't seem to be setup to restore those values, so that snapshots made with the default .req file don't restore either.

So I went to each of the suspension directories (/opt/rtcds/caltech/c1/target/c1SYS/c1SYSepics/   where SYS is sus, mcs, or rms) and modified teh autoBurt.req files found there with the following incantation:

sed -i 's/RO \(.*SW[12]R.*\)/\1/' autoBurt.req

This removes the RO at the beginning of the lines which have SW1R or SW2R in them.  These are the channels which correspond to filter bank switches.  As far as I can tell, the RO means to leave it alone.  Unfortunately, I didn't see an obvious autoBurt file specification in the DCC or on google in the 2 minutes I took to look for it.

We need to talk to Alex to figure out how that autoBurt.req file is generated and get it so it doesn't default to not restoring filter bank settings.

  3705   Wed Oct 13 11:09:28 2010 yutaUpdateComputersclean-installed CentOS 5.5 on mafalda

Dear mafalda,

Sorry for leaving you alone.
We put ethernet cable in you. You can talk to everyone now!
We created a user "controls" correctly. (UID: 1001)
We mounted linux1:/home/cds/ to your directory /cvs/cds.

Truly yours,
Joseph Betzwieser
Yuta Michimura

Quote:

Quote:

I clean-installed CentOS 5.5(32bit) on mafalda.
No firewalls, no SELinix.

 Yuta has removed my ethernet connection. Help me!!!

rossa:mDV>ping mafalda
PING mafalda.martian (192.168.113.23) 56(84) bytes of data.
From rossa.martian (192.168.113.215) icmp_seq=2 Destination Host Unreachable
From rossa.martian (192.168.113.215) icmp_seq=3 Destination Host Unreachable
From rossa.martian (192.168.113.215) icmp_seq=4 Destination Host Unreachable

--- mafalda.martian ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3999ms
, pipe 3

 

  3704   Wed Oct 13 09:35:41 2010 ranaUpdateelogstart script edited

The existing elog restart script was running the kill process in the background using the '&' symbol before starting new elog process. This is a BAD idea since there's no way to make sure that the background process has actually worked before the new one tries to start.

That's why you sometimes had to run the script twice. I've removed all of the background "cleverness" so now it will take ~2s more for the script to run - however, it now actually works. We may also upgrade from v2.7.5 to 2.8 today.

  3703   Wed Oct 13 00:35:26 2010 kiwamuUpdateGreen LockingPSL beat note setup

[ Kevin and Kiwamu ]

 We made the setup for the green PLL stuff on the PSL table.

 Now the two green beams are happily going to the RFPD.

Tomorrow we try to catch the beat note signal 

 

  - - - what we did

 * took the two light doors out from the OMC and the MC chamber in order to let the green light go through there.

 * using aluminum foils we covered the space between the OMC and the MC chamber in order to protect from dust

 * aligned the steering mirrors inside of the chamber because the height of the green light coming out from the chamber had been a little bit low at the PSL table.

 * at the PSL table we put several steering mirrors and a beam splitter which combines the two green lights

 * installed Hartmut's RFPD and applied -150V bias on it.

 * put a lens on each path of the green beam in order to make the beam size approximately the same at the RFPD

 * closed the light doors

 

- - - Notes

 * At the beginning, an output signal from the RFPD was pretty small ( less than 1mV at DC ), so I replaced a feedback resistor that was 241 Ohm by 24 kOhm.

   As a result the signal became about 10mV when the green lights go into the PD.

* Actually the power of the green beams are so weak.

  I measured them by using a Newport power meter, it said something like 4 uW for both of the green lights. 

  One of the reasons is that the transmitted light from the PMC which generates one of the green lights is already weak. It's about 480 mW ( while more than 600 mW was reflected by the PMC ! ).

  I am going to make sure if these numbers are reasonable or not.

 

  3702   Tue Oct 12 23:45:55 2010 ranaConfigurationDAQNDS2

I installed the NDS2 Client onto the workstations today using the instructions that Zach put onto the Wiki with a couple of modifications.

1) Instead of the adding path stuff in Matlab, I added the LD_LIBRARY_PATH and MATLABPATH variables into the .cshrc as instructed by JZ's NDS2 Wiki.

2) I installed the stuff into the shared /cvs/cds/caltech/apps/linux64/ partition so that it works now on all the 64-bit CentOS 5.5 workstations.

To run it you do:

> kinit albert.einstein

> matlab -nodesktop -nosplash

> help NDS2_GetData

(set the server to the NDS2 server that you like - the example in the help is fine)

> result = NDS2_GetData({'L1:LSC-DARM_ERR'}, 957313530, 10, server);

> plot(result.data)

Now you can get any of the S6 data super fast.

(** Remember to run kdestroy as soon as you are finished so that no one else in the control room can use your personal credentials. **)

Attachment 1: cerberus.jpg
cerberus.jpg
  3701   Tue Oct 12 23:35:12 2010 mafaldaUpdateComputerscelan-installed CentOS 5.5 on mafalda

Quote:

I clean-installed CentOS 5.5(32bit) on mafalda.
No firewalls, no SELinix.

 Yuta has removed my ethernet connection. Help me!!!

rossa:mDV>ping mafalda
PING mafalda.martian (192.168.113.23) 56(84) bytes of data.
From rossa.martian (192.168.113.215) icmp_seq=2 Destination Host Unreachable
From rossa.martian (192.168.113.215) icmp_seq=3 Destination Host Unreachable
From rossa.martian (192.168.113.215) icmp_seq=4 Destination Host Unreachable

--- mafalda.martian ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3999ms
, pipe 3

  3700   Tue Oct 12 22:06:08 2010 yutaUpdateComputerscelan-installed CentOS 5.5 on mafalda

I clean-installed CentOS 5.5(32bit) on mafalda.
No firewalls, no SELinix.

  3699   Tue Oct 12 17:42:57 2010 yutaUpdateSUSvery first measurement of Q-values for MC1

Background:
 Data aquisition system is fixed, and now we can use the Dataviewer to measure Q-values of the ringdowns for each DOF, each optics.
 First of all, I measured MC1 suspention damping servo for a test.

What I did:
1. Used DAQ channels activated in this entry(#3690) to see and compare the ringdowns when the damping servo is on and off with the Dataviewer.

2. Plotted the data and fitted the ringdown using this formula;
  p[0]*exp(-p[1]*t)*sin(p[2]*t+p[3])+p[4]
 I used python's scipy.optimize.leastsq for the fitting.

3. Calculated the resonant frequency f0 and Q-value using following formulas;
  f0=2*pi*sqrt(p[1]**2+p[2]**2)
  Q=f0/(2*pi)/(2*p[1])

4. For plotting, I subtracted the offset(=p[4]).

All parameters I used for this measurement are automatically saved here;
  /cvs/cds/caltech/burt/autoburt/snapshots/2010/Oct/12/13:07/c1mcs.epics
(-1,0,1 for all matrix elements, GAIN=3,3,3,150 for POS,PIT,YAW,SIDE)

Result:
 Attached is the plot of each 4 DOF ringdown when servo is off and on.
 "servo off" means off for that DOF. Servo for the other 3 DOFs are on.

 As you can see clearly, the damping servo is working.

 The resonant frequencies and Q-values calculated from the fitting are as follows;

  servo off servo on
f0 (Hz) Q f0 (Hz) Q
POS 0.97 large 0.97 16
PIT 0.71 96 0.73 6.9
YAW 0.80 100 0.82 8.9
SIDE 0.99 large 0.99 27


 Resonant frequencies and Q-values have about 1% and 10% error respectively.
 I estimated it from my 2-time measurement of the POS ringdown.

Next work:
 - Find and modify some scripts to optimize the matrix elements
 - Calibrate the displacement
 - Do the same thing for other optics

Attachment 1: MC1ringdown.png
MC1ringdown.png
  3698   Tue Oct 12 16:35:17 2010 steveConfigurationPSLPSL output monitor in place

Innolight PSL laser is set to @2.1A , ~1.6W output ! Please scan out when finished! 

The output monitoring pick up window W2-LW-2-2050-UV-1064-45S is in place. IOO_ANG_OPD and IOO_POS_QPD roughly aligned.

The PMC alignment and/ or mode matching is bad. PMC reflected is 50%, throughput 600mW

Remember to block PSL output ! into IFO

 

  3697   Tue Oct 12 15:51:18 2010 yutaBureaucracySAFETYthe 40m squad received safety training from Peter

Yuta, Joonho, and Suresh received the Basic Laser Safety Training from Peter King today.

Now, we got homework.

  3696   Tue Oct 12 13:05:00 2010 josephb, alexUpdateCDSfb still flaky, models time out fixed

Interesting information from Alex.  We're limited to 2 Megabytes per second per front end model.  Assuming all your channels are running at a 2kHz rate, we can have at most 256 channels being set to the frame builder from the front end (assuming 4 byte data).  We're fine for the moment, but perhaps useful to keep in mind.

I talked to Alex this morning and he said the frame builder is being flaky (it crashed on us twice this morning, but the third time seemed to stay up when requesting data).  I've added a new wiki page called "New Computer Restart Prodecures" under Computers and Scripts, found here. It includes all the codes that need to be running, and also a start order if things seem to be in a particularly bad state.  Unfortunately, there were no fixes done to the frame builder but it is on Alex's list of things to do.

In regards to the timing out of the front ends, Alex came over to the 40m this morning and we sat down debugging.  We tried several things, such as removing all filters from C1MCS.txt file in the chans directory, and watching the timing as we pressed various medm control buttons. We traced it to a filters used by the DAC in the model talking to the IOP front end, which actually sends the data to the physical DAC card.  The filter is used when converting between sample rates, in this case between the 16 kHz of the front end model and the 64 kHz of the IOP.  Sending it raw zeros after having had real data seemed to cause this filter to eat up an usually large amount of CPU time. 

We modified the /opt/rtcds/caltech/c1/core/advLigoRTS/src/include/drv/fm10Gen.c file.

We reverted a change that was done between version 908 and 929, where underflows (really small numbers) were dealt with by adding and then subtracting a very small number.  We left the adding and subtracting, but also restored the hard limits on the history.

So instead of relying on just:

input += 1e-16;
junk = input;
input -= 1e-16;

we also now use

if((new_hist < 1e-20) && (new_hist > -1e-20)) new_hist = new_hist<0 ? -1e-20: 1e-20;

Thus any filter value who's absolute value is less than 1e-20 will be clamped to -1e-20 or 1e-20.  On the bright side, we no longer crash the front ends when we turn something off.

 

  3695   Tue Oct 12 01:54:32 2010 kiwamuUpdateGreen Lockingmode matching to doubling crystal on PSL table

I improved the mode matching of the incident beam to the doubling crystal on the PSL table.

As a result it apparently got better (i.e. brighter green beam), but it's not the best because now the beam is a little too tightly focused on the crystal. 

I am going to work on it again someday after seeing the beat note signal.

 

- The measured waist sizes are

    41.94 [um] for vertical mode

   42.20 [um] for horizontal mode

while the optimum waist size is 50 um (see entry #3330).

The plot below shows the beam scan data which I took after improving the mode match.

PSL_doubling.png

  3694   Mon Oct 11 23:55:25 2010 Joonho LeeSummaryElectronicsCCD cables for output signal

Today I checked all the CCD cables which is connected output channels of the VIDEOMUX.

Among total 22 cables for output, 18 cables are type of RG59, 4 cables are type of RG58.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

 

Today, I labeled all cables connected to output channels of VIDEO MUX and disconnect all of them since last time it was hard to check every cable because of cables too entangled.

With thankful help by Yuta, I also checked which output channel is sending signal to which monitor while I was disconnecting cables.

Then I checked the types of all cables and existing label which might designate where each cable is connected to.

After I finished the check, I reconnected all cables into the output channel which each of cable was connected to before I disconnected.

 

4 cables out of 22 are type of RG58 so expected to be replace with cable of type RG59.

The result of observation is as follows. 

Ch#
where its signal is sent type
1 unknown 59
2 Monitor#2  58
3 Monitor#3 59
4 Monitor#4 59
5 Monitor#5 58
6 Monitor#6 59
7 Monitor#7 58
8 unknown / labeled as "PSL output monitor" 59
9 Monitor#9 59
10 Monitor#10 59
11 Monitor#11 59
12 Monitor#12 59
13 Unknown 59
14 Monitor#14 59
15 Monitor#15 59
16 unknown / labeled as "10" 59
17 unknown 59
18 unknown / labeled as "3B" 59
19 unknown / labeled as "MON6 IR19" 58
20 unknown 59
21 unknown 59
22 unknown 59

I could not figure out where 10 cables are sending their signals to. They are not connected to monitor turned on in control room

so I guess they are connected to monitors located inside the lab. I will check these unknown cables when I check the unknown input cables.

Next time, I will check out cables which is connected to input channels of VIDEIO MUX. Any suggestion would be really appreciated.

  3693   Mon Oct 11 22:45:16 2010 kiwamuUpdateComputerssolid works 2010 installed

solidworks.PNG

Solid works 2010 was installed to m3, an windows machine in the control room.

Have fun !

  3692   Mon Oct 11 22:04:28 2010 yutaUpdateCDSdamping for MCs are basically working

Background:
 Even if we can't use the Dataviewer to get the time series of each 4 DOF displacements, we can still use StripTool to monitor the ringdowns and see if the damping servo is working.

What I did:
1. Excited vibration by kicking the mirror randomly (by putting some offsets randomly and turing the filters on and off randomly).

2. Turned all the servo off by clicking "ShutDown" button.

3. Turned all the servo on by clicking "Normal" button.

3. Monitored each 4 DOF displacements with StripTool and see if there are any considerably low-Q ringdown after turning on the servo.
 The values I monitored are as follows;
  C1:SUS_MCX_SUSPOS_INMON
  C1:SUS_MCX_SUSPIT_INMON
  C1:SUS_MCX_SUSYAW_INMON
  C1:SUS_MCX_SDSEN_INMON  (X=1,2,3)

All the settings I used for this observation are automatically saved here;
  /cvs/cds/caltech/burt/autoburt/snapshots/2010/Oct/11/21:07/c1mcs.epics

Result:
 Attached is the screenshots of StripTool Graph window for each 3 MCs.
 As you can see, the dampings for each DOF, each MCs are basically working.

Note:
 Do NOT turn off all the damping servo by clicking "Damp" buttons or setting the SUSXXX_GAIN to 0. It crashes c1mcs.

Next work:
 - check and relate the signal sign with the actual moving direction of the optics
 - fix data aquisition system
 - measure Q-values when the servo is on and off using DAQ and Dataviewer

Attachment 1: SUS-MC1.png
SUS-MC1.png
Attachment 2: SUS-MC2.png
SUS-MC2.png
Attachment 3: SUS-MC3.png
SUS-MC3.png
  3691   Mon Oct 11 20:52:00 2010 ranaUpdateCDSActivation of DAQ channels for 8 optics

Bah!  We tried to get some data but totally failed. It seems like there is some rudimentary functionality in the FE process of the MC, but no useful DAQ at all.

Neither Dataview or DTT had anything. We looked and the NDS process and the DAQD process were not running on FB.

I restarted them both (./daqd -c daqdrc) & (./nds pipe > nds.log) but couldn't get anything.

There's a bunch of errors in the daqd.log like this:

CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:SUS-MC1_SUSPOS_INMON", Connecting to: c1susdaq:57416, Ignored: c1sus.martian:57416"
    Source File: ../cac.cpp line 1208
    Current Time: Mon Oct 11 2010 18:25:15.475629328
..................................................................
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:SUS-MC1_SUSPIT_INMON", Connecting to: c1susdaq:57416, Ignored: c1sus.martian:57416"
    Source File: ../cac.cpp line 1208
    Current Time: Mon Oct 11 2010 18:25:15.475900124

  3690   Mon Oct 11 17:31:44 2010 yutaUpdateCDSActivation of DAQ channels for 8 optics

(Joe, Yuta)

Background:
 We need DAQ channels activated to measure Q-values of the ringdowns for each DOF, each optics with the Dataviewer.

What we did:
1. Activated the following DAQ using daqconfig (in /cvs/cds/rtcds/caltech/c1/scripts).
 C1:SUS-XX_AASEN_IN1
 C1:SUS-XX_SUSBBB_IN1
 C1:RMS-YYY_AASEN_IN1
 C1:RMS-YYY_SUSBBB_IN1
 C1:MCS-ZZZ_AASEN_IN1
 C1:MCS-ZZZ_SUSBBB_IN1
  (XX=BS,ITMX,ITMY  YYY=PRM,SRM  ZZZ=MC1,MC2,MC3  AA=UL,UR,LR,LL,SD  BBB=POS,PIT,YAW)

2. Set datarate to 2048 for each DAQ.

3. Restarted fb(frame builder).

Result:
 We succeeded in making DAQ channels appear in the Dataviewer signal list, but we can't start the measurement because c1mcs is still flaky.

Note:
 We found that c1mcs crashes everytime when turning off all the damping servo (using "Damp" buttons on the medm screen).
 It doesn't crash when all the filters are off.

  3689   Mon Oct 11 16:09:10 2010 yutaSummarySUScurrent OSEM outputs

Background:
 The output range of the OSEM is 0-2V.
 So, the OSEM output should fluctuate around 1V.
 If not, we have to modify the position of it.

What I did:
 Measured current outputs of the 5 OSEMs for each 8 suspensions by reading sensor outputs(C1:SUS-XXX_YYPDMON) on medm screens.

Result:

  BS ITMX ITMY PRM SRM MC1 MC2 MC3
UL 1.20 0.62 1.69 1.18 1.74 1.25 0.88 1.07
UR 1.21 0.54 1.50 0.99 1.77 1.64 1.46 0.31
LR 1.39 0.62 0.05 0.64 2.06 1.40 0.31 0.19
LL 1.19 0.88 0.01 0.64 1.64 1.00 0.05 1.03
SD 1.19 0.99 0.97 0.79 1.75 0.71 0.77 0.93

 White: OK (0.8~1.2)
 Yellow: needs to be fixed
 Red: BAD. definitely need fix

  3688   Mon Oct 11 10:51:36 2010 steveUpdateSUSOSEMs, OSEMs, OSEMs...those lovely little OSEMs
Attachment 1: 40dll.jpg
40dll.jpg
  3687   Mon Oct 11 10:49:03 2010 josephbUpdateCDSc1sus stability

Taking a look at the c1sus machine, it looks as if all of the front end codes its running (c1sus - running BS, ITMX, ITMY, c1mcs - running MC1, MC2, MC3, and c1rms - running PRM and SRM) worked over the weekend.  As I see no

Running dmesg on c1sus reports on a single long cycle on c1x02, where it took 17 microseconds (~15 microseconds i maximum because the c1x02 IOP process is running at 64kHz).

Both the c1sus and c1mcs models are running at around 39-42 microseconds USR time and 44-50 microseconds CPU time.  It would run into problems at 60-62 microseconds.

Looking at the filters that are turned on, it looks as it these models were running with only a single optic's worth of filters turned on via the medm screens.  I.e. the MC2 and ITMY filters were properly set, but not the others.

The c1rms model is running at around 10 microseconds USR time and 14-18 microseconds CPU time.  However it apparently had no filters on.

It looks as if no test points were used this weekend.  We'll turn on the rest of the filters and see if we start seeing crashes of the front end again.

Edit:

The filters for all the suspensions have been turned on, and all matrix elements entered.  The USR and CPU times have not appreciably changed.  No long cycles have been reported through dmesg on c1sus at this time.  I'm going to let it run and see if it runs into problems.

  3686   Sun Oct 10 18:28:25 2010 kiwamuSummarySUSITMX OSEM offsets

Because of the in-vac work on Oct. 4th (see this entry) , ITMX's OSEM offsets were changed.

The two upper OSEMs are still fine, but LL and LR seem to be out of the OSEM's range. 

The plot below shows the trends of LL's and LR's readouts for about two weeks. (The channel name are in the old convention, i.e. ITMY)

OSEM.png

 Some data were missing due to the upgrade of the frame builder.

 It is apparent that the offsets are changed after the in-vac work on Oct. 4th, and now they just show almost zero numbers.

 

The damping of ITMX can still work, if LL and LR are disabled.

At some point before pumping down, we have to check the leveling of the ITMX table again.

  3685   Sun Oct 10 18:09:02 2010 KojiSummaryCOCPhase map interferometer calibration for the data on Oct 8th, 2010

Summary:

Calibration of the phase map interferometer was calculated for the data on Oct 8th, 2010.
The calibration value is 0.1905 mm/pixel.

This is slightly smaller than the assumed value in the machine that is 0.192mm/pixel.
This means that the measured radii of curvature must be scaled down with this ratio.
(i.e. RoC(new) = RoC(old) / 0.1922 * 0.19052)


Motivation:

Our tagets of the phasemap measurement are:

1. Measure the figure errors of the mirrors
2. Measure the curvature of the mirrors

The depth of the mirror figure is calibrated by the wavelength of the laser (1064nm).
However, the lateral scale of the image is not calibrated.
Although Zygo provides the initial calibration as 0.192 mm/pixel, we should measure the calibration by ourselves.

Method:

We found an aperture mask with a grid of holes with 2mm diameter and 3mm spacing (center-to-center).
Take the picture of this aperture and calibrate the pixel size. The aperture is made of stainless and makes not interference
with the reference beam. Thus we put a dummy mirror behind the aperture. (UPPER LEFT plot)

As the holes are aligned as a grid, the FFT of the aperture image shows peaks at the corresponding pitches. (UPPER MIDDLE plot)
As the aperture was slightly rotated, the grids of the peaks are also slanted.

We can obtain the spacing of the peak grids. How can we can that values precisely? I decided to make an artificial mask image.
The artificial mask (LOWER LEFT plot) has the similar FFT pattern (LOWER MIDDLE plot). The inner product of the two
FFT results (i.e. Sum[abs(fft1) x abs(fft2)]), quite a large value is obtained if the grid pitch and the aperture angle agrees between those images.
Note that the phase information was discarded. The estimated grid spacing of the artificial mask can be mathematically obtained.

Result:

The grid pitch and the angle were manually set as initial values. Then the parameters to give the local maximum was obtained by fminsearch of Matlab.
UPPER RIGHT and LOWER RIGHT plots show the scan of the evaluation function by changing the angle and the pitch. They behave quite normal.

The obtained values are

Grid pitch: 15.74 pixel
Angle: 1.935 deg

As the grid pitch is 3mm, the calibration is

3 mm / 15.74 pixel = 0.1905 mm/pixel

Discussion:

A spherical surface can be expressed as the following formula:

z = R - R Sqrt(1-r2/R2)      (note: this can be expanded as r2/(2 R)+O(r3) )

Here R is the RoC and r is the distance from the center. This means that the calibration of r quadratically changes the curvature.
We have measured the RoC of the spare SRM. We can compare the RoCs measured by this new metrology IFO and the old one,
as well as the one by Coastline optics. 

 

Attachment 1: calibration.pdf
calibration.pdf
  3684   Sun Oct 10 16:59:20 2010 KojiOmnistructureCOCPRM phase map measurement at Downs SB 014

[Kiwamu, Yuta, Koji]

We went to the new metrology lab at Downs subbasement (Rm014) in order to measure the phase map of the delivered PRMs.

It's brand-new. So we had to measure the reference phase map, calibration as well as the phase map of our mirrors (3 PRMs and 1 spare SRM). It took a whole day...

Attachment 1: IMG_3646.jpg
IMG_3646.jpg
Attachment 2: IMG_3647.jpg
IMG_3647.jpg
  3683   Sun Oct 10 16:44:59 2010 KojiOmnistructurePhotosKepco Tube HV supply
Attachment 1: IMG_3637.jpg
IMG_3637.jpg
Attachment 2: IMG_3640.jpg
IMG_3640.jpg
  3682   Fri Oct 8 17:36:16 2010 steveFrogsPhotosvisiting undergrads

Prof Alan Weistein guided the 24 student through the 40m. His performance was rated as  an enthusiastic 9.5

Attachment 1: P1060916.JPG
P1060916.JPG
Attachment 2: P1060921.JPG
P1060921.JPG
Attachment 3: P1060922.JPG
P1060922.JPG
Attachment 4: P1060915.JPG
P1060915.JPG
  3681   Fri Oct 8 17:35:24 2010 josephbUpdateCDSstatus of c1ioo, c1sus and rfm

RFM is still not working.  I can see data on a filter just before it reaches the RFM sending code, but I see only zeros on the receiving side.

c1sus machine and c1x02, c1sus, c1mcs, c1rms are running.  At the moment, the c1mcs model is running at about 42 microseconds for USR time and 56 microseconds for CPU MAX, which is close to the 61 microsecond limit.  This is with MC filters on.  So far it has not been late, but its not clear to me if its going to stay that way.  So far I haven't been able to isolate why it sometimes slows down after a few minutes.  Also, it was running faster earlier in the day (around 30-ish microseconds) and I believe it has slowed down slightly in the last hour or two.

c1ioo machine and c1x03, c1ioo are running. However its not doing very much good as I can't get any data transferred from it to any of the optic suspensions. I need to spend some more time debugging this and then grab Alex I think.

  3680   Fri Oct 8 15:57:32 2010 josephbUpdateCDSc1ioo status

I've been trying to figure out why the c1ioo machine crashes when I try to run the c1ioo front end.

I tried removing some RFM components from the c1ioo model, and then the c1gpt model (Kiwamu's green locking model) as an easier test case.  Both cause the machine to lock up once they start running.  Lastly, I tried running the c1x02 and c1sus models on the c1ioo machine instead of the c1sus machine, after first turning off all models on c1sus.  This led to the same lockup. 

Since those models run fine on the c1sus machine, I could only conclude that a recent change in the fe code generator or the Gentoo kernel and the Sun X4600 computer don't work together at the moment.

After talking to Alex, he got the idea to check if the monitor() and mwait() were supported on the c1ioo machine.  These function calls were added relatively recently, and are   used to poll a memory location to see if something has been written there, and then do something when it is.  Apparently the Sun X4600 computers do not support this call.  Alex has modified the code to not use these functions calls, at least for now.  He'd like to add a check to the code so it does use those calls on machines which have them supported.

After this change, the c1ioo and c1gpt front end codes do in fact run.

  3679   Fri Oct 8 12:29:21 2010 KevinUpdateComputersNew Netgear Switch

I removed some old equipment from the rack outside the control room and stacked them next to the filing cabinets in the control room. I also mounted the new Netgear switch in the rack.

  3678   Fri Oct 8 12:21:11 2010 josephbUpdateCDSchecking MC1 suspension damping

Upon investigation, it appears that the c1mcs model was (and still is) timing out after a random amount of time. Or in other words, it at some point it was taking too long to do all the calculations for a single cycle and falling behind. The evidence for this is from the dmesg command when run on c1sus.

There's a bunch of lines like:

[ 8877.438002] c1mcs: cycle 568 time 62; adcWait 0; write1 0; write2 0; longest write2 0

[ 8877.438002] c1mcs: cycle 569 time 62; adcWait 0; write1 0; write2 0; longest write2 0

With a final line like: [ 8877.439003] c1mcs: ADC TIMEOUT 1 2405 37 2277

This last line indicates in fell so far behind it gave up.

However, this doesn't actually seem to be related to the amount of computation going on with the front end. I restarted the c1mcs model this morning by logging into the c1sus machine, and changing to the /opt/rtcds/caltech/c1/target/c1mcs/bin directory and running:

lsmod

sudo rmmod c1mcsfe

sudo insmod c1mcsfe.ko

The first line just lists the running modules. The second removes the c1mcs module, and the third starts it up again.

I proceeded to turn all the filters and and set all the matrix values while keeping an eye on the C1MCS-GDS_TP.adl screen and its timing indicator. It was running fine with all these turned on. Then I ran a dtt session from rosalba (going to /opt/apps/, typing bash, then source gds-env.bash, and finally diaggui) as well as a dataviewer and looked at 6 test point channels. It received data fine.

However, about 2 minutes after I had stopped doing this (although the dataviewer realtime session was still going) the USR timing jumped from about 20 microseconds to 35 microseconds, and the CPU Max timing jumped to the 50-60 microsecond range. At this point dmesg started reporting things like:

[54143.465613] c1mcs: cycle 1076 time 62; adcWait 0; write1 0; write2 0; longest write2 0

[54143.526004] c1mcs: cycle 2064 time 62; adcWait 0; write1 0; write2 0; longest write2 0

About a minute later the code gave up and reported a ADC timeout via dmesg. None of the other front ends seem to be affected.

I had to clear the test points manually after stopping dataviewer and dtt by going to rosalaba,using the sourced gds-env.bash, and running diag -l. I then typed "tp clear 36 *" to clear all the test points on the model with FEC number 36 (corresponding to c1mcs).

I removed and restarted c1mcs again, trying to turn on a few things at a time and letting it run for a few minutes to see if I could narrow down if its one particular filter perhaps reaching an underflow and starting to bog down the computations. However, after about 45 minutes of this, the model is still running and I've turned all the filters on and have been running about 8 test points with no problem, so the problem is clearly intermittent.

Quote:

Notes:
 c1mcs crashed many times during the investigation, and I had to kill and restart it again and again.
 It seemed to be easily crashed when filters are on, and so I couldn't check whether the damping servo is working correctly or not today.

Next work:

  - fix c1mcs (and maybe others)
  - check the damping servo by comparing the displacements of each 4 degrees of freedom when servo in off and on.

 

ELOG V3.1.3-