40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 244 of 346 Not logged in
ID Date Author Type Category Subject
8023   Thu Feb 7 14:10:25 2013 ManasaUpdateOpticsLaserOptik - AR Reflectivity - Bad data

Reflectivity of AR surface of LaserOptik (SN6)

The first step measurements of R for AR surface. I am not convinced with the data....because the power meter is a lame detector for this measurement.

I'm repeating the measurements again with PDs. But below is the log R plot for AR surface.

R percentage

6000ppm @ 42 deg
3560ppm @ 44 deg
7880ppm @ 46 deg
4690ppm @ 48 deg

8045   Fri Feb 8 21:14:52 2013 ManasaUpdateOpticsG&H - AR Reflectivity

Hours of struggle and still no data

I tried to measure the AR reflectivity and the loss due to flipping of G&H mirrors

With almost no wedge angle, separating the AR reflected beam from the HR reflected beam seems to need more tricks.

The separation between the 2 reflected rays is expected 0.8mm. After using a lens along the incident beam, this distance was still not enough to be separable by an iris.

The first trick: I could find a prism and tried to refract the beams at the edge of the prism...but the edges weren't that sharp to separate the beams (Infact I thought an axicon would do the job better..but I think we don't have any of those).

Next from the bag of tricks: I installed a camera to see if the spots can actually be resolved.

The camera image shows the 2 sets of focal spots; bright set to the left corresponding to HR reflected beam and the other from the AR surface. I expect the ghost images to arise from the 15 arcsec wedge of the mirror. I tried to mask one of the sets using a razor blade to see if I can separate them and get some data using a PD. But, it so turns out that even the blade edge is not sharp enough to separate them.

If there are any more intelligent ideas...go ahead and suggest!

8046   Fri Feb 8 22:49:31 2013 KojiUpdateOpticsG&H - AR Reflectivity

How about to measure the AR reflectivity at larger (but small) angles the extrapolate the function to smaller angle,
or estimate an upper limit?

The spot separation is

D = 2 d Tan(\phi) Cos(\theta), where \phi = ArcSin(Sin(\theta) * n)

