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.

I restarted the frame builder in the last 15mins. 

I was making a change to a DAC channel in the C1IOO model.

I restarted the fb twice during the last 15mins.   This was after I added test points into the C1IOO/WFS1.mdl and C1IOO/WFS2.mdl.

On the plus side, it was the first time I've had to do it in a while..

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

Then I turned on the whitening filter for POXDC and POYDC (C1:LSC-POXDC FM1, C1:LSC-POYDC FM1) and changed the gain of analog whitening filter for POXDC and POYDC from 0 dB to 45 dB and from 0 dB to 39 dB, respectively (C1:LSC-POXDC_WhiteGain, C1:LSC-POYDC_WhiteGain).

In preparation for tonight's work, I did the following:

On the PSL table:

• Powered the RF amplifiers for the green beat signal on
• Reconnected the outputs of the Green beat PDs to the RF amplifiers
• Restored wiring in the fiber box such that both IR beats go to the frequency counter.

At the IOO Rack area:

• Restored wiring to the frequency counter module such that the IR beats from both arms go to the respective channels
• Partially cleaned up the setup used for measuring AUX laser frequency noise - moved the SR785 to the X end along with one SR560 so that we can measure the end PDH OLTF
• Brought the HP network analyzer back to the control room so that we can view the green beatnotes.

At the X-end:

• Turned the function generator used for PDH locking back on
• Checked that the AUX laser diode current is 1.90 A, and the crystal temperature is ~47.5 degrees, both of which I think are "good" values from our AUX laser frequency noise measurements
• Did some minor manual alignment of the PZT mirrors

At the Y-end:

• Restored the BNC connection from the PDH box to the laser's "FAST" control input. The long BNC cable used for the PLL is still running along the Y-arm, I will clean this up later.

Having done all this, I checked the green transmission levels for both arms (PSL green shutter closed, after running ASS to maximize IR transmission). GTRY is close to what I remember (~0.40) while the best I could get GTRX to is ~0.12 (I seem to remember it being almost double this value - maybe the alignment onto the beat PD has to be improved?). Also, the amplitudes of the beatnotes on the network analyzer are ~-50dBm, and I seem to remember it being more like -25dBm, so maybe the alignment on the PD is the issue? I will investigate further in the evening. It remains to measure the OLTF of the X-end PDH as well.

 Please, restore condition after you finished and update elog right away! People wasted hours yesterday not knowing the condition of the MC

ETMX medm screen values are blank.

 Our spare Osaka maglev purchased in Oct 2005 turned out to be having a viton o-ring seal connection on the intake.

It was shipped back to San Jose for retrofitting it with 6" conflat flange ( CF ) This CF is using copper gasket so there will be no permeation of He when you leak check the IFO

The digital controller and cable are here. The controller needs to be interfaced with the interlocks and computer system; those have been in a neglected condition lately.

see elog #1505  Historically after every REBOOT of c1vac2 the readbacks works for 3-4 days only. Fixing of this was postponed many times in the past as low priority or lack of knowledgeable

enthusiast.

The maglev TG390MCAB wil be back on Tuesday, May 4, 2009.  The mourning of our fateful 360 will only end at the first levitation of the 390.

To design a new resonant EOM box I started reviewing the prototype that I've built.

As a part of reviewing I checked an important thing that I haven't carefully done so far :

I compared the measured input impedance with that of predicted from a circuit model. I found that they show a good agreement.

So I am now confident that we can predict / design a new circuit performance.

* * * (input impedance) * * *

 Performance of a resonant circuit is close related to its input impedance and hence, in other words, determined by the input impedance.

Therefore an investigation of input impedance is a way to check the performance of a circuit. That's why I always use impedance for checking the circuit.

The plot below is a comparison of input impedance for the measured one and one predicted from a model. They show a good agreement.

(Note that the input impedance is supposed to have 50 Ohm peaks at 11, 29.5 and 55 MHz.)

 
* * * (circuit model) * * *

To make the things simpler I assume the following three conditions in my model:

 1. inductor's loss is dominated by its DC resistance (DCR)

 2. capacitor's loss is characterized only by Q-value

 3. Transformer's loss is dominated by DCR and its leakage inductance

