Its OK, but the real number comes from measuring the time series of this in the daytime (not the spectrum). What we care about is the peak-peak value of the PZT feedback signal measured on a scope for ~30 seconds. You can save the scope trace as a PNG.

Valera and I put the 2 Guralps and the Ranger onto the big granite slab and then put the new big yellow foam box on top of it.

There is a problem with the setup. I believe that the lead balls under the slab are not sitting right. We need to cut out the tile so the thing sits directly on some steel inserts.

You can see from the dataviewer trend that the horizontal directions got a lot noisier as soon as we put the things on the slab.

 Although trends are available, I am unable to get any full data from in the past (using DTT or DV). I started the FB's daqd process a few times, but no luck. 

I blame Joe's SimPlant monkeying from earlier today for lack of a better candidate. I checked and the frames are actually on the FB disk, so its something else.

The seismometers showed an increased noise in the Y-direction when put on top of the granite slab. By tapping the slab, you can tell that its really a mechanical resonance of the lead balls + granite system at ~15-20 Hz.

I tried new balls, flipping the slab upside down, and sitting on the slab for awhile. None of this changed the qualitative behavior, although each of the actions changed the resonance frequencies by several Hz.

I have removed the granite/balls and put the seismometers back on the linoleum floor. The excess noise is gone. I have put the new big box back on top of them and we'll see how the data looks overnight.

I expect that we should remove the linoleum in a wider area and put the seismometers directly on the floor.

This plot shows the noise with the box on, but no granite. We're still pretty far off from the Guralp data sheet.

I implemented software rotation in the huddle subtraction as Valera suggested and it works much better. The two plots below show the before and after. So far this is just 2 deg. of rotation around the z-axis. I'm assuming that aligning the seismometers vertically via bubble level is good enough for the z-axis, but I haven't calibrated the bubble yet.

The residual slope is now suspiciously smooth. I somehow suspect that our readout electronics can still be responsible. We need to hook up a 9V battery to the input terminals to check it out. Its a little steeper than 1/f and I thought that we had exonerated the Guralp breakout box in the past, but now I'm not so sure. I'll let Jenne comment on that.

I also noticed that we have not yet divided by sqrt(2) to account for the fact that we are subtracting 2 seismometers. In principle, an unbiased estimate of the single seismometer noise will be lower by sqrt(2) than the green curve.

 At ~2350 UTC on June 2, the seismometers were turned off. After the granite slab was repositioned with the new lead, the Ranger was turned on, but not the Guralps.

Now, after ~24 hours, I have put the Guralps onto the granite and turned them on. During this off time, the input channels should be ADC noise limited (or perhaps limited by the INA134 differential receiver chips inside of the Sander Liu AA chassis). The following plot shows that this noise level is ~0.8 uV/rHz and then rising like ~1/sqrt(f) below 5 Hz:

I checked the slab again by whacking it. It still rings with a Q of several, so I think we need to make the lead flatter. There should barely be any room between the granite and the linoleum.

UPDATE:

I guessed that it should be possible to make the slab-to-floor coupling better with flatter lead (Brian Lantz suggested to use lead sheets). So I removed my booties and jumped up and down on the granite several times. Because of my soft sole shoes, I was able to make an impulsive impact without shattering the granite. The effect of the stomping was pretty dramatic - the horizontal resonance frequency has gone up by a factor of 2. The red trace shows the new TF after the stomping:

 And the resulting spectrum is here too. As you can see, there is no excess between the Ranger and the Guralps until ~50 Hz where the mechanical resonance in the short direction (non-MC dir) takes over.

 So, the lesson for next time is to flatten the balls a little more. I leave it to Nancy to calculate the horizontal resonant frequencies of this lead/granite combo to see if it matches with our measurements.

For the huddle test, I have updated the code to divide the residual by sqrt(2) because of the assumption of equal noise from the 2 Guralps. We would have to multiply this trace by sqrt(2) to compare with the previous results.

Now the question is, how do I add a low noise ~50 mV offset to the front of the Guralp breakout box to test for the noise of the box?

While trying to set up the SIS-FFT to use our new ITM phase maps, I noticed that the surface of our ITMs looks pretty good actually (even compared to the aLIGO pathfinder optic map on the AIC wiki). I'm attaching it here for your viewing pleasure.

