**** Deleted
apps/emacs
apps/linux64/firefoxold
apps/linux64/comsol      (old v. 3.5)

* running up2date on rossa

* rossa needs to be able move windows between monitors: Xinerama?

* there are permissions problems: controls on rossa can't
make and delete directories made by 'controls' elsewhere.
Some sort of user# or group issue?

To bypass the polarizer issue, I just used cubes. One I took from the FSS-Refcav path and the other from the power control part of the old MOPA, just downstream of the MOPA's periscope.

We'll swab these out with the thin-film polarizers after we get the mounts made.

With the cubes in, I also installed the Faraday + its 1/2-wave plate. The transmission looks good and we're getting into the PMC and its flashing a TEM00 mode sometimes. I set up a signal generator to drive the SLOW actuator by 1 FSR at 0.1 Hz.

I have set up a PMC transmission camera and transPD so that its easy to align. The flashing mode already allows us to align most of the rest of the table (except FSS).

Our next step should be to run the cables for locking the PMC:

1. RF cables to the PMC_REFL
2. Dsub for the PMC RFPD
3. HV cable between the PMC servo board and the PMC PZT (why is this not RED? we have to make sure to abide by the cabling color code).
4. RF cable from 35.5 MHz Frequency Reference card to the PMC EOM via the RF summing box on the table.

On Tuesday, we need to make sure that all of our mounts' drawings are in the cue for the shop. I'll put the list of mounts onto the PSL upgrade wiki page.

We also have to come up with a plan for wiring some of the 2W NPRO's channels into the cross-connect so that we can have some laser channels recorded by EPICS.

We must remember that we are using the Rev.B SOS Coil Drivers and not the Rev. A. 

The main change from A->B was the addition of the extra path for the bias inputs. These inputs were previously handled by the slow EPICS system and not a part of the front end. So we used to have a separate bias screen for these than the bias which is in the front end. The slow bias is what was used for the alignment to avoid overloading the range of the main coil driver path.

Also, Kiwamu has modified the layout drawing to add the green PLL stuff. This has collapsed the reference cavity's wave function placing it close to its original position.

WE (maybe Valera and Steve) can now put the reference cavity back on the table.

I turned off the laser last night to protect against the electricians. but failed to elog it. I accept the burnt toast completely.

I wiped out the old CentOS install on rossa and installed CentOS 5.5 on there. The DVDs are on a spindle in the control room; there were 2 iso's, but I only needed the first to install most things.

It still needs to get all of the usual stuff (java, flash, nvidia) installed as well as setting up the .cshrc and the NFS mount of /cvs/cds. The userID and groupID are set to 1001 as before. Whoever

sees Sanjit first should steer him towards this elog entry.

I found Sanjit's instructions for doing the Nvidia settings too complicated and so I followed these instructions from Facebook:

http://www.facebook.com/notes/centos-howtos/installing-nvidia-display-drivers-on-centos-55/399295987425

After installations, the monitors were autodetected and the Xinerama effect is working.

I measured the RF power output of the VCO Driver box as a function of slider value. I measured using the Gigatronics Handheld power meter and connected to the AOM side of the cable after the white Pasternak DC block.

* at low power levels, I believe the waveform is too crappy to get an accurate reading - that's probably why it looks non-monotonic.

* the meter has a sticker label on it saying 'max +20 dBm'. I went above +20 dBm, but I wonder if maybe the thing isn't linear up there...

I restarted the seisBLRMS DMF monitor by ssh'ing into mafalda and starting up a matlab session. I also have started a StripTool session on rossa by forwarding the process from op440m.

We need to get the modern EPICS installation onto these linux machines by copying what K. Thorne has done at LLO.

The IR sensitive Olympus 570 camera gives us a really nice view of these IR beams. Its actually a lot better than what you can get with the analog IR viewers:

PSLAOMdogs

I changed the setpoint for the HVAC control (next to Steve) from 73F to 72F. This is to handle the temperature increase in the control room with the AC unit there turned off.

We know that the control setpoint is not linear, but I hope that it settles down after several hours. Lets wait until Tuesday evening before making another change.

I installed the blue IP camera from ZoneNet onto the PSL table. It gets its power from the overhead socket and connects via Cat5 to the Netgear switch in the PSL/IO rack.