All the parameters are quoted from either datasheet or my measurement. The model I am using is depicted in the schematic below.

Basically the Q-vaules for the capacitors that I used are quite low. I think higher Q capacitors will improve the performance and bring them to more 50 Ohm.

Background:
  Yesterday, I said I will use ZHL-32A for amplifying beat note signal, but as Koji pointed out, ZHL-32A is for medium high power.
  So I changed my mind to use ZFL-1000LN instead. ZFL-1000LN is a low noise RF amp whose maximum power is 3dBm.
  Also, we included a splitter in our consideration.

What I did:
1. Set up a new setup. ZFL-1000LN has a gain of +24dB at 80MHz and splitter ZFRSC-42 has a loss of -6dB. So;

beat note signal -> ZFL-1000LN -> ZFL-1000LN -> ZFRSC-42 => SR620 and VCO

2. Measured frequency-output relation. When the input signal was 80MHz -48dBm, the output was -8.7dBm. For other frequencies;
       60MHz  -3.3dBm
       70MHz  -5.7dBm
       80MHz  -8.7dBm
       90MHz  -5.5dBm
      100MHz  -3.5dBm
  So, we can see frequency up to >100MHz by SR620 using this setup.

3. Checked harmonics peak levels of the output using an RF spectrum analyzer. When the input signal was 80MHz -48dBm, the height of the peaks were;
     80MHz -8.8dBm
    160MHz -30dBm
    240MHz -42dBm
  Other peaks were smaller than the 3rd harmonics. Also, RF PD that detects beat note signal has a cut-off frequency at around 100MHz. So, we don't need to worry about wave transformation for this setup.

Yes. I corrected my previous elog.

Current status:

• There is a single Acromag ADC unit installed in 1X4
• It is presently hooked up to the PSL NPRO diagnostic connector channels
• I had (re)-started the acquisiton of these channels on August 16 - but for reasons unknown, the tmux session that was supposed to be running the EPICS server on megatron seems to have died on August 22 (judging by the trend plot of these channels, see Attachment #1)
• I had not set up an upstart job that restarts the server automatically in such an event. I manually restarted it for now, following the same procedure as linked in my previous elog.
• While I was at it, I also took the opportunity to edit the Acromag channel names to something more appropriate - all channels previously prefixed with C1:ACRO- have now been prefixed with C1:PSL-

Plan of action:

1. Hardware - we have, in the lab, in addition to the installed ADC unit
   • 3x 8 channel differential input ADC units
   • 2x 8 channel differential output DAC units
   • 1x 16 channel BIO unit
   • 2U chassis + connectors + breakout boards + other misc hardware that I think Johannes and Lydia procured with the original plan to replace the EX slow controls.
   • Some relevant elogs: Panel designs, breakout design, sketch for proposed layout, preliminary channel list.
     So on the hardware side, it would seem that we have everything we need to go ahead with replacing the EX slow controls with an Acromag system, although Johannes probably knows more about our state of readiness from a hardware PoV.
2. Software
   • We probably want to get a dedicated machine that will handle the EPICS channel serving for the Acromag system
   • Have to figure out the networking arrangement for such a machine
   • Have to figure out how to set up the EPICS server protocol in such a way that if it drops for whatever reason, it is automatically restarted

http://www.supermicro.com/products/system/1U/5015/SYS-5015A-H.cfm?typ=H

This is the machine that Larry suggested when I asked him for his opinion on a low workload rack-mount unit. It only has an atom processor, but I don't think it needs anything particularly powerful under the hood. He said that we will likely be able to let us borrow one of his for a couple days to see if it's up to the task. The dual ethernet is a nice touch, maybe we can keep the communication between the server and the DAQ units on their separate local network.

We'd like to setup the recording of the PSL diagnostic connector Acromag channels in a more robust way - the objective is to assess the long term performance of the Acromag DAQ system, glitch rates etc. At the Wednesday meeting, Rana suggested using c1ioo to run the IOC processes - the advantage being that c1ioo has the systemd utility, which seems to be pretty reliable in starting up various processes in the event of the computer being rebooted for whatever reason. Jamie pointed out that this may not be the best approach however - because all the FEs get the list of services to run from their common shared drive mount point, it may be that in the event of a power failure for example, all of them try and start the IOC processes, which is presumably undesirable. Furthermore, Johannes reported the necessity for the procServ utility to be able to run the modbusIOC process in the background - this utility is not available on any of the FEs currently, and I didn't want to futz around with trying to install it.

One alternative is to connect the PSL Acromag also to the Supermicro computer Johannes has set up at the Xend - it currently has systemd setup to run the modbusIOC, so it has all the utilities necessary. Or else, we could use optimus, which has systemd, and all the EPICS dependencies required. I feel less wary of trying to install procServ on optimus too. Thoughts?

Rga scan of day 231 since pumpdown pd66-m-d231

m stands for maglev pumping speed, vacuum normal condition of valves,

cc4 cold cathode gauge at the rga location,

cc1 is real ifo pressure from the 24" tube at the pumpspool,

PEM-count temp: vac envelope temp at the top of IOO chamber

We did our first ringdown measurement on the Y arm. First we tried to keep the arm locked in green during the ringdown, but for some reason it was not possible to get the cavity locked in green. So we decided to do the first measurement with infrared locked only.

For the measurement we had to change the LSC model to acquire the C1:LSC-TRY_OUT_DQ at higher sampling frequency. We changed the sampling frequencies of C1:LSC-{TRX,TRY}_OUT_DQ from 2048Hz to 16384Hz.

The measurement was done at GPS 1027289507. The ringdown curve looks very clean, but there seem to be two time constants involved. The first half of the curve is influenced by the shutter speed, then curvature is changing sign and the ringdown is likely taking over. We will try to fit a curve to the ringdown part, but it would certainly be better to have a faster shutter and record a more complete ringdown.

Is this the step response of the single pole low pass???
It should have an exponential decay, shouldn't it? So it should be easier to comprehend the result with a log scale for vertical axis...

I think you need a fast shutter. It is not necessary to be an actual shutter but you can use faster thing
which can shut the light. Like PMC or IMC actuators.

Another point is that you may like to have a witness channel like the MC transmission to subtract other effect.

Let's see if the ripples observed in the MC ringdown can be due to tilt motion of the mirrors.

The time it takes to produce a phase shift corresponding to N multiples of 2*pi is given by:

t = sqrt(2*N*lambda/(L*omega_T^2*(alpha_1+alpha_2)))

L is the length of the MC (something like 13m), and alpha_1, alpha_2 are the DC tilt angles of the two mirrors "shooting into the long arms of the MC" produced by the MC control with respect to the mechanical equilibrium position. omega_T is the tilt eigenfrequency of the three mirrors (assumed to be identical). lambda = 1.064e-6m;

The time it takes from N=1 to N=2 (the first observable ripple) is given by: tau1 = 0.6/omega_T*sqrt(lambda/L/(alpha_1+alpha_2))

The time it takes from N=2 to N=3 is given by: tau2 = 0.77*tau1

etc

First, we also see in the measurement that later ripples are shorter than early ripples consistent with some accelerated effect. The predicted ripple durations tau seem to be a bit too high though. The measurements show something like a first 14us and a late 8us ripple. It depends somewhat on the initial tilt angles that I don't know really.

In any case, the short ripple times could also be explained if the tilt motions start a little earlier than the ringdown, or the tilt motion starts with some small initial velocity. The next step will be to program a little ringdown simulation that includes mirror tilts and see what kind of tilt motion would produce the ripples exactly as we observe them (or maybe tilt motion cannot produce ripples as observed).

Isn't it just a ringing of the intracavity power as you shifted the laser frequency abruptly?

Hmm. I don't know what ringing really is. Ok, let's assume it has to do with the pump... I don't see how the pump laser could produce these ripples. They have large amplitudes and so I always suspected something happening to the intracavity field. Therefore I was looking for effects that would change resonance conditions of the intracavity field during ringdown. Tilt motion seemed to be one explanation to me, but it may be a bit too slow (not sure yet). Longitudinal mirror motion is certainly too slow. What else could there be?