40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 276 of 337  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  1370   Sun Mar 8 23:09:26 2009 ranaUpdateComputersNot even data retrieval working
Although getting the regular DAQ data works, we can't get any testpoints.

I tried restarting tpman several times; there's no inittab on fb40m for this so we should get Alex to set one up when he comes.
I also tried various power cycles and reboots: daqawg, daqctrl, etc. I also notice that Osamu's setup of new stuff is connected to
the same rack and power strips as all of our sensitive DAQ machines. We should find out if there was any hardware installed in the
last couple days; it would be easy to accidentally unplug or damage on of our fibers.

I moved the old tpman.log over to tpman.log.090308. It starts out with a header and then just lists when each TP is requested.

When restarting tpman it puts the following into the terminal:
fb:controls>./tpman &
[1] 1037
fb:controls>VMIC RFM 5565 (0) found, mapped at 0x2868c90
VMIC RFM 5579 (1) found, mapped at 0x2868c90
Could not open 5565 reflective memory in /dev/daqd-rfm1
16 kHz system
Spawn testpoint manager
Channel list length for node 0 is 4168
Test point manager (31001001 / 1): node 0
which is OK?; its the same startup outputs that are in the old log file. It would be nice if there was not and error message about the RFM.
Requesting new testpoints via tdsdata, dtt, or the diag command line doesn't seem to work. tpman doesn't spit anything out although 'tp show 0'
does show that the TP is selected.

Once Alex fixes the 'tpman' issue, we should make sure to put an inittab or startup script in there so that tpman writes a log
file and also archives its old log files upon a restart.
  1371   Sun Mar 8 23:14:52 2009 ranaUpdateComputer Scripts / Programstdsdata doesn't work

Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304.

He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.

This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:

./tdsdata 16384 2 C1:IOO-MC_F > /users/rana/test.txt

I loaded the data I got with the above command and there were no data dropouts. Possibly the dropout problem is only

associated with testpoints and so we have to wait for the TP fix.

  1378   Mon Mar 9 19:27:16 2009 ranaConfigurationComputersMove of the CLIO Digital Controls test setup

Because of the network interference we've had from the CLIO system for the past 3-4 days, I asked the guys to remove

the test stand from the 40m lab area. It is now in the 40m control room. Since it needed an ethernet connection to get out

for some reason we've let them hook into GC. Also, instead of using a real timing signal slaved to the GPS, Jay suggested

just skipping it and having the Timing Slave talk to itself by looping back the fiber with the timing signal. Osamu will enter

more details, but this is just to give a status update.

  1379   Mon Mar 9 19:33:10 2009 ranaUpdateDMFseisBLRMS in temp condition

The seisBLRMS has been running on megatron via an open terminal ssh'd into there from allegra with matlab running. This

is because I couldn't get the compiled matlab functionality to work.

Even so, this running script has been dying lately because of some bogus 'NDS' error. So for today I

have set the NDS server for mDV on megatron to be fb40m:8088 instead of nodus.ligo.caltech.edu. If this seems to fix the problem

I will make this permanent by putting in a case statement to check whether or not the mDV'ing machine is a 40m-martian or not.

Attachment 1: Untitled.png
  1383   Wed Mar 11 01:16:40 2009 ranaSummaryIOOrogue trianglewave in the MC Servo offset slider

On Monday evening, I ran this command: trianglewave C1:IOO-MC_REFL_OFFSET 0 4 120 600;ezcawrite C1:IOO-MC_REFL_OFFSET 1.76

which I thought (from the syntax help) would move that offset slider with a period of 120 seconds for 600 seconds. In actuality, the last argument is the

run time in number of periods. So the offset slider has been changing by 8 Vpp for most of the last day. Oops. The attached image shows what effect

this had in the MC transmitted power (not negligible). This would also make the locking pretty difficult.


In the second plot you can see the zoom in view for ~30 minutes. During the first part, the MCWFS are on and there are large fluctuations

