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.

You'll never guess what happened: the elog crashed!

I restarted it with the script. Yay.

The elog crashed, so we restarted it again.

with script

elog crashed on an upload. restarted and it worked fine with the same file.

 Again. Resubmitted an old entry with just text changes. Elog hung for 5 min +.

 Elog didn't respond, so I restarted it with the script.

Before killing the process somehow two elog daemons were running at the same time. I killed those two manually. 

 took two runs of the script as usual

I restarted the elog because i changed the configuration for the cryo-elog.

Used the "start-elog.csh" script in /cvs/cds/caltech/elog/

I restarted the elog with the script as it was not up when I tried to make a post. It was again unresponsive when I went to submit, but this time the script couldn't restart it. The log said it couldn't bind to 8080, which usually happens if the daemon is still running. I pkilled it, then reran the script, and it appears to be working.

elog was not responding for unknown reasons, since the elogd process on nodus was alive; anyway, I restarted it. 

 I have created an updated version of the "start-elog-nodus" script and put it in .../elog/elog-2.8.0. It seems to work fine.

Nancy notified me that the elog crashed. It was fixed.

I restarted elog, but it kept crashing. Some of the entries on Aug 6th caused the trouble.

I tried to refresh the pictures in entries 3376, 3377, 3378. Still it kept crashing.
I started to dig into the elog file itself. (/cvs/cds/caltech/elog/elog-2.7.5/logbooks/40m/100806a.log)

FInally I found that there was some invalid reply links in the entry 3379.

Date: Fri, 06 Aug 2010 19:29:59 -0700
Reply to: 3379
In reply to: 3379

The entry is refering this entry itself. That is weird. So I deleted the reply-to and in-reply-to lines.
Then elogd got happy.

In fact, 3379 was a dupulication of 3380, so I deleted this entry.

Restarted elog.

found it unresponsive. Restarted fine using procedure documented in wiki

Elog did not respond despite running the /cvs/cds/caltech/elog/start-elog.csh  script two times.  

It worked the after the third restart. 
 

The elog was not responding. I attempted to restart it by running .../start-elog.csh, but this didn't work (even after the usual ~2 times it needs).

Somehow pkill did not kill the daemon, so I kill -9'd it and that did the trick. I ran the start script once more and it came back online.

I just restarted the elog after I found it down a few minutes ago.