The code to plot it has been added to the SVN in the PhaseMaps/mat directory.

This is a reminder (mainly for Steve, who somehow doesn't believe these things) that op540m is not to be used for your general pleasure.

No web, no dataviewer, no DTT. Using these things often makes the graphical X-Windows crash. I have had to restart the StripTool, our seismic BLRMS and our Alarms many times because someone uses op540m, makes it crash, and then does not restart the processes.

Stop breaking op540m, Steve!

 That's hot stuff.

I was getting an excess noise in the C1:IOO-MC_DRUM1 channel - it was a flat spectrum of 10 cts/rHz (corresponding to 600 uV/rHz).

I tried a few things, but eventually had to power cycle the crate with c1iovme in order to recover the standard ADC noise level of 3x10^-3 cts/rHz with a 1/sqrt(f) knee at 10 Hz.

I checked the gain of the channel by injecting a 2 Vpp sine wave at 137.035 Hz. 2Vpp as measured on a scope gives 31919 cts instead of the expected 32768, giving a 2.5% error from what we would have naively calculated.

Even so, the noise in this channel is very surprisingly good: 0.003 / (31919 / 2) = 187 nV /rHz.  The best noise I have previously seen from an ICS-110B channel is 800 nV/rHz. What's going on here?

 I have always seen this when checking out the 40m medm SVN on a non-Linux box. I don't know what it is, but Yoichi and I investigated it at some point and couldn't reproduce it on CentOS. I think its some weirdness in the permissions of tmp files. It can probably be fixed by doing some clever checkin from the control room.

Even worse is that it looks like the whole 'SVN' mantra has been violated in the medm directory by the 'newCDS' team. It could be that Joe has decided to make the 40m a part of the official CDS SVN, which is OK, but will take some retraining on our part.

I've installed COMSOL 4.0 for 32/64 bit Linux in /cvs/cds/caltech/apps/linux64/COMSOL40/

It seems to work, sort of.

Notes:

1. It did NOT work according to the instructions. The CentOS automount had mounted /dev/scd0 on /media/COMSOL40. In this configuration, I was getting a permission denied error when trying to run the default setup script. I did a 'sudo umount /dev/scd0' to get rid of this bad mount and then remounted using 'sudo mount /dev/dvd /mnt'. After doing this, I ran the setup script '/mnt/setup' and got the GUI which started installing as usual.
2. I also pointed it at the linux64/matlab/ installation.
3. It seems to not work right on Rosalba because of my previous java episode. The x-forwarding from megatron also fails. It does work on allegra, however.

Those drawings are an OK start, but its obvious that things have changed at the 40m since 2002. We cannot rely on these drawings to determine all of the channel counts, etc.

I thought we had already been through all this...If not, we'll have to spend one afternoon going around and marking it all up. 

Not dead. It just had a HT fault. You can tell by reading the front panel. Cycling the power usually fixes this.

As per Steve's instructions, at 12:43 AM, I used the following steps to stop the pumpdown until the morning:

1. Close RV1 using the 'steering-wheel' wrench.
2. Close V3.
3. Turn OFF RP1.
4. Disconnect RP1 hose at the plastic disconnect attached to the slow-start throttle valve.

Kiwamu, Nancy, and I restored the power into the MC today:

1. Changed the 2" dia. mirror ahead of the MC REFL RFPD back to the old R=10% mirror.
2. Since the MC axis has changed, we had to redo the alignment of the optics in that area. Nearly all optics had to move by 1-2 cm.
3. 2 of the main mounts there had the wrong handedness (e.g. the U100-A-LH instead of RH). We rotated them to some level of reasonableness.
4. Tuned the penultimate waveplate on the PSL (ahead of the PBS) to maximize the transmission to the MC and to minimize the power in the PBS reject beam.
5. MC_REFL DC  =1.8 V.
6. Beams aligned on WFS.
7. MC mirrors alignment tweaked to maximize transmission. IN the morning we will check the whole A2L centering again. If its OK, fine. Otherwise, we'll restore the bias values and align the PSL beam to the MC via the persicope.
8. waveplates and PBS in the PSL were NOT removed.
9. MC TRANS camera and QPD have to be recentered after we are happy with the MC axis.
10. MC REFL camera has to be restored.
11. WFS measurements will commence after the SURF reports are submitted.

We found many dis-assembled Allen Key sets. Do not do this! Return tools to their proper places or else you are just wasting everyone's time!

 Just as I expected, since these hunuman didn't actually check MC_L after doing this stuff, MC_L was only recording ZERO. Joe and I reset and restarted c1susmve2 and then

verified (for real this time) that the channel was visible in both the Dataviewer real time display as well as in the trend.

The lesson here is that you NEVER trust that the problem has been fixed until you check for yourself. Also, we must always

specify a very precise test that must be used when we ask for help debugging some complicated software problem.

I re-aligned the beam into the PMC. I got basically no improvement. So I instead changed the .LOW setting so that PMCTRANS would no longer go yellow and make the donkey sound.

I did the same for the MOPA's AMPMON because its decayed state is now nominal.

Steve and I removed the thermal insulation from around the reference cavity vacuum chamber. It wasn't really any good anyways.

Here are the denuded photos:

Steve and I are now planning to replace the foam with some good foam, but before that we will wrap the RC chamber with copper sheets like you would wrap a filet mignon with applewood bacon.

This should reduce the thermal gradients across the can. We will then mount the sensors directly to the copper sheet using thermal epoxy. We will also use copper to cover most of this hugely

oversized window flange - we only need a ~1" hole to get the 0.3 mm beam out of there.

My hope is that all of this will improve the temperature stability of this cavity. Right now the daily frequency fluctuations of the NPRO (locked to the RC) are ~100 MHz. This implies

that the cavity dT = (100 MHz) / (299792458 / 1064e-9) / (5e-7) = 1 deg.    That's sad....

I also changed the RC_REFL cam to manual gain from AGC. I cranked it to max gain so that we can see the REFL image better.

After whatever Joe/Alberto did this afternoon, the MC was not locking. Koji and I removed several of the cables in the side of the rack where they

were apparently working (I say apparently because there's no elog).

MC is now locking but the autolocker did not work at first - op340m was unable to access any channels from c1iool0. After several minutes, it mysteriously

started working - the startup.cmd yields errors seen on the terminal. I attach the screen dump/.

Sometimes I like to plot the spectrum of MC_F. Its a good diagnosis of whether something is wrong.

The red trace is noisier than the blue reference. What is the cause of this?

As you can see, there was not much (if any) worsening of the laser frequency fluctuation from removing the RefCav insulation. The plots below are zooomed in:

I have used the same peak-to-peak scale so that its easy to compare the fluctuations before (LEFT) and after (RIGHT).

As you can clearly see, the laser frequency moves just as much now (the SLOW_DC) as it did before when it had the insulation. Only now the apparent (i.e. fake) RC temperature fluctuations are much larger. So this sensor is fairly useless as configured.

To make the beam on the MC trans camera bigger, I removed the lens + ND filter that was in that path.

The camera was getting the transmission through a BS1-33 (33% reflector). The reflection went to the TRANS QPD. I changed

the R=33% into an HR mirror (Y1-45P) so now the camera has a nice beam. The QPD was now saturating so I put a ND06 into that path

so now the TRANS_SUM is ~4.5-5 V when the MC is aligned.

The MC was also misaligned and failing to lock all weekend (why??) so I aligned the MC mirrors to get it to acquire again. Since we want to

collect MC seismic data, please make sure the MC is locked and running after finishing with your various MC or PSL work (this means YOU).

Since we now have a good measurement of the phase noise of the Rb clock Marconi locked to the Rb clock, I wanted to use that to check out the old DAQ system:

I used Megan's phase noise setup - Marconi #2 is putting out 11000013 Hz at 13 dBm into the ZP-3MH mixer. Marconi #1 is putting out 3 dBm at 11000000 Hz into the RF input.

The output goes through a 50 Ohm load and then a Mini-Circuits BNC LP filter (either 2 or 5 MHz). Then an SR560 set for low noise, G = 5, AC coupling, 1-pole LP @ 1 kHz.

This SR560 output goes into the channel C1:IOO-MC_DRUM1 (which is sampled at 16384 Hz with ICS-110B after the usual Sander Liu AA chassis containing the INA134s).

On Picasa

So...who was working around the PSL rack this morning and afternoon? Looks like there was some VCO phase noise work at the bottom of

the rack as well as some disconnecting of the Guralp cables from that rack. Who did which when and who needs to be punished?

 I just realized that an unfortunate casualty of this LSC work was the deletion of the slow controls for the LSC which we still use (some sort of AUX processor). For example, the modulation

depth slider for the MC is now in an unknown state.

I reconnected the RF signal to the FSS and to the FSS' EOM so that we could lock the refcav again.

I then started a 3 sec. period trianglewave on the AOM drive amplitude to see if there is a direct coupling from RIN to Frequency. Ideally we will be able to measure this by looking at the RCTRANS and the FSS-FAST.

 This is the 0.3 mHz BW spectrum of this test - as you can see the apparent linewidth (assuming the width is all caused by the DAQ jitter) is comparable to the BW and therefore not resolved.

Basically, the Hanning window function is not sharp enough to do this test and so I will do it offline in Matlab.

1) Gravity has to be included because the inverted pendulum effect changes the resonant frequencies. The deflection from gravity is tiny but the change in the dynamics is not. The results are not accurate without it. The z-direction probably is unaffected by gravity, but the tilt modes really feel it.

2) You should try a better meshing. Right now COMSOL is calculating a lot of strain/stress in the steel plates. For our purposes, we can imagine that the steel is infinitely stiff. There are options in COMSOL to change the meshing density in the different materials - as we can see from your previous plots, all the action is in the rubber.

