40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 323 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  1949   Wed Aug 26 15:42:17 2009 AlbertoUpdatePSLreference cavity temp box temporarly out of order

Quote:

There's no elog entry about what work has gone on today, but it looks like Peter took apart the reference cavity temperature control around 2PM.

I touched the reference cavity by putting my finger up underneath its sweater and it was nearly too hot to keep my finger in there. I looked at the heater power supply front panel and it seems that it was railed at 30 V and 3 A. The nominal value according to the sticker on the front is 11.5 V and 1 A.

So I turned down the current on the front panel and then switched it off. Otherwise, it would take it a couple of days to cool down once we get the temperature box back in. So for tonight there will definitely be no locking. The original settings are in the attached photo. We should turn this back on with its 1A setting in the morning before Peter starts so that the RC is at a stable temp by the evening. Its important NOT to turn it back on and let it just rail. Use the current limit to set it to 1 A. After the temperature box is back in the current limit can be turned back up to 2A or so. We never need the range for 3A, don't know why anyone set it so high.

While Peter King is still working on the reference cavity temperature box, I turned the power supply for the reference cavity's heater back on. Rana turned it off last night since the ref cav temperature box had been removed.

I just switched it on and turned the current knob in the front panel until current and voltage got back to their values as in Rana's picture.

I plan to leave it like that for half an hour so that the the cavity starts warming up. After that, I'll turn the current back to the nominal value as indicated in the front panel.

  1951   Wed Aug 26 16:11:41 2009 AlbertoUpdatePSLreference cavity temp box temporarly out of order

It turned out that half an hour was too long. In less than that the reference cavity temperature passed the critical point when the temperature controller (located just below the ref cav power supply in the same rack) disables the input power to the reference cavity power supply.

The controller's display in the front shows two numbers. The first goes with the temperature of the reference cavity; the second is a threshold set for the first number. The power supply gets enabled only when the first number comes under the threshold value.

Now the cavity is cooling down and it will take about another hour for its temperature to be low enough and for the heater power supply to be powered.

  1952   Wed Aug 26 16:31:34 2009 steveUpdatePSLreference cavity temp box temporarly out of order

Quote:

It turned out that half an hour was too long. In less than that the reference cavity temperature passed the critical point when the temperature controller (located just below the ref cav power supply in the same rack) disables the input power to the reference cavity power supply.

The controller's display in the front shows two numbers. The first goes with the temperature of the reference cavity; the second is a threshold set for the first number. The power supply gets enabled only when the first number comes under the threshold value.

Now the cavity is cooling down and it will take about another hour for its temperature to be low enough and for the heater power supply to be powered.

 The cavity temp cooled below SP2 set point 0.1  The Minco SP1 (present temp in Volts) now reading -0.037 so DC power supply was turned on and set to 12V 1A  

 

 

  5712   Thu Oct 20 12:43:19 2011 steveUpdateSAFETYrefilled first aid kits & their locations

First aid kits are located close vicinity of entry doors and under circuit breaker panels.

 

Attachment 1: P1080299.JPG
P1080299.JPG
Attachment 2: P1080306.JPG
P1080306.JPG
Attachment 3: P1080304.JPG
P1080304.JPG
Attachment 4: P1080305.JPG
P1080305.JPG
Attachment 5: P1080300.JPG
P1080300.JPG
Attachment 6: P1080301.JPG
P1080301.JPG
Attachment 7: P1080303.JPG
P1080303.JPG
Attachment 8: P1080307.JPG
P1080307.JPG
  2936   Sun May 16 12:51:08 2010 kiwamuUpdateGreen Lockingreflected beam at PD

Mode matching to the cavity has been done.

Now the reflection from the cavity is successfully going into the PD.

However I could not see any obvious error signal.

I should compute and re-check the expected signal level.

 


(mode matching of the crystal)

On the last Wednesday, Kevin and I measured the mode profile before the PPKTP crystal,  and we found the Gaussian beam at the crystal is focused too tightly (w = 38 um).

In order to achieve the best conversion efficiency the waist size should be 50.0 um. So we moved a lens, which was located before the crystal, to 7 cm more away from the crystal. Eventually we obtained a better focus (w = 50.1 um).

Thanks, Kevin. You did a good job.

 

(mode matching of the cavity)

