The old plots looked horrible, and so here is a new plot

The slopes and other stats are

Pitch

Linear model Poly1:
     f(x) = p1*x + p2
Coefficients (with 95% confidence bounds):
       p1 =        8550  (7684, 9417)
       p2 =       -2148  (-2390, -1906)

Goodness of fit:
  SSE: 9944
  R-square: 0.9923
  Adjusted R-square: 0.9907
  RMSE: 44.59

Yaw

Linear model Poly1:
     f(x) = p1*x + p2
Coefficients (with 95% confidence bounds):
       p1 =       -8310  (-8958, -7662)
       p2 =        2084  (1916, 2252)

Goodness of fit:
  SSE: 6923
  R-square: 0.9954
  Adjusted R-square: 0.9945
  RMSE: 37.21

I and koji setup the measurement of the QPD response to the pitch and yaw displacements of the beam spot.

We did this using a 100mW 1064nm laser. Its power was attenuated to ~ 1.9mW, and the spot size at the QPD position was 6000-7000 um .

The QPD was put on a translation stage, using which, the center of teh QPD wrt the beam spot could be moved in pitch and yaw.

Following are the measurements :

For yaw

:

The slope of teh linear region is -8356 /inch

 For pitch

The slope of the linear region in this is 9085/inch

[Jenne, Chip]

The alarm was still going, because the LOLO setting was higher than the LOW, which is a little bit silly.  So we changed the .LOLO setting to 0.80 (the LOW was set to 0.82)

We also changed psl.db to reflect these values, so that they'll be in there the next time c1psl gets rebooted.

The feedback signal going to the laser PZT at the X end station was measured in the daytime and the nighttime.

It's been measured while the laser frequency was locked to the arm cavity with the green light.

The red curve was measured at 3pm of 8/July Friday. And the blue curve was measured at 12am of 9/July Saturday. 

As we can see on the plot, the peak-peak values are followers

              daytime:  ~ 4Vpp

       nighttime:  ~1.8Vpp

It is obvious that the arm cavity is louder in the daytime by a factor of about 2.

Note: the feedback signal is sent to the PZT only above 1Hz because the low frequency part is stabilized mostly by the crystal temperature (see this entry)

 An entry on the 40m wiki page might serve you better, and be easier to sift through once all is said and done

For the sake of future users, I have decided to periodically add tips and tricks in using COMSOL that I have figured out, most probably after hours of circuitous efforts. They will always be listed under the new COMSOL Tips category.

Today's topic: Intrusions

COMSOL has a very user-friendly interface for taking objects from 2D to 3D using the "extrusion" feature. But suppose one wants to design an object which contains screw holes or some other indentation. I've found that creating "punctures" in COMSOL is either impossible or very complicated.

Instead, COMSOL encourages users to always "add" to the object. In other words, one must form the lowest level first, then build layers sequentially on top using new work plane and boolean difference operators. This will probably be a bit clearer with an example:

1) First, create the planar projection in a work plane:

2) Extrude the first layer only in the regular fashion:

 3) Add a new work plane which is offset in the z-direction to the deepest point of the intrusion.

 4) Now, create the shape of the intrusion in this new work plane.

5) Use the Boolean "Difference" to let COMSOL know that, on this plane, the object has a hole.

 6) Extrude once more from the second work plane to complete the intrusion.

The AC filters will be checked and/or replaced today. This means the AC will be off for sort periods of time. Temperature and particle count will be effected some what.

See 800 days plot

I have resurrected the MC WFS on Friday night.
I have uncommented the WFS part of the MC autolocker.
The WFS total gain was empirically set to 0.1 such that the loops have no instability.

The loops somewhat worked through the weekend although they seemed to have the drift of the operating points
in accordance with the WFS spot.

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.

In order to increase the green power on the PSL table, I moved the position of the Second Harmonic Generation (SHG) crystal by ~5cm.