in the transmitted power as the WFS offset changes. This implies that the large TEM00 carrier offset we induce with the slider couples into

the WFS signals because of imbalances in the quadrant gains - we need someone to balance the RF gains in the WFS quadrants by injecting

an AM laser signal and adjusting the digital gains.


Since there is still a modulation of the MC RFPD DC with the WFS on, we can use this to optimize the REFL OFFSET slider. The third plot

shows a 8 minute second trend of this. Looks like the slider offset of zero would be pretty good.

Attachment 1: Untitled.png
Attachment 2: Untitled.png
Attachment 3: a.png
  1384   Wed Mar 11 04:33:57 2009 ranaConfigurationComputer Scripts / Programswild ndsproxy tclshexe

The ndsproxy tcl task on nodus was eating up all the CPU and making the elog slow. I killed it and restarted it.

It looks like it hasn't been making a log file since January. Someone who has some skill in decoding the cryptic csh stdout redirection

syntax should look into this (its in target/ndsproxy/)

  1397   Thu Mar 12 19:11:27 2009 ranaUpdateIOOMC drift is terrible
Kakeru, Rana, Yoichi

We used the SUS DRIFT MON screen to set the MC biases such that the mirrors were returned to the old OSEM values.
To do this, we set the nominals and tolerances using the appropriate scripts in the mDV/extra/C1/ directory.

We then used the MC_ALIGN screen to set the angle bias sliders.

Then Kakeru and I went to the PSL table to the periscope magic and maximize the MC transmission. Kakeru seems to
have the careful Japanese alignment touch and I am hungry, so I am leaving him to optimize the power. After he
finishes he is going to align the beam to the WFS and turn the MC autolocker back on. The x-arm is locked on a
TEM00 mode so the MC alignment is maybe OK.
  1405   Mon Mar 16 01:20:40 2009 ranaConfigurationIOOMCWFS noise filtered on the SUS-MC
Recently, we noticed that the IOO-WFS system runs at 2048 Hz and sends its signals to the MC SUS
systems which run at 16 kHz. There is no upsampling filter or anti-imaging filter.

So, I've implemented an RLP666 filter as FM1 in the SUS-MCn_ASC(PIT/YAW) filter banks. This is like a 4th order
Cheby low pass with a low Q notch at 2048 Hz to catch the first image.

The attached PNG shows the ASCPIT_OUT signals before and after the filter is implemented. As you can see, the
big aliased spikes are gone. The reason that MC2 is different from MC1/3 is that they have a hardware 28Hz low pass
and MC2 doesn't. So MC2 had a 28 Hz low pass in software already to match the actuation phase between all the MC
mirrors. The apparent power law noise floor from 40-300 Hz in MC2 is not real - just the Hanning window tail.

And yes, it has been this way for several years and none of us noticed. It remains to be seen if this was causing
any noise in the MC coil drivers via slew rate limiting.
Attachment 1: xarm.png
  1415   Sun Mar 22 22:39:24 2009 ranaSummaryLSCCalibration of the ITM and ETM Actuation
I used the following procedure to calibrate the ITMX actuation signal.

Free Swinging Michelson:
- Restore Michelson
- Align Michelson: Minimize AS_DC (PD3_DC_OUT) by tweaking BS alignment.
- Enable Whitening filters for PD1_Q and PD3_DC.
- Run offsets script to get rid of DC and RF offsets.
- Use DTT Triggered Time Series to get time series and measure peak-peak
amplitude of PD1_Q using DTT horizontal cursors. (Templates/Calibration/090322/FreeSwing.xml)

Michelson Sweeps:
- Lock Michelson
- Drive ITMX_LSC_EXC using ITMX-MI-Sweep.xml template.
- (Next time remember to turn on a low pass in the MICH loop so that its an open loop measurement below 50 Hz).
- Fit and so some math.