D = 2 d Tan(\phi) Cos(\theta), where \phi = ArcSin(Sin(\theta) / n)         (<== correction by Manasa's entry)

\theta is the angle of incidence. For a small \theta, D is propotional to \theta.

So If you double the incident angle, the beam separation will be doubled,
while the reflectivity is an even function of the incident angle (i.e. the lowest order is quadratic).

I am not sure until how much larger angle you can use the quadratic function rather than a quartic function.
But thinking about the difficulty you have, it might be worth to try.

8047   Fri Feb 8 23:04:40 2013 ManasaUpdateOpticsG&H - AR Reflectivity

 Quote: D = 2 d Tan(\phi) Cos(\theta), where \phi = ArcSin(Sin(\theta) * n) \theta is the angle of incidence. For a small \theta, D is propotional to \theta.

n1Sin(\theta1) = n2 Sin(\theta2)

So it should be

\phi = ArcSin(Sin(\theta) / n

I did check the reflected images for larger angles of incidence, about 20 deg and visibly (on the IR card) I did not see much change in the separation. But I will check it with the camera again to confirm on that.

8051   Sat Feb 9 19:34:34 2013 ranaUpdateOpticsG&H - AR Reflectivity

Use the trick I suggested:

Focus the beam so that the beam size at the detector is smaller than the beam separation. Use math to calculate the beam size and choose the lens size and position. You should be able to achieve a waist size of < 0.1 mm for the reflected beam.

8060   Mon Feb 11 17:54:02 2013 KojiSummaryOpticsCurvature radii of the G&H/LaserOptik mirrors

I, by chance, found  that my windows partition has Vision32 installed.
So I run my usual curvature characterization for the TT phasemaps.

They are found under this link
https://nodus.ligo.caltech.edu:30889/40m_phasemap/40m_TT/（requires: LVC credentials)
or
/cvs/cds/caltech/users/public_html/40m_phasemap/40m_TT

asc/ (ascii files) --> .asc files are saved in Wyko ascii format.
bmp/ (screen shots of Vision32)
mat/ (Matlab scripts and results)
opd/ (Raw binary files)

Mirror / RoC from Vision32 / RoC from KA's matlab code
G&H "A" 0864 / -527.5 m / -505.2 m
G&H "B" 0884 / -710.2 m / -683.6 m
LaserOptik SN1 / -688.0 m / -652.7 m
LaserOptik SN2 / -605.2 m / -572.6 m
LaserOptik SN3 / -656.7 m / -635.0 m
LaserOptik SN4 / -607.5 m / -574.6 m
LaserOptik SN5 / -624.8 m / -594.3 m
LaserOptik SN6 / -658.5 m / -630.2 m

The aperture for the RoC in Vision32 seems a bit larger than the one I have used in the code (10mm in dia.)
This could be the cause of the systematic difference of the RoCs between these, as most of our mirrors
has weaker convex curvature for larger aperture, as seen in the figure. (i.e. outer area is more concave
after the subtration of the curvature)

I did not see any structure like Newton's ring which was observed from the data converted with SXMimage. Why???

Attachment 1: TT_Mirrors_RoC.pdf
8063   Mon Feb 11 19:55:47 2013 ManasaUpdateOpticsG&H - AR Reflectivity

I adjusted the focal length of the focusing lens and reduced the beam size enough to mask with the razor blade edge while looking at the camera and then making measurements using PD.

I am still not satisfied with this data because the R of the HR surface measured after flipping seems totally unbelievable (at around 0.45).

G&H AR reflectivity

R percentage

11 ppm @4 deg
19.8 ppm @6 deg
20 ppm @ 8 deg
30 ppm @ 20 deg

8069   Tue Feb 12 18:28:46 2013 JamieSummaryOpticsCurvature radii of the G&H/LaserOptik mirrors

 Quote: I, by chance, found  that my windows partition has Vision32 installed. So I run my usual curvature characterization for the TT phasemaps.

Is it possible to calculate astigmatism with your tools?  Can we get curvature in X/Y direction, preferably aligned with some axis that we might align to in the vacuum?

8075   Wed Feb 13 09:28:56 2013 SteveUpdateOpticsG&H - HR plots

Gooch & Housego optics order specification from 03-13-2010

Side 1: HR Reflectivity >99.99 % at 1064 nm for 0-45 degrees for S & P polarization

Side 2: AR coat R <0.15

The HR coating scans uploaded to 40mwiki / Aux optics today

8316   Wed Mar 20 14:44:47 2013 JamieUpdateOpticsupdated calculations of PRC/SRC g-factors and ARM mode matching

Below are new alamode calculations of the PRC and SRC g-factors and arm mode matchings.  These include fixes to the ABCD matrices for the flipped folding mirrors that properly (hopefully) take into account the focusing effect of passing through the optic substrates.

I've used nominal curvatures of -600 m for the G&H PR2/SR2 optics, and -700 m for the Laseroptik PR3/SR3 dichroics.

An interesting and slightly disappointing note is that it looks like it actually would have been better to flip PR3 instead of PR2, although the difference isn't too big.  We should considering flipping SR3 instead or SR2 when dealing with the SRC.  I'll take responsibility for messing up the calculation for the flipped TTs.

### PRC

 PR2 Reff PR3 Reff PRC g-factor (t/s) ARM mode matching Inf Inf .94/.94 .999 -600 -700 .99/.98 .84 413 (flipped) -700 .94/.93 .999 -600 409 (flipped) .92/.94 .999 413 (flipped) 409 (flipped) .87/.89 .97

### SRC

 SR2 Reff SR3 Reff SRC g-factor (t/s) ARM mode matching Inf Inf .96/.96 .999 -600 -700 NA NA 413 (flipped) -700 .96/.95 .998 -600 391 (flipped) .94/.96 .996 413 (flipped) 391 (flipped) .90/.92 .96

RXA: maybe nominal, but we don't actually have measurements of the installed optics' curvatures, so there could be ~10-15% errors in the RoC. Which translates into a 1-2% error in the g-factor.

8339   Mon Mar 25 16:51:59 2013 JenneUpdateOpticsupdated calculations of PRC/SRC g-factors and ARM mode matching

I think we like the idea of flipping SR2 better than SR3 for the same ghost beam reasons as PR2 is better than PR3.  There isn't very much free space in the BS chamber, and if we flip PR/SR3, we have to deal with green ghosts as well as IR.

The flipping SR2 case seems okay to me - flipping either one of the SR folding mirrors gives us a slightly better g-factor than the design with infinite curvatures, and flipping SR2 gives us slightly better mode matching to the arm than the flipped SR3 case, but more importantly, there are fewer ghosts to deal with.  I vote we flip SR2, not SR3.

8352   Tue Mar 26 11:33:55 2013 JamieUpdateOpticsHOWTO calculate effective RoC of flipped TT

In case anyone is curious how I got the numbers for the effective radius of curvature of the flipped TT mirrors, I include the code below.  Now you can calculate at home!

Here's the calculation for the effective RoC of a flipped SR2 with nominal un-flipped HR RoC of -600:

>> [Mt, Ms] = TTflipped(600, 5);
>> M2Reff('t', Mt, 5)

ans =

412.9652

>>



Attachment 1: mirror.m
function [Mt, Ms] = mirror(R, a1, n)
% [Mt, Ms] = mirror(R, a1, n)

if length(R) > 1
Rt = R(1);
Rs = R(2);
else
Rt = R;
Rs = R;
end

... 9 more lines ...
Attachment 2: transmission.m
function [Mt, Ms] = transmission(R, a1, n1, n2)
% [Mt, Ms] = transmission(R, a1, n1, n2)

if length(R) > 1
Rt = R(1);
Rs = R(2);
else
Rt = R;
Rs = R;
end

... 19 more lines ...
Attachment 3: TTflipped.m
function [Mt, Ms] = TTflipped(R, a1)
% [Mt, Ms] = TTflipped(R, a1)

if length(R) > 1
Rt = R(1);
Rs = R(2);
else
Rt = R;
Rs = R;
end

... 32 more lines ...
Attachment 4: M2Reff.m
function Reff = M2Reff(type, M, a)
% Reff = M2Reff('type', M, a)

n = 1;

R = -2*n/M(2,1);

ca = cos(a*pi/180);

switch lower(type)

... 8 more lines ...
13450   Wed Nov 22 17:52:25 2017 gautamUpdateOptimal ControlVisualizing cost functions

I've attempted to visualize the various components of the cost function in the way I've defined it for the current iteration of the Oplev optimal control loop design code. For each term in the cost function, the way the cost is computed depends on the ratio of the abscissa value to some threshold value (set by hand for now) - if this ratio is >1, the cost is the logarithm of the ratio, whereas if the ratio is <1, the cost is the square of the ratio. Continuity is enforced at the point at which this transition happens. I've plotted the cost function for some of the terms entering the code right now - indicated in dashed red lines are the approximate value of each of these costs for our current Oplev loop - the weights were chosen so that each of the costs were O(10) for the current controller, and the idea was that the optimizer could drive these down to hopefully O(1), but I've not yet gotten that to happen.

Based on the meeting yesterday, some possible ideas:

1. For minimizing the control noise injection - we know the transfer function from the Oplev control signal coupling to MICH from measurements, and we also have a model for the seismic noise. So one term could be a weighted integral of (coupling - seismic) - the weight can give more importance to f>30Hz, and even more importance to f>100Hz. Right now, I don't have any suc frequency dependant requirement on the control signal.
2. Try a simpler problem first - pendulum local damping. The position damping controller for example has fewer roots in the complex plane. Although it too has some B/R notches, which account for 16 complex roots, and hence, 32 parameters, so maybe this isn't really a simpler problem?
3. How do we pick the number of excess poles compared to zeros in the overall transfer function? The OL loop low-pass filters are elliptic filters, which achieve the fastest transition between the passband and stopband, but for the Oplev loop roll-off, perhaps its better to have a just have some poles to roll off the HF response?
Attachment 1: globalCosts.pdf
13497   Tue Jan 2 16:37:26 2018 gautamUpdateOptimal ControlOplev loop tuning

I've made various changes to the optimal loop design approach, but am still not having much success. A summary of changes made:

1. Parametrization of filter - enforcing uniqueness
• Previously, the input to the particle swarm was a vector of root frequencies and associated Q-factors.
• This way of parametrization is not unique - permuting the order of the roots yield the same filter, but particles traversing the high (65) dimensional parameter space may have to go over very expensive regions in order to converge with the global minimum / best performing particle.
• One way around this is to parametrize the filter by the highest pole/zero frequency, and then specifying the remaining roots by the cumulative separation from this highest root. This guarantees that a unique vector input to the particle swarm function specifies a unique filter.
• To avoid negative frequencies, I manually set a particular element of the vector to 0 if the cumulative sum yields a negative frequency. I believe this is how MATLAB's particle swarm implements the "constraints" in the constrained optimization routines.
2. Cost function - I've reformulated this into something that makes more sense to me, but probably can be improved further.
• Term #1 - integral of the area (evaluated with MATLAB's trapz utility) between the in-loop (i.e. suppressed) error signal and the sensing noise spectrum (for the latter, I use the orange curve from this plot). This is a signed number, so that suppression below the sensing noise is penalized. Target value is 1 urad rtHz. One problem I see with this approach is that if we believe the sensing noise measurement, then even at 10mHz, it looks like sensing noise is below the out-of-loop error signal level. So the optimizer doesn't seem to want to make the loop AC coupled.
• Term #2 - stability margin. I'm using this number, which is the distance-of-closest-approach to the point -1 in the Nyquist plot, instead of gain and phase margins, as this yields a more conservative robustness measure. Target value is 0.65.
• Term #3 - A2L contribution of in-loop control signal. This contribution is calculated using measurements of A2L coupling for the DRMI. The actual term that goes into the cost function is the ratio of the area under the in-loop control signal to that under the seismic noise curve above 35Hz. Further, f>100Hz is given 10x the weight of 35Hz<f<100Hz (I've not really played around with this weighting function). The goal is to be as close to the seismic curve as possible, at which point this term becomes 1.
• Terms #4 and #5 - the maximum open loop gain evaluated in a 1Hz wide bin centered around the bounce and roll resonances. The aim is to not exceed -40dB in these bins. Perhaps this needs to be reformulated, as the optimizer seems to be giving this term too much importance - the optimized loops have extremely deep bandstops around the BR resonances.
• To normalize each term, I divide by the "target" value mentioned above, so as to make the various terms comparable.
• Each term in the cost function has two regimes - one where it is rapidly varying close to the desired operating point, and one far away where the cost still increases monotonically, but slower (see Attachment #2).
• A scalar cost function is evaluated by taking a weighted sum of the above terms. The weights are chosen so as to make each term ~10 for the controller currently implemented.
• All of the above are only applicable if the resulting loop is stable - else, a large cost is assigned (exponential of sum of real parts of poles of OLTF).

Attachment #1 shows the outcome of a typical optimization run - so while I am having some more success with this than before, where the PSO algorithm was stalling and terminating before any actual optimization was done, it seems like I need to re-think the cost function yet again...

Attachment #2 shows the current terms entering the cost function, and their "desired" values.

The current version of the code I am using is here: although I may not have inculded some of the data files required to run it, to be fixed...

Attachment 1: loopOpt_180102_1706.pdf
Attachment 2: globalCosts.pdf
13498   Wed Jan 3 12:33:16 2018 ranaUpdateOptimal ControlOplev loop tuning

When putting code into git.ligo.org, one way to have automated testing is to use the Gitlab CI. This is an automated 'checker', much like the 'Travis' system used in GitHub. Essentially, you give it a make files which it runs somewhere and your GIT repo web page gets a little 'failed/passing' badge telling you if its working. You can also browse the logs to see in detail what happened. This avoids the 'but it works on my computer!' thing that we usually hear.

 Quote: The current version of the code I am using is here: although I may not have inculded some of the data files required to run it, to be fixed...

13500   Wed Jan 3 16:25:32 2018 awadeUpdateOptimal ControlOplev loop tuning

Another cool feature is client side pre-commit hooks. They can be used to run checks on the local version at the time of commit and refuses to push until the pass/fail exits 0.

Can be the same as the Gitlab CI or just basic code quality checks.  I use them to prevent jupyter notebooks being commited with uncleared cells. It needs to be set up on the user's computer manually and is not automatically cloned with the directory: a script can be included in the repo to do this and run manually on first time clone.

 Quote: When putting code into git.ligo.org, one way to have automated testing is to use the Gitlab CI. This is an automated 'checker', much like the 'Travis' system used in GitHub. Essentially, you give it a make files which it runs somewhere and your GIT repo web page gets a little 'failed/passing' badge telling you if its working. You can also browse the logs to see in detail what happened. This avoids the 'but it works on my computer!' thing that we usually hear.

13520   Tue Jan 9 21:57:29 2018 gautamUpdateOptimal ControlOplev loop tuning

After some more tweaking, I feel like I may be getting closer to a cost-function definition that works.

• The main change I made was to effectively separate the BR-bandstop filter poles/zeros and the rest of the poles and zeros.
• So now the input vector is still a list of highest pole frequency followed by frequency separations, but I can specify much tighter frequency bounds for the roots of the part of the transfer function corresponding to the Bounce/Roll bandstops.
• This in turn considerably reduces the swarming area - at the moment, half of the roots are for the notches, and in the (f0,Q) basis, I see no reason for the bounds on f0 to be wider than [10,30]Hz.

Some things to figure out:

1. How the "force" the loop to be AC coupled without explicitly requiring it to be so? What should the AC coupling frequency be? From the (admittedly cursory) sensing noise measurement, it would seem that the Oplev error signal is above sensing noise even at frequencies as low as 10mHz.
2. In general, the loops seem to do well in reducing sensing noise injection - but they seem to do this at the expense of the loop gain at ~1Hz, which is not what we want.
• I am going to try and run the optimizer with an excess of poles relative to zeros
• Currently, n(Poles) = n(Zeros), and this is the condition required for elliptic low pass filters, which achieve fast transition between the passband and stopband - but we could just as well use a less rapid, but more monotonic roll-off. So the gain at 50Hz might be higher, but at 200Hz, we could perhaps do better with this approach.
3. The loop shape between 10 and 30Hz that the optimizer outputs seems a but weird to me - it doesn't really quite converge to a bandstop. Need to figure that out.
Attachment 1: loopOpt_180108_2232.pdf
17192   Sat Oct 15 17:22:56 2022 ChrisUpdateOptimal ControlIMC alignment controller testing

We conducted a test of three alternative controllers for the IMC pitch DOFs on Friday. These were loaded into a new RTS model c1sbr, which runs on the c1ioo front end as a user-space program at 256 Hz. It communicates with the c1ioo controller via shared memory IPCs to exchange error and control signals.

The IMC maintained lock during the handoffs, and we were able to take one minute of data for each (circa GPS 1349807926, 1349808426, 1349808751; spectra attached), which we can review to assess the performance vs the baseline. (On the first trial, lock was lost at the end when the script tried to switch back to the baseline controller, because we did not take care to clear the integrators. On subsequent trials we did that part by hand.)

The method of setting up this test was convoluted, but now that we see it working, we can start putting in the merge requests to get the changes better integrated into the system. First, modifications were required to the realtime code generator, to get controllers running at the new sample rate of 256 Hz. (This was done in a separate filesystem image on fb1, /diskless/root.buster256, which is only loaded by c1ioo, so as to isolate the changes from the other front end machines.) The generated code then needed hand-edits to insert additional header files and linker options, so that the alternative controllers could be loaded from .so shared libraries. Also, the kernel parameters had to be set as described here, to allow the user-space controller to have a CPU core all to itself. Finally, isolating the core was done following the recipe in this script (skipping the parts related to docker, since we didn’t use it).

Attachment 1: 180.png
Attachment 2: 066.png
Attachment 3: 202.png
17198   Tue Oct 18 20:43:38 2022 AnchalUpdateOptimal ControlIMC open loop noise monitor

WFS loops were running for past 2 hours when I made the overall gain slider zero at:

PDT: 2022-10-18 20:42:53.505256 PDT
UTC: 2022-10-19 03:42:53.505256 UTC
GPS: 1350186191.505256

The output values are fixed to a good alignment. IMC transmission is about 14100 counts right now. I'll turn on the loop tomorrow morning. Data from tonight can be used for monitoing open loop noise.

17199   Wed Oct 19 09:48:49 2022 AnchalUpdateOptimal ControlIMC open loop noise monitor

Turning WFS loops back on at:

PDT: 2022-10-19 09:48:16.956979 PDT
UTC: 2022-10-19 16:48:16.956979 UTC
GPS: 1350233314.956979

17314   Sun Nov 27 15:30:22 2022 ChrisUpdateOptimal ControlIMC alignment controller testing

Five more mode cleaner alignment controllers were tested this morning (remotely). These were designed to run in tandem with the standard controller, instead of supplanting it. Before the test, c1ioo was burt restored back to the settings of the previous test on Oct 28, and in MC TRANS PIT/YAW filter banks the 80 dB gain filters were disengaged and outputs were enabled. Subsequently, all settings were returned to the original values. Each test consisted of five minutes with pitch alignment uncontrolled, five minutes with the standard controller only, and twenty minutes with both controllers enabled. GPS times for each phase of testing are the following:

• musgo
• OL start 1353602764
• CL start 1353603074
• policy start 1353603410
• musgo_ghost
• OL start 1353604697
• CL start 1353605007
• policy start 1353605355
• musgo_stumble
• OL start 1353606574
• CL start 1353606884
• policy start 1353607229
• musgo_goldfish
• OL start 1353608446
• CL start 1353608756
• policy start 1353609099
• musgo_late
• OL start 1353610321
• CL start 1353610631
• policy start 1353610971
17333   Sun Dec 4 10:03:02 2022 ChrisUpdateOptimal ControlIMC alignment controller testing

Another five mode cleaner alignment controllers were tested last night (remotely), running in tandem with the standard controller. As before, c1ioo was burt restored to Oct 28 and the MC TRANS PIT/YAW 80dB gain filters were disabled before the test. Each test consisted of five minutes with pitch alignment uncontrolled, five minutes with the standard controller only, and twenty minutes with both controllers enabled.

The first four tests went smoothly, but the last controller (goldfish_short) repeatedly broke the lock. Eventually I got it running with an output gain of 0.5, strong enough to see the misbehavior without unlocking the mode cleaner.

GPS times for each phase of testing were the following:

1. ichabod
• Open loop 1354165556
• Closed loop 1354165866
• Policy 1354166241
1. ichabod_2
• Open loop 1354167462
• Closed loop 1354167772
• Policy 1354168113
1. ichabod_3
• Open loop 1354169357
• Closed loop 1354169667
• Policy 1354170006
1. goldfish_long
• Open loop 1354171297
• Closed loop 1354171607
• Policy 1354172022
1. goldfish_short
• Open loop 1354173255
• Closed loop 1354173565
• Policy 1354173924 (output gain 1.0, immediately unlocked the cavity)
• Policy 1354175008 (output gain 0.1, 2 min)
• Policy 1354175189 (output gain 0.3, 2 min)
• Policy 1354175376 (output gain 0.5, 20 min)
17371   Wed Dec 21 12:38:32 2022 ChrisUpdateOptimal ControlIMC alignment controller testing

Three additional mode cleaner alignment controllers were tested Sunday night (remotely). They were run in tandem with the (recently improved) standard controller. Each test consisted of five minutes with pitch alignment uncontrolled, five minutes with the standard controller only, and twenty minutes with both controllers enabled.

GPS times for each phase of testing were the following:

1. slug_functional
• Open loop 1355466269
• Closed loop 1355466579
• Policy 1355466987
2. slug_hippocamp
• Open loop 1355468210
• Closed loop 1355468520
• Policy 1355468849
3. slug_hippocamp_slow
• Open loop 1355470093
• Closed loop 1355470403
• Policy 1355470855
17   Fri Oct 26 09:10:17 2007 steveRoutinePEMPEM &PSL trend
The fires are out, lab particle counts are up.
Psl HEPAs are at 100% and mobel HEPAs are just turned on
20 days plot and 5 hrs plot below
Attachment 1: counts&psl.jpg
Attachment 2: 5dcounts.jpg
83   Thu Nov 8 11:40:21 2007 steveUpdatePEMparticle counts are up
I turned up the psl HEPA filter to 100%
This 4 days plot shows why
Attachment 1: pslhepaon.jpg
114   Mon Nov 19 14:19:25 2007 steveOmnistructurePEMjackhammer
The construction personal successfully jackhemmered a fence around the "Drever's parking slot"
There is no parking space available close by
Attachment 1: jackhammer.jpg
Attachment 2: jackhammer2.jpg
151   Fri Nov 30 20:17:26 2007 AndreyConfigurationPEMAccelerometers and alum.plates for them
All 6 accelerometers which were located near the ITMX are turned off and disconnected from the power cords.
Actually these accelerometers are now in the office area on the electronics bench (to the left from Steve Vass' place).

I made today 4 new aluminum mounting plates for the accelerometers (I drilled holes and made threads in them). On Monday I will buy short screws and install accelerometers on these new mounting plates. These mounting plates will be screwed directly into the metallic frame which is firmly cemented to the ground. Before yesterday accelerometers were mounted on top of blue stack towers, not on the ground directly, so we hope that new measurements of the ground noise will be more realistic.

The 4 mounting plates are on the same desk -> on the electronics bench (to the left from Steve Vass' place). Please do not displace them.

Attached is a drawing of the aluminum mountain plate.
Attachment 1: Scheme_Aluminum_Piece-inches.pdf
152   Fri Nov 30 21:27:24 2007 ranaDAQPEMweather / stacis / c1pem1
I was trying to add some Seis BLRMS channels to the c1pem1 processor so that we could have DMT trends.

Then I found that none of the Weather channels have been working for a year or so. I could also not
telnet into it. I tried resetting it but no luck. There was no entry in the Wiki for it so I added
a place holder.

Have the weather channels ever worked? Do we have those sensors? I think I've never actually looked
for this. Seems like a fine ugrad job.
161   Mon Dec 3 19:44:58 2007 Accelerometers on new mountsConfigurationPEMAndrey

I (Andrey) continued today working with new accelerometer mounting. (see entry #151 about my Friday work).

I bought screws/washers and attached those mounts with accelerometers to metallic frames which are firmly cemented to the floor.

One such mount with three accelerometers (in X-, Y-, Z-directions) is installed near the ITMX (in the previous location, but NOT on top of the unused stack as before Friday), the other mount with three accelerometers in three orthogonal directions is installed near ETMX in the east end of the room (this set of accelerometers was installed between MC and BS before Friday). I uncoiled the cables, put them into the cable tray towards the ETMX, and hooked-up the three accelerometers near ETMX in the east end of the room.

Now all six accelerometers are hooked-up (that is, connected to power supply board with cables).

We decided with Steve Vass to put red cones (similar to those that are on highways in the road construction zones) in order to prevent people from bumping into accelerometers. Please use caution when walking along the X-arm.

I took several pictures of the new accelerometer setup. Picture "DSC_0194.JPG" shows the mount with accelerometers near the the ITMX and the beamsplitter chamber,
picture "DSC_0195.JPG" is the "zoomed-in" view of the same accelerometers, while picture "DSC_0196.JPG" shows the mount with accelerometers near ETMX in the east end of the room.

Many thanks to Mr. Steve Vass for his thorough explanation/showing me how to drill the metal and put threads in the holes.
Attachment 1: DSC_0194.JPG
Attachment 2: DSC_0195.JPG
Attachment 3: DSC_0196.JPG
172   Wed Dec 5 23:19:03 2007 AndreyConfigurationPEMAccelerometers are turned on

All accelerometers have been turned on, as Alan asked during Wednesday meeting.

Typical power spectra and coherence plots are attached below.

"East" in the name means that the previous location of accelerometrs was to the east from "Beamsplitter" (the location for "east" accelerometers was not changed, actually, it is still near ITMX), while "west" means that previously accelerometers were to the west from the BS, but now their new location is near the ETMX.

I will change the names of the channels tomorrow (Thursday) when someone (Tobin?) will show to me how to do it.

P.S. (addition made on Dec. 19th, 2007, by Andrey) I intended to change the names of accelerometers the next day, Thursday Dec. 06,
but I did not do it that day (did not understand how to do it), then I fell ill, and eventually
I changed the names of accelerometers on December 19th, see entry to ELOG #204)
Attachment 1: Power_Sp_and_Coh_XY-EAST.pdf
Attachment 2: Coherence-ZX_East.pdf
Attachment 3: Coherence-ZY_East.pdf
Attachment 4: Power_Sp_WEST.pdf
Attachment 5: Coherence-ZX_West.pdf
Attachment 6: Coherence-XY_West.pdf
Attachment 7: Coherence-YZ_West.pdf
189   Wed Dec 12 22:24:48 2007 tobinFrogsPEMweather station
I poked at the weather station briefly this evening.

* There's almost nothing in the elog about it.
* It exists. It is located on the North wall, just north of the beam splitter.
* It seems to be displaying reasonable data for the indoors, but nothing for the outdoor sensors.
* c1pem didn't seem to be starting up (couldn't telnet into it, etc). I altered its startup file and reset it several times, and eventually it came to life.
* the weather station has a serial cable that goes all the way to c1pem. I plugged it in.
* however, the Weather.st program complains "NO COMM"--it gets no data from the weather station
* The next thing to do is to plug in a laptop to that serial cable and see if the weather station can be convinced to talk.
200   Wed Dec 19 11:31:01 2007 steveOmnistructurePEMaircond filter maintenance
Jeff is working on all air condiontion units of the 40m lab
This we do every six months.
Attachment 1: acfilters6m.jpg
204   Wed Dec 19 20:28:27 2007 AndreyDAQPEMNames for all 6 accelerometers have been changed

I eventually changed the names for all 6 accelerometers (see my ELOG entry # 172 from Dec. 05 about my intent to do that).

I removed the word "BS" from their names,
and I changed the word combination "ACC_BS_EAST" in the old name for "ACC_ITMX" in the new name;
as well "ACC_BS_WEST" is now replaced by "ACC_ETMX".
(the reasoning behind such a change should become clear from my ELOG entry #172).

New accelerometer names are:
(note: there are no spaces (nowhere!) in the names of accelerometers, but ELOG replaces ": P" written without a space by a strange symbol )

C1 : PEM - ACC _ ETMX _ X ;
C1 : PEM - ACC _ ETMX _ Y ;
C1 : PEM - ACC _ ETMX _ Z ;
C1 : PEM - ACC _ ITMX _ X ;
C1 : PEM - ACC _ ITMX _ Y ;
C1 : PEM - ACC _ ITMX _ Z .

One can find them in "C1 : PEM - ACC" in Dataviewer.

255   Wed Jan 23 11:41:06 2008 steveUpdatePEMsulfur smell in 40m
Led - acid car batteries were overcharged in the machine shop next door
and sulfuric acid smell is coming over to the ifo room.

Entry room 103 is specially bad.
258   Thu Jan 24 11:52:56 2008 steveUpdatePEMthe mud is cleaned up & MOPA shutter is opened
Safety glasses are required again!

I have just opened the mopa shutter.
One janitor came to help with muddy floor.
Rack 1x1 toward ITMX chamber and the south wall of these area
were completely covered by mud. I wiped the floor of bottom of the rack
with towels. The cables were lifted and still should be wiped.

The bottom of LSC rack got less water, only on the west side.

We are ready to bring up the computers.

Thanks to ALL with the clean up, including Alan Rice

264   Fri Jan 25 09:22:21 2008 steveUpdatePEMburned toast award goes to
DYM for collaborating with the enemy.

In order to minimize the number of ants visiting our lab we have to take out side the lab
all food left over and organic waste. If you are eating here do not expect someone else
to clean up after you.

283   Mon Jan 28 19:35:55 2008 ranaSummaryPEMAccelerometer and Seismometer Coherences
The attached PDF shows that there is some strange behavior at low frequencies.

From the plot it looks like to me that the Wilcoxon accelerometers (which are supposed to have good response down to 0.05 Hz) are not displaying real seismic motion below 0.3 Hz. Because the coherence length for seismic waves at those frequencies should be 100's of meters we should expect that the accelerometers would have good coherence (>0.8) down there. Instead, my guess is that its all air currents, temperature, or electronics noise. These sensors are not reliable indicators for the microseism.

The Ranger seismometer, however, seems to work fine down to just below the microseism. The Ranger is mounted down around the X end and pointing in the z-direction. The coherence I plotted between it and EX_Z is larger than any other acc/seis pair (as expected).

JM and I discussed what could be done; if we get a SURF student who's into building stuff we can ask them to make a styrofoam hut for the Wilcoxons to see if that helps anything. JM also asked what the point of all this is.

IF we want to do good Adaptive Noise subtraction then we need sensors which can sense the motion which disturbs the mirrors and they need to sense it with a good SNR to get a good subtraction ratio. If the styrofoam thing doesn't work, we should probably look into getting a Guralp 3-axis seismometer for the corner area and just move the accelerometers down to the ends. The sites have Guralp CMG-40T units (~ 8k\$). I think we should check out the CMG-3T or the CMG-3ESP.

Does anyone know someone in the Geo depts that we can borrow one from?
Attachment 1: Acc.pdf
295   Sun Feb 3 05:02:41 2008 ranaUpdatePEMSeism 4 day
Attachment 1: Screenshot.png
298   Tue Feb 5 17:39:05 2008 jweinerConfigurationPEMPEM-AS_MIC taken down from AS table, will put in PSL enclosure soon
I took down the microphone that Andrey hung above the AS table his first week in lab. I want to hang the microphone above the PMC to check the effect of acoustic noise on the PMC. The cables were a little more tangled than I thought so I've only taken the microphone down and haven't hung it back up yet, but on Thursday I'll have enough time to carefully put it up inside the PSL and see what I can find out about acoustic noise inside the PSL. I think the microphone should be sensitive enough for the frequencies we're interested in, and I'll hopefully find out if it's sufficient once I put it up in the PSL. The microphone cable and microphone are on top of the PSL for now.
299   Wed Feb 6 09:17:31 2008 steveUpdatePEMIST building construction continoues
The bulldosers at work
Attachment 1: seismic8d.jpg
Attachment 2: seisioo.jpg
303   Fri Feb 8 17:55:53 2008 joshConfigurationPEMPEM-AS_MIC now in PSL enclosure
I have moved the microphone to the PSL enclosure, hanging near the south (Y) side from a support rod for the overhanging storage area so that it's reasonably close to the PMC. I've fastened it in many places using cable ties to make sure that it won't fall.

Alberto helped me solder together a female BNC-female 3.5 mm stereo adapter so that I can use the DAQ to output through BNC to PC speakers. My plan is do sweep sine output through PC speakers to find the transfer function of sound from outside the enclosure to inside the enclosure and by moving the microphone more centrally over the PSL table, check if there are any strong resonances. Hopefully I can use this technique at other places around the interferometer or measure the effect of installing acoustic foam.
308   Mon Feb 11 14:24:19 2008 steveUpdatePEMmore earthquakes
ITMX and ITMY sus damping restored after Baja earthquake 5.1 mag at 10:29 this morning.

The ground preparation for The ITS building is almost finished.
Activity is winding down, however the Baja California_ Mexico earthquake zone
"Guadala Victoria" started acting up on Friday.

Attachment 1: eqfeb11.jpg
324   Tue Feb 19 18:28:41 2008 JohnUpdatePEMMore seismic in Baja California
Steve spotted more activity from the same quake.

Reset watchdog on ETMY.
330   Fri Feb 22 02:51:20 2008 AndreyUpdatePEMAccelerometer ITMX seems to be broken

As people probably know,

I am trying (for a long time) to create a computational program that calculates the evolution of accelerometer time-domain data through stacks and pendulum transfer functions to test masses, and calculate the RMS of differential arm lenght spectrum.

I noticed on Tuesday that time-domain signals from the two accelerometers (one is near ETMX, the other one is near ITMX) seem to have different amplitudes of fluctuations around the mean value. I suspected that this is the main reason why I cannot get the awaited result of minimum of RMS for equal values of Q-factors for ETMX and ITMX suspensions (because we subtract two very different numbers, so we cannot get anything close to zero). I took amplitude spectra of the accelerometer data (dttfft2), and they look very differently for ETMX and ITMX accelerometers. I believe that spectrum of ETMX accelerometer represents seismic noise, but accelerometer ITMX seems to provide us with irrelevant and wrong data. No peaks, just almost monotoneous decreasing curve, and 10 times smaller amplitude. Therefore, ITMX seems to be broken.

I will try tomorrow to clap my hands, shout, yell, near the broken accelerometer to confirm that the accelerometer is broken (more precisely, that either accelerometer itself is broken,
or cable connections, or DAQ channel, but something is wrong). Now it is very late, and I am going home.

See attached figures: time-scale is 10^(-1), 10^0, 10^1, 10^2 Hz.
Attachment 1: Accelerom-EYMX-Feb22.jpg
Attachment 2: Accelerom-ITMX-Feb22.jpg
336   Fri Feb 22 15:16:33 2008 AndreyUpdatePEMITMX Accelerometer is NOT broken

As I wrote in message 330, there was a bad signal from ITMX accelerometer. I have found the reason: the BNC-cable which goes from the black board with switches for accelerometer gain (1,10,100) towards DAQ-tower was completely disconnected from that black board with gain-switches. The end of the long BNC-cable was on the floor. Therefore, it was totally impossible to see any accelerometer signal. The cable that I am writing about should transport the signal from ITMX_X accelerometer.

Now all the BNC-connections seem to be in good shape, and spectra of accelerometers near ITMX and ETMX , both of them are in x-directions, are very much similar.
Attachment 1: Accelerom-ITMX-Feb23.jpg
Attachment 2: Accelerom-ETMX-Feb23.jpg
363   Fri Mar 7 00:47:54 2008 ranaConfigurationPEMRanger SS-1
Yesterday evening around 7:30 PM, I changed the Ranger seismometer from a
vertical to a horizontal seismometer. To do this I followed the instructions
in the manual.
1) Lock it down.
2) Turn it sideways. Use the leveling screws to center the bubble level.
3) Carefully loosen the hanger rod and release slowly the tension to allow
the mass to recenter.
4) Look through the little viewhole next to the rod to make the white lines
line up. This means the mass is centered.
5) Look at the output on a scope. It should be freely moving with a ~1 sec.
period.

The attached plot shows the before and after spectra.
Attachment 1: ss1.pdf
368   Tue Mar 11 23:14:01 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
Steve and Matt moved the accelerometers and seismometers today.
The accelerometers are now placed around the MC and the seismometer is in-between MC1 & MC2.

We have changed the names of the acc channels to reflect whether they are close to MC1/MC3
or MC2. We tested the accelerometer to channel name mapping by switching gains at the wilcoxon
breakout box and also by tapping. It seems now that the previous setup near the ITMX/ETMX had
some few channels mislabeled which would have given some confusing results.

Alex, Jay, and Rolf came over today and installed, then de-installed some of the hardware for
sending the PEM channels over to the C1ASS machine where the adaptive filter front end will go.
Everything should be back to the way it was...hopefully, the guys will modify the ADCU PEM
code to send the signals to the new FE over the reflective memory net and then send them to the
MCL inputs of the suspensions. So the first incarnation should use the accelerometers and seismometer
to drive MC1 and/or MC3.
Attachment 1: Acc.pdf
369   Wed Mar 12 00:36:52 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
I used the MISO FIR Wiener matlab code to see how well we might do in principle.

The attached 3 page PDF file shows the MC_L control signal (force on MC2) and the residual
after subtracting off the accelerometer and seismometer using a 32 Hz sample rate and
512 taps (page 1), 1024 taps (page 2), and 2048 taps (page 3). As Matt smarmily points out,
there's not a lot to win by going beyond 512; maybe a factor of sqrt(2) for a factor of 4
tap number.
Attachment 1: finished.pdf
370   Wed Mar 12 00:40:35 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
Same as above but with 2048 taps and a 128 Hz sample rate. Does much better at the 16 Hz bounce mode.
Attachment 1: mc2048-128.pdf
371   Wed Mar 12 00:47:26 2008 ranaConfigurationPEMAccelerometer and Seismometer movements
And this is a cool snapshot showing how this operation used 16 cores on menkar !
Attachment 1: Screenshot.png
ELOG V3.1.3-