After this modification, the green power increased from 200 uW to 640 uW. This is sufficiently good.

     As I said in the past elog entry (# 3122), the power of the green beam generated at the PSL table should be about 650 uW.

I measured the green power by the Ophir power meter and found it was ~200 uW, which made me a little bit sad.

Then I performed the beam scan measurement to confirm if the crystal  was  located on the right place. And I found the postion was off from the optimum position by ~5cm.

So I slided the postion of the SHG oven to the right place and eventually the power got increased to 640 uW.

some notes: 

(power measurement)

        The outgoing beam from the SHG crystal is filtered by Y1-45S to eliminate 1064nm.

According to Mott's measurement Y1 mirrors are almost transparent for green beams (T~90%), but highly reflective for 1064nm (T~0.5%).

All the green power were measured after the Y1 mirror by the Ophir configured to 532nm, though, the measured power might be offseted by a leakage of 1064nm from the Y1 mirror.

I didn't take this effect into account.

(beam scanning and positioning of crystal)

          Here is the properties of the incident beam. These numbers are derived from the beam scan measurement.

w0h             = 52.6657      +/- 0.3445 um

w0v             = 52.4798      +/- 0.1289  um

z0h             = 0.574683         +/- 0.001937 m

z0v             = 0.574325         +/- 0.0007267 m

Where the suffixes "h" and "v" stand for "horizontal" and "vertical" respectively.

The distances are calibrated such that it starts from the lens postion.

Both waist size are already sufficiently good because the optimum conversion can be achieved when the waist size is about 50um ( see this entry)

The measured data and their fitting results are shown in attachement 1.

         According to my past calculation the center of the crystal should be apart from the beam waist by 6.8mm (see this entry). 

So at first I put the oven exactly on the waist postion, and then I slided it by 6.8mm.

(to be done)

        I need to find an optimum temperature for the crystal in order to maximize the green power.

Previously the optimum temperature for the crystal was 38.4 deg. But after moving the position I found the optimum temperature is shifted down to around 37deg.

Here are some more details about the current phasecam setup. We are using a He-Ne laser setup

A crude snap shot of the setup....

We sent light through SM2 (Steering Mirror 2)  to BS1(Beam-Splitter 1) where the laser light is split into two parts, one going to the AOM and the other to the EOM. The EOM adds 40 MHz sidebands to the incoming carrier light after SM3, and the AOM shifts the frequency of the incident light on it to 40.000 005 MHz. The purpose for doing this juggling is to intentionally create a beat signal off the reference beam from the AOM with the sidebands added at the EOM. Note that, we are driving the AOM at 7dBm and the EOM at 13 dBm with 0 (nil) modulation. The two lights are combined at the BS2 and sent off through SM5 to the camera. The CMOS of the camera contains silicon based Micro MT9V022 chip which has a quantum efficiency of 50% at 633 nm. Thus we expected a fairly good response to this He-Ne setup from the camera. 

Using a trigger circuit, we triggered the camera at 20 Hz by sending a 20Hz sinusoidal signal to it. The trigger circuit converts this to a positive square waves. Then I roughly figured out the optimum exposure time for the camera before the DC levels saturates it by writing a code for taking a series of 25 images at different exposure time. I found that 500µs seems to be a reasonable exposure time. So, using this data, I took 20 consecutive images and sent them through a short Fourier Transform segment using Matlab to see the beat signal. Note that the DC component from these processing of the images have some fringe pattern which is due to the ND 2.5 filter that we were using to reduce the light power incident on the camera. The FT method also gave us the presence of the beat signal at the corresponding bin of the FT (for example: for 5Hz beat signal, I got the DC at bin 1 of the FT and 5Hz component at bin 6 as expected). Then I changed the AOM driving frequency to 40.000 001 MHz in order to see a 1 Hz beat signal. The results for both is in my previous post. 

For the last week, I have been attempting to determine the mirror stack transfer function which relates mechanical mirror response to a given ground-motion drive. The idea is to model the stacks in COMSOL and ultimately apply mechanical tests for manual calculation.

Procuring the correct drawings to base my 3D models off of was no simple task. There are two binders full of a random assortment of drawings, and some of them are associated with the smaller chambers, while others are appropriate for the main chamber, which is what we're interested in right now. For future workers, I suggest checking that your drawings are appropriate for the task at hand with other people before wasting time beginning the painstaking process of CAD design in COMSOL.

The drawings that I ultimately decided to use are attached below. They detail four layers of stacks, each which arrange 15, 12, 8, and 5 (going from bottom to top) Viton damping springs in an orderly fashion. The numbers have been chosen to keep the load per spring as constant as possible, in order for all springs to oscillate with as close a resonant frequency to each other as possible.

After making some minor simplifications, I have finished modeling the top stack:

After triangular meshing, before my many failed attempts at mechanical testing:

Both the Viton and steel portions have been given their material properties, and so I should be (theoretically ) ready to perform some eigenfrequency calculations on this simplified system. If my predictions are correct, these eigenfrequencies shouldn’t be too far of the eigenfrequencies of the 4-layer stacked system, because of the layout of the springs. I’ve tried doing mechanical tests on the top stack alone, but there hasn’t been much progress yet on this end, mostly because of some boundary value exceptions that COMSOL keeps throwing at me.

In the next couple weeks or so, I plan to extend this model to combine all four layers into one completed stack, along with a simple steel base and mirror platform. I also plan to figure out how to make eigenfrequency and transfer function measurements.

Lastly, to anyone who is experienced with COMSOL, I am facing two major roadblocks and could really use your help:

1) How to import one model into another, merge models together, or copy and paste the same model over and over.