Arm Sweeps for the ETMs:
- Lock a single arm
- Sweep ITM & ETM.
- Then sweep MC2 and record drive signal from MC board to the VCO driver.
- Compare and contrast.
Attachment 1: free.png
  1416   Sun Mar 22 22:47:58 2009 ranaUpdateDMFseisBLRMS compiled but still dying
Looks like seisBLRMS was restarted ~1 AM Friday morning but only lasted for 5 hours. I just restarted it on megatron;
let's see how it does. I'm not optimistic.
  1417   Sun Mar 22 23:16:41 2009 ranaDAQComputer Scripts / Programstpman restart
Could get testpoints but couldn't start excitations. Restarted tpman on daqawg. Works now.

Still no log file. Mad
  1418   Mon Mar 23 15:50:44 2009 ranaConfigurationLSCfilters deleted, lsc rebooted

The LSC time had gone too high. I deleted ~20 filters and rebooted. CPU time came down to 50 usec.

The filters all looked like old trash to me, but its possible they were used.

I didn't delete anything from the DARM, CARM, etc. banks but did from the PD and TM filter banks. You can always go back in time by using the


  1424   Tue Mar 24 23:23:05 2009 ranaUpdateLSCNew PO DC
We also found that the SPOB RF cable was going through a splitter before going into the SPOB demod board. The other
input of the splitter was open (not terminated). Using 50m Ohm devices without terminated inputs is illegal. It
makes there be standing waves in the cables and makes the RF phase very dependent on cable lengths. We took away
the splitter and ran the cable straight. So expect some change in the SPOB gain and phase plus some shame.
  1441   Mon Mar 30 09:07:22 2009 ranaUpdateSUSMC1 drift investigation continued
Maybe we can temporarily just disconnect the bias and just use the SUS sliders for bias if there's enough range?
  1456   Mon Apr 6 21:50:43 2009 ranaUpdateLSCArm Locking via pushing MC2
Inspired by our 'No Refcav' scheme here, I was inspired to re-explore the idea of locking the
CARM DOF using only feedback to the MC/laser. Last week I got this to work on the single arm and
full IFO at Livingston.
I also estimate the MC noise there.

Today I found the settings to allow X-arm locking here without any feedback to the ETM or ITM:

- Set the LSC Output Matrix to feed the XARM signal to MC2.
- Turn OFF the input of the LSC-ETMX filter bank (this does not disable tickling).
- Turn OFF FM7 (0.1:10) in MC2-MCL.
- Turn ON MC2-LSC with a gain of 0.2 and FM3 FM4 FM5.

That's enough to lock the arm - its pretty stable. This also assumes that the LSC-MC2 bank has its nominal gain of -0.178.

To determine the gain of +0.2 in the MC2-LSC filter bank, I measured the TF from MC2->PD3_I and from ETMX->PD3_I. I adjusted
the gain to be equal at 150 Hz for acquisition and the sign to be opposite to account for the (-) in LSC-MC2. The TF is

After locking, I type a zero into the MC2-MCL filter bank and that shuts off the feedback from the MC servo to MC2. This is
now topologically similar to the standard CM servo configuration.

The second attachment has the trends of this locking. You can see that the MC_F goes off into the weeds, but the MCL signal
does not so much. I think maybe the MC length is drifting a lot - not the arm.

The third attachment shows the spectra.
Attachment 1: mc2-xarm.pdf
Attachment 2: Untitled.png
Attachment 3: nohands.pdf
  1460   Wed Apr 8 18:18:33 2009 ranaConfigurationComputersLSC code recompiled with a fix for denormalization problem
Below is the link to the anti-denormalization technique that Rolf and Alex implemented at the sites,
that was pointed out by Chris Wipf from MIT:

  1461   Wed Apr 8 18:46:50 2009 ranaConfigurationGeneralDMF, SVN, x2mc, and matlab

While waiting for the installation of the 32-bit Matlab 2009a to finish, I tried updating our seisBLRMS.m code.

