The LSC time had gone too high. I deleted ~20 filters and rebooted. CPU time came down to 50 usec.

The filters all looked like old trash to me, but its possible they were used.

I didn't delete anything from the DARM, CARM, etc. banks but did from the PD and TM filter banks. You can always go back in time by using the

filter_archive/

New flipping mirror installed on the AP table on the beam path to the REFL199 PD.

If you're missing the double demod signal, please check that it is actually down.

Vacuum normal valve condition was changed to accommodate SRS-RGA calibration.

VM1 was closed to isolate the RGA from the IFO.

 
 
VM3 opened to TP3.
 
This condition is called back ground (BG) mode. It is where we can calibrate and see the RGA background without the IFO.

While waiting for the installation of the 32-bit Matlab 2009a to finish, I tried updating our seisBLRMS.m code.

Although DMF is in SVN, we forgot to check it out and so the directory where we have been doing our mods is not a working copy and our changes have not been captured: Shame.

We will probably have to wipe out the existing SVN trunk of DMF and re-import the directory after checking with Yoichi for SVN compliance.

Also wrote a script: LSC/x2mc, which will transition from regular ETM based X Arm locking to the MC2 based locking. It ran once OK, but I get a segfault on the 'trianglewave' which was trying to run the 'ezcastep' perl script which was calling 'ezcastep.bin'.

I also restarted the seisBLRMS.m on a terminal on Mafalda in the new Matlab 2009a to see if it loses its NDS connection like it did with 2007a. I also reduced the 'delay' parameter to 4 minutes and the 'interval' to 1 minute. This should be so that the total delay is now 5 minutes between seismic noise and seismic trend.

nodus was hanging because it was trying to mount the cit40m account from rigel and rigel was not responding.

Neither I nor Yoichi can recall what the cit40m account does for us on nodus anymore and so I commented it out of the nodus /etc/vfstab.

nodus may still need a boot to make it pay attention. I was unable to do a 'umount' to get rid of the rigel parasite. But mainly I don't want anything in

the 40m to depend on the LIGO GC system if at all possible.

VM1 was closed to isolate the RGA from the IFO.

            
 
            
 
            
VM3 opened to TP3.
            
 
            
This condition is called back ground (BG) mode. It is where we can calibrate and see the RGA background without the IFO.
            

 Vacuum valve configuration is back to VACUUM NORMAL  condition. RGA  calibration  completed.

RGA  scan attached is the backgroud of the rga with std cal leak open, sn 08581

Krypton at amu 84 and Argon at amu 40 are the cal signals.

The new Level 13 mixer on the PMC servo board is installed (minicircuits SRA-3MH).   Since the RF output of the LO board was ~16dBm, I put a 3dB attenuator between the LO board and the LO input on the servo board.  Since the previous cable was *just* the right length, this required adding a tiny bit of cable.  I found a very short cable, which worked out nicely, and didin't leave bunches of extra cable between the two boards.  One of these days if I have time (i.e. if it is necessary), I'll make a new cable for this purpose, so that we don't have 2 cables daisy-chained. 

A note on the Mixer-replacement:  The mixer on the PMC servo board is soldered in a set of 8 through-holes, not stuck in a socket.  So I had to desolder the old Level 23 Mixer (minicircuits RAY-3) which was a total pain.  Unfortunately, in this process, I lifted one of the pads off the back side of the board.  Once the old mixer was removed, it became clear that the pin for the pad I had lifted was shorted via a trace on the front side of the board to the pin directly across from it.  So when installing the new mixer, I did my best to get some solder into the through-hole for the lifted-pad-pin, and then tied it using a jumper wire to the pin that it's shorted to on the front of the board.  You can't see the trace that shorts the two pins because it's underneath the mixer, when the mixer is installed.  (Sidenote: after talking with Rana, this should be okie-dokie, especially if these are ground pins).

The PMC and MC locked nice and happily after I replaced the board and turned all the HV supplies back on, so I call this a success!

I also measured the OLG of the PMC servo after today's adventures in mixer-land.  I get a UGF of 1.4kHz, with 66 degrees of phase margin.  The method for this is in elog 924.

I checked the phase slider setting of the PMC phase screen by putting 30kHz at 100mV into the Ext DC input of the servo board, and looking at the 30kHz peak output of the Mixer Out.  I fiddled with the phase slider, and chose the value for which the 30kHz peak was maximized.  The phase slider is now set to 5.0V. 

The CRYO pump cooled down and VC1 was opened. This valve configuration is Cryo-only

PSL output shutter opened at 4pm 

PZT HV power supplies turned on for OMC and IOO steering mirrors.

There positions were not corrected to strain gauge values.

Ben helped us to conclude that the FAILURE led indicator is working correctly and

has nothing to do with the one lose, dangling wire#258 in the side connects of the vac rack.

I reset the CSB switch inside the Maglev controller and tried to start accelerating.

It fails after 2-3 sec and failure led light comes on.

Now we can say the MAGLEV 360 is DEAD and the new OSAKA TG420M can be swapped in.

However it requires new interface with our epics based MEDM or better...?

CC1 5e-7 Torr,  VC1 closed at 18:25,  IFO is not pumped, RGA is in bg-mode

At about 1am or so Yoichi and I opened VC1.  CC1 had fallen to about 5e-5 torr.

Congratulation Yoichi and Peter for full rf locking at night. Let's remember that the cryopump was shaking the hole vac envelope and ifo during this full lock.