2) Understanding and debugging run-time errors during mechanical testing.

If you have any idea how to attack either of these issues, please talk to me! Thanks!

I turned off fb40m2 and fb40m temporarily while we added an extra power strip  to the (new) 1X6 rack at the bottom in the back.  This is to allow for the addition of the 4600 computer  given to us by Rolf (which needs a good name) into the rack above the fb machine.  The fb40m2 was unfortunately plugged into the main power connectors, so we unplugged two of its cables, and put them into the new strip. While trying to undo some of the rats nest of cables in the back I also powered down and unpluged briefly the c0dcu1, the pem crate, and the myrinet bypass box.

I am in the process of bringing those machines back up and restoring the network.

Also this morning, Megatron was moved from the end station into the (new) 1X3 rack, along with its router.  This is to allow for the installation of the new end computer and IO chassis.

I just found the singular values and the condition number of the 4*4 matrix relating the WFS error signals and the MC1 and MC2 movements.

the condition number is ~12.5. I think its small enough to continue with the scheme. (if the measurements and all are reliable).

I and Koji were trying to lock the mode cleaner for measuring the beam power at MC2 end. That is when we obtained the trans and refl values.

The beam characteristics at the MC2 were measured so that we could now use a dummy beam of similar power to test and characterize the QPD we are about to install at the MC2 end. This QPD wil provide two more signals in pitch and yaw, and hence complete 6 signals for 6 rotatioanl dof of the cavity. (4 are coming from WFS).

Once the QPD is characterised, it can be used to see the spot position at MC2. This is related to the mirror angles.

The width measurements were done using a beam scan. the beam scan was properly adjusted so that the maxima of the intensity of the sopt was at its center.

We also fitted gaussian curve to the beam profile, and it was a substantially good fit.

The whole idea is that I am trying  to look how the Wavefront sensors respond to the perturbations in the mirror angles. Once this is known, we should be able to control the mirror-movements.

the starting point would be to do just the DC measurements (which I did today). For proper analysis, AC measurements are obviously required.(will be done later).

The matrices so calculated can be inverted, and if found enough singular, the method can be used to control.

The first shot is to see teh dependency of teh error signals only on MC1 and MC3, and see if that is kind of enough to control these two mirrors.

If this works, the QPD signals could be used to control MC2 movements.

The WFS error signals were recorded in the order

WFS1_PIT

WFS1_YAW

WFS2_PIT

WFS2_YAW

these measurements are made in the linear region, that is the MC is nearly perfectly aligned.

This is  the average and std. dev.of 5 measurements taken of the same signals over 10 secs each. The std. dev are under 10%. And hence, I will be using 10 secs for measurements for the WFS signals after perturbations to the mirrors.

avg =

829.4408
-517.1884
297.4168
-944.7892


std_dev =

9.0506
22.9317
15.4580
8.9827

I perturbed the Pitch and Yaw of the Three mirrors (in order MC1,2,3), using ezcastep and calculated the coefficients that relate these perturbations to the WFS error signals.

The perturbation made is of -0.01 in each dof , and after measuring the WFS error for it, the system is reverted back to the previous point before making the other perturbation.

I was able to calculate the coefficients since I have assumed a linear relationship..

Following are the coefficients calculated using 10 secs measurements

coef_mat =

   1.0e+05 *

                            MC1_P   MC1_Y  MC2_P   MC2_Y    MC3_P   MC3_Y  constant
WFS1_PIT        -0.1262    0.3677   -0.4539   -0.6297   -0.1889   -0.1356   0.013664
WFS1_YAW     -0.0112   -0.7415   -0.1844    2.4509   -0.0023   -0.3531  -0.016199
WFS2_PIT         0.1251    0.4824   -0.2028   -0.6188    0.0099   -0.1490   0.006890
WFS2_YAW      0.0120   -0.7957   -0.1793    0.9962   -0.0493    0.2672 -0.013695

Also, I measured the same thing for 100s, and to my surprize, even the signs of coeficients are different.

coef_mat =

   1.0e+05 *

                           MC1_P   MC1_Y  MC2_P   MC2_Y    MC3_P   MC3_Y   constant
WFS1_PIT       -0.1981    0.3065   -0.6084   -0.9349   -0.4002   -0.3538   0.009796
WFS1_YAW     0.0607   -0.6977    0.0592    2.8753    0.3507    0.0373   -0.008194
WFS2_PIT        0.0690    0.4769   -0.2859   -0.7821   -0.1115   -0.2953  0.004150
WFS2_YAW     0.0580   -0.8153   -0.0937    1.1424    0.0650    0.4203  -0.010629

