You should wipe off the table cover before you take it off next time.

It is important to turn up the PSL encloure HEPA Variac voltage if you are working in there. It takes less than 10 minutes to reach lab condition.

Lab air count normal. It is not logged. I have a notebook of particle count on the SP table next to the Met One counter.

Please wet WIPE before opening chamber or optical table ! ! 

 with methanol soaked kimwipes.

The Met One particle counter is located on CES wall, just behind ITMX chamber. 

The numbers are not so bad, but have you ( ...a)  asked the IFO lately?

 Zach

• I get so many freebies it's ridiculous

e-log was repeatedly hanging and several attempts to start the daemon failed.

problem was solved after clearing the (firefox) browser cache, cookie, everything!!

I found the e-log has been down around 3:40pm, then I restarted the e-log. Now it's working.

Thanks.

I made some changes to the elog on nodus:

• Made a backup of /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg called elogd.cfg.bk.20100407 in the same directory
• Added a folder: /cvs/cds/caltech/elog/elog-2.7.5/logbooks/EAGER_Lab
• Restarted the elog daemon via the start-elog-nodus script in the elog-2.7.5 directory

I saw that the current version of the elog seems to be in the svn, so tried to svn the changes from nodus via ssh, but got this message:

"svn: This client is too old to work with working copy '/cvs/cds/caltech/elog/elog-2.7.5'; please get a newer Subversion client."

I feel I should svn this but don't want to *&#@ the svn/elog up.

For now I will leave it alone and ask a question: Is the folder /cvs/cds/caltech/elog/elog-2.7.5/ under SVN control? Is it also under CVS control?

TL;DR:  New tab added to elog.

No damage. The BS sensor UR 0.220 V has been low for some times.

Dataviewer does not work for long term trend.

6.2M Bandon, OR did not trip any sus

Nothing tripped.

Earthquake 4.4 Leo Carrillo Beach.

Some of the watchdogs tripped out.

quake coming through.  I've re-enabled optic damping (except ETMY), and left off the oplevs for now.  We can do a resonant-f  check over the weekend.

Looks like it was a magnitude 5 near Olancha, where they sell really good fresh jerky.  quake

Earthquake Details

• This event has been reviewed by a seismologist.

latest news: there's actually been about a dozen earthquakes in Keeler in the last couple hours:   http://earthquake.usgs.gov/eqcenter/recenteqsus/Maps/special/California_Nevada_eqs.php

-Rana

Local eq shakes the lab

Large earthquake shakes Baja California, Mexico and 6 over Magnitude 5 aftershakes follow.  The frontend computers are still down since Friday.

Shasky day yesterday postpones venting. We had about 11 shakes larger than mag 4.0 Mag5.5 was the largest at  13:58 Sunday, Aug 26 at  the Salton Sea area.

Atm3,  ITMX and ETMX  did not come back to it's position

Southern Mexio is still shaking..... so as we

No sus tripped. Seimometers do not see the 5.3M  ?

Lompoc 4.3M and 3.7M Avalon

M4 local earthquake at 10:10 UTC    There is no sign of damage.

....here is an other one.........M5.8 Ferndale, CA at 16:40 UTC

I changed the names on a switch(SW1) in the C1:PSL-FSS screen.  To do this I had to edit the psl.db database file in the directory /cvs/cds/caltech/target/c1psl.  After this change, when I executed this screen, all fields in the C1PSL_FSS screen went blank.  As the change to database file takes effect only after we restart the C1PSL machine (slow machine) I went ahead and reset the c1psl machine.  I then used the burttoday to locate the most recent snapshot files and then used burtgooey to restore all the values in the c1psl.snap file.

Everything back to normal now.

(Suresh, Yuta)

If you come up with a good idea and want to add new things to current RT model;

 1. Go to simLink directory and open matlab;
    cd /cvs/cds/rtcds/caltech/c1/core/advLigoRTS/src/epics/simLink
    matlab

 2. In matlab command line, type;
    addpath lib

 3. Open a model you want to edit.
    open modelname

 4. Edit! CDS_PARTS has useful CDS parts.
    open CDS_PARTS
    There are some traps. For example, you cannot put cdsOsc in a subsystem

 5. Compile your new model. See my elog #3787.
 
 6. If you want to burt restore things;
    cd /cvs/cds/caltech/burt/autoburt/snapshots/YEAR/MONTH/DATE/TIME/
    burtgooey

 7. Edit MEDM screens
    cd /cvs/cds/rtcds/caltech/c1/medm
    medm

 8. Useful wiki page on making a new suspension MEDM screens;
    http://lhocds.ligo-wa.caltech.edu:8000/40m/How_to_make_new_suspension_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!!