Although DMF is in SVN, we forgot to check it out and so the directory where we have been doing our mods is not a working copy and our changes have not been captured: Shame.

We will probably have to wipe out the existing SVN trunk of DMF and re-import the directory after checking with Yoichi for SVN compliance.

Also wrote a script: LSC/x2mc, which will transition from regular ETM based X Arm locking to the MC2 based locking. It ran once OK, but I get a segfault on the 'trianglewave' which was trying to run the 'ezcastep' perl script which was calling 'ezcastep.bin'.

I also restarted the seisBLRMS.m on a terminal on Mafalda in the new Matlab 2009a to see if it loses its NDS connection like it did with 2007a. I also reduced the 'delay' parameter to 4 minutes and the 'interval' to 1 minute. This should be so that the total delay is now 5 minutes between seismic noise and seismic trend.

  1467   Fri Apr 10 01:24:08 2009 ranaUpdateComputersallegra update (sort of)

I tried to play an .avi file on allegra. In a normal universe this would be easy, but because its linux I was foiled.

The default video player (Totem) doesn't play .avi or .wmv format. The patches for this work in Suse but not Fedora. Kubuntu but not CentOS, etc.I also tried installing Kplayer, Kaffeine, mplayer, xine, Aktion, Realplay, Helix, etc. They all had compatibility issues with various things but usuallylibdvdread or some gstreamer plugin.So I pressed the BIG update button. This has now started and allegra may never recover. The auto update wouldn't work in default mode becauseof the libdvdread and gstreamer-ugly plugins, so I unchecked those boxes. I think we're going to have this problem as long as we used any kind ofadvanced gstreamer stuff for the GigE cameras (which is unavoidable).


  1468   Fri Apr 10 03:10:08 2009 ranaSummaryLockingLaser PM to REFL-DC transfer functions at multiple CARM offsets

I hereby award the previous rainbow transfer functions the plot innovation of the month award for its use of optical frequency to denote CARM offset.

The attached movie here shows the sensing matrix (minus MICH) as a function of CARM offset. There are 3 CARM signals plotted:

GREEN - tonights starting CARM signal - REFL_DC

RED - my favorite CARM signal - REFL 166 I

CYAN - runner up CARM signal - POX 33 I

  1475   Sun Apr 12 19:27:20 2009 ranaUpdatePSLPMC LO Calibration


3.8Vpp is about 16dBm.
The mixer for the PMC demodulator is level 23. So 16dBm is insufficient.
What is the level of the new mixer Steve ordered ? 13 ?

Since Steve and Jenne were on it, I'm sure they ordered the optimum values...

From the table, it looks like the drive level adjuster is busted. Its not supposed to just give a
1-2 dB change over the full range. We'll have to think about what exactly to do, but we should
probably install the level 13 mixer and put in the right attenuation to make the LO be ~13.5 dBm
including the filter. Also need to calibrate the LO readback on the board like what Peter did for
the FSS.
  1476   Sun Apr 12 19:31:43 2009 ranaSummaryElectronicsAmphony 2500 Headphones
We bought the Amphony 2500 Digital Wireless headphones recently. The other cheapo headphones we have are OK for control room use, but have a lot of noise
and are, therefore, not useful for noise hunting.

The new digital ones are pretty much noise-free. With the transmitter next to rosalba, you can walk halfway down the east arm and all around the MC area
before the reception goes bad. For real noise hunting, we will want to put the transmitter next to the BS chamber and take an analog pickoff from the DC PDs.

In the OMC diagram, we should put an AUDIO filterbank and wire it to the DAC so that we can do arbitrary IIR filtering on the audio signal.
  1483   Wed Apr 15 02:18:42 2009 ranaConfigurationComputersnodus vfstab changed for rigel

nodus was hanging because it was trying to mount the cit40m account from rigel and rigel was not responding.

Neither I nor Yoichi can recall what the cit40m account does for us on nodus anymore and so I commented it out of the nodus /etc/vfstab.