The reason I can understand is that the measurements were not made at the same time, and hence conditions might have changed.

A thing to note in all these coefficients is that they relate the error signals to the 'perturbation' around a certain point (given below). That point is assumed to lie in the linear region.

MC1_PIT      2.6129
MC1_YAW   -5.1781
MC2_PIT       3.6383
MC2_YAW    -1.2872
MC3_PIT      -1.9393
MC3_YAW    -7.518

Last night, we successfully connected and powered our circuit, which allowed us to test whether our OSEMs were working.  Previously, we had been unable to accomplish this because (1) we weren't driving it sufficiently high voltage, and  (2) we didn't check that the colored leads on our circuit actually corresponded to the colored ports on the power supply (they were all switched, which we are in the process of rectifying), so our circuit was improperly connected to the supply .  Unfortunately, we didn't learn this until after nearly cooking our circuit, but luckily there appears to have been no permanent damage .

Our circuit specs suggested powering it with a voltage difference of 48V, so we needed to run our circuit at a difference of at least 36-40 V.  Since our power supply only supplied a difference of up to 30V in each terminal, we combined them in order to produce a voltage of up to double that.  We decided to power our circuit with a voltage difference of 40V (+/- 20V referenced to true ground).  The current at the terminals were 0.06 and 0.13 A. 

To test our circuit, we used a multimeter to check the supplied voltage at different test points, to confirm that an appropriate input bias was given to various circuit elements.  We identified the direction of LED bias on our OSEM, and connected it to our circuit. We were extremely gratified when we looked through the IR viewer and saw that, in fact, the LED in the OSEM was glowing happily .

We hooked up two oscilloscopes and measured the current through the coil, and also through the LED and photodiode in the OSEM.  We observed a change in the photodiode signal when we blocked the LED light, which was expected.  The signal at the PD and the LED were both sinusoidal waves around ~3 kHz.

We then went back to our levitation setup, and crudely tried to levitate a magnet with attached flag by using our hands and adjusting the gain (though we also could have been watching the PD current).  The first flag we tried was a soldering tip; we couldn't levitate this but achieved an interesting sort of baby-step "levitation" (levitation .15) which allowed us to balance the conical flag on its tip on top of the OSEM (stable to small disturbances).  After learning that conical flags are a poor idea, we switched our flag to a smaller-radius cylindrical magnet.  We were much closer to levitating this magnet, but were unable to conclusively levitate it .

 
Current plan:

Adjust the preset resistors to stabilize feedback

Check LED drive circuit.

Finish calculating the transfer function, and hook up the circuit to the spectrum analyzer to measure it as well.

Observe the signal from the photocurrent as disturbances block the LED light.

Play with the gain of the feedback to see how it affects levitation.

 

Single layer of stack successfully modeled in COMSOL. I'm working on trying to add Viton springs now and extend it to a full stack. Having some difficulty with finding consistent parameters to work with.

 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.

We gave the Zonet camera the IP 192.168.113.26 and the name Zonet1.

We did this by modifying the /var/named/chroot/var/named/113.168.192.in-addr.arpa.zone and martian.zone files on linux1 as root.

After talking with Rolf, and clarifying exactly which machine I wanted, he gave me an 4600 Sun machine (similar to our current megatron).  I'm currently trying to find a good final place for it, but its at least here at the 40m. 

I also acquired 3 boards to plug our current VMIPMC 5565 RFM cards into, so they can be installed in the IO chassis.  These require +/- 5V power be connected to the top of the RFM board, which would be not possible in the 1U computers, so they have to go in the chassis.  These style boards prevent the top of the chassis from being put on (not that Rolf or Jay have given me tops for the chassis).  I'm planning on using the RFM cards from the East End FE, the LSC FE, and the ASC FE. 

I talked to Jay, and offered to upgrade the old megatron IO chassis myself if that would speed things up.  They have most of the parts, the only question being if Rolf has an extra timing board to put in it.  Todd is putting together a set of instructions on how to put the IO chassis together and he said he'd give me a copy tomorrow or Monday.  I'm currently planning on assembling it on Monday.  At that point I only need 1 more IO chassis from Rolf.

NEW CDS SETUP CHANGE:

When I asked about the dolphin IO chassis, he said we're not planning on using dolphin connections between the chassis and computer anymore.  Apparently there was some long distance telecon with the dolphin people and they said the Dolphin IO chassis connection and RFM doesn't  well together (or something like that - it wasn't very clear from Rolf's description).  Anyways, the other style apparently is now made in a fiber connected version (they weren't a year ago apparently), so he's ordered one.  When I asked why only 1 and what about the IOO computer and chassis, he said that would either require moving the computer/chassis closer or getting another fiber connection (not cheap).

So the current thought I hashed out with Rolf briefly was:

We use one of the thin 1U computers and place that in the 1Y2 rack, to become the IOO machine.  This lets us avoid needing a fiber.  Megatron becomes the LSC/OAF machine, either staying in 1Y3 or possibly moving to 1Y4 depending on the maximum length of dolphin connection because LSC and the SUS machine are still supposed to be connected via the Dolphin switch, to test that topology.

I'm currently working on an update to my CDS diagram with these changes and will attach it to this post later today.

This has been fixed, thanks to some help from Alex. It doesn't correspond to new computers being put in, but rather corresponds to a dcu_id change I had made in the new LSC model.

The fundamental problem is way back when I built the new LSC model using "lsc" as the name instead of something like "tst", I forgot to go to the current frame builder master file (/cvs/cds/caltech/chans/daq/master) and comment out the C1LSC.ini line. Initially there was no conflict with c1susvme, because the initially was dcu_id 13. The dcu_id was eventually changed to 10 from 13 , and thats when it conflicted with the c1susvme2 dcu_id which was also 10. I checked it against wiki edits to my dcu_id list page and I apparently updated the list on May 20th when it changed from 13 to 10, so the time frame fits.  Apparently it was previously conflicting with C0GDS.ini or C1EXC.ini, which both seem to have dcu_id = 13 set, although the C1EXC file is all commented out. The C0GDS.ini file seems to be LSC and ASC test points only.

The solution was to comment out the C1LSC.ini file line in the /cvs/cds/caltech/chans/daq/master file and restart the framebuilder with the fixed file.

Hmm. I expect that you will put more details of the work tomorrow.
i.e. motivation, method, result (the previous entry is only this),
and some discussiona with how to do next.

Nancy and Koji:

This is what I and Koji measured after aligning the MC in the afternoon.

MC_Trans 4.595 (avg)

MC_Refl 0.203 (avg)

MC2_trans :

power = 1.34mW

13.5% width : x=6747.8 +- 20.7 um  , y = 6699.4+- 20.7 um

Rana found out that a connection was bad in the shown place, due to which the MEDM screen was showing bad offset for length control.

Basically, the offset slider value would not go into the system because of that bad connection, and was locking the mode cleaner at the wrong location.

[Rana, Jenne]

We discovered to our great dismay that several important channels (namely C1:IOO-MC_L, but also everything on c1susvme2) are not being recorded, and haven't been since May 17th.  This corresponds to the same day that some other upgrade computers were installed.  Coincidence?

We've rebooted pretty much every FE computer and the FrameBuilder and DAQ_CONTROL approximately 18 times each (plus or minus some number).  No matter what we do, or what channels we comment out of the C1SUS2.ini file, we get a Status on the DAQ_Detail screen for c1susvme2 of 0x1000.  Except sometimes it is 0x2000.  Anyhow, it's bad, and we can't make it good again. 

I have emailed Joe about fixing this (with some assistance from Alberto, since we all know how much he likes doing the Nuclear Reboot option for the computers :)

[Jenne, Kyung Ha]

We made some good progress on suspending the Tip Tilt ECDs today.  We finished one whole set, plus another half.  The half is because one of the screw holes on the lower right ECD somehow got cross threaded.  The ECD and screws in question were separately wrapped in foil to mark them as iffy.  We'll redo that second half tomorrow.  This makes a total of 2.5 (including yesterday's work) ECD backplanes suspended.  The only thing left for these ones is to trim up the excess wire.

We also (with Koji) took a look at the jig used for suspending the mirror holder.  It looks like it was designed for so many Tip Tilt generations ago as to be basically useless for the 40m TTs.  The only really useful thing we'll get out of it is the distance between the suspension block and the mirror holder clamps.  Other than that we'll have to make do by holding the mirror and block at the correct distance apart, utilizing a ruler, calipers, or similar.  Rana pointed out that we should slightly bend the blade springs up a bit, so that when they are holding the load of the mirror holder, they sit flat. 

Attached below are 2 different pictures of one of the ECD backplane sets that has been suspended.  One with black background to illustrate the general structure, and one with foil background to emphasize the wires.

I also removed two of the AM stabilizers from the 1Y2 rack. The other one, which is currently running th MC modulations, is still in the rack, and there it is going to remain together with its distribution box.

I stored both AM stabilizers and the Stochmon box inside the RF cabinet down the East arm.

The 1 Ton yellow crane support beam jammed up at Friday morning, June 25.