You can connect to it on the Martian network by connecting to http://192.168.113.201:3037. Your computer must have Java working in the browser to make that work.

So far, this works on rossa, but not the other machines. It will take someone with Joe/Kiwamu level linux savvy to fix the java on there. I also don't know how to fix the host tables, so someone please add this camera to the list and give it a name.

As you can see from the image, it is  illuminating the PSL with IR LEDs. I've sent an email to the tech support to find out if we can disable the LEDs.

Our new 2W Mephisto has a pretty zippy "SLOW" temperature input. Tuning the perl PID servo, I found that the best response came from setting

the "P" and "D" terms to zero. This is because the internal temperature stabilization servo has a fairly high UGF. In the attached

image you can see how the open loop step response looks (loop is open then the "KI" parameter is set to zero). The internal servo

really has too little damping. There is a 30% overshoot when it gets a temperature step. For this kind of servo Innolight would have done better

to back off on the gain until they got back some phase margin.

New SLOW parameters:

timestep = 1.9 s

KP = 0

KI = 0.035

KD = 0

SVN down

mafalda down

I am guessing that the NFS file system hangup may have caused some machines to get into an awkward state. We may be best off doing a controlled power cycle of everything...

We added the Thorlabs HV Driver in between the FSS and the NPRO today. The FSS is locking with it, but we haven't taken any loop gain measurements.

This box takes 0-10 V and puts out 0-150 V. I set up the FSS SLOW loop so that it now servos the output of FAST ot be at +5V instead of 0V. This is an OK

temporary solution. In the future, we should add an offset into the output of the FSS board so that the natural output is 0-10 V.

I am suspicious that the Thorlabs box has not got enough zip to give us a nice crossover and so we should make sure to measure its frequency response with a capacitive load.

I found that several linux libraries have been moved around and disabled today. In particular, I see a bunch of new stuff in apps/linux/ and ezca tools are not working.

Who did this and why is there no ELOG ???

Also found that someone has pulled the power cable to the function generator I was using to set the VCO offset. This is the one on top of the Rb clocks. Why?? Why no elog? This is again a big waste of time.

Its pretty exciting to see that Joe got Alex to actually use the ELOG. Its a proof that even rare events occur if you are patient enough.

1) I fixed the MEDM links to point to the new sitemap.adl in /opt/rtcds. There is a link on the new sitemap which points to the old sitemap so that there is nothing destroyed yet.

2) Some of the fields in the screen are white. These are from the new c1sus processor, not issues with the slow controls. I think its just stuff that has not yet been created in the C1SUS simulink module.

3) The PZT steering controls are gone. Without this we cannot get the beam down the arm. Must fix before aliging things after the MC. Since PZT used to be controlled by ASC, we'll have to wire the Piezo Jena PZT controls in from a different VME 4116. Possibly c1iool0's crate?

4) Also, the IPANG and IPPOS are somehow not working right. I guess this is because they are part of the ASC / the old ETMX system. We'll have to wire the IPANG QPD into the new ETMY ADC system if we want to get the initial alignment into the Y-arm correct.

5) I've started migrating things over from the old SITEMAP. Please just use the new SITEMAP. it has a red link to the old one, but eventually everything on the new one will work after Joe, Alex, me, and Kiwamu are done tweaking.

This is the link to the NDS2 webpage:

https://www.lsc-group.phys.uwm.edu/daswg/wiki/NetworkDataServer2

We should install this so that we can use this modern interface to get 40m data from outside and inside of the 40m.

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

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

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.

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.

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.

Why EXCMON? I think that we should modify the filter coefficients so that the decimation filter that makes OUT16 is a 2nd order Butterworth at 1 Hz instead of whatever bogus thing it is now. Then we can delete the EXCMON from the DAQ and add either OUTPUT or OUTMON. That way we will have a low frequency signal (OUT16) and a sort of aliased RMS (OUTMON).

I deleted a bunch of categories from the elogd.cfg file. Not every kind of locking and activity gets its own activity. All of the things related to length sensing and control should be LSC. If there's a high pollen count its under PEM. etc., etc., etc.

I decided that the 'tetex' distribution which comes with CentOS is total BS and I removed it from rossa using 'yum erase tetex'. I installed TexLive using the instructions on the web; its much better, actually works, and also has RevTex 4.1 which allows Jenne and I to write our paper.

Eventually, we'll standardize our workstation setups.

