I'm using COMSOL to simulate the effect of cavity sagging to find the optimum suspension points. The answer is not yet ready, I'm still working around COMSOL.

• Problem with point like contact: First I tried to simulated 4-fixed-point support, however the result was asymmetric along beam line. It might be the result from the point-like contacting areas between the support and the cavity. You can see the tilting along the beam line in the figure below. Note the constrained area  of the support effect the sagging slightly as well [add ref].

.

fig1: cavity sagging, on 4 point suspension. The cavity is not symmetric on left and right.

     So, as a start, I switched to half line support. As my cavity support will be rods placed perpendicular to the refcav, the simulation might not be off by much. Then I checked the displacement at the center of the mirrors. The result was, the further to the ends of the spacer, the less displacement of the mirrors. I think this is strange. I also remember a paper about this and their cavity dimension is similar to what we have, and their result is slightly away from the ends [ref]. I'll have to double check the result again.

Note: I think what is wrong is how I use the displacement of the mirrors along the beamline as differential length of the cavity, I have not taken into account tilting of the mirrors yet. Also, I'll try to position the venting hole downward to see if there is any differences in the result or not.

I'm still working on COMSOL, now my model has the following features:

• support points are simulated by four rectangles on the spacer surface. The support areas can be changed, and their positions can be moved along the beamline and around the cross section directions. I'm still not sure what should be the effective area for the simulation. However, the paper from Milo's group [2009] showed that the areas of the supports points do not affect the optimum position that much (but the support must be constrained in the same direction as gravity only). I have not tried to constrained the points in only one direction yet.
• I used a symmetry plane to model only half of the spacer. This will reduce some simulation time and avoid any asymmetry due to the mesh size.
• I'm trying to use matlab with comsol and print out the result. The work is stil in progress.

Note:

Milo etal. 2009 Phys Rev A 79.053829.

I used COMSOL with MATLAB to run the simulation. I tried to vary support position and checked the mirror displacement along the beam line axis and tilt angle.

With Aidan help, I am finally able to run matlab with comsol to get the results (displacement of the mirror surface and tilt).

 We are not planning to cut the cavities for support points, so we will choose the support positions on the spacer's surface, with parameter X and theta, see the figure below for their definitions.

As a start, I chose theta = 30 and 60 degree. The displacement and tilt (due to cavity sagging under its weight at 1g)as a function of support position are plotted below.

It is possible to minimize the tllt, but the displacement is still a bit bad. The result from 8" spacer, the sensitivity to acceleration is ^(dL/L) / _(m/s^2) = 2x10^-10, while the current result will be about  1x10^-10. Since the cavity is shorten by ~ a factor 4, I expect a better sensitivity to vibration.

==next==

I'll try to change the area of the support points to check its effect on the displacment.

I have to check if I can constrain the support points in one direction or not.

I ran a few more simulations to see how support area would affect the displacement. It turned out that it was not significant, for area = 0.056 x 10^-3, 0.9 x 10^-3 and 5.6 x 10^-3 [inch²]. This is good because we don't have to worry too much about the effective area of the contact points in the simulation. The errors will probably be dominated by other parameters (mostly, support positions). Judging from all the requirements, I think I'm close to making the decision for the support position.

     The plot below shows results from different support angles, (theta = [30,45,60]).

==a few comments about the plot==

• The area of the support points are not significant in the simulation, see green, red, cyan plots.
• For the support angle, it seems that the smaller theta, the less sensitivity to vertical acceleration (blue ,pink, green). However, smaller angle means the support area becomes more vertical. This will cause two issues that I can think of, (1) more force on the spacer which will increase the surface loss, (2) a bit harder to machine the mount. About the loss, I think it is still ok if the normal force from the support to the spacer is less than a factor of 5. This gives us the smallest angle of ~ 12degree, but at this angle, the optimum support point for zero tilt will be very close to the ends of the 1.45" spacer (based on the blue ,pink, green curve) and it will be unsafe to mount the cavities in case they slide out of the supports.

            I think possible choices (considering loss, machining, safety) for the support positions will be some where around 0.7-1.2 inch along the beam line, and the angle will be ~ 12 - 30 degree. I'll run more simulation to see if I can find it.

==Note==

1. I reproduced the result for 8" cavity with wire support and got the same result as before (dL/L)/(acceleration) ~ 2 x 10^-10 (1.7x10^-10, to be more exact), but the tilt is 9x10^-9 rad which is a lot larger than the results from the short cavity. So I think my simulation for short cavity is fine as I can reproduce the same result.
2. I tried to constrained the support area in vertical direction only, but the simulation failed. I think this is because of the bending of the spacer surface. If you let it slide horizontally, the surface will tilt a bit as well and cannot be kept fix in vertical direction. Then for the constrain in all directions, I don't think there will be a solution for zero coupling for the short cavity.

 After checking displacement and tilt of the mirrors from various support points, the tentative support positions will be 1.2"  and 30 degree, (see entry 1060 for their definitions). I'll check the sensitivity along other directions (horizontal), and see if the noise budget will be acceptable or not.

After running more simulations, I got the cavity's length sensitivity due to vertical acceleration. The angle varied between 12 to 45 degree. And the nice point seems to be 30 degree at 1.2".  I will check the length and tilt sensitivity on horizontal acceleration, and compute the noise budget to make sure that seismic noise will be acceptable. After that I'll finish the drawing for the cavity mount.

Note: I just realized that I should have used strain/acceleration unit in the displacement plot. I'll fix that later.

I checked the cavity length sensitivity to horizontal acceleration ( normal to the beam line axis). Unlike the result from vertical acceleration, the cavity length did not change smoothly with the position.  For the optimum point(30 degree, 1.18 inch apart), the displacement sensitivity due to horizontal acceleration is about a factor of 2 larger than that of vertical acceleration.

 Since both horizontal(H) and vertical(V) seismic noise on the table are comparable [psl:xxx], I want to make sure that there will be no serious displacement noise due to acceleration on vertical direciton.