The 40m vertex crane has a folding I-beam support to reach targeted areas. The rotating I-beam is 8 ft long. The folding extension arm gives you another 4 ft.

The 12 ft full reach can be achieved by a straightening of the 4 ft piece. There is a spring loaded latch on the top of the I-beam that locks down when the two I-beams align.

This lock joins the two beams into one rigid support beam for the jib trolley to travel.  The position of this latch is visible when standing below, albeit not very well.

To be safe it is essential that this latch is locked down fully before a load is put on the crane.

We were preparing to pump down the 40m vacuum system on Friday morning. The straight alignment of the 8 and 4 ft piece made us believe that

the support beams were locked. In reality, the latch was not locked down. The jib trolley was driven to the end of the 12 ft I-beam. The 200 lbs ITM-east door was lifted

when the 4 ft section folded 50 degrees around the pivot point. This load of door + jib-trolley + 4 ft I-beam made the support beam sag about 6 inches

The door was removed from the jib hoist with the blue Genie-lift. The sagging was reduced to ~3".

The Genie-lift platform was raised to support the sagging crane jib-trolley. The lab was closed off to ensure safety and experts were called in for consultation. It was decided to bring in professional riggers.

Halbert Brothers, Inc. rigging contractor came to the lab Tuesday morning to fix the crane. The job was to unload the I-beam with safety support below. They did a very good job.

The static deformation of I-beams sprung back to normal position. There are some deformation of the I-beam ~2 mm where the beams were jammed under load.

It is not clear if this is a new deformation or if the crane sections have always been mis-aligned by a couple of mm.

The crane was tested with 450 lbs load at 12 ft horizontal travel position. The folding of I-beams were repeatedly tested for safe operation. Its a 1 ton crane, but we tested it with 450 lbs because that's what we had on hand.

We're working on the safety upgrade of this lift to prevent similar accident from happening.

Pictures below:

Atm 1)   load testing 2007

Atm 2)   jammed-sagging under ~400 lbs, horizontal          

Atm.3)   jammed-folded 50 degrees, vertical     

Atm.4)   static deformation of I-beams

Atm.5)   unloading in progress with the help of two A-frames          

Atm.6)   it is unloaded

Atm.7-8) load testing        

Atm.9)   latch locked down for safe operation            

Atm.9)   zoom in of the crane sections misalignment    

Wednesday after the meeting - Started report, learnt mode cleaner locking from Kiwamu and Rana, saw how to move optics on the tables with Rana and kiwamu.

Thursday - Made the report

Tuesday - report.

Today - am trying locking the MC with kiwamu's help to see the WFS signals and also to start characterizing the QPD.

I have completed the following tasks:

1. Find a simplified calibration of the exposure time for the current He-Ne setup. Basically, I triggered the camera to take 20 snapshots with a 20 Hz driving signal at different exposure time beginning from 100 us (microsecond) upto 4000 us with an increment of 200 us.

    Result: The current power allows the camera to have an exposure time of ~500 us before the DC level begans to saturate.

2. Aidan and I did some alignment and connected the AOM and corrected the driving frequency of its PZT to 40 Mhz(which apparently was disconnected which in turn gets the credit of NO beat signal for me until Tuesday 07/06/2010 5:30 PST) .

    Result: I got the beat signal of 1 Hz and 5 Hz. Image follows (the colormap shows the power in arbitrary units).

3. Finished writing my Progress Report 1 .

Summary of this Week's Activities:

6/30: 2nd and 3rd drafts of Progress Report

7/1: 4th draft and final drafts of Progress Report; submitted to SFP

7/5: Began working through busbar COMSOL example

7/6: LIGO meeting and lecture; meeting with Koji and Steve to find drawing of stacks; read through Giaime's thesis, Chapter 2 as well as two other relevant papers.

7/7: Continued working on busbar in COMSOL; should finish this as well as get good headway on stack design by the end of the day.

Weekly Update:

Last Weds-Thurs, we wrote and edited our progress reports.

Tuesday (and Weds morning):  Continued circuit analysis of Haixing's circuit and plotting transfer functions (almost have one for entire circuit).  Hooked up OSEM and circuit to power supply, but the LED didn't appear to light up in IR.  Now we are going to hook the OSEM directly to the power supply, sans circuit, to see if the problem is with the circuit or OSEM.

How do you calibrate this to Hz/rtHz?

I measured the RC transmitted light signals here at the 40m. I made all connections through the PSL patch panel.

Other than two steering mirrors in front of the periscope, and the steering mirror for the RFPD which were used to steer

the beam into the cavity and the RFPD respectively, no optics are adjusted.