3) I don't think the mesh density directly limits the upper measurement frequency. When you redo the swept-sine using the matlab scripting, use a logarithmic frequency grid like we usually do for the Bode plots. The measurement axis should go from 0.1 - 30 Hz and have ~100 points.

In any case, the whole thing looks promising: we've got real solid models and we're on the merge of being able to duplicate numerically the Dugolini-Vass-Weinstein measurements.

Someone had left a typo in the MC autolocker script recently while trying to set the lock threshold to 0.09. As a result, the autlocker wouldn't run.

I repaired it, made a few readability improvements, and checked in the new version to the SVN. If you make script changes, check them in. If you think its too minor of a change for a SVN checkin, don't do it at all.

I bet you thought that the NPRO slow actuator response could be well represented by a pole at ~0.1 Hz? Well, that's just what they want you to believe.

I attach the response measured in FSS-FAST (with no feedback to the SLOW actuator) when the SLOW is given a step. As you may remember from

kindergarten, the response of a single pole low pass should just be an exponential. Clearly, there's more here than 1 pole.

 I also inserted a factor of 0.01 in the FSSSlowServo code so I could make the gain sliders have reasonable values (they used to all be ~1e-3). The SVN and the MEDM snapshot are updated.

Alastair found that the foam hut that he and Jan put on top of the Rb clocks to temperature stabilize them was too good of an insulator. The Rb boxes had gotten very hot and became internally unlocked as seen on the front panel.