On the COMSOL model, I fixed only one side of the support to push against horizontal acceleration (see pic). As the support can only push against the cavity, not pull. It should make more sense to use this boundary condition.

For the effect from H acceleration, I varied the angle from 12 to 42 degree, and distance from 0.8 to 1.2 inch. The displacement did not change smoothly with the support positions. So I could not tell which way I should choose for the optimum support. However, the displacement seems to be around 2x10^-10 inch for most of the positions. [the unit on the y axis of the plot should be inch per acceleration].

For the optimum support (1.18 Inch, 30 degree) the senstivity is about 1x10^-10 inch/ (m/s^2).

As Rana and Jan suggested, I thought about the effect of mirror's radius of curvature and DC tilt effect to cavity length noise. I ran a few simulation tests and the results were not changing much.

==cavity length noise==

The cavity length mainly changes from two effect

1) Actual position change:

2) Tilting of the mirror: If both mirrors tilt up or down together by theta, the cavity length will be longer by R*theta^2, see the attached picture. The calculation takes mirror's ROC and optical axis shifting into account.

   So, to find the best place to support the cavity, the contribution from both effects should be minimize.

==COMSOL Simulation: effects from different boundary conditions==

We have been discussing about different boundary conditions for support points whether to use fixed in all direction, fixed in only vertical direction, point support, or finite area. So I decided to check the effect from the following condition