We re-aligned the beam into the cavity (the DC level increased from 2 V to 3.83V) (Fig2) (We could not recover the power back to what it was 90 days ago)

and the reflected beam to the center of the RFPD.

I measured the spectral density of the signal of the transmitted beam behind RefCav in both time and frequency domain.

This will be compared with the result from PSL lab later, so I can see how stable the signal should be.

I did not convert Vrms/rtHz to Hz/rtHz because I only look at the relative intensity of the transmitted beam which will be compared to the setup at PSL lab. 

 We care about this power fluctuation because we plan to measure

 photo refractive noise on the cavity's mirros

(this is the noise caused by dn/dT in the coatings and the substrate,

the absorption from fluctuating power on the coating/mirror changes

the temperature which eventually changes the effective length of the cavity as seen by the laser.)

      The plan is to modulate the power of the beam going into the cavity,

the absorption from ac part will induce frequency noise which we want to see.

Since the transmitted power of the cavity is proportional to the power inside the cavity.

 Fluctuations  from other factors, for example, gain setting,  will limit our measurement. 

That's why we are concerned about the stability of the transmitted beam and made this measurement.

[Jenne, Kyung Ha]

We successfully suspended the 4 eddy current dampers for the first Tip Tilt.  We had some lessons learned, including how to carefully get an allen wrench in between the dampers to do up some of the screws, and how to be careful not to bend the wire while tightening the screws.  More tomorrow...

I talked to Alex, and he explained the steps necessary to get the real time linux kernel installed.  It basically went like copy the files from c1iscex (the one he installed last month) in the directory /opt/rtlidk-2.2 to the c1sus locally.  Then go into rtlinux_kernel_2_6, and run make and make install (or something like that - need to look at the make file).  Then edit the grub loader file to look like the one on c1iscex (located at /boot/grub/menu.lst).

This will then hopefully let us try out the RCG code on c1sus and see if it works.

We rebooted c1iovme because the lines stopped responding to inputs on C1:I00-MC_DRUM1. This fixed the problem.

I went to talk to Rolf and Jay this morning.  I asked Rolf if a chassis was available, so he went over and disconnected one of his test stand chassis and gave it to me.  It comes with a Contect DIO-1616L-PE Isolated Digital IO board and an OSS-MAX-EXP-ELB-C, which is a host interface board.  The OSS board means it has to go into the south end station.  There's a very short maximum cable length associated with that style, and the LSC and IOO chassis will be further than that from their computers (we have dolphin connectors on optical fiber for those connections).

I also asked Jay for another 4 port 37 d-sub ADC blue and gold adapter box, and he gave me the pieces.  While over there, I took 2 flat back panels and punched them with approriate holes for the scsi connectors that I need to put in them.  I still need to drill 4 holes in two chassis to mount the boards, and then a bit of screwing.  Shouldn't take more than an hour to put them both together.  At that point, we should have all the adapter boxes necessary for the base design.  We still need some stuff for the green locking, as noted on Friday.

Major hardware still needed:

2 Dolphin style IO chassis

1 computer for south end front end

I connected a monitor and keyboard to the new c1sus machine and discovered its not running RTL linux.  I changed the root password to the usual, however, without help from Alex I don't know where to get the right version or how to install it, since it doesn't seem to have an obvious CD rom drive or the like.  Hopefully Tuesday I can get Alex to come over and help with the setup of it, and the other 1-2 IO chassis.

Kiwamu and I went through and looked at the spare channels available near the PSL table and at the ends.

First, I noticed I need another 4 DB37 ADC adapter box, since there's 3 Pentek ADCs there, which I don't think Jay realized.

PSL Green Locking

Anyways, in the IOO chassis that will put in, for the ADC we have a spare 8 channels which comes in the DB37 format.  So one option, is build a 8 BNC converter, that plugs into that box.

The other option, is build 4-pin Lemo connectors and go in through the Sander box which currently goes to the 110B ADC, which has some spare channels.

For DAC at the PSL, the IOO chassis will have 8 spare channel DAC channels since there's only 1 Pentek DAC.  This would be in a IDC40 cable format, since thats what the blue DAC adapter box takes.  A 8 channel DAC box to 40 pin IDC would need to be built.

End Green Locking

The ends have 8 spare DAC channels, again 40 pin IDC cable.   A box similar to the 8 channel DAC box for the PSL would need to be built.

The ends also have spare 4-pin Lemo capacity.  It looked like there were 10 channels or so still unused.  So lemo connections would need to be made.  There doesn't appear to be any spare 37 DB connectors on the adapter box available, so lemo via the Sander box is the only way.

Notes

Joe needs to provide Kiwamu with cabling pin outs.