nodus may still need a boot to make it pay attention. I was unable to do a 'umount' to get rid of the rigel parasite. But mainly I don't want anything in

the 40m to depend on the LIGO GC system if at all possible.

  1485   Wed Apr 15 03:52:27 2009 ranaUpdateDMFNDS client32 updated for DMF
 Since our seisBLRMS.m complains about 'can't find hostname' after a few hours, even though matlab is able to ping fb40m, 
I have recompiled the NDS mex client for 32-bit linux on mafalda and stuck it into the nds_mexs/ directory. This time I 

 compiled using the 'gcc' compiler instead of the 'ANSI C' compiler that is recommended in the README (which, I notice,


 is now missing from Ben Johnsons web page!). Let's see how long this runs.

  1501   Mon Apr 20 18:36:37 2009 ranaUpdateCamerasMafalda may need an update
Sadly, the sensoray crap doesn't seem to build on CentOS. I too would prefer a homogenous solution,
but I don't know how to make this happen without punishing Joe with sensoray driver development on CentOS.
  1503   Mon Apr 20 20:00:44 2009 ranaConfigurationIOOMcWFS gains re-allocated
Since it looks like the night time people have been running with a WFS gain of 0.05 and I like the slider
to be at 1.0, I lowered all of the WFS1/2_P/Y gains by 10 and increased the overall slider from 0.05 to 1.0.
So the loop gains are now 2x higher; with it like this I guess the UGFs are in the ~0.2-0.5 Hz range.
  1504   Mon Apr 20 20:45:25 2009 ranaConfigurationGeneralSVN: project area added
I added the /cvs/cds/project/ directory to the SVN. I've noticed that we've been using target/ for code which is not
being targeted for any IOCs. This is out of line with the intention of separating real time FE code from just regular
code that we use for diagnostics or otherwise.

So please move all of your non-FE code over to project from target. And if you didn't have it in SVN at all, you
should experience level 3 shame and then import it.
  1505   Mon Apr 20 23:27:59 2009 ranaSummaryVACc1vac2 rebooted: non-functional for several months
We found several problems with the framebuilder tonight. The first symptom was that it was totally out of
disk space. The latest daqd log file had gone up to 500 MB and filled the space. The log file was full of
a lot of requests from my seisBLRMS.m code, but what was really making it so big was that it couldn't
connect to c1vac2 (aka scipe4) to make connections for some channels.

We looked into the daqd log files and this has been going on since at least December. There were several
'whited out' records for TP2 and TP3 in the Vacuum overview as well as the Checklist screen! Why did no
one notice this and fix it??
WE cannot function if we just ignore any non-functioning displays and say
"Oh, that never worked."

For sure, we know that it was working in 2005. Jay and Steve and Alan looked at it.

Today it was responding to ping and telnet, but not allowing any new connections. I hit the RESET button
on it. Several lights went RED and then it came back up. The readbacks on the EPICS screens are OK too.

I went into fb0 and deleted many of the GB size log files from the past several months. There is now
19GB free out of its local 33GB disk.
  1552   Wed May 6 19:04:11 2009 ranaSummaryVACvac images
Since there's no documentation on this besides Steve's paper notebooks...

and BTW, since when did the elog start giving us PNG previews of PDFs?
Attachment 1: vacrack.pdf
  1562   Fri May 8 04:31:35 2009 ranaUpdateComputer Scripts / Programselog and NDS
In the middle of searching through the elog, its stopped responding. So I followed the Wiki instructions
and restarted it (BTW, don't use the start-elog-nodus script that's in that directory). Seems OK now,
but I am suspicious of how it sometimes does the PDF preview correctly and sometimes not. I found a
'gs' process on there running and taking up > 85% of the CPU.

I also got an email from Chris Wipf at MIT to try out this trick from LASTI to maybe fix the
problems I've been having with the DMF processes failing after a couple hours. I had compiled but
not tested the stuff a couple weeks ago.

