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.

For the proposed construction in the NW corner of the CES building (near the 40m BS chamber), they did a simulated construction activity on Wednesday from 12-1.

In the attached image, you can see the effect as seen in our seismometers:

this image is calculated by the 40m summary pages codes that Tega has been shepherding back to life, luckily just in time for this test.

Since our local time PDT = UTC - 7 hours, 1900 UTC = noon local. So most of the disturbance happens from 1130-1200, presumably while they are setting up the heavy equipment. If you look in the summary pages for that day, you can also see the IM lost lock. Unclear if this was due to their work or if it was coincidence. Thoughts?

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.

Today I found the elog down, so I rebooted it following the instructions in the wiki.

 I have the impression that Nodus has been rebooted since last night, hasn't it?

nodus:log>dmesg

Sun Jun 21 00:06:43 PDT 2009
Mar  6 15:46:32 nodus sshd[26490]: [ID 800047 auth.crit] fatal: Timeout before authentication for 131.215.114.93
Mar 10 11:11:32 nodus sshd[22775]: [ID 800047 auth.crit] fatal: Timeout before authentication for 131.215.114.93
Mar 11 13:27:37 nodus sshd[7768]: [ID 800047 auth.error] error: connect_to 131.215.115.52 port 7000: Connection refused
Mar 11 13:27:37 nodus sshd[7768]: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 11 13:31:40 nodus sshd[7768]: [ID 800047 auth.error] error: connect_to 131.215.115.52 port 7000: Connection refused
Mar 11 13:31:40 nodus sshd[7768]: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 11 13:31:45 nodus sshd[7768]: [ID 800047 auth.error] error: connect_to 131.215.115.52 port 7000: Connection refused
Mar 11 13:31:45 nodus sshd[7768]: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 11 13:34:58 nodus sshd[7768]: [ID 800047 auth.error] error: connect_to 131.215.115.52 port 7000: Connection refused
Mar 11 13:34:58 nodus sshd[7768]: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 12 16:09:23 nodus sshd[22785]: [ID 800047 auth.crit] fatal: Timeout before authentication for 131.215.114.93
Mar 14 20:14:42 nodus sshd[13563]: [ID 800047 auth.crit] fatal: Timeout before authentication for 131.215.114.93
Mar 25 19:47:19 nodus sudo: [ID 702911 local2.alert] controls : 3 incorrect password attempts ; TTY=pts/2 ; PWD=/cvs/cds ; USER=root ; COMMAND=/usr/bin/rm -rf kamioka/
Mar 25 19:48:46 nodus su: [ID 810491 auth.crit] 'su root' failed for controls on /dev/pts/2
Mar 25 19:49:17 nodus last message repeated 2 times
Mar 25 19:51:14 nodus sudo: [ID 702911 local2.alert] controls : 1 incorrect password attempt ; TTY=pts/2 ; PWD=/cvs/cds ; USER=root ; COMMAND=/usr/bin/rm -rf kamioka/
Mar 25 19:51:22 nodus su: [ID 810491 auth.crit] 'su root' failed for controls on /dev/pts/2
Jun  8 16:12:17 nodus su: [ID 810491 auth.crit] 'su root' failed for controls on /dev/pts/4


nodus:log>uptime
 12:06am  up 150 day(s), 11:52,  1 user,  load average: 0.05, 0.07, 0.07

I found elog got crashed. I rebooted the elog daemon just 10minutes before.

I just restarted the elog.  It was crashed for unknown reasons.  The restarting instructions are in the wiki.

This morning I found the elog down. I restarted it using the procedure in the wiki.

Just now found it dead. Restarted it. Is our elog backed up in the daily backups?

In the last hour or so the elog crashed. I  have restarted it.

I just found the elog down and I restarted it.

This afternoon the elog crashed. We just restarted it.

 Again, this morning Zach told me that the elog had crashed while he was trying to post an entry.

I just restarted it.

 I restarted the ELOG on NODUS just now. Our attempt to set up error logging worked - it turns out ELOG was choking on the .ps file attachment.

So for the near future: NO MORE .PS files! Use PDF - move into the 20th century at least.

matlab can directly make either PNG or PDF files for you, you can also use various other conversion tools on the web.

Of course, it would be nice if nodus could handle .ps, but its a Solaris machine and I don't feel like debugging this. Eventually, we'll give him away and make the new nodus a Linux box, but that day is not today.

 The elog was down and I ran the restart script.

i just restarted the elog for the third time in the past 12 hours.

I checked the elog.log file to debug the problem. It doesn't contain eveidence of any particular cause, except for png/jpg file uploads happened last night.

I'm not sure we can blame Image Magic again because the last crash seems to be occurred just after an entry with e jpg picture was included in the body of the message. I think Image Magic is used only for previews of attachments like pdfs or ps.

Maybe we should totally disable image magic.

 The elog crashed when I was uploading a photo just now. I logged into nodus and restarted it.

 I restarted the elog with the restart script as it was down.

 Restarted the elog with the script as it was down.

And again.

 Elog was down. Restarted with the script.