If Kiwamu makes a couple spares of the 8 BNC to 37DB connector boards, there's a spare 37DB ADC input in the SUS machine we could use up, providing 8 more channels for test use.

Thanks to Steve's work on some L brackets, and Kiwamu's lifting help, we now have a new SUS IO chassis in the new 1X4 rack (formerly the 1Y4 rack), just below the new SUS and LSC computers.  I have decided to call the sus machine, c1sus, and give it IP address 192.168.113.85.  We also put in a host interface adapter, OSS-HIB2-PE1x4-1x4 Re-driver HIB, which connects the computer to the IO chassis.

The IP was added to the linux1 name server.  However, the computer itself has not been configured yet.  I'm hoping to come in for an hour or two tomorrow and get the computer hooked up to a monitor and keyboard and get its network connection working, mount /cvs/cds and get some basic RCG code running.

We also ran ethernet cables for the SUS machine to the router in 1X6 (formerly 1Y6) as well as a cable for megatron from 1X3 (formerly 1Y3) to the router, in anticipation of that move next week.

During the day, I realized we needed 2 more ADCs, one of which I got from Jay immediately.  This is for two 110Bs and 4 Pentek ADCs.  However, there's a 3rd 110B connected to c0dcu1 which goes to a BNC patch panel.  Original Jay thought we would merge that into 4 pin lemo style into the 2nd 110B associated with the sus front ends.  We've decided to get a another ADC and adapter.  That will have to be ordered, and generally take 6-8 weeks.  However, it may be possible to "borrow" one from another project until that comes in to "replace" it.  This will leave us with our BNC patch panel and not force me to convert over 20 cables.

I also discovered we need one Contec DIO-1616L-PE Isolated Digital IO board for each Chassis, which I wasn't completely aware of.  This is used to control the ADCs/DACs adapter boards in the chassis.  It means we need still need to put a Binary Output board in the c1iscex chassis.  Hopefully the chassis as they come in come from Downs continue to come with the Contec DIO-1616L-PE boards (they have so far).

The current loadout of the SUS chassis is as follows:

Treton Board

Far left slot, when looking from the front has the OSS-MAX-EXP-ELB-C board, used to communicate with the c1sus computer.

Slot 1 ADC PMC66-16AI6455A-64-50M

Slot 2 DAC PMC66-16AO16-16-F0-OF 

Slot 3-6 BO Contec DIO-32L-PE Isolated Digital Output board

Slot 7 ADC PMC66-16AI6455A-64-50M

Slot 8-9 DAC PMC66-16AO16-16-F0-OF 

Slot 10-11 ADC PMC66-16AI6455A-64-50M

Slot 12 Contect DIO-1616L-PE Isolated Digital IO board

Back  Board

Slot 1 ADC adapter D0902006

Slot 2 DAC adapter D0902496-v1

Slot 7 ADC adapter D0902006

Slot 8-9 DAC adapter D0902496-v1

Slot 10-11 ADC adapter D0902006

Kevin sent me an email with top secret info on where one of the other accelerometer cubes was hiding (it was with his shaker setup on the south side of the SP table), so I took it and put the 3 MC1 accelerometers in their 3-axis configuration. 

Also, I changed the orientation of both sets of 3 axis accelerometers to reflect a Right Handed configuration, to go along with the new and improved IFO configuration.  Previously (including last night), the MC2 accelerometers were together in a Left Handed configuration.

In order to identify the output adapter of the BNC patch panel used for about 20 PEM channels, I had to disconnect its power and remove the back panel.  Channels coming into that panel (seismometers and so forth) was out from 1:36 to 1:56 pm.

I did a quick check of some of the channels and it looks like its working again after putting it all back together.

Slow pump down _pd68 has reached the vacuum normal state.  CC4_Rga region is pumped now. The RGA is still off.

Precondition to this pump down:                                                                                                                                                                                                                                                           129 days at atm,                                                                                                                                                                                                                                                                                         ITMs replaced. MMT, oplev and other components were removed from BSC, ITMCs. New MMT mirrors are in.                                                                                                             IOO_access_connector was out. The end chambers were not opened.

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!

40m SURFs Razib Obaid, Nancy Aggarwal, Unknown Bearded SMURF, Megan Daily, Gopal Nataraj, Katharine Larson and Sharmila Dhevi received 40m specific safety training on June 23, 2010.

Now that the MC is back up and running, I put the Guralp seismometers at the ends of the mode cleaner.  Gur1 is near MC2, and Gur2 is near MC1 (yes, it seems backwards....that's how the cable lengths work).  Also, the set of 3 MC2 accelerometers are in place under MC2.  I can't find the black cube for the other set of accelerometers, so there aren't any around MC1/3.