Today after it failed, I tried running other stuff in matlab and got some "too many files open" error messages.
So I have now copied the 32-bit linux NDS mex files into the mDV/nds_mexs/ directory. Restarted the
seisBLRMS.m about an hour ago.
  1567   Fri May 8 16:29:53 2009 ranaUpdateComputer Scripts / Programselog and NDS
Looks like the new NDS client worked. Attached is 12 hours of BLRMS.
Attachment 1: Untitled.png
  1570   Sat May 9 15:19:10 2009 ranaUpdatePSLLaser head temperature oscillation
This is 8 days of 10-minute trend.

DTEC is just the feedback control signal required to keep the NPRO's pump diode at a constant temperature.
Its not the amplifier or the actual NPRO crystal's temperature readout.

There is no TEC for the amplifier. It looks like to me that by opening up the flow to the NPRO some more
we have reduced the flow to the amplifier (which is the one that needs it) and created these temperature

What we need to do is choke down the needle valve and ream out the NPRO block.
Attachment 1: Picture_2.png
  1583   Wed May 13 21:15:04 2009 ranaSummarySUSChannel Hopping: That ancient enemy (MC problems)
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.
  1596   Sun May 17 23:22:19 2009 ranaUpdateEnvironmentseisBLRMS for the past 3 weeks
Looks like Chris Wipf's fix of using fclose worked for the NDS client.
The attached plot shows the minute trend RMS - we should put the calibration for these into the .m file
so that the EPICS values are in something useful like microns or microns/sec.

I also now see why Nodus seems really slow with the elog sometimes. When we load a page with an attached
PDF, it runs 'gs' to try to generate the PNG preview. Because its on Solaris it often fails because it
can't find some font. We should probably disable the preview or fix the font issue.
Attachment 1: Untitled.png
  1597   Mon May 18 01:54:35 2009 ranaUpdatePEMUnplugged Guralp channels
To see if Caryn's data dropouts were happening, I looked at a trend of all of our temperature channels. Looks OK now.

Although you can't see it because I zoomed in, there's a ~24 hour relaxation happening before Caryn's sensors equilibrate.
I guess that's the insulating action of the cooler? We need a picture of the cooler in the elog for posterity.
Attachment 1: Untitled.png
  1598   Mon May 18 02:18:17 2009 ranaSummarySEIUsing STACIS w/ a good position sensor
WE turned off STACIS a few years ago because we noticed that it was causing noise below a few Hz and making
the overall velocity between the ends higher than with them off. I'm pretty sure they were causing noise
because they use little geophones which are noisy. Below ~0.2 Hz the horizontal geophones are also probably
limited by tilt-horizontal coupling.

Another concept (based on discussion with Brian Lantz and Matt Evans) is to instead put a good position sensor
between the ground and then blue support beam. Since the the STACIS rubber acts like a Q~2 passive resonance at
20 Hz, the whole seismic system (including the blue beams, in-vac tubes, and internal stack) act like a proof
mass of a seismometer.

So, in principle, if we use a very good position sensor and feedback to the STACIS piezo actuators, we can cancel
the ground motion before it enters the stacks. The initial LIGO OSEMs have a noise of 10^-10 m/rHz above 10 Hz
and going up like 1/f below 10 Hz. The AdvLIGO BOSEMs have a noise of ~2x better. Even better, however, are the
UK's EUCLID interferometric OSEMs (developed by Stuart Aston and Clive Speake).

In the attached plot, I show what we can get if we use these EUCLIDs make a ~60 Hz BW feedback loop w/ STACIS.

BLACK   - raw ground motion measured by the Guralp
MAGENTA - motion after passive STACIS (20 Hz harmonic oscillator with a Q~2)
GREEN   - difference between ground and top of STACIS
YELLOW  - EUCLID noise in air
BLUE    - STACIS top motion with loop on (60 Hz UGF, 1/f^2 below 30 Hz)
CYAN    - same as BLUE, w/ 10x lower noise sensor