After we let them cool down with the box off, I turned them back on. After several minutes the 'Locked' light came back on. Some minutes after that the '1PPS Sync' light also came on, indicating that the two had become somewhat synchronized. It really means that the frequencies are kind of close: I think its roughly that f1-f2 < 2 mHz.

I put the yellow box back on and have left it with a small gap on the bottom so that the hot air can get out. Hopefully, this will protect the clocks from the wind, but not cause them to overheat.

The signal going to the DAQ right now is DC-coupled, with a gain of 1. The peak-peak beat signal in this situation is 6300 counts.

My guess is that the clocks will by synchronized by tomorrow afternoon so that we can get the measurement done. Please don't disturb the clocks or the yellow box around them. Try to minimize any activity around that area.

 I tried to get the clocks to be closer to 90 deg for the relative phase by adding some cable length to one of the lines, but they are still wandering too much. We need to use the serial interface and up the gain in their 1PPS locking loops.

The green xterm on op540m which is running the seisBLRMS DMF got stuck somehow ~3 days ago and lost its NDS connection. I closed the matlab session and restarted it. Seismic trends are now back online.

http://lhocds.ligo-wa.caltech.edu:8000/40m/PSL/LayoutUpgrade

P-pol = purple

S-pol = red

The .graffle file for this is in the 40m SVN's omnigraffle dir/