I put a lens with f=-50 mm after the crystal to diverge the green beam more quickly. Then the beam is going through the Faraday of 532 nm, two final modematching lenses and ETMY at last.

By shifting the positions of these lenses, I obtained the reflection from ITMY with almost the same spot size as that of the incident. This means modemathing is good enough.

I put two more steering mirrors before its injection to the ETM, this allows us to align the beam axis against the cavity.

I aligned the axis by using the steering mirrors and now the green beam are successfully hitting the center of both the ETM and the ITM.

Then the alignment of the ETM and the ITM was adjusted from medm, so that both reflection goes in the same path as that of the incident.

And then I put a PD (Thorlabs PDA36A) to see the reflection rejected by the Faraday.

Connecting a mixer and a local oscillator (Stanford func. generator) with f=200kHz, but I couldn't see any obvious PDH signal....

Since the PD is DC coupled, the signal is almost dominated by DC voltage. Even if I inserted a high pass filter to cut off the DC, the AC signal looks very tiny..

  2937   Sun May 16 19:25:45 2010 KojiUpdateGreen Lockingreflected beam at PD

Don't make a short cut. The beam size at a single place does not tell you anything.
Measure the mode of of the beam at multiple points. Calculate the mode matching ratio.

Align the mirrors precisely. Try to see the DC fringe. Predict the size of the DC fringe.

Test the demodulation system with a function generator. Find the 200kHz signal using the spectrum analyzer to find the signal and the optimal alignment.

Put the DC signal and the AC signal to the oscilloscope as X&Y.

Good luck.

 

  417   Mon Apr 7 18:58:49 2008 steveUpdateGeneralreflectivity of SS304
The reflectivity of stainless steel 304 super polished # 8 was measured the same way as elog entry 409

The reflectivity: 74 +- 1 % from incident angle 10 to 80 degrees
Attachment 1: ss304s8refl.pdf
ss304s8refl.pdf ss304s8refl.pdf
  409   Wed Apr 2 15:03:51 2008 steveUpdateGeneralreflectivity of black glass
The reflectivity of black glass, shade 12 was supplied by Donald O'Shea
of Emerald Glass Inc., Westlake, OH 44145

The reflectivity of this glass was measured as shown

Old 1064 nm Crysta Laser with poor beam quality was the source.
Attachment 1: bg12refl.pdf
bg12refl.pdf
Attachment 2: bg12refsetup.pdf
bg12refsetup.pdf
  6280   Tue Feb 14 17:09:05 2012 steveUpdateGeneralreflectivity of green welding glass

 Schott, Athermal green welding glass, shade #14 reflectivity was measured in 1.2W,  ~1 mm diameter  beam of MC reflected.

The P polarization measurement  was done with the help of half wave plate and PBC

 

 

Attachment 1: gg#14ref.pdf
gg#14ref.pdf
Attachment 2: gg14refl1Wps.png
gg14refl1Wps.png
  6095   Fri Dec 9 15:14:41 2011 DenUpdateCDSrelease 2.4

Alex has created a 2.4 branch of the RCD. Jamie, we can try to compile and install it. As a test a did it for c1oaf, it compiles, installs and runs once variables SITE, IFO, RCD_LIBRARY_PATH are properly defined. As we do not want to run one model at 2.4 code and others at 2.1, I recompiled c1oaf back to 2.1. Jamie, please, let me know when you are ready to upgrade to 2.4 release.

  8254   Thu Mar 7 18:48:43 2013 yutaUpdateComputer Scripts / Programsreleasing my secret scripts

I released/updated my secret scripts to real scripts directory.
I checked they run correctly (but maybe not working correctly).


burtlookup.py
  in ./scripts/general/burtlookup.py

  It returns a value of a specified channel in the past using burt snapshots.
  Help is available.


GRtoggler.py
  in ./scripts/ALS/GRtoggler.py

  Toggles green shutter until it locks TEM00.
  Help is available. Threshold setting is critical.


MCbeeper.py
  in ./scripts/MC/MCbeeper.py

  Beeps when MC is unlocked.


yutalib.py
  in ./scripts/pylibs/yutalib.py

  Python library for data loading, saving and plotting.
  I think it's well commented.


pyezcalib.py
  in ./scripts/pylibs/pyezcalib.py

  Python library for ezca stuff.
  It has functions for recording and resetting default channel values in case of interrupt.