Koji and I figured out what the problem is.  Apparently firefox 17.0 (specifically it's user-agent string) breaks fckeditor, which is the javascript toolbox the elog uses for the wysiwyg text editor.  See https://support.mozilla.org/en-US/questions/942438.

The suspect line was in elog/fckeditor/editor/js/fckeditorcode_gecko.js.  I hacked it up so that it stopped whatever crappy conditional user agent crap it was doing.  It seems to be working now.

Edit by Koji: In order to make this change work, I needed to clear the cache of firefox from Tool/Clear Recent History menu.

Phil Ehrens gave me a DVD of the 40m elog, apache, and (Jamie's) SVN archive.
I copied it to nodus:/home/controls/dvd-from-ehrens.  Once we get the elog
running on nodus, we can copy the datafile over again from dziban (so that
we don't lose any elog entries) and switch over.

 was down.  I restarted the version in the 2.7.5 folder.  It went down again almost immediately but stayed up after the second restart.

Elogd have been restarted several times today because it died everytime I submit something.
Here is the copy of the log.

I modified elogd.c as shown below in order not to allow to display all of the entries at once by specifying page number "0".

After this modification, elog seems to have survived 66 times of attacks by googlebots.

==============================

rossa:src>pwd
/cvs/cds/caltech/elog/elog-2.8.0/src

rossa:src>diff elogd.c_orig elogd.c
19912a19913,19917
>
>    /* KA */
>    if (page_n<1)
>      page_n = 1;
>


Suresh killed the elogd again from India. This was the log file:

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Referer: http://www.ligo.caltech.edu/~ajw/40m_upgrade.html
Cookie: elmode=threaded; __utma=65601905.411937803.1291369887.1291369887.1291369887.1; __utmz=65601905.1291369887.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SITESERVER=ID=4981c5fd42ae53c9c9e0980f2072be4f
Via: 1.1 sfire5.du.ac.in:3128 (squid/2.6.STABLE6)
X-Forwarded-For: 10.11.1.120
Cache-Control: max-age=259200
Connection: keep-alive

Stop killing our elog!

After another elog crash, I've blacklisted the domain that Suresh is using by editing the apache httpd.conf. Let's see what happens now.

ELOG has crashed and I restarted it.

Actually the filtering is not effective so far as elog is not using apache but has its own web server inside.
So this just block the access to port 30889 (=SVN, Dokuwiki, etc).

The #3 enclosure door was removed for the carpenter shop this morning. They will make 5 full size doors with window on each.

TEMPORARY aluminum sheet is clamped into its place. This sheet should not be removed till new doors arrive.

The inside Formica color will be changed from white to black to reduce the green scattering.

Ben and Sam came over to fix one of  the east side  sliding  door sensor that had to be moved from the inside  to outside on the enclosure.

We turned off the 2w Innolight for 20minutes. The power is back on, the  PMC and MC locked itself immediately.

 I'm planning to remove the ETMY optical table enclosure and move it over to CES Shop 8am Thursday morning.

We'll install spring loaded lathes, hooks and quick release pins.

The bridge will be reinforced with steel plate to support release pins on posts.

There will be an other cut out for cable feedtrough as it is shown on elog #8472

Let me know if this timing does not fit your work.

 Thin wall connector from McMCarr#55275K25 was tested in 150 mW, 1 mm beam size of 1064 nm  overnight. It did not show any degradation.

 The bridge support posts were shimmed today. Surgical tubing 402R - o - rings were glued togeather with " instant krazy glue "

Atm2  Carey CH-3540 latches are compressed ~2.5 mm in the clamped position.

Atm3 is showing the captured quick release pin in the steel reinforced bridge that is supported by the post. It works great. The post screw is sealed by o-ring. The quick-pin is sealed by an epoxy attached copper cap.

Atm4 Enclosure is on it's back. Bottom o-ring can be seen. The hole reinforced bridge structure is visible.

Now I'm working on the window connection to the chamber. I'm very close leak checking this box.

In case of leaking around the top tubing seals we have two options:

a, cut down on the cover rim by 0.040"  or b, increase tubing diameter

The PSL enclosure now have 4 windows on each side. The bottom rail guides on the east side will be replaced by  one  U-channel for smoother, more gentle sliding.

Door position indicator- interlock switches are not wired yet.

A thermal feedback was installed to the end PDH locking and it works well. There are no saturations 

As I said the feedback signal was sometimes saturated at the sum-amp because the drive signal going to the laser PZT was large at low frequency (below 1Hz).

So I made a passive low pass filter which filters the signal controlling the temperature of the laser crystal, and put it before the temperature drive input.

Now the amount of the feedback signal got reduced when it is locked, and there are no saturations. It's very good.

(thermal property of the crystal) 

According to the specification sheet for the 1W Innolight, the thermal properties of the crystal are:

  Response coefficient : 3GHz/K 

  Temperature control coefficient : 1K/V

  Thermal response bandwidth: 1Hz 

(filter circuit and actuator response)

In order to feedback the signal blow 1Hz, a low pass fiter is needed. 

The attachment:1 shows the filter circuit I made.

Since I found that the drive input had an input impedance of 100kOhm, so I put relatively big resistors to have a moderate gain.

The expected actuator responses are also attached.

The blue curve represents the response of the PZT, the green is the thermal response including the low pass filter and the red curve is the total response composed of both the responses.

I assume that the PZT response is 1MHz/V according to Mott's measurement.

Also I assume that the thermal response intrinsically has two poles at 1Hz according to the specification listed above.

In the total response, there is a little gain reduction around 2Hz due to the cancelation of each other, but it still looks okay.

GJ!

[Koji, Yuta]

We checked that PZTs between SRM and OMC (called OMC stage 1 and 2) is working.
Now we need them to be EPICS channels because they are not connected to digital world right now.

Background:
  For the IFO alignment, what we have been doing for last 2weeks is,

1. Align Y arm to Y end green and maximize green transmission
2. Use PZT2 to maximize TRY (PZT1 is not functioning well. PZT1 Y do a little, but X totally does nothing.)
3. Align BS and X arm to maximize TRX
4. Tune BS and ITMX so that reflection from both arms overlap at AS
5. Align X end green to that we can see bright(~250 uW) TEM00 at transmission

  However, we found that something (Y arm axis or Y end green?) has drifted horizontally and can't make Y green transmission and TRY high level at same time. Because PZT1 is not functioning well, it is hard to compensate beam translation.
  So, now what we have to do is to align Y arm to IR incident beam. That means, we either have to realign Y end green or forget about maximizing green transmission. I think I will leave green as it is for a while because calibration of the beatbox is going on and I want to proceed to PRC.
  Anyway, if we align IFO to the IR incident beam, we see clipping in the AS port. From the contrast measurement last night, we thought clipping comes from somewhere between BS and AS port. So, we need PZTs between BS and AS port working.

What we did:
  1. Turned on 24P 24N power supplies(Sorensen DCS33-33E) in AUX_OMC_SOUTH rack to supply power to AUX_OMC_NORTH rack. 18P 18N cables to OMC_NORTH was unplugged and used by the beatbox, so we reconnected them.

  2. Turned on KEPCO high voltage power supply to supply 150 V to the PZT driver, but it was not functioning well. So, we currently use Aligent HP 6209B instead. Its on the OMC_NORTH rack.

  3. PZT driver output to OMC stage 1 was unplugged. So, we plugged them.

  4. Opened PZT driver (LIGO-D060287), put some signal from Piezo_Drive_in(J4 in schematic), and checked beamspot at AS port is moving. The gain from Piezo_Drive_in to the output (hv_out) was ~20.

  5. We could avoid clipping by putting some offset to OMC stage 2 (or 1) in yaw. That means, the clipping comes from after OMC stage 2.

Conclusion:
  If we can control OMC stage 1 and 2, we can avoid clipping. So, we want them to be EPICS channels.

I made a super sweet new foam box for our EOM.  It's awesome, and should be reasonably easy to duplicate.  Check out the PHOTOS!

Notes:

* I didn't think I was going to cover the inside of the box at first, since the foam is non-fuzz-generating, but Koji suggested it would be a good idea anyway.  The foam was cut perfectly to the EOM, so adding the tape inside makes it a tight fit.  Especially height-wise...leave a little space next time.

* To cover the insides of the optical path holes, do it in 2 parts.  One half-cylinder, and then another.  Way easier than trying to do the whole thing at once.  Also, pre-cut the tabs on both sides of the foil before inserting.  Then you just have to grab the tabs with tweezers and flatten them, and they hold the aluminum tape in place. 

* Having 1" wide, 2" wide and 3" wide aluminum tape was handy.  3" to make the top, 2" for the sides, and 1" for the inside of the holes. 

 These are great photos and a nice box, but I fear from the photos that there's too much air getting in. How to pack it so that there's no air flow? How does the temperature sensors wires get in?

pushd /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86
setenv PATH ${PATH}:`pwd`
cd /cvs/cds/caltech/users/tf/build/labca_2_1/lib/linux-x86
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:`pwd`
popd

addpath /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86/labca
help labca
foo = lcaGet('C1:PSL-FSS_RCTRANSPD')

Physical Electronics: Vac-Seal #288-6000 arriving Monday. Our last bag used last week had a p/n 1002003 with expiration date   .....2009 ? and it was stored in the

refrigerator all times. We are getting 68 small bags.

We should have precision gluing notes of epoxies/procedures used on our sus upgrade.