I removed the multiply resonant EOM that has been set by a SURF student from PSL table.

I will use it for checking the resonant circuit.

 We closed the chambers last night with heavy doors and reopened it today.

 JDSU can repair the Lightwave M126-1064-700 NPRO, sn 415  They do not need the Controller sn 516 

 Posted in the 40m Wiki_ PSL_ NPRO  cost repair and/or option to buy Innolight laser as replacement

The most recent power outage took out our projector and mixer. The projector was sent for repair while we ordered a new mixer. Both arrived today. Steve is working on re-installing the projector right now, and I installed the mixer which was verified to be working with our DAFI system (although the 60Hz issue still remains to be sorted out). The current channel configuration is:

Ch1: 3.5mm stereo output from pianosa

Ch2: DAFI (L)

Ch3: DAFI (R)

I've set some random gains for now, but we will have audio again when locking

[Rana, Jenne, Suresh]

Yesterday, We replaced the existing beam steering mirror and the PZT it was mounted on with a Gooch and Housego mirror (20ppm transmission at < 30deg incidence @1064nm) and a Polaris-K1 Newport steel mount. (JD)

We realigned the G&H mirror to get the MC flashing. 

We then had to reduce the gain in the servo circuit to accommodate the increased optical power going into MC. 

MC locked to PSL once again.

Note: 

      the old mirror stuck on the PZT has been removed.  The mirror had no markings and has been stored in the 'Unknown Optics' Box along the East Arm.

      The PZT has been stored in the PZT cabinet along with its 2in mirror mount.

Spent a lot of time aligning tonight.  The BS is not staying put--sometimes after a lock loss it gets badly mis-aligned. 

DD handoff is working, after putting beam on REFL diodes and running senseDRM script.

locking work proceeding apace tonight.

diagonalized DRM with setDDphases & senseDRM. 

initial locks are fairly quick, aqstep script succeeds reliably.

first part of cm_step (handoff CARM-> MCL) usually works.

tuning up later parts of cm_step (presumably due to optical gain changes resulting from MOPA decline). 

got to arm powers ~60.

1.The aim is the laser frequency stabilisation of PSL and AUX.

2.As a first step we want to couple some of the AUX laser beam into a single mode optical fibre and route the fibre to the PSL table.

3.The position of the optical fibre on the ETMY table is shown by the coupler in the attached picture. The yellow lines show the new scheme we want to implement.

4.WHAT WE DID TODAY.

• The Y-arm was locked so that we could use the transmitted IR beam as the reference.
• We shifted the position of the "QPDY_PD" .
• We also shifted the "ETMYT" camera to make space for the "QPDY_PD".
• The mirror  directing the beam into the "QPDY_PD" was rotated by 90 degrees to adhere to the new position of the "QPDY_PD".
•  The attached photo shows the table as it is right now after the repositioning.

rob, alberto, rana, pete

we reset this computer, which was out of sync (16384 in the FE_SYNC field instead of 0)

  Smoking Sorensen could have triggered the smoke alarm!

 Yesterday I called CIT Fire Protection Services very first to deactivate the sensors temporarily. The smoke alarm was turned back on right after the particle count dropped.

 Their phone number is posted at the entry doors 104M and 104W as shown below.

 script

 More of the same. 

Who is putting weird figures into the elog?!?!  I haven't checked lately, but this is what usually crashes the elog.  It's been happening a lot lately, and it might be the .pdf's. 

Let's play a new game.  We'll call this game "Everyone only use .png files for the next week" Ready? GO!

Do we know what causes the crashes for definite? Let's give the whole knowledge gathering a shot. Surfs welcome to post. Please follow the format and keep it brief. P.S. if the elog stops responding or hangs while you're trying to edit a post or write a post, you may have crashed it.

Person

• Crashes

Dmass

• I have crashed the elog with downsized jpegs (~300-900kB).
• I see jpegs on the front page of the 40m (which seem to have not crashed it?)
• I have posted pdf's with and without png thumbnails (associated automatically via the Mac program preview) without problem.

Edit this post to add your own experience using the above format

 script

 Restarted the elog using the script. I had to do it twice for it to work. This is not the first time this has happened---does anyone know why this might be?

took two again

 Restarted the elog with the script

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.

Did the same.

Did it again. It seemed that Google bot came to the elog and tried to obtain "http://nodus.ligo.caltech.edu:8080/robots.txt". That was the last of the log.
Bot came from the AJW's homepage. Also Google FeedFecther came to the elog.

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.

Google bot  crashed the elog again. Then, I found that Google bot (and I) can crash elogd by trying to show the threaded view.
There looks similar issue reported to the elog forum, the author did not think this is a true bag.

Note: This happens only for the 40m elog. The other elogs (ATF/PSL/TCS/SUS/Cryo) are OK for the threaded view.

 Restarted the elog with the script

 I restarted the elog using the script.

 again

with script

Restarted the elog with the script.

 with script

Elog crashed / dormant for long time.  A look at the log file indicated that it was busy generating png thumbnails for pdf files.

Restarted at Wed Sep  7 20:41:13 PDT 2011

Elog was hanging, restarted with the script.

Elog was hanging. Restarted it with script.

Basically, elog hangs up by the visit of googlebot.

Googlebot repeatedly tries to obtain all (!) of entries by specifying  "page0" and "mode=full".
Elogd seems not to have the way to block an access from the specified IP.
We might be able to use http-proxy via apache. (c.f. http://midas.psi.ch/elog/adminguide.html#secure)

Or can we tweak the source of elod such that it does not accept "page0"?


GET /40m/page0?mode=full&new_entries=1 HTTP/1.1
Host: 131.215.115.52:8080
Connection: Keep-alive
Accept: */*
From: googlebot(at)googlebot.com
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Accept-Encoding: gzip,deflate

 There are much more simple ways to prevent page indexing by googlebot: http://www.google.com/support/webmasters/bin/answer.py?answer=156449

However, I really think that's a less-than-idea solution to get around the actual problem which is that the elog software is a total piece of crap.  If google does not index the log then it won't appear in google search results.

But if there is one url that when requested causes the elog to crash then maybe it's a better solution to cut of just that url.

 with script.

 Restarted the elog again, this time using .../elog/start-elog.csh, which Joe pointed out works just fine. I have amended the wiki instructions to point to this script, instead.

Physically rebooted c0rga workstation after failing to ssh into it (even as it was able to ping into it...) the RGA seems to be off though. The last log with data on it appears to date back to 2020 Nov 10, but reasonable spectra don't appear until before 11-05 logs. Gautam verified that the RGA was intentionally turned off then.

Since the c1lsc machine became frozen I restarted the c1lsc machined and daqd.

Then I burtrestored c1lsc, c1ass and c1oaf to this evening. They seem running okay.

 The elog was down so I restarted it. The instructions on the wiki do not work as the process has some complicated name (i.e. it is not just 'elogd'). I used kill and the pid number.

I will get around to updating the restart script to work with 2.8.0.

The manual instructions on the 40m wiki for restarting wouldn't work.  I killed the process okay, but then I got an error saying it "couldn't bind to port 8080, please try again using -p to select port".  The automated script worked though.

Elog was not responding and was restarted.

Elog suspended 2 times for 1 hour. Too high frequency.

Restarted.

[Kevin, Jenne]

Kevin's awesome final report/elog entry was so awesome that it crashed the elog.  It has been restarted.  We're going to put his pictures and documentation in the wiki, with a link from the elog to prevent re-crashing.

I'm blaming Zach on this one, for trying to upload a pic into the ATF elog (even though he claims it was small....)  Blame assigned: check.  Elog restarted: check.