Yuta has also successfully set up zita to run the projector, so we should clear our some of the boxes and bookshelves in that area so that the projection can be larger.

I copy section 6.2 into here to share with you all what the diagnostic capabilities of the new NPRO are. Its not a lot.

We'll need to record a sample of the NPRO output beam on a regular photodiode in order to get a real power monitor. My plan is to use a regular 25-pin Dsub and run it fron the NPRO controller over to the PSL rack and hijack the old MOPA monitoring channels (3113 and 3123 ADCs).

To get the angle to length signal before the c1ioo processor gets going, we need a length signal. We can use either the error signal or the control signal.

I recommend using the control signal since its not puny. The 4-pin LEMO inputs to the OSEM ADC that Suresh has wired are differential so we can, in principle, use either the BNC output of the SERVO plug or the 2-pin LEMO output.

The analog whitening on the OSEM Whitening board should be engaged via the SUS MEDM screen so that we get a good SNR at the A2L dither frequencies.

If the ADC saturates, then we should use a pomona box RC low pass to cut everything off above 100 Hz.

Also, a comment about Yuta's elog: we estimated that the seismic motion was ~1e-7 - 1e-6 meters. The MC linewidth ought to be ~lambda/(2*Finesse) ~ 1e-9.

So, the MC servo as it was was not giving us enough gain (1/f above 50 Hz; UGF ~5-10 kHz) to get the error signal to stay in the linear PDH region. Kevin's filter gave us ~10x more gain at the seismic frequencies (1-3 Hz) of concern.

I've wheeled the old HP audio frequency signal analyzer into the control room to debug the GPIB/python interface. The wireless setup was getting more than 80% packet loss in the office area.

I also noticed that we have multiple and competing copies of the netgpib package installed. Kiwamu is going to merge them soon. Pleae only use the official location:

scripts/general/netgpibdata/

which is also the SVN working copy. Committ all changes periodicallty so that we can share the updated versions between sites.

When swapping Eurocard boards, it is safest to first turn down the power supplies and then do the swapping.

Otherwise, it is sometimes the case that people plug in the board slowly and/or asymmetrically. This can cause the opamp to see one of the power supply rails without the other (e.g. +15 but not -15).

This can destroy some opamps. The true danger is that there may be damage to the board which you do not notice for several months, thereby leaving a timebomb for the next person.

Don't be an electronics terrorist!

I moved the lens just before the PMC to check the mode matching landscape. The PMC trans went up from ~6.5 to ~6.8. That's 5% with ~1 hour of work.

As per the micrometer, this took ~7-8 mm of travel. Since there's so much power left in the HOMs, we we we will have to do a proper mode scan and re-calculate the solution.

The measured transmission is now ~610 mW. The power reflected from the PMC with it unlocked is ~1400 mW.

I looked at this web page: http://www.teledyne-cougar.com/Index.asp for the RF company that Rich has recently started using.

There are ~15 amplifiers that they sell which have a NF < 2 dB and work in the 10-100 MHz band. We should call them to find out if they will package some amps for us or at least sell us a few with eval. boards so that we can make our own.

The moral of the story is, PUT THINGS IN THE ELOG. This wild process is one of those things where people say 'this won't effect anything', but in fact it wastes several hours of time.

We like to have the MC TRANS channels so that we can run all of our old scripts and trends on it. This is the usual BROWN

channel that's on the LockMC screen. Its also the thing that we use for thresholding to activate the MC Autolocker Daemon.

I modified the ioo.db file in the target/c1iool0/ directory so that the MC_TRANS_SUM, _P, and _Y channels are all now just

CALC records of the MC2 OL channels (where the calculation is MC_TRANS_SUM = MC2 OL_SUM + 0.001, etc.). I then

rebooted c1iool0 a few times to get the syntax right. It SEEMS to be working now. I'm sure that this won't effect anything.
I've committed the new file to the SVN repo. Once Suresh is done hacking the QPD circuit, we can set the threshold in the Autolocker.

As part of the effort to debug what was happening with the slow computers, I disabled the auto MEDM snapshots process that Yoichi/Kakeru setup some long time ago:

https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

We have to re-activate it now that the MEDM screen locations have been changed. To do this, we have to modify the crontab on nodus and also the scripts that the cron is calling. I would prefer to run this cron on some linux machine since nodus starts to crawl whenever we run ImageMagick stuff.