./scripts/PRCmodescan
  Python scripts for PRC modescan. Not well commented. Not organized.
  See elog #8012


./scripts/Alignment
  Python and shell scripts for alignment work. Not well commented.
  See elog #8164


./scripts/SUS/OplevCalibration
  Python scripts for oplev calibration. Not well commented.
  See elog #8221


./scripts/dither/gfactormeasurement
  Python scripts for g-factor measurement. Not well commented.
  See elog #8230


./scripts/SUS/ActuatorCalib
  Python scripts for calibrating actuators. Not well commented.
  See elog #8242

  11618   Fri Sep 18 09:06:26 2015 ranaFrogsComputer Scripts / Programsremote data access: volume 1, Inferno

Trying to download some data using matlab today, I found that my ole mDV stuff doesn't work because its MEX files were built for AMD64...

Tried to rebuild the NDS1 MEX according to 7 year old instructions didn't work; our GCC is 'too' new.

From the Remote Data Access wiki (https://wiki.ligo.org/RemoteAccess/MatlabTools) I got the new 'get_data.m' and 'GWdata.m'. These didn't run, so I updated the nds2-client and matlab-nds2-client on Donatella.

Still doesn't run to get 40m data. It recognizes that we're C1, but throws some java exception error. Maybe it doesn't work on the NDS1 protocol of our framebuilder?

So then I noticed that our NDS2 server on megatron is no longer running...thought it was supposed to run via init.d. Found that the nds2 binary doesn't run because it can't find libframecpp.so.5; maybe this was blown away in some recent upgrade? We do have versions 3, 4, 6, 7, & 8 of this library installed.

So now, after an hour or two, I'm upgrading the nds2 server on megatron (plus a hundred dependencies) as well as getting a newer version of matlab to see if there's some kind of java version issue there.

Of course python still works to get data, but doesn't have any of the wiener filter calculating code that matlab has...

  11623   Fri Sep 18 19:19:49 2015 ranaFrogsComputer Scripts / Programsremote data access: volume 1, Inferno

NDS2 restarted after hours long upgrade process; testing has begun. Let's try to get some long stretches of MC locked with MCL FF ON this weekend so's I can test out the angular FF idea.

  11813   Wed Nov 25 22:37:12 2015 yutaroUpdateLSCremoval of Gautam's cable in 1Y2 and restoration of POYDC

[yutaro, Koji]

We disconnected the cable that was connected to CH5 of the whitening filter in 1Y2, then connected POYDC cable to there (CH5). This channel is where POYDC used to connect.

Then we turned on the whitening filter for POYDC (C1:LSC-POYDC FM1) and changed the gain of analog whitening filter for POYDC from 0 dB to 39 dB (C1:LSC-POYDC_WhiteGain).

  2898   Fri May 7 21:55:59 2010 kiwamuUpdatePSLremove Mach-Zehnder

[Koji, Kiwamu]

The Mach-Zehnder on the PSL table was removed.

A path for 166 MHz modulation in the Mach-Zehnder (MZ) was completely removed, the setup for another path remains the same as before.

Also the photo detector and the CCD for the PMC transmittion were moved to behind the PZT mirror of PMC. 

 


Before removing them, we put an aperture in front of the PD for MC REFL so that we can recover the alignment toward MC by using the aperture.

After the removal we tried to re-align the EOM which imposes the sideband of 29MHz for MC.

We eventually got good alignment of 97% transmissivity at the EOM ( the power of the incident beam is 1.193W and trans was 1.160W )

And then we aligned the beam going to MC by guiding the reflected beam to the aperture we put. This was done by using the steering mirrors on the periscope on the corner of the PSL table.

Now MC got locked and is successfully resonating with TEM00.

Attachment 1: NO_MachZehnder_s.jpg
NO_MachZehnder_s.jpg
  8168   Tue Feb 26 10:17:44 2013 JamieUpdateSUSremoved global/local switch from sus_single_control

[jamie, brett]

Yesterday we added some new control logic to the sus_single_control part to allow for global damping.  Today we decided that a binary switch between local/global damping was probably a bit extreme since we might want to smoothly ramp between them, instead of just hard switching.  So we removed this switch and are now just summing the control inputs from global and local damping right before the output matrix.

Changes were committed to the SVN, and all suspension models were recompiled/installed/restarted.

 

  2169   Mon Nov 2 13:34:36 2009 kiwamuConfigurationPSLremoved multiply resonant EOM

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.

  8953   Thu Aug 1 16:03:52 2013 SteveUpdateGeneralreopen BS & IOO

Quote:

[Koji, Manasa]

We missed to check that we had the green transmitted to the PSL after flipping the SRC and PRC folding mirrors.
There is no green transmission reaching the PSL even after locking the arms to green.

We should fix this tomorrow. The BS heavy door should come off.

Steve! Do not start pump down tomorrow !

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

Attachment 1: IOOnorth.jpg
IOOnorth.jpg
  8307   Mon Mar 18 14:58:15 2013 SteveUpdateGreen Lockingrepair or replace dead NPRO

 

 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

  12659   Fri Dec 2 16:21:12 2016 gautamUpdateGeneralrepaired projector, new mixer arrived and installed

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 laugh

  4137   Tue Jan 11 17:08:43 2011 SureshConfigurationPSLreplaced the pzt-steering mirror on PSL

[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.

  313   Tue Feb 12 16:39:52 2008 robUpdateLockingreport

Did some locking work on DRFPMI on sunday and (with John) on monday nights. So far progress has not been terribly encouraging.

Problems include the DD_handoffs not working and the CARM->MCL handoff not working so well. To get around the DD signals trouble, I decided for now to just ignore 67% of the DD signals. We should be able to run with PRC & MICH on single demod signals, and SRC on a DD signal. This seems to work well in a DRMI state, and it also works well in a DRMI+2ARMs state.

The CARM->MCL handoff actually works, but it doesn't take kindly to the AO path and it doesn't work very stably. I guess this was always the most fragile part of the whole locking procedure, and it's fragility is really coming to light now. Investigation continues.
  531   Thu Jun 12 01:51:23 2008 robUpdateLockingreport
rob, john

We've been working (nights) on getting the IFO locked this week. There's been fairly steady incremental progress each night, and tonight we managed to control CARM(MCL) using PO-DC, with the CARM(AO) path also on PO-DC. In the past, reaching this state has usually meant we're home free, as we could just crank the gain on the common mode servo and merrily reduce the CARM offset. Tonight, however, this state has been very twitchy, and efforts to ramp up the gain have been unsuccessful.

I've attached a diagram which I hope makes clear where we are in the stages of lock acquisition.
Attachment 1: lock_control_sequence.png
lock_control_sequence.png
  532   Thu Jun 12 15:09:33 2008 alanUpdateLockingreport
Rob: Awesome figure. As you can imagine, I have lots of questions, and hope that you will consider this figure to be the beginning, leading to ever-more detailed versions. But for now, I just want to ask whether you understand *what* is twitchy, and what the twitchiness does to prevent you from taking this further?
  533   Thu Jun 12 15:55:15 2008 robUpdateLockingreport

Quote:
Rob: Awesome figure. As you can imagine, I have lots of questions, and hope that you will consider this figure to be the beginning, leading to ever-more detailed versions. But for now, I just want to ask whether you understand *what* is twitchy, and what the twitchiness does to prevent you from taking this further?


I definitely don't understand what's twitchy, but I have suspicions. Tonight we'll try to start by revisiting the other loops (the non-CARM loops) and see how they're dealing with the changing power levels. It may be that the DARM loop is going unstable due to gain variations (due to either increasing power or to rotation of demod phase) or it could be the PODD (or SPOB) saturating with increased power in the recycling cavity. I just hope the glitchiness doesn't have a digital origin.
  1889   Wed Aug 12 02:00:32 2009 robUpdateLockingreport

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.

  1930   Wed Aug 19 23:57:35 2009 robUpdateLockingreport

 

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.

  4846   Tue Jun 21 00:38:21 2011 SonaliUpdateGreen Lockingrepositioned "QPDY_PD"

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.
5.We continue with the positioning of the fibre-coupling tomorrow.
Attachment 1: ETMY_table_2011_June20.png
ETMY_table_2011_June20.png
Attachment 2: ETMY_table_change1.jpg
ETMY_table_change1.jpg
  1643   Tue Jun 2 23:53:12 2009 peteDAQComputersreset c1susvme1

rob, alberto, rana, pete

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

  10476   Tue Sep 9 09:19:21 2014 SteveUpdatesafetyresponse to fried Sorensen

Quote:

Quote:

Q and Steve will follow elog 10028 entry to prepare the vacuum system for safe reboot

Here's the sequence of the morning so far:

  • I aligned the IFO (IR arms with ASS, X green with PZTs, PRM with PRMI locked on REFL33)
  • I closed the PSL shutter, and went inside to align PRM and both ITM oplevs (all others were within 10urad of zero in both directions)
  • While aligning those oplevs, I noticed the smell of burnt electronics. We tracked it down to the +15V sorensen in the rack nearest the PSL table
    • I claim the precipitating event was PSL shutter activity. If I recall correctly, the seismic rainbow traces went bonkers around the same time as the shutter was closed. There is a Guralp interface in the rack powered by the failed sorensen, so this would explain the erratic seismometer signals correlated with the power supply failure. We will look into potential shorts caused by the shutter. (Steve looked up the PMC trans and Guralp DQ channels, and confirmed the temporal coincidence of the events.)
  • We shut off all of the sorensens so that electronics were not being driven asymmetrically. 
  • Steve and I secured the vacuum system for computer reboots, as referred to in Steve's elog. Some combination of Jenne, Rana and Manasa shut down the control room computers, and turned off the watchdogs. 
  • Manasa and I moved Chiara inside, next to Mafalda, along with its backup HDs. It has been labeled. 
  • Booted up control room machines, they came up happy. 
  • FB and front-ends didn't need reboot, for some lucky reason. Watchdogs came back happily, oplev spots didn't move noticeably. 

The IFO is still down, as the PMC won't lock without the rack power, and we haven't pinned down the shorting mechanism. We don't want the replacement sorensen to immediately blow when plugged in. 

  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.

 

Attachment 1: friedSorenson.png
friedSorenson.png
Attachment 2: smokeAlarm1a.jpg
smokeAlarm1a.jpg
Attachment 3: smokeAlarm2a.jpg
smokeAlarm2a.jpg
  3415   Thu Aug 12 23:17:54 2010 ZachUpdateelogrestarted

 script

  3416   Thu Aug 12 23:41:48 2010 JenneUpdateelogrestarted

Quote:

 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!

  3420   Fri Aug 13 13:11:30 2010 DmassUpdateelogrestarted

Quote:

Quote:

 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

  3445   Thu Aug 19 21:56:02 2010 ZachUpdateelogrestarted

 script

  3465   Tue Aug 24 17:57:57 2010 ZachUpdateelogrestarted

 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?

  3466   Tue Aug 24 22:26:16 2010 ZachUpdateelogrestarted

took two again

Quote:

 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?

 

  4052   Tue Dec 14 09:26:17 2010 ZachUpdateelogrestarted

 Restarted the elog with the script

  4071   Sat Dec 18 06:24:49 2010 ranaUpdateelogrestarted

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.

  4072   Sat Dec 18 23:33:06 2010 KojiUpdateelogrestarted

Did the same.

Quote:

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.

 

  4073   Sun Dec 19 11:19:42 2010 KojiUpdateelogrestarted

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.

  4074   Sun Dec 19 22:45:28 2010 ranaUpdateelogrestarted

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.

  4111   Wed Jan 5 10:45:51 2011 KojiUpdateelogrestarted

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.

Quote:

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.

 

  4114   Wed Jan 5 21:19:29 2011 ZachUpdateelogrestarted

 Restarted the elog with the script

  4332   Mon Feb 21 11:05:51 2011 ZachUpdateelogrestarted

 I restarted the elog using the script.

  4334   Mon Feb 21 23:00:06 2011 ZachSummaryelogrestarted

 again

  4378   Fri Mar 4 13:25:04 2011 ZachUpdateelogrestarted

with script

  4556   Fri Apr 22 02:10:53 2011 ZachUpdateelogrestarted

Restarted the elog with the script.

  4571   Tue Apr 26 22:56:35 2011 ZachUpdateelogrestarted

 with script

  5362   Wed Sep 7 20:44:11 2011 SureshUpdateelogrestarted

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

 

  5785   Wed Nov 2 14:07:25 2011 ZachUpdateelogrestarted

Elog was hanging, restarted with the script.

ELOG V3.1.3-