One of the SURF projects this summer is to put together a couple different sensors like EUCLID to understand the noise.
Attachment 1: stacis40.png
  1600   Mon May 18 15:31:11 2009 ranaUpdatePEMTemp sensor

Picture of cooler for posterity is attached

I'm puzzled as to why the minute trend doesn't pick this up; its clearly there in the full data.

Looks like its several samples too. Can someone please reboot this DCU and see if the problem goes away?
Attachment 1: Untitled.png
  1602   Mon May 18 20:16:20 2009 ranaConfigurationVACnot it
There was essentially no change in the ETMY oplev spectrum with the cryo off!

So I went out to the ETMY OL table to see what else was going on. I found there one of
the most horrible opto-mechanical setups
I have ever seen (and remember that I have once
seen someone mount an NPRO on a cardboard box). Some bad person had mounted the ETMY OL
lens on a 12" long skinny post and extended it towards the viewport. So there was a post
holder on the table and a lens ~12" away on a rickety lever arm.

I took this lens away and the spectrum is now good. Shame on you.
CYAN -  cryo ON
BLACK - cryo OFF
BLUE -  no crappy lens + mount

This OL needs to be fixed correctly by putting in a proper lens to get a small spot on the QPD.
Attachment 1: a.png
  1603   Mon May 18 21:34:18 2009 ranaConfigurationSUSETMY f2pRatio script run
Now that the ETMY optical lever is not so bad, I ran the f2pRatio script and it seems to have worked.

I cleaned up the script a little also. Updated in the SVN.

ETMY's A2L scripts have to be run to reduce the A2L noise once the arm is locked again. Might also need
to set the OL UGF too.
  1608   Tue May 19 16:08:03 2009 ranaSummarySEIEUCLID
From Stuart Aston, I've attached a picture of the EUCLID position sensor:
Attachment 1: Picture_6.png
  1617   Thu May 21 18:07:32 2009 ranaUpdatePSLScrew on Needle valve loosened
Alberto and I went in to loosen up the needle valve yesterday around 4:30 PM. The idea was to cut down on
the flow to the NPRO so that the cooling power of the chiller would be used almost entirely on the
amplifier instead of the NPRO block.

The need valve was basically all the way open. The lock nut was screwed in all the way and stuck. By using
pliers and a wrench for the nut, we freed the lock nut. Even so, the screw for the needle valve seemed to
be bad: I think the thread is stripped; it doesn't go down even after several turns. I even tried to squirt
alchohol on it and really press down in the hopes of catching a thread. It may have closed slightly but its
impossible to be sure.

I also increased the NPRO diode current to the max (+0.1 A). This got us a little bit of NPRO power and
I hope some more AMPMON stability. The attached plot shows 4 days of minute trend. If you squint you
might believe that we got some suppression in the HTEMP fluctuations over the last two days.
Attachment 1: Untitled.png
  1618   Thu May 21 18:21:57 2009 ranaSummaryTreasureYoichi's words

Yoichi's final words on what do next with the interferometer (as of 5 PM on May 21, 2009):

  1. Measure laser noise couplings in spring and anti-spring configurations.
  2. Dewhitening filter turn on for the ETMs.
  3. Noisebudget - import from the sites.
  4. Stabilize CM handoff.

My personal sub-comments to these bullets:

  1. For the laser noise I'm not sure that we will be able to understand these if the couplings are mainly from junk light due to accidental HOM resonances.
  2. WE should look into putting a static passive stage of filtering into the ETMs if warranted by the NB.
  3. Because of the sad track record with this, I will start us off this time by importing and modifying the H1/L1 versions.
  4. I guess we can do this by just acquiring on MC2 with the huge CARM offset. It works for the single arm so it should work for offset CARM.
  1639   Mon Jun 1 15:01:31 2009 ranaUpdatePSLLaser Power after fixing the laser chiller: more traces