Also, we should remember to start moving the old target/ directories into the new area. All of the slow VME controls are still not in opt/rtcds/.

Since Nodus is a Solaris machine it can barely handle doing the ImageMagick commands (such as convert and import). I removed the auto MEDM snapshot routine from it

awhile ago and I think the rate of ELOGD crashes has decreased, although its not definitive.

The snapshots have now been re-actived to run on MAFALDA, after I fixed the absolute pathnames in the scripts and installed (via yum) the packages that mafalda

needed to run this (Xvfb, openmotif, compat, etc.). The snapshots web page is now refreshing by itself and the statScreen/cronjob.sh is running on mafalda 5x per hour.

https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

IF I believe this calibration and IF I believe that the noise is the same with no magnet in there, then its almost 1 nm/rHz @ 1 Hz.

I am guessing that Jenne's calculation will show that this is an unacceptably high level of OSEM sensor noise, OAF-wise.

import re
o = open("output.adl","w")
data = open("test.adl").read()
o.write( re.sub("C0:TIM-PACIFIC_STRING","C1:FEC-34_TIME_STRING",data)  )
o.close()

The next step is to figure out how to apply this to all the files in a directory.

The following channels should be named as below to keep in line with their names pre-upgrade rather than use _DAQ in the name.

Valera and Haixing and I installed a PMC REFL camera today. We stole the camera control box from the MC2 trans area (because I don't know why we need a camera there).

We installed it such that it is looking at the leak through of the last turning mirror before the PMC REFL RFPD. This beam was previously going into a Thorlabs razor blade dump.

There is no steering mirror to align into this camera; we just positioned the camera such that the REFL beam fills up the monitor. WE cable tied the cable to the table and the

output of the camera control box is piped into the control room correctly as PMCR. The "IMCR" quadrant is actually the PMCT beam. JoonHo is going to fix this promptly.

Also, I noticed how beautiful  the MC2 Simulink diagram is so I post it here for your viewing pleasure. We should take this as a reference and not produce any new diagrams which are less useful or beautiful or easy to understand.

Wow. I typed DTT on rossa and it actually worked! No complaints about testpoints, etc. I was also able to use its new 'NDS2' function to get data off of the CIT cluster (L1:DARM_ERR from February). You have to use the kinit/kdestroy stuff to use NDS2 as usual (look up NDS2 in DASWG if you don't know what I mean).

https://nodus.ligo.caltech.edu:30889/gw.swf

This morning (~0100) I started to redo some of the wiring in the rack with the FB in it. This was in an effort to activate the new Megatron (Sun Fire 4600) which we got from Rolf.

Its sitting right above the Frame Builder (FB). The fibers in there are a rats nest. Someone needs to team up with Joe to neaten up the cabling in that rack - its a mini-disaster.

While fooling around in there I most probably disturbed something, leading to the FB troubles today.

Looks like there was a power outage. The control room workstations were all off (except for op440m). Rosalba and the projector's computer came back, but rossa and allegra are not lighting up their monitors.

linux1 and nodus and fb all appear to be on and answering their pings.

I'm going to leave it like this for the morning crew. If it

This is looking better, but the fit data for the TF should be plotted along with the data. The data should be made up of points and the fit a line.

For the fit, we should have the Q of the main resonance as well as the peak height of the main resonance and the values of the gain at the notch frequencies.

Also the peak as well as the notches should have the frequencies fit for and labeled. In principle, you can make the plot on the wiki have all of the data. Then in the end we can print the plot in a small size and glue it to the PD's backside.

 I suppose that if we were really clever we would intentionally choose either the AR or HR surface so as to minimize the effect of the thermal lensing and/or thermal expansion from the locked interferometer absorption.

The process was taking up 100% of the CPU and not responding via web. The .log file showed the last action was somebody reading/editing one of Jenne's entries from August regarding TT ECD. The restart script didn't work, so I had to do a 'kill -9' to get it to die.

I deleted the yellow box which showed up by default when making an elog entry. Would be nice if we could make it so that you have to click a button to 'opt-in' for the yellow box rather than get it by default.

I added a 'robots.txt' file to the /users/public_html/ area using Google's instructions (it only works with robot compliant crawlers), but am not sure how to put robots.txt into the elog port.