#
# Script to backup via rsync the most recent 40m minute trends and
# any changes to the /cvs/cds filesystem.
#
50 05 * * * /cvs/cds/caltech/scripts/backup/rsync.backup < /dev/null > /cvs/cds/caltech/scripts/\
backup/rsync.backup.log 2>&1

30 06 * * * find /usr/controls/jobs -mtime +7 -exec /bin/rm -f {} \;

Having determined that Rana (the computer) was having to many issues with testing the new Raid array due to age of the system, we proceeded to test on fb40m.

We brought it down and up several times between 11 and noon.  We  eventually were able to daisy chain the old raid and the new raid so that fb40m sees both.  At this time, the RAID arrays are still daisy chained, but the computer is setup to run on just the original raid, while the full 14 TB array is initialized (16 drives, 1 hot spare, RAID level 5 means 14 TB out of the 16 TB are actually available).  We expect this to take a few hours, at which point we will copy the data from the old RAID to the new RAID (which I also expect to take several hours).  In the meantime, operations should not be affected.  If it is, contact one of us.

This afternoon the alignment script chrashed after returning sysntax errors. We found that the tpman wasn't running on the framebuilder becasue it had probably failed to get restarted in one of the several reboots executed in the morning by Alex and Jo.

Restarting the tpman was then sufficient for the alignment scripts to get back to work.

CYAN -  cryo ON
BLACK - cryo OFF
BLUE -  no crappy lens + mount

I've disabled the alarm for PEM_count_half, using the mask in the 40m.alhConfig file.  We can't do anything about it, and it's just annoying.

I edited the configure scripts (those called from the C1IFO_CONFIGURE screen) for restore XARM and YARM.  These used to misalign the ITM of the unused arm, which is totally unnecessary here, as we have both POX and POY.  They also used to turn off the drive to the unused ETM.  I've commented out these lines, so now running the two restores in series will leave a state where both arms can be locked.  This also means that the ITMs will never be deliberately mis-aligned by the restore scripts.

I'm setting SLOWDC to about -5.

I had to edit FSSSlowServo because it had hard limits on SLOWDC at (-5 and 5).  It now goes from -10 to 10.

I added op540m's display 0 (the northern-most monitor in the control room) to the MEDM screens webpage: https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

Now we can see the StripTool displays that are usually parked on that screen.

I restarted ntpd on op440m to solve a "synchronization error" that we were having in DTT.  I also edited the config file (/etc/inet/ntp.conf) to remove the lines referring to rana as an ntp server; now only nodus is listed.

To do this:

log in as root

/usr/local/bin/ntpd -c /etc/inet/ntp.conf

Here is a set of mode scans of the AS port, using the OMC as a mode scanner.  The plot overlays various configurations of the IFO.  

To remove PZT nonlinearity, each scan was individually flattened in fsr-space by polynomial (3rd order) fitting to some known peak locations (the carrier and RF sidebands).
 

Joe and Steve

The retrofitted Osaka 390 was installed on the pumpspool yesterday.

V1 gate valve is disabled for safety by disconnected pneumatic power plug.

The foreline of this maglev now have a KF25 size viton o-ring directly on the turbo.

This is bad for leak hunting.

Joe is ready with new interface cable. Power supply and cables are in place.

The maglev was pumped down this morning.

All new gas kits and metal hose were leak checked by sprayed methanol.

There is no obvious sign of leak. I was expecting the pressure to drop below 1e-5 Torr in one hour.

TP2 is drying out the levitating coils of the turbo at ~7 l/s for N2

We'll start the pump as soon as Joe is in.

 Joe and Steve

The Maglev is running at 680 Hz, 40,800 RPM with V1 gate valve  closed and  valve disabled to change position. C1vac2 was rebooted before starting.

Interlocks are not tested yet, but the medm COVAC_MONITOR.adl screen is reading correctly. RGA scan will determine the need for baking on Monday

The foreline pressure is still  ~2e-5 Torr

Acceleration takes 3 minutes 30sesconds without load. There is no observabale temp effect on the body of the turbo during braking and acceleration.

The IFO is still pumped by the CRYO only

We updated the vacuum control and monitor screens  (C0VAC_MONITOR.adl and C0VAC_CONTROL.adl).  We also updated the /cvs/cds/caltech/target/c1vac1/Vac.db file.

1) We changed the C1:Vac-TP1_lev channel to C1:Vac-TP1_ala channel, since it now is an alarm readback on the new turbo pump rather than an indication of levitation.  The logic on printing the "X" was changed from X is printed on a 1 = ok status) to X is printed on a 0 = problem status.  All references within the Vac.db file to C1:Vac-TP1_lev were changed.  The medm screens also now are labeled Alarm, instead of Levitating.

2) We changed the text displayed by the CP1 channel (C1:Vac-CP1_mon in Vac.db) from "On" and "Off" to "Cold - On" and "Warm - OFF".

3) We restarted the c1vac1 front end as well as the framebuilder after these changes.

 The new Maglev fore line pressure is at 4e-6 torr at day 3

Valve VM1 was closed to isolate IFO from RGA and valve VM2 was opened so the RGA can scan the Maglev only.

The maglev fore line pressure is 3e-6 torr at CC2 after 4 days of pumping. Varian turbo V-70 is pumping on it through V4 and VM2

Actual pumping speed ~10 l/s for N2. There was no baking. The maglev performance looks good : 3e-9 torr on CC4  with RGA -region only.

I checked out a copy of matapps into /cvs/cds/caltech/apps/lscsoft so that I could find the matlab function strassign.m, which is necessary for some old mDV commands to run.  I don't know why it became necessary or why it disappeared if it did.