I used the free software called 'ABCD' for Mac to construct this mode matching solution for going from the PMC to the IMC.

After getting it close by eye, I plugged the initial guess into Matlab and let it optimize the distances. I then plugged this into 'ABCD'

to get the exact solution. ABCD doesn't actually optimize anything; it just makes a nice table and graphically plots the solution.

• The first waist between the first lens (f = +200 mm) and the second lens (f = -150 mm) is where the triple mod EOM goes. I have not accounted for the index (1.75) of the KTP.
• The third lens we need is a f = +400 mm lens. I have put the lenses in the new layout drawing at the positions indicated in the Omnigraffle drawing. Each grid square corresponds to 1 inch.

The part numbers for these lenses are:

PLCX-25.4-103.0-UV-1064

PLCC-25.4-77.3-UV-1064

PLCX-25.4-206.0-UV-1064

In a manner similar to the now classic 'Mode Matching from PMC to IMC' entry, I have calculated the lenses and positions needed to match the 2W NPRO beam into the PMC.

The added complication is that we also want to have a reasonable beam size to get into the Faraday and the AOM. It seems that this should be possible using one lens.

After the beam comes out of the AOM, there's another lens to match to the PMC. Its possible to do this with more lenses, but this is just an effort to minimize the number

of surfaces in the beam.

For the future SLOW controls our current plan is to keep using the VME based stuff and associated processors (Baja, Motorola, etc.). This is not

a sustainable plan since these are obsolete and eventually will die. One option is to use these boxes from Diamond Systems:

http://www.diamondsystems.com/products/octavio

In fact, many of the mounts need to be adapted to 4": the beefy steering mirrors going into the PMC, the PMC RFPD, the ISS AOM, the Faraday between the NPRO and the AOM, the NPRO itself, the ISS PDs.

Also for the FSS: the 21.5 MHz EOM, the PBS, the AOM, the refcav periscope, and the RFPD.

Its obvious, in retrospect, that we would have to do this, but it somehow didn't occur to me until actually trying to put things on the table...

The NPRO itself is already tapped with 3 (metric) M3 holes. It also has 4 (un-tapped) holes at its 4 corners which look like they are for feet. Anyone have a mount design for the Innolight NPRO already?

We also started labeling the table with the new coordinate system. In this system, the NE corner is the origin. The screw hole which is most NE is 1,1. The numbering increases in the south (+X) direction and goes negative in the west (-Y) direction.

We changed the name of the new control room computer from kallo to rossa (since its red).

I also tried to install the nVidia graphics driver, but failed. I downloaded the one for the GeForce 310

for x86_64 from the nVidia website, but it failed to work. I installed it, but then X windows wouldn't start.

I've left it running a basic VESA driver.

Kiwamu updated the host tables to reflect the name change. We found that both rossa and allegra were

set up to look at the old 131.* DNS computers and so they were not resolving correctly. We set them up for new way.

The lifting and resetting of the BLUE PSL enclosure has made it unstable somehow. When I push on it a little it rocks back and forth a lot.

Steve, please look into what's happening and stiffen it if you can. Its too unstable right now.

To test out this website - emachineshop.com, Jenne and I are designing some of the mounts for the new beam height.

It took me a few hours to figure out how to do it, but the software is easy enough for simple stuff. This is a brass mount with M4 clearance holes which are countersunk and a lip so that it can be dogged down to the table.

And I raised it back to 73F. The thermometers on the wall show 74-75F as the actual room temp. The dial on the temperature controller is not calibrated.

1. Steve is handling the mount height increase for the PMC and RC steering mirrors, as well as a mount (non-steerable) for the ISS' AOM.
2. Rana is working on the laser mount.
3. Jenne is drawing and getting the PMC mount made.
4. We got the lenses from CVI for the mode matching, but not the metric screws for the laser mounting. I am tempted to tap holes in the laser base.

The differences between this setup and the one used previously is the lack of the 50 Ohm terminator in the mixer output and

that the SR560 readout with the G=100 should come before the first SR560 via T, so as not to be spoiled by the high noise of the G=1 SR560.

With the setup now working, we should now test the power filtering for the crystal and amplifier.