40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 235 of 341 Not logged in
ID Date Author Type Category Subject
12390   Wed Aug 10 03:08:03 2016 gautam UpdateSUSETMY patch-up

[lydia, gautam]

Rana felt it was alright to use the wire clamp and suspension cage in its existing condition for checking the ETMY magnet-OSEM coil alignment. So we set about trying to re-suspend ETMY. The summary of our attempts:

• Transferred optic from magnet gluing rig to the suspension cage
• Adjusted bottom EQ stops till the scribe lines on both sides were at 5.5" as verified with the microscope
• Looped cleaned length of wire around optic, attached free ends to winches, placed the wires under light tension by finger-pulling the slack out
• Lowered the bottom EQ stops
• Winched the optic to the right height
• Clamped the wire with the only wire clamp on this variant of the suspension cage. We used the same torque wrench at the same torque setting as was successful for ETMX. But after removing the winches, and releasing the face EQ stops, the optic seems to have sagged a lot - it now touches all the bottom EQ stops, and the more I lower it, the more it seems to come down. Perhaps it is the effect of the wire grooves in the cage, or that the wire-clamp itself is slightly different from the piece used on the ETMX cage, but 1.3Nm of torque doesn't seem to have tightened the wire clamp sufficiently
• We can still probably salvage the situation by re-attaching the winches to the top of the cage, setting the optic to the right height again, and clamping the wire clamp with more torque (as this is just a check to see that the reglued magnet configuration is compatible with the OSEM coil positions on the cage). Before air baking the cage, we will have the old wire grooves removed, and then suspend the optic with a fresh loop of wire after the bake
• We could not check the magnet-OSEM alignment because of the slipping of the wire through the clamp. We decided against pushing on tonight
• Optic is currently in the cage, resting on the bottom EQ stops and with all face EQ stops within 1mm of the optic. The OSEM coils have not been inserted into the holders

Regarding the vacuum bake of the optics: why do we want to do this again? Koji mentioned that the EP30-2 curing process does not require a bake, and there is also no mention of requiring a vacuum bake in the EP30-2 gluing guide. Is there any other reason for us to vacuum bake the optic?

12397   Wed Aug 10 23:45:03 2016 gautam UpdateSUSETMY re-suspended

Summary:

• ETMY has been re-suspended
• Reglued magnets (and also those that weren't knocked off) quite well with OSEM coils (see attachments)
• Pitch balance is off by ~2.8mrad (8mm over 1.5m lever arm) after inserting and centering OSEMs
• The same damping scheme used during the ETMX re-suspension process works reasonably well with ETMY as well

Details:

• I suspected that I had not tightened the wire clamp enough yesterday, and that the wire had slipped once the winches were removed
• Steve and I looked into the torque wrench situation today, and I realised that I had not been using the torque wrench correctly. What I thought were clicks indicating that the set torque has been reached was in fact just the sound the piece makes when going the opposite way relative to the direction set by the clip on the torque wrench. Anyways, the point is that while I thought I was tightening the screws with ~1.3Nm of torque, what was actually being applied was much less (although I don't have a good way to quantify how much less)
• So today I put the winches back on top of the tower, and winched the optic back up to the correct height using the ususal scribe line + microscope prescription
• I then tightened the wire clamp by hand. This is obviously not very repeatable, but it will have to do until we get a torque wrench with the correct range
• This seems to have done the trick - I did the tightening shortly after lunch, and after ~10 hours, there is no evidence of any wire sag
• I then proceeded to insert the OSEMs, first not all the way in to check the clearance available to the magnet, and once I was satisfied there was no danger of knocking anything off, went ahead and inserted the coils till the PD readouts were approximately half of the maximum (i.e. fully un-occluded) values. I used the OSEM coils originally on the ETMY tower, but all the other readout and drive electronics in the signal chain (satellite box included) belong to the ETMX setup (so as to avoid any cable routing over 80m from the Y end to the cleanroom). After some adjustment of the OSEM holding plates, I was able to center the magnets relative to the coils
• The tower only allows for a side OSEM to be inserted on one side. The other side does not have a threaded hole for a set screw. So we are forced to use the reglued magnet and not the side magnet that was not knocked off. By eye, it looks like the magnet may never completely occlude the LED, but the Striptool trace I was using to monitor the output of the PD did not yield any conclusive evidence. The optic was moving around a lot and I did not perform this check after turning the damping on
• I was able to damp the optic as well as we were able to damp ETMX on the clean bench (with the HEPA turned OFF). I had to turn the YAW gain down from 100-->75 to avoid some oscillations
• I then proceeded to check the pitch balance with the HeNe. The spot is low on an iris 1.43m away by ~8mm, which corresponds to a pitch misalignment of ~2.8mrad. I am not sure what to make of this - but perhaps its not unreasonable that we see this? Is there any record of what fine pitch balancing was achieved when the optic was put together back in 2010? This is also very sensitive to how far in/out the OSEM coils are, and though I've tried to center the coils as best as I can, I obviously have not done a perfect job...

What's next?

• Is the observed pitch imbalance a deal breaker? If so, I guess we need to re-glue a standoff?
• Are we willing to accept the side OSEM situation? (Tomorrow, I need to do a check to see what, if any, dynamic range we lose, with the damping on)
• If both the above are not problems we need to worry about, then:
• ETMY + ETMX -------> Vacuum bake on 22nd August (? - Bob also told me earlier today that he will try and put in some old turbo pump next week, and if that works, we could possibly get in the queue even before the 22nd)
• ETMY tower -------> Steve for sanding and removing wire grooves -------> Air bake
• ETMX tower -------> Air bake (provided the latest round of wire tightening has not left any grooves in the top piece of the tower, if it has, this needs to be cleaned up too)
• Some lengths of SOS wire (for re-suspending optics after bake) -------> Air bake

Attachments:

Attachment #1: Striptool trace showing all OSEM coils have been pushed in till the PD readout is approximately half the fully open value

Attachment #2: Pitch balance is off by ~2.8mrad (the Iris center is 5.5" above the table)

Attachment #3: UR magnet

Attachment #4: UL magnet

Attachment #5: LR magnet

Attachment #6: LR magnet

Attachment #7: SD magnet

Attachment 1: ETMY_OSEMStrip.PDF
Attachment 2: IMG_2998.JPG
Attachment 3: IMG_3000.JPG
Attachment 4: IMG_3001.JPG
Attachment 5: IMG_3002.JPG
Attachment 6: IMG_3003.JPG
Attachment 7: IMG_3004.JPG
12758   Wed Jan 25 19:39:07 2017 gautam UpdateIMC29.5 MHz modulation depth measurement plan

Just collecting some links from my elog searching today here for easy reference later.

• EOM datasheet: Newfocus 4064 (according to this, the input Impedance is 10pF, and can handle up to 10W max input RF power).
• An elog thread with some past measurement details: elog 5339. According to this, the modulation depth at 29.5 MHz is 4mrad. The EOM's manual says 13mrad/V @1000nm, so we expect an input signal at 29.5MHz of 0.3V(pk?). But presumably there is some dependance of this coefficient on the actual modulation frequency, which I could not find in the manual. Also, Kiwamu's note (see next bullet) says that the EOM was measured to have a modulation depth of 8 mrad/V
• A 2015 update from Kiwamu on the triple resonant circuit: elog 11109. In this elog, there is also a link to quite a detailed note that Kiwamu wrote, based on his analysis of how to make this circuit better. I will go through this, perhaps we want to pursue installing a better triple resonant circuit...

I couldn't find any details of the actual measurement technique, though perhaps I just didn't look for the right keywords. But Koji's suggestion of measuring powers with the bi-directional coupler before the triple resonant circuit (but after the power combiner) should be straightforward.

14750   Thu Jul 11 13:09:22 2019 gautam SummaryCDSP2 interface board

it will connect to a 15 pin breakout board in the Acromag chassis

 Quote: It's nice and compact, and the cost of new 15-pin DSUB cables shouldn't be a factor here.  What does the 15p cable connect to?
11599   Tue Sep 15 15:10:48 2015 gautam, ericq, ranaSummaryLSCPRFPMI lock & various to-do's
I was observing Eric while he was attempting to lock the PRFPMI last night. The handoff from ALS to LSC was not very smooth, and Rana suggested looking at some control signals while parked close to the PRFPMI resonance to get an idea of what frequency bands the noise dominated in. The attached power spectrum was taken while CARM and DARM were under ALS control, and the PRMI was locked using REFL_165. The arm power was fluctuating between 15 and 50. Most of the power seems to be in the 1-5Hz band and the 10-30Hz band.

Rana made a number of suggestions, which I'm listing here. Some of these may directly help the above situation, while the others are with regards to the general state of affairs.

• Reroute both (MC and arm) FF signals to the SUS model
• For MC, bypass LSC
• Rethink the MC FF -
• Leave the arm FF on all the time?
• The positioning of the accelerometer used for MC FF has to be bettered - it should be directly below the tank
• The IOO model is over-clocking - needs to be re-examined
• Fix up the DC F2P - Rana mentioned an old (~10 yr) script called F2P ratio, we should look to integrate the Python scripts used for lock-in/demod at the sites with this
• Look to calibrate MC_F
• Implement a high BW CARM servo using ALS
• Gray code implementation for EPICS gain-stepping

Attachment 1: powerSpec0915.pdf
11579   Fri Sep 4 20:42:14 2015 gautam, ranaUpdateCDSCheckout of the Wenzel dividers

Some years ago I bought some dividers from Wenzel. For each arm, we have x256 and a x64 divider. Wired in series, that means we can divide each IR beat by 2^14.

The highest frequency we can read in our digital system is ~8100 Hz. This corresponds to an RF frequency of ~132 MHz which as much as the BBPD could go, but less than the fiber PDs.

Today we checked them out:

1. They run on +15V power.
2. For low RF frequencies (< 40 MHz) the signal level can be as low as -25 dBm.
3. For frequencies up to 130 MHz, the signal should be > 0 dBm.
4. In all cases, we get a square wave going from 0 ~ 2.5 V, so the limiter inside keeps the output amplitude roughly fixed at a high level.
5. When the RF amplitude goes below the minimum, the output gets shaky and eventually drops to 0 V.

Since this seems promising, we're going to make a box on Monday to package both of these. There will one SMA input and output per channel.

Each channel will have a an amplifier since this need not be a low noise channel. The ZKL-1R5 seems like a good choice to me. G=40 dB and +15 dBm output.

Then Gautam will make a frequency counter module in the RCG which can do counting with square waves and not care about the wiggles in the waveform.

I think this ought to do the trick for our Coarse frequency discriminator. Then our Delay Box ought to be able to have a few MHz range and do all of the Fast ALS Carm that we need.

Attachment 1: TEK00000.PNG
Attachment 2: TEK00001.PNG
Attachment 3: TEK00002.PNG
11940   Wed Jan 20 23:26:10 2016 gautam, ranaUpdateLSCPSL and AUX-X temperatures changed

Earlier today, we did a bunch of stuff to see if we could improve the situation with the excess ALS-X noise. Long story short, here are the parameters that were changed, and their initial and final values:

X-end laser diode temperature:     28.5 degrees ---> 31.3 degrees

X-end laser diode current:             1.900 A ---> 1.942 A

X-end laser crystal temperature:   47.43 degrees ---> 42.6 degrees

PSL crystal temperature:              33.43 degrees ---> 29.41 degrees

PSL Diode A temperature:           21.52 degrees ---> 20.75 degrees

PSL Diode B temperature:           22.04 degrees ---> 21.3 degrees

The Y-end laser temperature has not yet been adjusted - this will have to be done to find the Y-beatnote.

Unfortunately, this does not seem to have fixed the problem - I was able to find the beatnote, with amplitude on the network analyzer in the control room consistent with what we've been seeing over the last few days, but as is clear from Attachment 1, the problem persists...

Details:

• PSL shutter was closed and FSS servo input was turned off.
• As I had mentioned in this elog, the beat can now only be found at 47.41 degress +/- 1 deg, which is a shift of almost 5 degrees from the value set sometime last year, ~42.6 degrees. Rana thought it's not a good idea to keep operating the laser at such a high crystal temperature, so we decided to lower the X-end laser temperature back to 42.6 degrees, and then adjust the PSL temperature appropriately such that we found a beat. The diode temperature was also tweaked (this requires using a small screwdriver to twist the little knob inset to the front panel of the laser controller) - for the end laser, we did not have a dedicated power monitor to optimize the diode temperature by maximizing the current, and so we were just doing this by looking at the beat note amplitude on the network analyzer (which wasn't changing by much). So after playing around a little, Rana decided to leave it at 31.3 degrees.
• We then went to the PSL table and swept through the temperature till a beat was found. The PMC wouldn't stay locked throughout the sweep, so we first did a coarse scan, and saw weak (due to the PMC being locked to some weird mode) beatnotes at some temperatures. We then went back to 29.41 degrees, and ran the PMC autolocker script to lock the PMC - a nice large beatnote was found.
• Finally, Rana tweaked the temperatures of the two diodes on the PSL laser controller - here, the optimization was done more systematically, by looking at the PMC transmitted power on the oscilloscope (and also the MEDM screen) as a function of the diode temperature.
• I took a quick look at the ALS out of loop noise - and unfortunately, our efforts today does not seem to have noticeably improved anything (although the bump at ~1kHz is no longer there).

Some details not directly related to this work:​

• There are long cables (routed via cable tray) suitable for RF signals that are running from the vertex to either end-table - these are labelled. We slightly re-routed the one running to the X-end, sending it to the IOO rack via the overhead cable tray so that we could send the beat signal from the frequency counter module to the X-end, where we could look at it using an analyzer while also twiddling laser parameters.
• A webcam (that also claims to have two-way audio!) has been (re?)installed on the PSL table. The ethernet connection to the webcam currently goes to the network switch on the IOO rack (though it is unlabelled at the moment)
• The X-end area is due for a clean-up, I will try and do some of this tomorrow.
Attachment 1: 2016_01_20_ALS_OutOfLoop_1.pdf
2246   Thu Nov 12 01:18:34 2009 haixingUpdateSUSopen-loop transfer function of mag levi system (comparison between simulink and measurement)

I built a Simulink model of the magnetic levitation system and try to explain the dip in the open-loop transfer function that was observed.

One can download the model in the svn. The corresponding block diagram is shown by the figure below.

Here "Magnet" is equal to inverse of the magnet mass. Integrator "1/s" gives the velocity of the magnet. A further integrator gives the displacement of the magnet.

Different from the free-mass response, the response of the magnet is modified due to the existence of the Eddy-current damping  and negative spring in the vertical

direction, as indicated by the feedback loops after two integrals respectively. The motion of the magnet will change the magnetic field strength which in turn will pick

up by the Hall-effect sensor. Unlike the usual case, here the Hall sensor also picks up the magnetic field created by the coil as indicated by the loop below the mechanical

part. This is actually the origin of the dip in the open-loop transfer function. In the figure below, we show the open-loop transfer function and its phase contributed by both

the mechanical motion of the magnet and the Hall sensor with the black curve "Total". The contribution from the mechanical motion alone is shown by the magenta curve

"Mech" which is obtained by disconnecting the Hall sensor loop (I rescale the total gain to fit the measurement data due to uncertainties in those gains indicated in the figure).

The contribution from the Hall sensor alone is indicated by the blue curve "Hall" which  is obtained by disconnecting the mechanical motion loop. Those two contributions

have the different sign as shown by the phase plot, and they destructively interfere with each other and create the dip in the open-loop transfer function.

In the following figure, we show the close-loop response function of the mechanical motion of the magnet.

As we can see, even though the entire close loop of the circuit is stable, the mechanical motion is unstable around 10 Hz. This simply comes from the fact that

around this frequency, the Hall sensor almost has no response to the mechanical motion due to destructive interference as mentioned.

In the future, we will replace the Hall sensor with an optical one to get rid of this undesired destructive interference.

2274   Mon Nov 16 15:18:10 2009 haixingUpdateSUSStable magnetic levitation without eddy-current damping

By including a differentiator from 10 Hz to 50 Hz, we increase the phase margin and the resulting

magnetic levitation system is stable even without the help of eddy-current damping.

The new block diagram for the system is the following:

Here the eddy-current damping component is removed and we add an additional differential

circuit with an operational amplifier OP27G.

In addition, we place the Hall sensor below the magnet to minimize the coupling between

the coil and the Hall sensor.

The resulting levitation system is shown by the figure below:

4086   Wed Dec 22 11:24:23 2010 haixingUpdateSUSmeasurement of imbalance in quadrant maglev protope

Yesterday, a sequence of force and gain measurement was made to determine the imbalance in the

quadrant, magnetic-levitation prototype. This was the reason why it failed to achieve a stable levitation.

The configuration is shown schematically by the figure below:

Specifically, the following measurements have been made:

(1) DC force measurement among four pairs of magnets at fixed distance with current of the coils on and off

From this measurement,  the DC force between pair of magnets is determined and is around 1.6 N at with a

separation of 1 cm. This measurement also lets us know the gain from voltage to force near the working point.

The force between pair "2" is about 13% stronger than other pairs which are nearly identical. The force by the

coil is around 0.017 N per Volt (levitation of 5 g per 3 Volt); therefore, we need around 12 volt DC compensation

of pair "2" in order to counterbalance such an imbalance.  Given the resistence of the coil equal to 26 Om, this

requires almost 500 mA DC compensation. Koji suggested that we need a high-current buffer, instead of what

has been used now.

(2) DC force measurement among four pairs of magnets (with current of the coils off) as a function of distance

From this measurement, we can determine the stiffness of the system. In this case, the stiffness or the

effective spring constant is negative, and we need to compensate it by using a feedback control. This is

one of the most important parameters for designing the feedback control. The data is still in processing.

(3) Gain measurement of the OSEM from the displacement to voltage.

This measurement is a little bit tricky due to the difficulty to determine the displacement of the flag.

After several measurements, it gave approximately 2 V/cm.

Plan for the next few days:

From the those measurements, all the parameters for the plant and sensor that need to determine the

feedback control are known. They should be plugged into the simulink model and to see whether the

old design is appropriate or not. Concerning the experimental part, we will first try to levitate the configuration

with 2 pairs of magnets, instead of 4 pairs, as the first step, which is easier to control but still interesting.

4906   Wed Jun 29 01:23:21 2011 haixingUpdateSUSissues in the current quad maglev system

Here I show several issues that we have encountered in the quad magnetic levitation system. It would be great if you can give
some suggestions and comments (Poor haixing is crying for help)

The current setup is shown by the figure below (I took the photo this morning):

Basically, we have one heavy load which is rigidly connected to a plane that we try to levitate. On corners of the
plane, there are four push-fit permanent magnets. Those magnets are attracted by four other magnets which are
mounted on the four control coils (the DC force is to counteract the DC gravity). By sensing the position of the plane
with four OSEMs (there are four flags attached on the plane), we try to apply feedback control and levitate the plane.
We have made an analog circuit to realize the feedback, but it is not successful. There are the following main issues
that need to be solved:

(1) DC magnetic force is imbalanced, and we found that one pair has a stronger DC force than others. This should
be able to solved simply by replacing them with magnets have comparable strength to others.

(2) The OSEM not only senses the vertical motion, but also the translational motion. One possible fast solution is to
cover the photodiode and only leave a very thin vertical slit so that a small translational motion is not sensed.
Maybe this is too crappy. If you have better ideas, please let me know. Koji suggested to use reflective sensing
instead of OSEM, which can also solve the issue that flags sometimes touche the hole edge of the OSEM and
screw up the sensing.

(3) Cross coupling among different degrees of freedom. Basically, even if the OSEM only senses the vertical motion,
the motion of four flags, which are rigidly connected to the plane, are not independent. In the ideal case, we only
need to control pith, yaw and vertical motion, which only has three degrees of freedom, while we have four sensing outputs
from four OSEMs. This means that we need to work out the right control matrix. Right now, we are in some kind of dilemma.
In order to obtain the control matrix, we first have to get the sensing matrix or calibrate the cross coupling; however, this is
impossible if the system is unstable. This is very different from the case of quad suspension control used in LIGO,
in which the test mass is stable suspended and it is relatively easy to measure the cross coupling by driving the test mass
with coils. Rana suggested to include a mechanical spring between the fixed plane and levitated plane, so that
we can have a stable system to start with. I tried this method today, but I did not figure out a nice way to place the spring,
as we got a hole right in the middle of the fixed plane to let the coil connectors go though. As a first trial, I plan to
replace the stop rubber band (to prevent the plane from getting stuck onto the magnets) shown in the figure with mechanical
springs. In this case, the levitated plane is held by four springs instead of one. This is not as good as one, because
of imbalance among the four, but we can use this setup, at least, to calibrate the cross coupling. Let me know if you come
up better solution.

After those issues are solved, we can then implement Jamie's Cymac digital control, which is now under construction,
to achieve levitation.

4992   Tue Jul 19 21:05:55 2011 haixingUpdateDAQchoose the right relay

Rana and I are working on the AA/AI circuit for Cymac. We need relays to bypass certain paths in the circuit, and we just found a nice website
explaining how to choose the right relay:

http:/zone.ni.com/devzone/cda/tut/p/id/2774

This piece of information could be useful for others.

5019   Fri Jul 22 15:39:55 2011 haixingUpdateSUSmatching the magnets

Yi Xie and Haixing,

We used the Gauss meter to measure the strength distribution of bought magnets, which follows a nice Gaussian distribution.
We pick out four pairs--four fixed magnets and four for the levitated plate that are matched in strength. The force difference is
anticipated to be within 0.2%, and we are going to measure the force as a function of distance to further confirm this.

In the coming week, we will measure various transfer functions in the path from the sensors to the coils (the actuator). The obtained
parameters will be put into our model to determine the control scheme. The model is currently written in mathematica which can
analyze the stability from open-loop transfer function.

5022   Sun Jul 24 20:36:03 2011 haixingSummaryElectronicsAA filter tolerance analysis

Koji and Haixing,

We did a tolerance analysis to specify the conner frequency for passive low-pass filtering in the AA filter of Cymac. The
link to the wiki page for the AA filter goes as follows (one can have a look at the simple schematics):
http://blue.ligo-wa.caltech.edu:8000/40m/Electronics/BNC_Whitening_AA

Basically, we want to add the following passive low-pass filter (boxed) before connecting to the instrumentation amplifier:

Suppose (i) we have 10% error in the capacitor value and (ii) we want to have common-mode rejection
error to be smaller than 0.1% at low frequencies (up to the sampling frequency 64kHz), what would be
conner frequency, or equivalently the values for the capacitor and resistor, for the low-pass filter?

Given the transfer function for this low-pass filter:

and the error propagation equation for its magnitude:

we found that the conner frequency needs to be around 640kHz in order to have
with

5024   Sun Jul 24 22:19:19 2011 haixingSummaryElectronicsAA filter tolerance analysis

>> This sort of OK, except the capacitor connects across the (+) terminals of the two input opamps, and does not connect to ground:

>> Also, we don't care about the CMRR at 64 kHz. We care about it at up to 10 kHz, but not above.

In this case, the conner frequency for the low-pass filter would be around 100kHz in order to satisfy the requirement.

>>And doesn't the value depend on the resistors?

Yes, it does. The error in the resistor (typically 0.1%)  is much smaller than that of the capacitor (10%). Since the resistor error propagates in the same as the capacitor,
we can ignore it.

Note that we only specify the conner frequency (=1/RC) instead of R and C specifically from the tolerance analysis, we still need to choose appropriate
values for R and C with the conner frequency fixed to be around 100kHz, for which we need to consider the output impedance of port 1 and port 2.

5038   Tue Jul 26 21:11:40 2011 haixingSummaryElectronicsAA filter tolerance analysis

Given this new setup, we realized that the previous tolerance analysis is incorrect. Because the uncertainty in the capacitance value
does not affect the common mode rejection, as two paths share the same capacitor. Now only the imbalance of two resistors is relevant.
The error propagation formula goes as follows:

We require that the common-mode rejection error at low frequency up to 8kHz, namely
with , one can easily find out that the corner frequency needs to be around 24kHz.

2140   Sun Oct 25 14:29:45 2009 haixing, kiwamuConfigurationGeneralSR785 spectrum analyzer

In this morning, we have disconnected SR785 which was in front of 1X2 rack, to measure a Hall sensor noise.

After a while, we put back SR785 and re-connected as it has been.

But the display setup might have been changed a little bit.

16984   Mon Jul 11 11:56:40 2022 he YehonathanUpdateBHDMICH AS55 noise budget

I calculated a noise budget for the MICH using AS55 as a sensor. The calculation includes closed-loop TF calculations.

The notebook and associated files can be found on https://git.ligo.org/40m/bhd/-/blob/master/controls/compute_MICH_noisebudget.ipynb.

Attachment 1 shows the loop diagram I was using. The equation describing the steady-state of the loop is

$\left[\mathbb{I}-G \right]\begin{pmatrix} \gamma \\ \delta \\ \Delta\end{pmatrix} = \begin{pmatrix} \alpha \\ \beta \\ \epsilon\end{pmatrix}$

, where G is the adjacency matrix given by

$G=\begin{pmatrix} 0 & 0 & AE_2\\ 0 & 0 & BE_2 \\ E_1C & E_1D & 0 \end{pmatrix}$

First, the adjacency matrix G is constructed by stitching the small ABCDE matrices together. Once the inverse of (I-G) is calculated we can simply propagate any noise source to $\delta$ and then calculate $\left[\mathbb{I}-E(CA+DB)\right]B^{-1}\delta$ to estimate the displacement of the optics.

Attachment 2 shows the calculated noise budget together with Yuta's measurement.

All the input and output electronics are clumped together for now. Laser noise is irrelevant as this is a heterodyne measurement at 55MHz.

It seems like there is some mismatch in the calibration of the optical gain between the measurement and model. The missing noise at 3-30Hz could be due to angle-to-length coupling which I haven't included in the model.

Attachment 1: Control_Diagram.pdf
Attachment 2: MICH_AS55_Noise_Budget.pdf
6412   Wed Mar 14 05:26:39 2012 interferomter tack forceUpdateGeneraldaytime tasks

The following tasks need to be done in the daytime tomorrow.

• Hook up the DC output of the Y green BBPD on the PSL table to an ADC channel (Jamie / Steve)
• Install fancy suspension matrices on PRM and ITMX [#6365] (Jenne)
• Check if the REFL165 RFPD is healthy or not (Suresh / Koji)
• According to a simulation the REFL165 demod signal should show similar amount of the signal to that of REFL33.
• But right now it is showing super tiny signals [#6403]
6416   Wed Mar 14 14:09:01 2012 interferomter tack forceUpdateGeneraldaytime tasks

 Quote: The following tasks need to be done in the daytime tomorrow. Hook up the DC output of the Y green BBPD on the PSL table to an ADC channel (Jamie / Steve) Install fancy suspension matrices on PRM and ITMX [#6365] (Jenne) Check if the REFL165 RFPD is healthy or not (Suresh / Koji) According to a simulation the REFL165 demod signal should show similar amount of the signal to that of REFL33. But right now it is showing super tiny signals [#6403]

For ITMX, I used the values from the conlog:

2011/08/12,20:10:12 utc 'C1:SUS[-_]ITMX[-_]INMATRIX'

These are the latest values in the conlog that aren't the basic matricies.  Even though we did a round of diagonalization in Sept, and the
matricies are saved in a .mat file, it doesn't look like we used the ITMX matrix from that time.



For PRM, I used the matricies that were saved in InputMatricies_16Sept2011.mat, in the peakFit folder, since I couldn't find anything in the Conlog other than the basic matricies.


UPDATE:  I didn't actually count the number of oscillations until the optics were damped, so I don't have an actual number for the Q, but I feel good about the damping, after having kicked POS of both ITMX and PRM and watching the sensors.

407   Mon Mar 31 14:01:40 2008 jamieSummaryLSCSummary of DC readout PD non-linearity measurements
From March 21-26, I conducted some measurements of the response non-linearity of some mock-up DC readout photodetectors. The detectors are simple:
Vbias ---
|
PD
|-------- output
resistor
|
---
-

This is a description of the final measurement.

The laser current modulation input was given a 47Hz sine wave at 20mV. A constant small fraction of the beam was shown onto the reference detector, and a beam that was varied in DC power level was incident on the test detector. Spectra were taken from both detectors at the same time, 0.25Hz bandwidth, over 100 averages.

At each incident power level on the test detector, the Vpk in all multiples of the modulation frequency were measured (ie. V[i*w]). The difference between the 2f/1f ratio in the test and reference was then calculated, ie:
V_test[2*w]/V_test[1*w] - V_ref[2*w]/V_ref[1*w]

This is the solid black line in the plot ("t21-r21_v_power.png").

The response of a simulated non-linear detector was also calculated based on the Vpk measured at each harmonic in the reference detector, assuming that the reference detector had a purely linear response, ie:
V_nl[beta,2*w]/V_nl[beta,1*w] - V_l[2*w]/V_l[1*w]

these are the dashed colored lines in the plot ("t21-r21_v_power.png").

The result of the measurement seems to indicate that the non-linearity in the test detector is less than beta=-1.

The setup that was on the big optics table south of the laser, adjacent to the mode cleaner, is no longer needed.
Attachment 1: t21-r21_v_power.png
4549   Wed Apr 20 23:20:49 2011 jamieSummaryComputersinstallation of CDS tools on pianosa

This is an overview of how I got (almost) all the CDS tools running on pianosa, the new Ubuntu 10.04 control room work station.

This is machine is experiment in minimizing the amount of custom configuration and source code compiling. I am attempting to install as many tools as possible from existing packages in

## available packages

I was able to install a number of packages directly from the ubuntu archives, including fftw, grace, and ROOT:

apt-get install \ libfftw3-dev \ grace \ root-system

## LSCSOFT

I installed all needed LSCSOFT packages (framecpp, libframe, metaio) from the well-maintained UWM LSCSOFT repository.

$cat /etc/apt/sources.list.d/lscsoft.listdeb http://www.lsc-group.phys.uwm.edu/daswg/download/software/debian/ squeezedeb-src http://www.lsc-group.phys.uwm.edu/daswg/download/software/debian/ squeeze contrib  sudo apt-get install lscsoft-archive-keyringsudo apt-get updatesudo apt-get install ldas-tools-framecpp-dev libframe-dev libmetaio-dev lscsoft-user-en You then need to source /opt/lscsoft/lscsoft-user-env.sh to use these packages. ## EPICS There actually appear to be a couple of projects that are trying to provide debs of EPICS. I was able to actually get epics working from one of them, but it didn't include some of the other needed packages (such as MEDM and BURT) so I fell back to using Keith's pre-build binary tarball. Prereqs: apt-get install \ libmotif-dev \ libxt-dev \ libxmu-dev \ libxprintutil-dev \ libxpm-dev \ libz-dev \ libxaw7-dev \ libpng-dev \ libgd2-xpm-dev \ libbz2-dev \ libssl-dev \ liblapack-dev \ gfortran Pulled Keith's prebuild binary: cd /ligo/apps wget https://llocds.ligo-la.caltech.edu/daq/software/binary/apps/ubuntu/epics-3.14.10-ubuntu.tar.gz tar zxf epics-3.14.10-ubuntu.tar.gz GDS I built GDS from svn, after I fixed some broken stuff [0]: cd ~controls/src/gdssvn co https://redoubt.ligo-wa.caltech.edu/svn/gds/trunkcd trunk#fixed broken stuff [0]source /opt/lscsoft/lscsoft-user-env.sh./bootstrapexport GDSBUILD=onlineexport ROOTSYS=/usr./configure --prefix=/ligo/apps/gds --enable-only-dtt --with-epics=/ligo/apps/epics-3.14.10makemake install ## dataviewer I installed dataviewer from source: cd ~controls/src/advLigoRTSsvn co https://redoubt.ligo-wa.caltech.edu/svn/advLigoRTS/trunkcd trunk/src/dv#fix stupid makefile /opt/rtapps --> /ligo/appsmakemake install I found that the actual dataviewer wrapper script was also broken, so I made a new one: $ cat /ligo/apps/dv/dataviewer
#!/bin/bashexport DVPATH=/ligo/apps/dvID=DCDIR=/tmp/${ID}DCmkdir$DCDIRtrap "rm -rf $DCDIR" EXIT$DVPATH/dc3 -s ${NDSSERVER} -a$ID -b $DVPATH "$@"

## environment

Finally, I made a environment definer file:

$cat /ligo/apps/cds-user-env.sh# source the lscsoft environment. /opt/lscsoft/lscsoft-user-env.sh# source the gds environment. /ligo/apps/gds/etc/gds-user-env.sh# special local epics setupEPICS=/ligo/apps/epicsexport LD_LIBRARY_PATH=${EPICS}/base/lib/linux-x86_64:$LD_LIBRARY_PATHexport LD_LIBRARY_PATH=${EPICS}/extensions/lib/linux-x86_64:$LD_LIBRARY_PATHexport LD_LIBRARY_PATH=${EPICS}/modules/seq/lib/linux-x86_64:$LD_LIBRARY_PATHexport PATH=${EPICS}/base/bin/linux-x86_64:$PATHexport PATH=${EPICS}/extensions/bin/linux-x86_64:$PATHexport PATH=${EPICS}/modules/seq/bin/linux-x86_64:$PATH# dataviewer pathexport PATH=/ligo/apps/dv:${PATH}# specify the NDS serverexport NDSSERVER=fb

[0] GDS was not compiling, because of what looked like bugs. I'm not sure why I'm the first person to catch these things. Stricter compiler?

To fix the following compile error:

TLGExport.cc:1337: error: ‘atoi’ was not declared in this scope

Index: /home/controls/src/gds/trunk/GUI/dttview/TLGExport.cc===================================================================--- /home/controls/src/gds/trunk/GUI/dttview/TLGExport.cc	(revision 6423)+++ /home/controls/src/gds/trunk/GUI/dttview/TLGExport.cc	(working copy)@@ -31,6 +31,7 @@ #include <iomanip> #include <string.h> #include <strings.h>+#include <stdlib.h>  namespace ligogui {    using namespace std;

To fix the following compile error:

TLGPrint.cc:264: error: call of overloaded ‘abs(Int_t&)’ is ambiguous

Index: /home/controls/src/gds/trunk/GUI/dttview/TLGPrint.cc===================================================================--- /home/controls/src/gds/trunk/GUI/dttview/TLGPrint.cc	(revision 6423)+++ /home/controls/src/gds/trunk/GUI/dttview/TLGPrint.cc	(working copy)@@ -22,6 +22,7 @@ #include <fstream> #include <map> #include <cmath>+#include <cstdlib>  namespace ligogui {    using namespace std;
4732   Tue May 17 17:01:22 2011 jamieConfigurationCDSUpdate LSC channels from _DAQ to _DQ

As of RCG version 2.1, recorded channels use the suffix "_DQ", instead of "_DAQ".  I just rebuilt and installed the c1lsc model, which changed the channel names, therefore hosing the old daq channel ini file.  Here's what I did, and how I fixed it:

$ssh c1lsc$ cd /opt/rtcds/caltech/c1/core/trunk
$make c1lsc$ make install-c1lsc
$cd /opt/rtcds/caltech/c1/scripts$ ./startc1lsc
$cd /opt/rtcds/caltech/c1/chans/daq$ cat archive/C1LSC_110517_152411.ini | sed "s/_DAQ/_DQ/g" >C1LSC.ini
telnet fb 8087 daqd> shutdown  5049 Wed Jul 27 15:49:13 2011 jamieConfigurationCDSdataviewer now working on pianosa Not exactly sure what the problem was, but I updated to the head of the SVN and rebuilt and it seems to be working fine now. 5060 Fri Jul 29 12:39:26 2011 jamieUpdateCDSc1iscex mysteriously crashed c1iscex was behaving very strangely this morning. Steve earlier reported that he was having trouble pulling up some channels from the c1scx model. I went to investigate and noticed that indeed some channels were not responding. While I was in the middle of poking around, c1iscex stopped responding altogether, and became completely unresponsive. I walked down there and did a hard reset. Once it rebooted, and I did a burt restore from early this morning, everything appeared to be working again. The fact that problems were showing up before the machine crashed worries me. I'll try to investigate more this afternoon. 5094 Tue Aug 2 16:43:23 2011 jamieUpdateCDSNDS2 server on mafalda restarted for access to new channels In order to get access to new DQ channels from the NDS2 server, the NDS2 server needs to be told about the new channels and restarted. The procedure is as follows: ssh mafalda cd /users/jzweizig/nds2-mafalda ./build_channel_history ./install_channel_list pkill nds2 # wait a few seconds for the process to quit and release the server port ./start_nds2  This procedure needs to be run every time new _DQ channels are added. We need to set this up as a proper service, so the restart procedure is more elegant. An additional comment from John Z.: The --end-gps parameter in ./build_channel_history seems to be causeing some trouble. It should work without this parameter, but there is a directory with a gps time of 1297900000 (evidently a test for GPS1G) that might screw up the channel list generation. So, it appears that the end time requires a time for which data already exists. this wouldn't seem to be a big deal, but it means that it has to be modified by hand before running. I haven't fixed this yet, but I think that I can probably pick out the most recent frame and use that as an end-time point. I'll see if I can make that work... 5127 Fri Aug 5 20:37:34 2011 jamieSummaryGeneralSummary of today's in-vacuum work [Jamie, Suresh, Jenne, Koji, Kiwamu] After this morning's hiccup with the east end crane, we decided to go ahead with work on ETMX. Took pictures of the OSEM assemblies, we laid down rails to mark expected new position of the suspension base. Removed two steering mirrors and a windmill that were on the table but where not being used at all. Clamped the test mass and moved the suspension to the edge of the table so that we could more easily work on repositioning the OSEMs. Then leveled the table and released the TM. Rotated each OSEM so that the parallel LED/PD holder plates were oriented in the vertical direction. We did this in the hopes that this orientation would minimize SD -> POS coupling. For each OSEM, we moved it through it's full range, as read out by the C1:SUS-ETMX_{UL,UR,LL,LR,SD}PDMon channels, and attempted to adjust the positions so that the read out was in the center of the range (the measured ranges, mid values, and ultimate positions will be noted in a follow-up post). Once we were satisfied that all the OSEMs were in good positions, we photographed them all (pictures also to follow). Re-clamped the TM and moved it into it's final position, using the rails as reference and a ruler to measure as precisely as possible : ETMX position change: -0.2056 m = -20.56 cm = -8.09 in (away from vertex) Rebalanced the table. Repositioned the mirror for the ETMX face camera. Released TM clamps. Rechecked OSEM centering. Unblocked the green beam, only to find that it was displaced horizontally on the test mass about half an inch to the west (-y). Koji determined that this was because the green beam is incident on the TM at an angle due to the TM wedge. This presents a problem, since the green beam can no longer be used as a reference for the arm cavity. After some discussion we decided to go with the TM position as is, and to realign the green beam to the new position and relock the green beam to the new cavity. We should be able to use the spot position of the green beam exiting the vacuum at the PSL table as the new reference. If the green X beam exiting at the PSL table is severely displaced, we may decide to go back in and move ETMX to tweak the cavity alignment. At this point we decided that we were done for the day. Before closing up, we put a piece of foil with a hole in it in front of the the TM face, to use as an alignment aperture when Kiwamu does the green alignment. Kiwamu will work on the green alignment over the weekend. Assuming everything works out, we'll try the same procedure on ETMY on Monday. 5128 Fri Aug 5 20:44:26 2011 jamieMetaphysicsTreasureFilm crew here Monday morning Just a reminder that a film crew will be here Monday morning, filming Christian Ott for some Discovery channel show. They are slated to be here from 8am to 12:30pm or so. They will take a couple of shots inside the lab, and the rest of the filming should be of Christian in the control room (which they will "clean up" and fit with "sexy lighting"). I will try to be here the whole time to oversee everything. 5143 Mon Aug 8 19:45:27 2011 jamieUpdateCDSactivateDQ script run; SUS channels being acquired again > Also the BS is missing its DAQ channels again (JAMIE !) so we can't diagnose it with the free swinging method. I'm not sure why the BS channels were not being acquired. I reran the activateDQ script, which seemed to fix everything. The BS DQ channels are now there. I also noticed that for some reason there were SUS-BS-ASC{PIT,YAW}_IN1_DQ channels, even though they had their acquire flags set to 0. This means that they were showing up like test point channels, but not being written to frames by the frame builder. This is pretty unusual, so I'm not sure why they were there. I removed them. 5161 Wed Aug 10 00:11:39 2011 jamieUpdateSUScheck of input diagnolization of ETMX after OSEM tweaking Suresh and I tweaked the OSEM angles in ETMX yesterday. Last night the ETMs were left free swinging, and today I ran Rana's peakFit scripts on ETMX to check the input diagnolization: It's well inverted, but the matrix elements are not great:  pit yaw pos side butt UL 0.3466 0.4685 1.6092 0.3107 1.0428 UR 0.2630 -1.5315 1.7894 -0.0706 -1.1859 LR -1.7370 -1.5681 0.3908 -0.0964 0.9392 LL -1.6534 0.4319 0.2106 0.2849 -0.8320 SD 1.0834 -2.6676 -0.9920 1.0000 -0.1101  The magnets are all pretty well centered in the OSEMS, and we worked at rotating the OSEMS such that the bounce mode was minimized. Rana and Koji are working on ETMY now. Maybe they'll come up with a better procedure. 5162 Wed Aug 10 00:21:10 2011 jamieUpdateCDSupdates to peakFit scripts I updated the peakFit routines to make them a bit more user friendly: • modified so that any subset of optics can be processed at a time, instead of just all • broke out tweakable fit parameters into a separate parameters.m file • added a README that describes use These changes were committed to the 40m svn. 5176 Wed Aug 10 15:39:33 2011 jamieUpdateSUScurrent SUS input diagonalization overview Below is the overview of all the core IFO suspension input diagonalizatidons. ### Summary: ITMY, PRM, BS are really bad (in that order) and are our top priorities. ### UPDATE: I had originally put the condition number of the calculated input matrix (M) in the last column. However, after some discussion we decided that this is not in fact what we want to look at. The condition number of a matrix is unity if the matrix is completely diagonal. However, even our ideal input matrix is not diagonal, so the "best" condition number for the input matrix is unclear. What instead we do know is that the matrix, B, that describes the difference between the calculated input matrix, M, and the ideal input matrix, M0: should be diagonal (identity, in fact): M = M0 B B should be diagonal (identity, in fact), and it's condition number should ideally be 1. So now we calculate B-1, since it can be calculated from the pre-inverted input matrix: B-1 = M-1 * M0 From that we calculate cond(B) == cond(B-1). cond(B) is our new measure of the "badness" of the OSEMS. ### new summary: ITMY, PRM, BS are really bad (in that order) and are our top priorities.  TM INPUT MATRIX (M) cond(M) cond(B) PRM  pit yaw pos side butt UL -2.000 -2.000 -2.000 -0.345 2.097 UR -0.375 -0.227 -0.312 -0.060 0.247 LR 1.060 1.075 0.971 0.143 -0.984 LL -0.565 -0.698 -0.717 -0.141 0.672 SD 1.513 1.485 1.498 1.000 -1.590  75.569 106.756 SRM  pit yaw pos side butt UL 0.791 1.060 1.114 -0.133 1.026 UR 1.022 -0.940 1.052 -0.061 -1.027 LR -0.978 -0.987 0.886 -0.031 0.903 LL -1.209 1.013 0.948 -0.103 -1.043 SD 0.286 0.105 1.249 1.000 0.030  2.6501 3.90776 BS  pit yaw pos side butt UL 1.420 0.818 -0.069 0.352 1.038 UR 0.276 -1.182 1.931 -0.217 -0.905 LR -1.724 -0.274 1.940 -0.254 0.862 LL -0.580 1.726 -0.060 0.315 -1.194 SD 0.560 0.171 -3.535 1.000 0.075  9.8152 7.28516 ITMX  pit yaw pos side butt UL 0.437 1.015 1.050 -0.065 0.714 UR 0.827 -0.985 1.129 -0.221 -0.957 LR -1.173 -1.205 0.950 -0.281 1.245 LL -1.563 0.795 0.871 -0.125 -1.084 SD -0.581 -0.851 2.573 1.000 -0.171  4.08172 4.69811 ITMY  pit yaw pos side butt UL 0.905 -0.884 -0.873 0.197 0.891 UR -1.095 1.088 1.127 -0.252 -1.115 LR -0.012 -0.028 0.002 0.001 0.030 LL 1.988 -2.000 -1.998 0.451 1.964 SD 4.542 -4.608 -4.621 1.000 4.517  801.453 774.901 ETMX  pit yaw pos side butt UL 0.344 0.475 1.601 0.314 1.043 UR 0.283 -1.525 1.786 -0.071 -1.181 LR -1.717 -1.569 0.399 -0.102 0.938 LL -1.656 0.431 0.214 0.283 -0.837 SD 0.995 -2.632 -0.999 1.000 -0.110  4.26181 4.33518 ETMY  pit yaw pos side butt UL -0.212 1.272 1.401 -0.127 0.941 UR 0.835 -0.728 1.534 -0.101 -1.054 LR -0.953 -1.183 0.599 -0.066 0.827 LL -2.000 0.817 0.466 -0.092 -1.177 SD -0.172 0.438 2.238 1.000 -0.008  4.04847 4.33725 5207 Fri Aug 12 15:16:56 2011 jamieUpdateSUStoday's SUS overview Here's an update of the suspensions, after yesterdays in-vacuum work and OSEM tweaking: • PRM and ETMY are completely messed up. The spectra are so bad that I'm not going to bother posting anything. ETMY has extreme sensor voltages that indicate that it's maybe stuck to one of the OSEMS. PRM voltages look nominal, so I have no idea what's going on there. • ITMY is much improved, but it could still use some work • SRM is a little worse than what it was yesterday, but we've done a lot of work on the ITMY table, such as moving ITMY suspension and rebalancing the table. • BS looks for some reason slightly better than it did yesterday  TM M cond(B) SRM  pit yaw pos side butt UL 0.828 1.041 1.142 -0.135 1.057 UR 1.061 -0.959 1.081 -0.063 -1.058 LR -0.939 -0.956 0.858 -0.036 0.849 LL -1.172 1.044 0.919 -0.108 -1.035 SD 0.196 -0.024 1.861 1.000 0.043  4.20951 ITMY  pit yaw pos side butt UL 1.141 0.177 1.193 -0.058 0.922 UR 0.052 -1.823 0.766 -0.031 -0.974 LR -1.948 -0.082 0.807 -0.013 1.147 LL -0.859 1.918 1.234 -0.040 -0.957 SD -1.916 2.178 3.558 1.000 0.635  7.70705 BS  pit yaw pos side butt UL 1.589 0.694 0.182 0.302 1.042 UR 0.157 -1.306 1.842 -0.176 -0.963 LR -1.843 -0.322 1.818 -0.213 0.957 LL -0.411 1.678 0.158 0.265 -1.038 SD 0.754 0.298 -3.142 1.000 0.053  6.12779 5240 Mon Aug 15 17:23:55 2011 jamieUpdateSUSfreeswing script updated I have updated the freeswing scripts, combining all of them into a single script that takes arguments to specify the optic to kick: pianosa:SUS 0> ./freeswing usage: freeswing SET usage: freeswing OPTIC [OPTIC ...] Kick and free-swing suspended optics. Specify optics (i.e. 'MC1', 'ITMY') or a set: 'all' = (MC1 MC2 MC3 ETMX ETMY ITMX ITMY PRM SRM BS) 'ifo' = (ETMX ETMY ITMX ITMY PRM SRM BS) 'mc' = (MC1 MC2 MC3) pianosa:SUS 0>  I have removed all of the old scripts, and committed the new one to the SVN. 5241 Mon Aug 15 17:36:10 2011 jamieUpdateSUSStrangeness with ETMY (was: Monday SUS update) For some reason ETMY has changed a lot. Not only does it now have the worst "badness" (B matrix condition number) at ~10, but the frequency of all the modes have shifted, some considerably. I did accidentally bump the optic when Jenne and I were adjusting the OSEMs last week, but I didn't think it was that much. The only thing I can think of that would cause the modes to move so much is that the optic has been somehow reseated in it's suspension. I really don't know how that would have happened, though. Jenne and I went in to investigate ETMY, to see if we could see anything obviously wrong. Everything looks to be ok. The magnets are all well centered in the OSEMs, and the PDMon levels look ok. We rechecked the balance of the table, and tweaked it a bit to make it more level. We then tweaked the OSEMs again to put them back in the center of their range. We also checked the response by using the lockin method to check the response to POS and SIDE drive in each of the OSEMs (we want large POS response and minimal SIDE response). Everything looked ok. We're going to take another freeswing measurement and see how things look now. If there are any suggestions what should be done (if anything), about the shifted modes, please let us know. 5242 Mon Aug 15 17:38:07 2011 jamieUpdateGeneralFoil aperture placed in front of ETMY We have placed a foil aperture in front of ETMY, to aid in aligning the Y-arm, and then the PRC. It obviously needs to be removed before we close up. 5247 Tue Aug 16 10:59:06 2011 jamieUpdateSUSSUS update Data taken from: 997530498+120 Things are actually looking ok at the moment. "Badness" (cond(B)) is below 6 for all optics. • We don't have results from PRM since its spectra looked bad, as if it's being clamped by the earthquake stops. • The SRM matrix definitely looks the nicest, followed by ITMX. All the other matrices have some abnormally high or low elements. • cond(B) for ETMY is better than that for SRM, even though the ETMY matrix doesn't look as nice. Does this mean that cond(B) is not necessarily the best figure of merit, or is there something else that our naive expectation for the matrix doesn't catch? We still need to go through and adjust all the OSEM ranges once the IFO is aligned and we know what our DC biases are. We'll repeat this one last time after that.  TM M cond(B) BS  pit yaw pos side butt  UL 1.456 0.770 0.296 0.303 1.035   UR 0.285 -1.230 1.773 -0.077 -0.945 LR -1.715 -0.340 1.704 -0.115 0.951 LL -0.544 1.660 0.227 0.265 -1.070 SD 0.612 0.275 -3.459 1.000 0.046  5.61948 SRM  pit yaw pos side butt UL 0.891 1.125 0.950 -0.077 0.984 UR 0.934 -0.875 0.987 -0.011 -0.933 LR -1.066 -1.020 1.050 0.010 1.084 LL -1.109 0.980 1.013 -0.056 -0.999 SD 0.257 -0.021 0.304 1.000 0.006  4.0291 ITMX  pit yaw pos side butt UL 0.436 1.035 1.042 -0.068 0.728 UR 0.855 -0.965 1.137 -0.211 -0.969 LR -1.145 -1.228 0.958 -0.263 1.224 LL -1.564 0.772 0.863 -0.120 -1.079 SD -0.522 -0.763 2.495 1.000 -0.156  4.55925 ITMY  pit yaw pos side butt UL 1.375 0.095 1.245 -0.058 0.989 UR -0.411 1.778 0.975 -0.022 -1.065 LR -2.000 -0.222 0.755 0.006 1.001 LL -0.214 -1.905 1.025 -0.030 -0.945 SD 0.011 -0.686 0.804 1.000 0.240  4.14139 ETMX  pit yaw pos side butt UL 0.714 0.191 1.640 0.404 1.052 UR 0.197 -1.809 1.758 -0.120 -1.133 LR -1.803 -1.889 0.360 -0.109 0.913 LL -1.286 0.111 0.242 0.415 -0.902 SD 1.823 -3.738 -0.714 1.000 -0.130  5.19482 ETMY  pit yaw pos side butt UL 1.104 0.384 1.417 0.351 1.013 UR -0.287 -1.501 1.310 -0.074 -1.032 LR -2.000 0.115 0.583 -0.045 0.777 LL -0.609 2.000 0.690 0.380 -1.179 SD 0.043 -0.742 -0.941 1.000 0.338  3.57032 5260 Thu Aug 18 00:58:40 2011 jamieUpdateSUSoptics kicked and left free swinging ALL optics (including MC) were kicked and left free swinging at: 997689421 The "opticshutdown" script was also run, which should turn the watchdogs back on in 5 hours (at 6am). 5263 Thu Aug 18 12:22:37 2011 jamieUpdateSUSsuspension update Most of the suspension look ok, with "badness" levels between 4 and 5. I'm just posting the ones that look slightly less ideal below. • PRM, SRM, and BS in particular show a lot of little peaks that look like some sort of intermodulations. • ITMY has a lot of elements with imaginary components • The ETMY POS and SIDE modes are *very* close together, which is severely adversely affecting the diagonalization  PRM  pit yaw pos side butt UL 0.466 1.420 1.795 -0.322 0.866 UR 1.383 -0.580 0.516 -0.046 -0.861 LR -0.617 -0.978 0.205 0.011 0.867 LL -1.534 1.022 1.484 -0.265 -1.407 SD 0.846 -0.632 -0.651 1.000 0.555 5.62863 SRM  pit yaw pos side butt UL 0.783 1.046 1.115 -0.149 1.029 UR 1.042 -0.954 1.109 -0.060 -1.051 LR -0.958 -0.926 0.885 -0.035 0.856 LL -1.217 1.074 0.891 -0.125 -1.063 SD 0.242 0.052 1.544 1.000 0.029  4.0198 BS  pit yaw pos side butt UL 1.536 0.714 0.371 0.283 1.042 UR 0.225 -1.286 1.715 -0.084 -0.927 LR -1.775 -0.286 1.629 -0.117 0.960 LL -0.464 1.714 0.285 0.250 -1.070 SD 0.705 0.299 -3.239 1.000 0.023  5.5501 ITMY  pit yaw pos side butt UL 1.335 0.209 1.232 -0.071 0.976 UR -0.537 1.732 0.940 -0.025 -1.068 LR -2.000 -0.268 0.768 0.004 1.046 LL -0.129 -1.791 1.060 -0.043 -0.911 SD -0.069 -0.885 1.196 1.000 0.239  4.28384 ETMY  pit yaw pos side butt UL 1.103 0.286 1.194 -0.039 0.994 UR -0.196 -1.643 -0.806 -0.466 -1.113 LR -2.000 0.071 -0.373 -0.209 0.744 LL -0.701 2.000 1.627 0.217 -1.149 SD 0.105 -1.007 3.893 1.000 0.290  9.25346 Attachment 2: SRM.png 5265 Thu Aug 18 22:24:08 2011 jamieOmnistructureVIDEOUpdated 'videoswitch' script I have updated the 'videoswitch' program that controls the video MUX. It now includes the ability to query the video mux for the channel mapping: controls@pianosa:~ 0 /opt/rtcds/caltech/c1/scripts/general/videoswitch -h Usage: videoswitch [options] [OUT]      List current output/input mapping [for OUT] videoswitch [options] OUT IN     Set output OUT to be input IN Options:   -h, --help            show this help message and exit   -i, --inputs          List input channels and exit   -o, --outputs         List output channels and exit   -l, --list            List all input and output channels and exit   -H HOST, --host=HOST  IP address/Host name controls@pianosa:~ 0\$ 

5286   Tue Aug 23 10:38:27 2011 jamieUpdateSUSSUS update

SUS update before closing up:

• MC1, MC2, ITMX look good
• MC3, PRM look ok
• SRM pos and side peaks are too close together to distinguish, so the matrix is not diagnalizable.  I think with more data it should be ok, though.
• all ITMY elements have imaginary components
• ITMY, ETMX, ETMY appear to have modest that swapped position:
• ITMY: pit/yaw
• ETMX: yaw/side
• ETMY: pos/side
• MC3, ETMX, ETMY have some very large/small elements

Not particularly good.  We're going to work on ETMY at least, since that one is clearly bad.

 OPTIC M cond(B) MC1       pit     yaw     pos     side    butt UL    0.733   1.198   1.168   0.050   1.057  UR    1.165  -0.802   0.896   0.015  -0.925  LR   -0.835  -1.278   0.832  -0.002   0.954  LL   -1.267   0.722   1.104   0.032  -1.064  SD    0.115   0.153  -0.436   1.000  -0.044  4.02107 MC2        pit     yaw     pos     side    butt UL    1.051   0.765   1.027   0.128   0.952   UR    0.641  -1.235   1.089  -0.089  -0.942   LR   -1.359  -0.677   0.973  -0.097   1.011   LL   -0.949   1.323   0.911   0.121  -1.096   SD   -0.091  -0.147  -0.792   1.000  -0.066   4.02254 MC3        pit     yaw     pos     side    butt UL    1.589   0.353   1.148   0.170   1.099   UR    0.039  -1.647   1.145   0.207  -1.010   LR   -1.961  -0.000   0.852   0.113   0.896   LL   -0.411   2.000   0.855   0.076  -0.994   SD   -0.418   0.396  -1.624   1.000   0.019 3.60876 PRM       pit     yaw     pos     side    butt UL    0.532   1.424   1.808  -0.334   0.839   UR    1.355  -0.576   0.546  -0.052  -0.890   LR   -0.645  -0.979   0.192   0.015   0.881   LL   -1.468   1.021   1.454  -0.267  -1.391   SD    0.679  -0.546  -0.674   1.000   0.590   5.54281 BS        pit     yaw     pos     side    butt UL    1.596   0.666   0.416   0.277   1.037   UR    0.201  -1.334   1.679  -0.047  -0.934   LR   -1.799  -0.203   1.584  -0.077   0.952   LL   -0.404   1.797   0.321   0.247  -1.077   SD    0.711   0.301  -3.397   1.000   0.034   5.46234 SRM NA NA NA ITMX        pit     yaw     pos     side    butt UL    0.458   1.025   1.060  -0.065   0.753   UR    0.849  -0.975   1.152  -0.199  -0.978   LR   -1.151  -1.245   0.940  -0.243   1.217   LL   -1.542   0.755   0.848  -0.109  -1.052   SD   -0.501  -0.719   2.278   1.000  -0.153 4.4212 ITMY        pit     yaw     pos     side    butt UL    0.164   1.320   1.218  -0.086   0.963   UR    1.748  -0.497   0.889  -0.034  -1.043   LR   -0.252  -2.000   0.782  -0.005   1.066   LL   -1.836  -0.183   1.111  -0.058  -0.929   SD   -0.961  -0.194   1.385   1.000   0.239   4.33051 ETMX        pit     yaw     pos     side    butt UL    0.623   1.552   1.596  -0.033   1.027   UR    0.194  -0.448   1.841   0.491  -1.170   LR   -1.806  -0.478   0.404   0.520   0.943   LL   -1.377   1.522   0.159  -0.005  -0.860   SD    1.425   3.638  -0.762   1.000  -0.132   4.89418 ETMY        pit     yaw     pos     side    butt UL    0.856   0.007   1.799   0.241   1.005   UR   -0.082  -1.914  -0.201  -0.352  -1.128   LR   -2.000   0.079  -0.104  -0.162   0.748   LL   -1.063   2.000   1.896   0.432  -1.119   SD   -0.491  -1.546   2.926   1.000   0.169   9.11516

5291   Tue Aug 23 17:45:22 2011 jamieUpdateSUSITMX, ITMY, ETMX clamped and moved to edge of tables

In preparation for tomorrow's drag wiping and door closing, I have clamped ITMX, ITMY, and ETMX with their earthquake stops and moved the suspension cages to the door-edge of their respective tables.  They will remain clamped through drag wiping.

ETMY was left free-swinging, so we will clamp and move it directly prior to drag wiping tomorrow morning.

5293   Tue Aug 23 18:25:56 2011 jamieUpdateSUSSRM diagnalization OK

By looking at a longer data stretch for the SRM (6 hours instead of just one), we were able to get enough extra resolution to make fits to the very close POS and SIDE peaks.  This allowed us to do the matrix inversion.  The result is that SRM looks pretty good, and agrees with what was measured previously:

 SRM        pit     yaw     pos     side    butt UL    0.869   0.975   1.140  -0.253   1.085   UR    1.028  -1.025   1.083  -0.128  -1.063   LR   -0.972  -0.993   0.860  -0.080   0.834   LL   -1.131   1.007   0.917  -0.205  -1.018   SD    0.106   0.064   3.188   1.000  -0.011   4.24889

5294   Wed Aug 24 09:11:19 2011 jamieUpdateSUSETMY SUS update: looks good. WE'RE READY TO CLOSE

We ran one more free swing test on ETMY last night, after the last bit of tweaking on the SIDE OSEM.  It now looks pretty good:

 ETMY       pit     yaw     pos     side    butt UL   -0.323   1.274   1.459  -0.019   0.932  UR    1.013  -0.726   1.410  -0.050  -1.099  LR   -0.664  -1.353   0.541  -0.036   0.750  LL   -2.000   0.647   0.590  -0.004  -1.219  SD    0.021  -0.035   1.174   1.000   0.137   4.23371

So I declare: WE'RE NOW READY TO CLOSE UP.

5297   Wed Aug 24 12:08:56 2011 jamieUpdateSUSITMX, ETMX, ETMY free swinging

ITMX: 998245556

ETMX, ETMY: 998248032

5317   Mon Aug 29 12:05:32 2011 jamieUpdateCDSRe : fb down

fb was requiring manual fsck on it's disks because it was sensing filesystem errors.  The errors had to do with the filesystem timestamps being in the future.  It turned out that fb's system date was set to something in 2005.  I'm not sure what caused the date to be so off (motherboard battery problem?)  But I did determine after I got the system booting that the NTP client on fb was misconfigured and was therefore incapable of setting the system date.  It seems that it was configured to query a non-existent ntp server.  Why the hell it would have been set like this I have no idea.

In any event, I did a manual check on /dev/sdb1, which is the root disk, and postponed a check on /dev/sda1 (the RAID mounted at /frames) until I had the system booting.  /dev/sda1 is being checked now, since there are filesystems errors that need to be corrected, but it will probably take a couple of hours to complete.  Once the filesystems are clean I'll reboot fb and try to get everything up and running again.

5319   Mon Aug 29 18:16:10 2011 jamieUpdateCDSRe : fb down

fb is now up and running, although the /frames raid is still undergoing an fsck which is likely take another day.  Consequently there is no daqd and no frames are being written to disk.  It's running and providing the diskless root to the rest of the front end systems, so, so the rest of the IFO should be operational.

I burt restored the following (which I believe is everything that was rebooted), from Saturday night:

/opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Aug/27/23:07/c1lscepics.snap /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Aug/27/23:07/c1susepics.snap /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Aug/27/23:07/c1iooepics.snap /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Aug/27/23:07/c1assepics.snap /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Aug/27/23:07/c1mcsepics.snap /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Aug/27/23:07/c1gcvepics.snap /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Aug/27/23:07/c1gfdepics.snap /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Aug/27/23:07/c1rfmepics.snap /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Aug/27/23:07/c1pemepics.snap 

5320   Mon Aug 29 18:24:11 2011 jamieUpdateSUSITMY stuck to OSEMs?

ITMY, which is supposed to be fully free-swinging at the moment, is displaying the tell-tale signs of  being stuck to one of it's OSEMs.  This is indicated by the PDMon values, one of which is zero while the others are max:

UL: 0.000
UR: 1.529
LR: 1.675
LL: 1.949
SD: 0.137


Do we have a procedure for remotely getting it unstuck?  If not, we need to open up ITMYC and unstick it before we pump.

5323   Tue Aug 30 11:28:56 2011 jamieUpdateCDSframebuilder back up

The fsck on the framebuilder (fb) raid array (/dev/sda1) completed overnight without issue.  I rebooted the framebuilder and it came up without problem.

I'm now working on getting all of the front-end computers and models restarted and talking to the framebuilder now.

5324   Tue Aug 30 11:42:29 2011 jamieUpdateCDStestpoint.par file found to be completely empty

The testpoint.par file, located at /opt/rtcds/caltech/c1/target/gds/param/testpoint.par, which tells GDS processes where to find the various awgtpman processes, was completely empty.  The file was there but was just 0 bytes.  Apparently the awgtpman processes themselves also consult this file when starting, which means that none of the awgtpman processes would start.

This file is manipulated in the "install-daq-%" target in the RCG Makefile, ultimately being written with output from the src/epics/util/updateTestpointPar.pl script, which creates a stanza for each front-end model.  Rebuilding and installing all of the models properly regenerated this file.

I have no idea what would cause this file to get truncated, but apparently this is not the first time: elog #3999.  I'm submitting a bug report with CDS.

ELOG V3.1.3-