•  Point like support, fixed in all direction
•  Point like support, fixed only in vertical direction
• Area support, fixed in all direction  (The size of the area does not change the result that much, see PSL:1061. This time I chose 1mm^2 which is 1.5x10^-3 [in^2].)

 ==result==

    There are no significant differences among the chosen boundary conditions. I varied the angle from 30, 45 and 60 degree, all the boundary conditions resulted in the same sagging behavior, so the best choice will be 30 degree as discussed in PSL:xx .The plot below shows the displacement per [m/s^2] of the mirror center along the beam line and tilt angle per [m/s^2] of the mirror, (the support angle is 30degree). With any boundary conditions, the optimum position will be quite the same (30 degree,  1.2" apart).

==where is the optimum spot? what is the coupling from seismic to cavity length?==

 From the simulation, with our restriction on support position (angle between 30 to 60 degree, 0.5 - 1.2" apart), the mirror positions always extend the cavity length. Since tilt will always increase the cavity length, we cannot cancel the effect between translation and tilt. The best way is to minimize translation and choose zero tilt as before.

About the coupling, at the optimum spot where tilting is zero, there will be no tilting motion. Displacement noise will only come from translation of the mirrors.

I looked into the model a bit more to make sure that I included all the effects and get the coupling right [more to come]

fig1: displacement(beam line direction) per unit acceleration on the mirror surface. X-axis represents the position on the mirror along vertical line. Each plot represents result from different support positions. For optimum point (1.17"), the sensitivity to vertical seismic is around 2.1x10^-12 m/(m/s^2).

fig2: This plot shows the result as in fig1, with the means removed. Typically we want the tangent line at the center to be zero for minimum tilt.

1. Now I use SI units in the simulation.
2. The surface displacement along vertical direction is ~ 5 x10^-10 m. The spot radius is 100 um, so the effect from translation along vertical direction is negligible. We can assume that the beam still hits and senses the center of the mirror.
3. Check the result between support length between 1.18" +/- 0.02" (+/- 0.5 mm). This tolerence is what I estimate to be our assembly tolerence.
4. I calculated the tilt by using the tangent line at the displacement on the vertical line in the mirror center. Note that my mirror surface in the simulation is flat instead of curve. At 100 um away from the center, the surface height will change by ~ 10^-8 m due to the mirror's RoC. Meanwhile, the result from simulation (flat surface) shows that the displacement around 100 um away will change ~ 10^-12 m. However, I don't think it will effect our model much, since most of the deformation occurs around the support point, not the mirror. It means all the tilting comes from deformation on the spacer, not the mirror. So the simulation for flat mirror should be a good approximation.

 I'm trying to estimate the coupling between seismic to displacement noise of the cavity using COMSOL. 

From the design, the strain due to the seismic noise is about 2e-11.  But we want to see what happen if the support positions are moved away from the specified points a bit. This time the model is a whole cavity, not just 1/8 as I did before. This is to see results of the mis-positioned support points. However, COMSOL has some problems

• The solution for the full sized cavity is not symmetric even with the optimum support points. I think this is because the mesh size is not physically symmetric, but the result gets better (the sagging becomes more symmetric) when the mesh size is smaller. However, the calculation time is quite long (~3.5 minutes for each run).
•  I cannot adjust the angle, I can only adjust the beam line position. I'm not sure why COMSOL has this problem. It is not a syntax problem. I ran the iteration and it gave me two results , then the error message poped out. So I only changed the support positions along the beam line direction 
• The random I used is white, where the error is +/- 0.5 mm. I could not use Gaussian, because sometimes the support positions were out of the spacer. I think It should be fine for now to see how the result will be

Right now I have ~30 data points after 4 hrs of running the simulation. I'll get a bit more data and will see how it goes when I histogram it.

I tried to estimate the coupling from seismic to displacement noise. With the common mode rejection taken into account, the coupling from vertical acceleration to differential length between the two cavities is about 6x10^-12.

• With random errors add in the position (+/- 1mm) of the support position, I used COMSOL to find out the coupling from acceleration to strain noise to a single cavity. Note that I did not use Gaussian distribution because sometimes the support position will be place away from the cavity. so I used random error with confined limit to +/- 1mm.
• Then I histogram it. The result is shown in the figure below.

• Take some common mode rejection into account. Since most of the time, the coupling will fall between 0.98 x10^-10 to 1.04 x10^-10  [s^2/m].  We can assume an upperbound that one cavity has the coupling of 1.04x10^-10 and another has 0.98x10^-10. Thus, the effective coupling for the differential strain is (1.04-0.98)x10^-10 = 6x10^-12. 
• I have to admit that the result is very weird. With the ideal support position, the coupling for a single cavity is also about 6x10^-12. I did not expect that by changing the positions slightly, the coupling for each cavity can be worse by 200 times. I suspect that COMSOL might add some errors as well, see psl:1056. The cavity does not bend down symmetrically, even with the perfectly symmetric support position, but I did not think it will be this huge.

We finished the first comsol model which where we can modify the geometry automatically. The problem with comsol is that you can't export geometry data in a useful format, only binary which you can't modify. So the only way to have an adjustable geometry model is to use matlab code, and only call the comsol fem solver. A problem with matlab is that the documentation for the comsol interfacing is bad close to not existent. So e.g. if you create an object you don't know how to access the individual subdomains because you don't know anything about the numbering scheme. Here the solution was to create the geometry, import that from the matlab workspace into comsol, then use the comsol gui to create the subdomains and boundary conditions, export the stuff into a matlab file (whic you can't re-open in comsol), and copy all the information about the indexing and material property declaration back into the matlab file. Here is an example how the boundary condition syntax looks like:

bnd.Hy = {0,1};
bnd.Hz = {0,1};
bnd.ind = [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,1,2,1,1,1,1,1,1,1,1,1, 1,1,2,1,2,1,1,1,1,1,1,1,1,1,1,1,1,1];

So without the gui you can't identify the right index for the surfaces you wanna fix. But once you have done this and all the material declaration in the matlab file you can use the object created with matlab and use all the boundary conditions created with comsol and combine that. At the end the simple model for the basic cavity is 750 (!) lines of code.

Now you can do changes to the geometry within matlab as long as the indexing does not change, which is not the case for us if we move the grooves a little bit.

As we can't run a model with a good mesh on our computers (not enough memory) we tried to start comsol on menkar. Unfortunately the comsol installation does not support the integration into matlab, so you can't start matlab with the comsol functions (or better you can't run comsol which then also starts matlab and configures it in the way that you can call the comsol functions within matlab. So we can't do a good simulation and parameter sweep right now until we fix this. Jan has the same problem on his computer.

First plots will be provided tomorrow....

the documents we have in the PSL lab about the connection made in the PSL rack cross-connect panel are not consistent with the current wiring.
A couple of channels are labeled to be connected to the VMIC3123 card (16bit) , but are connected to the VMIC3113A card (12bit).
One of these channels is  PSL-FSS_RCTRANSPD. I will reconfigure some of those channels.
Documentation will be provided in the elog and changes marked in the existing, printed version of cross-connect panel document.

cleaned the conical springs Rana bought. Will characterize and try them tomorrow

- personal notes -

current cross-connect connections

------------  PMC --------------

C3:PSL-PMC_RFPDDC:
block TB4
1 - LO
2 - HI
connected to J3-3113A, 1/2 (CH32)

-------------

C3:PSL-PMC_PMCERR:
block TB4
3 - LO
4 - HI
connected to J3-3113A,  5/6 (CH34)

-------------

C3:PSL-PMC_PMCTRANSPD:
connected to J4-3123  5/17 (CH2)
5 - LO  /  17 - HI

------------  RCAV --------------

C3:PSL-FSS_RFPDDC:
block TB2
1 - LO
2 - HI
connected to J2-3113A  43/44 (CH21)

-------------

C3:PSL-FSS_RCTRANSPD:
connected to J4-3123  2/14 (CH0)
2 - LO  /  14 - HI

-------------

C3:PSL-FSS_MIXERM
block TB2
5 - LO
6 - HI
connected to J2-3113A  53/54 (CH26)

------------  ACAV --------------

C3:PSL-ACAV_RFPDDC:
block TB2
3 - LO
4 - HI
connected to J2-3113A  47/48 (CH23)

-------------

C3:PSL-ACAV_RCTRANSPD:
connected to J4-3123  16/3 (CH1)
16 - LO  /  3 - HI

------------  TEST --------------

C3:PSL-TEST_SHORT:
connected to J4-3123  25/12 (CH7)
25 - LO  /  12 - HI

workers finished the piping stuff for today but have to come back to connect it to the stuff one floor above. It's not the sprinkler stuff, it's heating water.
So some other guys will show up in the future to drill holes for the sprinkler pipes and installation of the sprinklers.

turned the laser back on

tapped a few #2-56 holes in the top of the copper tube which will be used as a radiative shield and heater for the cavities. The holes are needed to fix the heating wire (AWG32, NiCr80, 11.3Ohms/ft, w/Heavy ML Enamel,  0.0080" Diameter). Polished and cleaned the tube ready for in-vacuum use (not baked, does not fit in chamber). Teflon pieces and screws for mounting the thing got cleaned and are currently vacuum-baked at 80degC over night.
Here a list of thoughts/facts:

• Wire resistance is about pi*2.5in/12*11.3 = 7.4Ohms/turn.
• The total heating power for the chamber to bring it from RT to 35degC is about 7W.
• I would like to drive the heater directly with an low-noise opamp to not have to build a low-noise, high power driver
• Using standard opamps the maximum voltage will be somewhere around 12V.
• Assuming 1W of power for each heater is more than plenty we need to go for 20 turns.
• 20 turns would get us 148 Ohms, so maximum current @12V would be 80mA
• LT1028/1128 can only drive 25mA, AD797 can directly drive 50mA
• 50mA and 20 turns would allow (only) 370mW of heating
• if we go to 25 turns we will have 185Ohms, giving us 465mW of heating power using 50mA @9.25V
• The whole shield is 10 inches long (the cavity is 8 inches). 
• A uniform distribution is different as the shield has two cut-outs for the cavity supports.
• The frequency difference of both cavities at 35C is ~160MHz
• tuning factor for the cavity is ~155MHz/K (or 6.4mK/MHz)
• required temp difference will be 1K if we use both AOMs
• 1K temp gradient requires 22 mW heating power for polished copper cylinder in polished SS cylinder (no conductivity assumed, is wrong but have to measure contact area between PTFE mounts and top stack plate)
• conductive PTFE pieces are 0.188" thick, assuming an touching area of 0.5"x0.125" this results in a conductive heat transfer of 2.2mW per mount, so a total of 6.6mW for all three mounts
• --> total heat transfer assuming 1K temperature difference : ~30 mW

picture shows one of the shields with some copper wire for test-wrapping

We had a problem with power coupling efficiency to the PMC.  Sometime it changes from 80% to 40% or less.

When the temperature of the NPRO is varied by a voltage calibrator @ slow actuator input of the laser controller,

at certain T(V), the coupling efficiency drops from 80% to 40% or less. This might be mode hopping.  However, the transmitted beam power still oscillates ,

and one can see the beam spot pulsating on the screen. I thought it might be mode hopping too, but after changing T, the fluctuation of the power has not gone, there is some suppression though. So it might be the servo. I'll check the TF of the servo and compare it with the schematic, D980352-B-1.

restarted it

 Both crate crashes around 17:20 today. I reset them back.

After we use the perl scripts for PID thermal control on RCAV and ACAV, the crates crash more often.

I'll see how long it can run this time.

for fb2 from outside is

131.215.114.84

The current plot for PMC's OLG TF is plotted below. The RF V is 6V, Gain slider is 14 dB.

The UGF is 820 Hz with phase margin (PM) = 180 - 53 = 127 degree.

At higher gain slider setup, the system starts to oscillate. One possible cause is the peak near 10^4 Hz which

might be the PZT's resonance frequency.

Without the notch the total gain we can increase will be limited by the peak.

I'll make a notch to damp it down.

The current spec will be ~20dB notch at 12.5 kHz, FWHM ~1kHz

From current setup, the optical TF should be + 16.5 dB flat, and the gain added by the gain slider is +14 dB.

previous setup we have opt TF = -5 dB and +30 dB from gain slider.

So we have improved the overall gain by ~5 dB and to UGF increased from 530 to 830 Hz.

analyzed the data taken yesterday with the old TTFSS setup. Measured the EP noise (out1, common path, right after the mixer) and converted into frequency noise using an average number of the error signal slope of ~1MHz/V (which by the way is pretty bad).  Plot of electronic noise (demodulated PD signal) shows a noise level of ~20nV/rtHz, not super good but possible. With terminated input (~7nV/rtHz) it is slightly above the noise floor of the analyzer (6nV/rtHz)  which means it's about 4nV/rtHz which is OK.

If we compare the projected noise with the coating thermal noise we see that we are not able to measure anything useful with the current scheme. We need to gain about a factor of 10 to 20 more sensitivity. I suggest we switch to a resonant EOM to increase the modulation index and move to a lower frequency at the same time to increase the sensitivity of our RF PDs (old or new). This might also help us later when we need to stabilize the EOM temperature to minimize the RF-AM. HV-modulation might actually cause RF-AM which we are not able to cancel with our feedback from RF-AM sensing to EOM temp or DC actuator. We should check if we can use existing equipment like a 14.75MHz EOM we have or we can switch to the 21.5MHz which we used before. Switching can be done within one afternoon, two at most.

We've moved on today towards a real TTFSS. Tara made the power cables and we quickly measured the noise of the EP of the new setup. Almost all harmonics are gone. Only tiny pickup of line harmonics is visible. Will make plots later.

 As Frank proposed to use side band frequency at 21.5 or 14.75 MHz, I checked the HOM of both frequencies.

See more details about HOM from psl:106

Fig 1: HOM from 21.5 MHz sideband.  At 17th HOM the frequency difference between the sideband and the HOM is ~2MHz, which is much bigger than the cavity's linewidth.

Fig2: HOM from 14.75 MHz sideband. The difference between 10th HOM and the resonant frequency is 2.2 MHz, which is much bigger than the cavity linewidth (~75 kHz).

It is unlikely that one of the HOMs will resonate inside the cavity if the frequency difference is much larger than the cavity linewidth. So, there is no apparent overlap  we have to worry about for both frequencies.

Thu Jan 12 10:53:29 2012: The code for HOM is on svn.

Today I measured beat noise again to see where we are after adjusting many parameters.

The beat measurements are plotted below for 100 kHz and 10 kHz input range.

For 100kHz input range (grey), we are limited by LO phase noise. The shape of the phase noise has changed

from previous data in pink.

For 10 kHz input range (red), something else is the limiting source. I'm checking if we are limited by RFPD noise or not, but

the result is not conclusive yet.

I also measured the noise at the error point for ACAV loop (loop closed) in green, then projected it on the nb

by multiplying by the slope of the error signal (0.252 MHz/V = cavity's FWHM / error signal pkpk value = 108 kHz / 428 mVpk-pk.)

The level of the noise match the beat around 30Hz to 1kHz, but diverges at higher frequency.

Not quite sure if it makes sense or not (PLL loop is valid upto ~  3kHz.)

The input referred noise of RFPD and the PDH box is measured, by blocking the beam on the RFPD

and measuring the singal on PDH out.  The data is divided by the TF of the PDH box ( I measured this while the loop is closed,)

and multiplied by the error signal's slope, then plotted in blue.

The result is not quite right. It's higher than the beat. I'll have to check this.

*ACAV gain is set to 1.5 for all measurements.

RCAV common gain is set to 22.0 dB

power to each cavity = 1 mW

   Temperature on both cavities are fairly constant over -8 hrs, still can't simultaneously lock both cavities.                        

                              ACAV                      RCAV

XXX_SETPT          37.3                       35.0

XXX_TEMPAVG        37.301                 34.997

SLOWDC              -0.11645 (VCOMON center @ 0),    -0.1114

XXX_HEATER      4.72971              (FSS)1.49154

Since everything is stable now, I'll lock RCAV and adjust ACAV temperature to lock them together withing AOM range.

I'll change ACAV_SETPT from 37.3->37.4, to see how SLOWDC has to change to lock ACAV.

Wed Sep 01 21:04:24 2010

After 6 hrs, ACAV_TEMPAVG is stable around 37.4 C.

SLOWDC for ACAV is -0.1200 (VCOMON center @ 0)

 This means For ACAV, dV(slow dc) per dT(ACAV) = (0.1203-0.11645)/0.1 = 0.039 V/K.

Since RCAV is locked when SLOWDC = -0.1114, we have to decrease the temperature from 37.4 C by (0.1203 - 0.1114)/0.039 = 0.2282 K.

That is 37.4 - 0.2282 = 37.1718.

Now I set ACAV_SETPT to 37.2 C.

- personal notes -

slow actuator values

RCAV : 0.1924
ACAV : 0.2043

(.1924 V - .2043V) * 1180 MHz/V =  14 MHz difference

personal notes to lock system remotely:

for PMC:
PMC voltage 203.5V --> DC offset -3.258
slow DC value : 0.15
PMC transmission value: 0.291V

I've been working on our new ws1 all day today, trying to get it back to where ws3 was.  I got git working, recreated our python virtual environment, and got apache2 going again.  However, the last step is actually getting beatnote data off cymac3 and plotting it.  Unfortunately, I'm getting gigantic spikes from the cymac3 and I'm not sure why.

I opened a fresh ipython session and ran the following:
from gwpy.time import tconvert
import nds2
from pylab import *
ion()
c2 = nds2.connection('cymac3.ligo.caltech.edu', 8088)
backTime = 300 # 5 mins of time
chanName = 'X3:TST-BEAT_OUT_DQ'
data = c2.fetch(tconvert('now').gpsSeconds - 60 - backTime, tconvert('now').gpsSeconds - backTime, [chanName]) # read data from 5 minutes ago.
plot(data[0].data)

If I do this, I get the plot posted below.
I did a test for our three other channels for the accelerometers, and they all exhibit similar spikiness.
(chanNames = ['X3:TST-ACC_X_OUT_DQ', 'X3:TST-ACC_Y_OUT_DQ', 'X3:TST-ACC_Z_OUT_DQ'])

Unclear what's wrong with cymac3.  I'm worried this is happening for all its channels, but I'm not sure and don't want to mess with another lab's ADC.

The real time model X3TST was not running. I likely forgot to restart it after the power outage of a week ago. 

I restarted and now I can see a sinusoid in the data:

from gwpy.time import tconvert
import nds2
from pylab import *
ion()
c2 = nds2.connection('cymac3.ligo.caltech.edu', 8088)
backTime = 10 
chanName = 'X3:TST-BEAT_OUT_DQ'
gps = tconvert('now').gpsSeconds
data = c2.fetch(gps-backTime*2, gps-backTime, [chanName])
x = data[0].data
plot(x)

I recommend Craig write a script called whatsupDAQ.py. It could be run whenever to collate some DAQ status indicators and report what's up. Something like the CDS overview MEDM screen, but command line.

replaced the hard drive, created an new ext3 file system and mounted it as /frames/full. After forced fsck for the other drives computer is back online. Daqd is working in principle, but  it crashes after a minute or so.

Most often error message:   [Thu Dec  8 20:30:41 2011] failed to rename file; errno 2

Error message changes from time to time: [Thu Dec  8 20:09:45 2011] framer(): failed to rename file; errno 2

I don't know which file and why does the error message change?. Have to contact Alex...

checked the source code for the daqd. There is only one line where one of the messages occurs. Couldn't find the part of the source code for the second error message

/* Write out a frame */
        int nwritten = write (fd, ost -> str (), image_size);
        if (nwritten == image_size) {
          if (rename(_tmpf, tmpf)) {
            system_log(1, "failed to rename file; errno %d", errno);
            fsd.report_lost_frame ();
            set_fault ();
          } else {
            DEBUG(3, cerr << "frame " << frame_cntr << "(" << frame_number << ") is written out" << endl);
            // Successful frame write
            fsd.update_dir (gps, gps_n, frame_file_length_seconds, dir_num);
          }
        } else {
          system_log(1, "failed to write full frame out; errno %d", errno);
          fsd.report_lost_frame ();
          set_fault ();
        }
        close (fd);
        TNF_PROBE_0(daqc_c_framer_frame_write_end, "daqd_c::framer", "frame write");

looks like the daqd has problems writing the frames to disk. Standard Error #  2: No such file or directory

daqd crashed on 12/2/2011 around 9.12am without log entry. Last file : controls controls  57833 Dec  2 09:12 C-R-1006881152-32.gwf.
Can't restart. Log file stays empty. Disks are not full.

Talked to Alex about the daqd and it's strange behavior on our machine.

1. The first thing is that the daqd did not show up as a process even it was running. According to Alex this happens because we only write about 100 EPICS channels so they cpu load is so small that it does not show up all the time so you can easily miss it. The safest way to find out if it's running is to try to telnet into it on port 8087 and check the status.
2. We have the following error message in our log file (since a long time ago):
   A call to "assert (pE == &entry)" failed in ../../cds/project/daq/fb2/exServer.h line 346
   EPICS Release EPICS R3.14.10- $R3-14-10-RC2$ $2008/10/10 15:01:51$.
   E-mail this message to the author or to tech-talk@aps.anl.gov
   Calling epicsThreadSuspendSelf()
   This happens because it's trying to start an epics ioc using a wrong version of the epics library. We tried different version but couldn't fix it. Looks like the easiest solution would be to re-compile the daqd.
3. Error message: failed to rename file; errno 2
   This means it can't rename the current frame file it is writing to which can have several reasons. Most often it does not have the rights to do so and a second option is that if the daqd is already running but invisible and you try to start (another) one there is no exception catching for that case and those two processes create a conflict because they try to create/write to the same file.
4. If you want to grab data using the dataviewer you get the following message even if data exists
   read(); errno=9
   read(); errno=9
   T0= some time and length of data
   No data output
   Unknown problem. Even the data exists and can be grabbed using different command line tools to directly access the frames the dataviewer does not get data. A second weird behavior is that if you request let's say 60 seconds it request 120 seconds. Should not be like that but that's a dataviewer problem.

restarted the framebuilder process. Channel list needs to be updated, i didn't clean up the FSS channels so there are still old/unused channel names.

Current list of saved channels.

106 channels total
105 trend channels

chnum   slow    |name                           |rate   |trend  |group  |bps    |bytes  |offset |type   |active
0       0       C3:PSL-BOX_SENS1                                16      1       0       4       64      0       4       1
0       0       C3:PSL-BOX_SENS2                                16      1       0       4       64      64      4       1
0       0       C3:PSL-BOX_SENS3                                16      1       0       4       64      128     4       1
0       0       C3:PSL-BOX_SENS4                                16      1       0       4       64      192     4       1
0       0       C3:PSL-BOX_TEMPAVG                              16      1       0       4       64      256     4       1
0       0       C3:PSL-BOX_HEATER                               16      1       0       4       64      320     4       1
0       0       C3:PSL-BOX_SETPT                                16      1       0       4       64      384     4       1
0       0       C3:PSL-BOX_KP                                   16      1       0       4       64      448     4       1
0       0       C3:PSL-BOX_KI                                   16      1       0       4       64      512     4       1
0       0       C3:PSL-BOX_KD                                   16      1       0       4       64      576     4       1
0       0       C3:PSL-BOX_ENABLE                               16      1       0       4       64      640     4       1
0       0       C3:PSL-BOX_TIMEOUT                              16      1       0       4       64      704     4       1
0       0       C3:PSL-BOX_SCALE                                16      1       0       4       64      768     4       1
0       0       C3:PSL-ACAV_RFPDDC                              16      1       0       4       64      832     4       1
0       0       C3:PSL-ACAV_RCTRANSPD                           16      1       0       4       64      896     4       1
0       0       C3:PSL-ACAV_LOCKEDLEVEL                         16      1       0       4       64      960     4       1
0       0       C3:PSL-RCAV_SENS1                               16      1       0       4       64      1024    4       1
0       0       C3:PSL-RCAV_SENS2                               16      1       0       4       64      1088    4       1
0       0       C3:PSL-RCAV_SENS3                               16      1       0       4       64      1152    4       1
0       0       C3:PSL-RCAV_SENS4                               16      1       0       4       64      1216    4       1
0       0       C3:PSL-RCAV_TEMP                                16      1       0       4       64      1280    4       1
0       0       C3:PSL-RCAV_TEMPAVG                             16      1       0       4       64      1344    4       1
0       0       C3:PSL-RCAV_S1CAL                               16      1       0       4       64      1408    4       1
0       0       C3:PSL-RCAV_S2CAL                               16      1       0       4       64      1472    4       1
0       0       C3:PSL-RCAV_S3CAL                               16      1       0       4       64      1536    4       1
0       0       C3:PSL-RCAV_S4CAL                               16      1       0       4       64      1600    4       1
0       0       C3:PSL-RCAV_SETPT                               16      1       0       4       64      1664    4       1
0       0       C3:PSL-RCAV_KP                                  16      1       0       4       64      1728    4       1
0       0       C3:PSL-RCAV_KI                                  16      1       0       4       64      1792    4       1
0       0       C3:PSL-RCAV_KD                                  16      1       0       4       64      1856    4       1
0       0       C3:PSL-RCAV_ENABLE                              16      1       0       4       64      1920    4       1
0       0       C3:PSL-RCAV_TIMEOUT                             16      1       0       4       64      1984    4       1
0       0       C3:PSL-RCAV_SCALE                               16      1       0       4       64      2048    4       1
0       0       C3:PSL-RCAV_RFPDDC                              16      1       0       4       64      2112    4       1
0       0       C3:PSL-RCAV_RCTRANSPD                           16      1       0       4       64      2176    4       1
0       0       C3:PSL-RCAV_LOCKEDLEVEL                         16      1       0       4       64      2240    4       1
0       0       C3:PSL-FSS_HEATER                               16      1       0       4       64      2304    4       1
0       0       C3:PSL-FSS_FREQCOUNT                            16      1       0       4       64      2368    4       1
0       0       C3:PSL-FSS_VCOMON                               16      1       0       4       64      2432    4       1
0       0       C3:PSL-FSS_VCOMON_CAL                           16      1       0       4       64      2496    4       1
0       0       C3:PSL-FSS_VCOFREQ                              16      1       0       4       64      2560    4       1
0       0       C3:PSL-FSS_RFPDDC                               16      1       0       4       64      2624    4       1
0       0       C3:PSL-FSS_LODET                                16      1       0       4       64      2688    4       1
0       0       C3:PSL-FSS_PCDET                                16      1       0       4       64      2752    4       1
0       0       C3:PSL-FSS_FAST                                 16      1       0       4       64      2816    4       1
0       0       C3:PSL-FSS_PCDRIVE                              16      1       0       4       64      2880    4       1
0       0       C3:PSL-FSS_RCTLL                                16      1       0       4       64      2944    4       1
0       0       C3:PSL-FSS_VCODET                               16      1       0       4       64      3008    4       1
0       0       C3:PSL-FSS_TIDALOUT                             16      1       0       4       64      3072    4       1
0       0       C3:PSL-FSS_MODET                                16      1       0       4       64      3136    4       1
0       0       C3:PSL-FSS_VCODETPWR                            16      1       0       4       64      3200    4       1
0       0       C3:PSL-FSS_MIXERM                               16      1       0       4       64      3264    4       1
0       0       C3:PSL-FSS_SLOWM                                16      1       0       4       64      3328    4       1
0       0       C3:PSL-FSS_VCOM                                 16      1       0       4       64      3392    4       1
0       0       C3:PSL-FSS_TIDALINPUT                           16      1       0       4       64      3456    4       1
0       0       C3:PSL-FSS_SW1                                  16      1       0       4       64      3520    4       1
0       0       C3:PSL-FSS_SW2                                  16      1       0       4       64      3584    4       1
0       0       C3:PSL-FSS_PHFLIP                               16      1       0       4       64      3648    4       1
0       0       C3:PSL-FSS_VCOTESTSW                            16      1       0       4       64      3712    4       1
0       0       C3:PSL-FSS_VCOWIDESW                            16      1       0       4       64      3776    4       1
0       0       C3:PSL-FSS_INOFFSET                             16      1       0       4       64      3840    4       1
0       0       C3:PSL-FSS_MGAIN                                16      1       0       4       64      3904    4       1
0       0       C3:PSL-FSS_FASTGAIN                             16      1       0       4       64      3968    4       1
0       0       C3:PSL-FSS_PHCON                                16      1       0       4       64      4032    4       1
0       0       C3:PSL-FSS_RFADJ                                16      1       0       4       64      4096    4       1
0       0       C3:PSL-FSS_SLOWDC                               16      1       0       4       64      4160    4       1
0       0       C3:PSL-FSS_VCOPWR                               16      1       0       4       64      4224    4       1
0       0       C3:PSL-FSS_VCOMODLEVEL                          16      1       0       4       64      4288    4       1
0       0       C3:PSL-FSS_TIDALSET                             16      1       0       4       64      4352    4       1
0       0       C3:PSL-FSS_LOCK                                 16      1       0       4       64      4416    4       1
0       0       C3:PSL-FSS_SLOWLOOP                             16      1       0       4       64      4480    4       1
0       0       C3:PSL-PMC_PMCTLL                               16      1       0       4       64      4544    4       1
0       0       C3:PSL-PMC_RFPDDC                               16      1       0       4       64      4608    4       1
0       0       C3:PSL-PMC_LODET                                16      1       0       4       64      4672    4       1
0       0       C3:PSL-PMC_PMCTRANSPD                           16      1       0       4       64      4736    4       1
0       0       C3:PSL-PMC_PCDRIVE                              16      1       0       4       64      4800    4       1
0       0       C3:PSL-PMC_PZT                                  16      1       0       4       64      4864    4       1
0       0       C3:PSL-PMC_MODET                                16      1       0       4       64      4928    4       1
0       0       C3:PSL-PMC_PMCERR                               16      1       0       4       64      4992    4       1
0       0       C3:PSL-PMC_SW1                                  16      1       0       4       64      5056    4       1
0       0       C3:PSL-PMC_SW2                                  16      1       0       4       64      5120    4       1
0       0       C3:PSL-PMC_PHFLIP                               16      1       0       4       64      5184    4       1
0       0       C3:PSL-PMC_BLANK                                16      1       0       4       64      5248    4       1
0       0       C3:PSL-PMC_GAIN                                 16      1       0       4       64      5312    4       1
0       0       C3:PSL-PMC_INOFFSET                             16      1       0       4       64      5376    4       1
0       0       C3:PSL-PMC_PHCON                                16      1       0       4       64      5440    4       1
0       0       C3:PSL-PMC_RFADJ                                16      1       0       4       64      5504    4       1
0       0       C3:PSL-PMC_RAMP                                 16      1       0       4       64      5568    4       1
0       0       C3:PSL-PMC_LOCK                                 16      1       0       4       64      5632    4       1
0       0       C3:PSL-PEM_RMTEMP                               16      1       0       4       64      5696    4       1
0       0       C3:PSL-PEM_BOXTEMP                              16      1       0       4       64      5760    4       1
0       0       C3:PSL-FSS_RFAM_RCAV                            16      1       0       4       64      5824    4       1
0       0       C3:PSL-FSS_RFAM_ACAV                            16      1       0       4       64      5888    4       1
0       0       C3:PSL-FSS_EOM_TSET                             16      1       0       4       64      5952    4       1
0       0       C3:PSL-FSS_EOM_TACT                             16      1       0       4       64      6016    4       1
0       0       C3:PSL-FSS_EOM_IMON                             16      1       0       4       64      6080    4       1
0       0       C3:PSL-FSS_EOM_SETTEMP                          16      1       0       4       64      6144    4       1
0       0       C3:PSL-GEN_DAQ1                                 16      1       0       4       64      6208    4       1
0       0       C3:PSL-GEN_DAQ2                                 16      1       0       4       64      6272    4       1
0       0       C3:PSL-GEN_DAQ3                                 16      1       0       4       64      6336    4       1
0       0       C3:PSL-GEN_DAQ4                                 16      1       0       4       64      6400    4       1
0       0       C3:PSL-GEN_DAQ5                                 16      1       0       4       64      6464    4       1
0       0       C3:PSL-GEN_DAQ6                                 16      1       0       4       64      6528    4       1
0       0       C3:PSL-GEN_DAQ7                                 16      1       0       4       64      6592    4       1
0       0       C3:PSL-GEN_DAQ8                                 16      1       0       4       64      6656    4       1
10001   0       C3:FB1-FB_DUMMY                                 16384   0       0       4       65536   6720    4       0

Yesterday, I reset the PSL crate behind the SUN computer, but the channel C3:PSL-ACAV_TEMPAVG is stil inactive.

looks like some fault of the database. /usr1/epics/psl/db/acav.db does not contain the correct entry. check rcav.db and copy the record for "C3:PSL-RCAV_TEMPAVG" into acav.db. Then simply change "RCAV" into "ACAV" everywhere for this record. Also change the setpoint for the ACAV in the startup.cmd file to 37.3 and the ACAV-heater value to 4.653. Those are the latest values when both where locked for several hours. Reset the crate again.

 Will do in a moment, I'm taking data from ACAV for now just to compare with yesterday results.

made the changes a minute ago. simply reboot after changing the values in the startup.cmd (those i didn't change)

be carefull with the data you are taking right now. it's wrong for your projection as the power fluctuations are different when locking only the ACAV using the AOM. The largest contributor might be the pointing from the AOM itself, which is different if the laser isn't locked to the other cavityat the same time.

Why don't you use the new fast channels you have hooked up last week? And don't forget to change the names of those :-)

 I didn't disabled the loop when I measured it, and yeah it looks bad. I think I'll just try to lock both cavities for now.

I'll connect the signals from PDs behind Rcav and Acav to the new fast channels(32k).

About changing the channels' names, I asked DMASS to help and he suggested to use them as they are for now because of the risk of screwing the system up from a typo.

From the bode plot, something is not quite right. I'll debug the PMC servo. My plan is

1) Measure the TF from FP1 test to FP4 (output mon), change gain setting and see if the TF change as expected.

 *note the real TF is 20log (Vpzt/ Vin) but Vpzt ~ 50 Vmon.  Vmon is connected to Vpzt with divider circuit. To get the real TF, 20log(Vpzt/Vin), the magnitude from out TF between FP1 and out mon will be added by 20log50 = 34 dB.

2) Compare it with the calculated TF from PMC schematic 

made another step from 26.6degC to 30.6degC (4 Kelvin). Checked beat frequency to be ~72.192MHz @26.6degC, so we can re-use the iLIGO VCO when operating at high enough temperatures.

The initial step of 100mK was only a test to see if everything works. Local temp fluctuations have still a lot of influence to the precision of the reading, so the following numbers are rough estimates. The larger step will hopefully result in a better value.
The Marconi feedback signal changed by ~1.2V with a tuning coeff. of ~284kHz/V, so this gave a change of 341kHz total, so about 3.41MHz/K.

The original sensitivity can be estimated as

a_SiO2 = 5.5e-7  , L_spacer = 203.2mm  -> dL_spacer = 111.76nm/K

with FSR = 738MHz

-> df = 155MHz/K

started 3 days ago. first entry on

Dec  4 04:17:14 fb2 smartd[3490]: Device: /dev/sdc, 589 Currently unreadable (pending) sectors
Dec  4 04:17:14 fb2 smartd[3490]: Device: /dev/sdc, 553 Offline uncorrectable sectors

disk is up, but read only, causing daqd to crash. Will replace disk tomorrow. will keep old disk but not copy full data to new disk. trend data is on separate disk and working fine so far.

I finished soldering together the other two channels for temperature control. This is what the board looks like now:

Front

Back

I began troubleshooting the new channels. The second channel (top right) is tentatively working up until the buffer stage, but showed some strange behaviors. When it is working up to the buffer stage, adding the buffer stage drive the output of each stage (and all of the corresponding inputs) to about +12V. When the buffer stage is removed, everything remains at +12V, but this is sometimes fixable by toggling the power, and consistently fixable by just pulling out the OP27 chips and putting them back in. As far as I can tell, everything is powered correctly, and nothing is shorting or disconnected where it shouldn't be. 

For the third channel (bottom right), only the AD620 stage is working. Adding the next stage causes both the outputs and the inputs to go to +12V as well. The connections here also seem correct as far as I can tell. I'm thinking it's possibly related to the problems in the 2nd channel, maybe there's some buildup of charge, or other hysteresis, somewhere, that is messing things up. The observed behavior of this third channel is consistent enough that it may just be a connection error somewhere. The inconsistent behavior of the second channel, though, suggests that it probably has to do with something transient.

Will continue troubleshooting when I get back.

Please don't use red WIMA (or any film) capacitors for power line bypassing (decoupling). These are for audio frequency signal filtering.

Use high-K cetamic caps (~100nF) for bypassing. They should be placed as close to the chips as possible.

In addition, 100uF electrolytic caps should be added to the regulators to prevent regulator oscillations.
 

Useful links:
https://en.wikipedia.org/wiki/Decoupling_capacitor
http://www.analog.com/media/en/training-seminars/tutorials/MT-101.pdf

We seem to be lacking in ceramic caps of this size or larger, same with electrolytics.  We may need a restock at some stage.

40m is the emergency stock for WB Labs, vice versa.

So after testing out the LT1012 op amp in many simple configurations and not having any of them work (and the measurements were the same whether they were powered or not), I decided to dig around for another op amp chip, which did work, so I think all 4 of LT1012 chips that I got from the 40m stock are just faulty (not sure what that means for the rest of the chips there).

After swapping out chips, the circuit worked functionally. Just from playing around with the function generator and oscilloscope, it looks like the gain is 0.5 around 20Hz (should be dropping off faster), but I'll try to get an actual frequency response measurement next time.

Also, the legs on the capacitors are really short and I'm not sure they're all actually making contact, so I'll probably extend them with some wire to be sure, but that might also be part of it.

I realized that we have not checked the eigenmodes of 1.45" cavity yet, so I used comsol to find out several modes. The lowest mode is ~ 46kHz, and the first longitudinal mode is about 60kHz. The frequencies are high enough so that the thermal noise calculation in dc- 10kHz frequency band can be done with quasi-static assumption.

1) I tried a simple cylindrical shape, with the dimension of the spacer. The result for the first longitudinal mode is 74KHz, the analytical result is ~ 77kHz, see PSL:1135. It seems that COMSOL's result and the analytical results are comparable.

2) Then I simulated the whole reference cavity. The lowest body mode is ~ 47kHz. The body expand-contract radially, and should not change the cavity beamline length that much. The first longitudinal mode is ~ 60kHz. The color on the surface shows the rms displacement from all direction.