We should completely turn off the air conditioner when working on green locking.

Even if green beams propagates inside of chambers, the air conditioner does affect the spatial jitter of the beam. 

The attached picture was taken when Steve and I were seeing how the green beam jittered. 

At that time the beam was injected from the end table and going through inside of the ETM, the ITM and the BS camber.

Eventually it came out from the camber and hit the wall outside of the chamber. It was obvious, we could see the jittering when the air cond. was ON.

With no DARM offset, sweeping CARM shows an asymmetry between the state where we lock to a DARM spring and the state with a DARM anti-spring.  This is why we have a link between the DARM and CARM optical springs. 

For each DARM detune direction (positive or negative, spring or anti-spring), there is only one CARM direction which can yield a DC-based error signal lock with a CARM offset but no DARM offset, which is what we want.

I checked the effect of the arm length to the reflectance of the f2(=5*f1) sidebands.

Conclusion: If we choose L_arm = 38.4 [m], it looks sufficiently being away from the resonance
We may want to incorporate small change of the recycling cavity lengths so that we can compensate the phase deviation from -180deg.

f1 of 11.065399MHz is assumed. The carrier is assumed to be locked at the resonance.

Attachment 1: (Left) Amplitude reflectance of the arm cavity at f2 a a function of L_arm. (Right) Phase
Horizontal axis: Arm length in meter, Vertical Magnitude and Phase of the reflectance

At L=37.93 [m], f2 sidebands become resonant to the arm cavity. Otherwise, the beam will not be resonant.

Attachment 2: close-up at around 5 f1 frequency.
The phase deviation from the true anti resonance is ~0.7deg. This can be compensated by both PRC and SRC lengths.

I was told yesterday, that on Friday the construction people accidentally ripped out one of the 40m soil ground.....AND HOW MANY MORE ARE THERE? nobody knows.

It was ~8 ft long and 0.5" diameter buried in the ground. There is no drawing found to identify this exact building ground. They promised to replace this on Wednesday with a 10 ft long and 0.75" diameter.

The  the wall will be resealed where the conduit enters  the  north west corner of the IFO room 104

There should be no concern about safety because the 40m building main ground is connected to the CES Mezzanine step-down transformer.

 Atm1 is showing ground bus under N-breaker panel in 40m IFO room north-west corner.

The second ground bus is visible farther down south under M-breaker panel.

Atm2 is the new ground that will be connected to ground bus-N

elog was acting up again (not running), so I restarted it. 

And again.  This makes 4 times since lunchtime yesterday....something bad is up.

I've set up nodus to start the ELOG on boot, through /etc/init/elog.conf. Also, thanks to this, we don't need to use the start-elog.csh script any more. We can now just do:

controls@nodus:~  $ sudo initctl restart elog

I also tweaked some of the ELOG settings, so that image thumbnails are produced at higher resolution and quality. 

elog died b/c someone somewhere did something which may or may not have been innocuous. I ran the script in /cvs/cds/caltech/elog to restart the elog (thrice).

I have now banned Warren from clicking on the elog from home

Restarted elog 9:11PM 9/5/11

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.

This is cool though the projector is flashing the blue screen alternately.

I gave the dual head video card (ATI RADEON something) to Yuta a month ago.
It is on the top of Zita. This would make the things more fun.

The elog was so dead this time that the restart script didn't work.  I followed the restart-by-hand instructions instead, with success.

 Just for added interest, I tried a different method when the restart script broke.  The "start-elog-nodus" script has a line "kill elogd".  This seems not to be actually killing anything anymore, which means the elog can't restart.  So this time I went for "kill <pid number>", and then ran the startup script.  This worked.  So it's the "kill elogd" which isn't working reliably.

I found the elog dead again this morning, and the script didn't kill again. I modified the script to use the following line instead of "pkill elogd":

kill `ps -ef | grep elogd | grep -v grep | grep -v start-elog-nodus | awk '{print $2}'`

Hopefully the script will be a bit more robust in the future.

like the subject says...

I found the elog got down around 7:30 am in this morning.

So I restarted it by running the script: "start-elog-nodus" as instructed on the wiki.

http://lhocds.ligo-wa.caltech.edu:8000/40m/How_To/Restart_the_elog

...I restarted it.

I found the elog down and I restarted it.

Then, after few seconds it was down again. Maybe someone else was messing with it. I restarted an other 5 times and eventually it came back up.

In nodus, I moved the elog from /export to /cvs/cds/caltech. So now it is in the cvs path instead of a local directory on nodus.

For a while, I'll leave a copy of the old directory containing the logbook subdirectory where it was. If everything works fine, I'll delete that.

I also updated the reboot instructions in the wiki. some of it also is now in the SVN.