If you look at the correlation between RMTEMP and HTEMP, you see what we knew: namely that there
was a 1:1 correlation before. After the chiller fix, I can see no correlation between the room and
amplifier temperature at the resolution of 10:1. So the chiller loop has a gain > 10 at 24 hour time

I don't understand why the PMC looks more stable.
Attachment 1: Picture_7.png
  1640   Mon Jun 1 19:19:26 2009 ranaUpdatePSL1000 days of hour-trend
Attachment 1: u.png
  1646   Wed Jun 3 03:30:52 2009 ranaUpdateMOPANPRO current adjust
I increased the NPRO's current to the max allowed via EPICS before the chiller shutdown. Yesterday, I did this
again just to see the effect. It is minimal.

If we trust the LMON as a proportional readout of the NPRO power, the current increase from 2.3 to 2.47 A gave us
a power boost from 525 to 585 mW (a factor of 1.11). The corresponding change in MOPA output is 2.4 to 2.5 W
( a factor of 1.04).

Therefore, I conclude that the amplifier's pump has degraded so much that it is partially saturating on the NPRO
side. So the intensity noise from NPRO should also be suppressed by a similar factor.

We should plan to replace this old MOPA with a 2 W Innolight NPRO and give the NPRO from this MOPA back to the
bridge labs. We can probably get Eric G to buy half of our new NPRO as a trade in credit.
Attachment 1: Untitled.png
  1649   Wed Jun 3 18:55:27 2009 ranaUpdateCOCsnapshot of upgrade layout
Attachment 1: layout.png
  1689   Sun Jun 21 00:08:26 2009 ranaConfigurationComputerselog rebooted



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
Mar 10 11:11:32 nodus sshd[22775]: [ID 800047 auth.crit] fatal: Timeout before authentication for
Mar 11 13:27:37 nodus sshd[7768]: [ID 800047 auth.error] error: connect_to 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 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 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 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
Mar 14 20:14:42 nodus sshd[13563]: [ID 800047 auth.crit] fatal: Timeout before authentication for
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

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

  1702   Thu Jun 25 17:27:42 2009 ranaUpdateComputerstdsresp on linux
I downloaded the tdsresp.pl from LLO and put it into the various TDS/bin paths. Also updated the LLO specific path stuff. It runs.
  1706   Fri Jun 26 19:14:04 2009 ranaUpdateEnvironmentseisBLRMS for the past 3 weeks
Restarted the seisBLRMS.m on mafalda (running a term on op540m). Don't know why it stopped - the
terminal had a 'disabled by EPICS' message even though the EPICS enable button was enabled.

I also changed the delay from 4 to 2 minutes. So now it is calculating a 64 s PSD starting from 2 minutes ago. We had
put it back to 4 minutes long ago since the framebuilder was acting slow, but maybe it will work now since its using
the NDS1 protocol instead of direct frame reading. If it starts not finding data, please kill the seisBLRMS and restart
it with a 3 minute delay.
  1727   Thu Jul 9 02:18:09 2009 ranaUpdatePEMBonnie moved to PSL, getting some coherence with the PMC_ERR channel
My guess is that we need a different acoustic strategy. The microphones are mainly for high frequencies,
so you should not expect any coherence with MC_L (or even better, MC_F) below 100 Hz. I expect that the
main coherence for MC_F will come from the PSL in that band.

After subtracting that one out, we should look at the signal from the lock of the X or Y arm, and see
if we can nail that by putting a mic right above the AS table (leaving enough room to take the lid off).
If that works OK, we can find a spot under the lid and se if it gets better.
  1729   Thu Jul 9 19:24:50 2009 ranaUpdatePEMmore mic position changes; mics not picking up high frequencies
Might be the insidious 850 Hz AA filters in the black AA box which precedes the ADC.

Dan Busby fixed up the PSL/IOO chassis. WE might need to do the same for the PEM stuff.
ELOG V3.1.3-