M4.7 - Santa Isabel, Mexico 2012-04-12 06:48:38 UTC

Mode Cleaner doesn't want to stay locked. Seismic is coming down from an earthquake ~20min ago.

We're in the process of measuring IPPOS, so this is obnoxious.

EDIT: Followed by a 6.2 and a 7.1 at 07:06UTC and 07:15UTC in the same area.

We're following the tried and true tradition of going home when there's an earthquake big enough that the MC won't stay locked.

Several optics have rung up, PRM is the only one which has tripped so far, because the side sensor has the extra gain, but the watchdog threshold is set for the face OSEMs.

Another histogram. This one allows the MMT mirror positions to move, the MMT incident angle for both curved optics to change, and the MC waist size and position to change. The error quoted for the MC waist size measurement from 2010

was +\- 0.01mm, and the MC waist position was +\- 28mm.

This histogram is showing that we're pretty sensitive to the MC waist measurement, which is used to define the beam. We can be up to ~2% off in our ideal mode matching to the arms if we're using the incorrect initial beam for the telescope design.

MMT code things to calculate, and what information it gives us:

REFL beam path, for PRM flipping comparison

Thick IPPO non-normal incidence - I'm not sure how to do this yet, since I only know how non-normal incidence changes effective radii of curvature, and this is a flat optic, so *cos(theta) or /cos(theta) won't do anything to an infinite RoC

Compare PRC waist to arm cavity waist, using "known" optic positions

Mode matching sensitivity to MC waist measurements

I don't know why, but they're looking around on the roof, and inside our ceiling above the bathrooms.

Bob tells me that the carpenter is going to move the nitrogen bottles to the other side of the outside door, so that the plumbers can install a safety shower / eyewash right outside our door.

Also, the carpenter just mounted a new glass door cabinet from Bob's lab in the IFO room, so we have some new storage space.

Over the next few days, I will be working on upgrading the aLIGO Conlog install to include new bugfixes distributed by Patrick T. The currently running conlog *should* not be affected, but please let me know if it is (ryan.fisher@ligo.org).

Now that Mike has got the Sensoray working, Jenne/Suresh should grab some new images of the ETM cage as Keiko did so that we can analyze them for another mode matching diagnostic.

I re-looked at the mode matching's sensitivity to misplaced optics. Here is the plot that the original MMT code from 2010 spits out:

What this plot is telling us is that we should lose no more than 0.1% of mode matching "goodness" if we messed up the curved optic's positions by up to 2 cm. If we can't place optics to within 2 cm, we might as well go back to optics kindergarten, because that's pretty lame.

UPDATE: Here is a histogram using the new code, which definitely includes the non-unity index of refraction for the transmissive optics and the Faraday. The only optics which are permitted to move are the 2 curved optics, and they are allowed a stdev of 20mm. Again, we shouldn't be doing worse than ~99% mode matching, even if we're 2cm off from the MMT positions that we measured with a ruler. This histogram only has 300 iterations, since it takes quite a while (~0.5sec) to calculate each iteration. Note this is mode overlap using the measured MC waist, propagated through optics, compared to the ideal arm mode. This is completely ignoring the IPPOS measurements so far.

UPDATE 2: Allowed 5 degrees of incident angle motion for both curved optics, which changes the astigmatism of the beam downstream. Still, no big change from ~99% mode matching efficiency. Again, this doesn't include any information from the IPPOS measurements. 3000 iterations this time around, since I didn't need my computer. Curved optics still allowed to move back and forth by 2cm.

More meditations and conclusions to follow... currently running hist code to allow tilt of optics, to account for astigmatism changes also.

Suresh and I are going to do some beam measurements tomorrow with the beamscanner, and then we will do a few measurements with the razor blade technique, to confirm that we're doing things okey dokey.

The highest resolution available is 720x480 pixels. Bit depth of captured images and video is most likely 16 bits per pixel. Video may be captured raw as well, which will be necessary for image subtraction/enhancement, however it cannot currently be played raw. A captured image is shown below, along with MP4 video.

I tried to figure out why offline LMS filter subtract seismic noise much better from MC_F then the Wiener filter. I did the calculations twice - with my codes and with Matlab in-build functions, the results are the same. So this is not a code error.

The coherence between GUR 1, 2 and MC_F is still poor. Wiener filter is linear and its performance is confined to the frequency ranges where we see coherence. Lms filter is non-linear and it may be possible to subtract the noise even if non-linear effects are present in the system.

I've checked seismometer readout box again. I've soldered 50 Ohms to plus and minus inputs to VERT 1,2 N/S 1,2, E/W 1,2 - GUR 1 and 2 use these channels. Then I put the box back and connected it to the ADC.

The plot shows that the readout box noise is below the ADC noise.It is possible that amplifiers introduce non-linear effects. To check this I plotted the coherence between OSEM sensors and GUR1X signal:

The coherence between OSEM sensors and GUR1X is pretty good, so may be witness path is not responsible for low coherence at 0.1 - 0.5 Hz between MC_F and GUR 1,2. IT seems that MC_F is bad at low frequencies. I terminated the input to the Channel 1 of the Pentek Generic board, where MC_F is plugged in.

The new hysteresis model is slightly based on the SHO equation, but with the force being out of phase with the position by an amount of hysteresis {x(t)=Amp*sin(freq*t), F(t)=Amp*sin(freq*t+Hyst)}. The new model can be found at /users/mjenson/matlab/hyst_v_3.mdl. Pictures are: new hysteresis model, x(t) subsystem in new model[xh''(t) only lacks -1 multiplier and includes hysteresis variable], new plots.

I didn't understand how CARM can be decreased 2 orderes of magnitude and PRCL can be INCREASED by such small offsets (see the matrix quoted).

Apparently it was because of an optical-spring ish effect from the "detuning" (which is actually RAM position offsets). I put two plots which are CARM and PRCL tranfer functions to REFL f1 or POP f1, when there is a slight PRCL offset (0, 1e-14m, and 1e-15m cases are plotted). Looking at these plots, it was not a good idea to calculate the LSC matrix in DC because they are affected by this detuning a lot. I'll try f = 150 Hz for the matrix.

Turns out that the "MPEG-4 VES" video format is just bad for captured video. Everything except "MP4" and "MPEG-TS" works for streaming, and "MP4" and "MPEG-TS" seem to be the only captured formats that can be viewed properly.

The Sensoray device is currently viewing Monitor 4 and plugged into Pianosa. The user interface is run at /home/controls/Downloads/sdk_2253_1.2.2_linux/python demo.py. It can preview and capture the video stream, however the captured files are terrible. I believe it has something to do with the bitrate, since the captured video with lower bitrates are not as bad as the ones with higher bitrates, but I am not certain.

We were wondering why the STS-2 signal was funny. When I went to look at it, the X-axis indicator was pointing ~45deg from the x-axis, so that it was pointing between the arms of the IFO. Also, the bubble in the level was totally stuck on one side. We locked the masses, and I put the seismometer back to the correct orientation, and then leveled it. We unlocked the masses and turned the power back on, and hit the auto-zero button a few times. Right now the X-axis signal is fine, but Y and Z are still railed, but it's been like 24 seconds, not 24 hours since we last hit auto zero, so there's still some time to wait.

Also, GUR2 was unplugged on both ends of the cable. We plugged it back in. However, it looks like the *seismometer* labeled #1 is now plugged into *channels* GUR2, and the seismometer labeled #2 is plugged into channels GUR1. Recall that Den has only modified X, Y, Z for GUR1 channels, not any other channels in the breakout box.

c1ioo computer can not connect to the framebuilder and everything is red in the status for this machine, C1:FEC-33_CPU_METER is not moving.

EDIT by KI:

We rebooted the c1ioo machine, but none of the ftont end model came back. It looked like they failed the burt process for some reasons according to dmesg.

Then we restarted each front end model one by one, and every time after immediately we restarted it we hit the 'BURT' button in the GDS screen.

I've changed R2 resistor in the seism box for the VERT 1 channel from 464 Ohm to 1051 Ohm to reduce the gain of this channel by a factor of 2. This should help the GUR1Z signal not to be corrupted inside the AA box, so we can use it in the adaptive filtering.

I think we can try to damp 1 Hz resonance more. In September it was not seen because of the digital noise. After we've figured it out, 1 Hz resonance began to be more clear (blue line).

Now applying oaf we reduce the effect of the stack and the 1 Hz resonance is even more clear:

The RAID (JetStor SATA 416S) is indeed resyncing itself after a disk failure. There is a hot spare, so it's stable for the moment. But we need a replacement disk:

RAID disks: 1000.2GB Hitachi HDT721010SLA360

Do we have spares? If not we should probably buy some, if we can. We want to try to keep a stock of the same model number.

Other notes:

The RAID has a web interface, but it was for some reason not connected. I connected it to the martian network at 192.168.113.119.

Viewing the RAID event log on the web interface silences the alarm.

I retrieved the manual from Alex, and placed it in the COMPUTER MANUALS drawer in the filing cabinet.

Suresh reported to Den, who reported to me (although no elogs were made.....) that something was funny with the FB. I went to look at it, and it's actually the RAID array rebuilding itself. I have called in our guru, Jamie, to have a look-see.

I've run static and adaptive filters simultaneously. AA32 filters rotate the phase of the witness signals GUR1X and GUR1Y and now the performance of the static filter is worse. Next time I'll recalculate Wiener filter coefficients taking this into account. But still 2 filters together can deal with a stack better.

I've run static and adaptive filters simultaneously. AA32 filters rotate the phase of the witness signals GUR1X and GUR1Y and now the performance of the static filter is worse. Next time I'll recalculate Wiener filter coefficients taking this into account. But still 2 filters together can deal with a stack better.

I made static filter to work to evaluate the actuator TF.. Here is the result of static filtering:

What I did:

I did offline simulation of the MC_F Wiener filtering using 2 witness signals - GUR1X and GUR1Y. I've downsampled the data from 2048 to 128 Hz and applied the Wiener filter with 10000 for each witness channel:

Result of the filtering Filter coefficients for gur1x and then gur1y

Gur1x -> MC_F transfer function Gur1y -> MC_F transfer function

Then using vectfit I approximated obtained transfer functions in the region 0.5 - 20 Hz. I used a window function and then weights to get a more precise result in this range using only 8 poles and zeros.

I obtained the zpk-model for each witness channel and entered it into the FOTON splitting it into 2 parts before that because FOTON does not like too long filters. These zpk-models are at the C1:OAF-STATIC_STATMTX_8_8 and C1:OAF-STATIC_STATMTX_8_9 filter banks.

Today I tried to make the lms filter to work online. I played around with the signals (GUR1_X and MC_F) to pre-whiten them and in the end the following configuration worked out:

1. mu = 0.03, tau = 1e-5, downsample=8, nCoeff = 4000, delay = 5 (sample-and-hold delay is not included in the new code, it should be added here!)

3. witness adaptation path: AA32 AND AI32 = cheby1("LowPass", 4, 1, 32) AND 0.1:0

4. error path: AA32 AND 0.1:0 AND anti_1Hz. Before I added anti_1Hz filter oaf did nothing. This filter tries to approximate the actuator transfer function. Note, it is not in the witness adaptation path. This is some sort of whitening.

5. correction path: AI32, gain = -1

Convergence time ~ 5 mins. The performance of the filter is far not perfect compared to the offline implementation. But it deals with a stack though.

Here are the hysteresis plots from the most recent model, which uses a modified harmonic oscillator equation y''=-(Frequency)^{2}*y-Hysteresis. The hysteresis constant seems to change both the amplitude and equilibrium point of the pendulums, which is akin to changing the length of a pendulum without changing the frequency. This does not make sense. Perhaps the hysteresis value should be moved to the "spring" constant for the pendula and not restricted to a position-biasing value.

I'm still wondering whether iteration version or simple version is closer approximation to the real situation. Sorry for few explanations here. I will try to present those on Friday.

* So far, I used to add all the offsets at once. This time I add CARM and get the CARM row, add PRCL and get the PRCL row... and so on.

I

Quote:

Koji and Jamie suggested me to include the coupling between DoFs when I calculate the last matrix. So far, I just add all the pos-offsets of 5 DoFs and re-calculate the matrix again. However, once I add one DoF pos-offset, it could already change the LSC matrix therefore different pos-offset to the other four DoF, we must iterate this process until we get the equilibrium pos-offsets for 5 DoFs.

I also noticed an error in the optical configuration file. AM mod levels were smaller than that supposed to be because of the hald power going through the AM-EOMs in the MZI paths. Also I have put PM-Mods in the MZT path which gives the smaller mod indexes. So, smaller mod levels were applied both for PM and AM. As PM-AM ratio is still kept in this, so the matrices were not very wrong, I assume. I'll modify that and post the results again.

A better hysteresis model based on the simple harmonic oscillator equation. Useless variables have been removed and output can now be saved to workspace for plotting. The model is at "/users/mjenson/matlab/SHO_hyst.mdl".

I've added the PEM_SLOW.ini file to the fb master file, which should give us the slow seismic RMS channels when the framebuilder is restarted. Example channels:

[C1:PEM-RMS_ACC6_1_3]
[C1:PEM-RMS_GUR2Y_0p3_1]
[C1:PEM-RMS_STS1X_3_10]
etc.

The framebuilder seems to have been restarted, or restarted on it's own, so these channels are now being acquired.

Below is a minute trend of a smattering of the available RMS channels over the last five days.

Koji and Jamie suggested me to include the coupling between DoFs when I calculate the last matrix. So far, I just add all the pos-offsets of 5 DoFs and re-calculate the matrix again. However, once I add one DoF pos-offset, it could already change the LSC matrix therefore different pos-offset to the other four DoF, we must iterate this process until we get the equilibrium pos-offsets for 5 DoFs.

I also noticed an error in the optical configuration file. AM mod levels were smaller than that supposed to be because of the hald power going through the AM-EOMs in the MZI paths. Also I have put PM-Mods in the MZT path which gives the smaller mod indexes. So, smaller mod levels were applied both for PM and AM. As PM-AM ratio is still kept in this, so the matrices were not very wrong, I assume. I'll modify that and post the results again.

> (B) Are pos-offsets degrade the CARM and DARM so much (See, the quoted result below), is that true?

Here is the new results. It does change CARM a lot, but not DARM:

Matrix1 (normalised so that the diagonals are 1):

REFL f1 : 1.000000 0.000000 0.000008 -0.000005 0.000003

AS f2 : 0.000001 1.000000 0.000005 -0.003523 -0.000001

POP f1 : -3956.958708 -0.000183 1.000000 0.019064 0.000055

POP f2 : -32.766392 -0.154433 -0.072624 1.000000 0.024289

POP f2 : 922.415913 -0.006625 1.488912 0.042962 1.000000

(=Matrix 2)

Position offsets:

only CARM, 4.6e-16 (this number changed because I increased the resolution of the calculation)

Matrix3 (normalised by matrix 1):

REFL f1 : 0.039780 -0.000000 0.003656 0.000005 -0.000003

AS f2 : 0.000008 1.000017 0.000005 -0.003499 -0.000001

POP f1 : 159.146819 -0.000138 15.605155 0.019393 0.000055

POP f2 : 1.277223 -0.154415 0.047344 1.000008 0.024289

POP f2 : -35.422498 -0.006633 -1.886454 0.042963 1.000000

CARM got a small position offset which degrades CARM signal 2 orders of mag (still the biggest signal in the sensor, though).

DARM was not so bad, and probably the change of the DoF mixture is mostly not changed.

Matrices don't change only with 1e-4 RAM. It changes with position offsets.

I'll see how the matrix changes without position offsets but only with RAM effects, changing RAM levels.

Again, above is C1 configuration, 1e-4 RAM level of PM level.

Quote:

I add a flow-chart drawing what the scripts do and how the scripts calculate the LSC matrix.

(1) First, you calculate the LSC matrix WITHOUT RAM or anything, just for a reference. This is the first matrix shown in the quoted post.

(2) The script calculates the LSC matrix with RAM. Also, the PDH signals for all 5 DoF are calculated. The PDH signals have offsets due to the RAM effect. The operating position offsets are saved for the next round.

(3) The script calculates the LSC matrix again, with RAM plus the offset of the operation points. The matrix is shown in the last part of the quoted post.

Now I am going to check (A) LSC matrices (matrix 2, the second matrix of above chart) with different RAM levels (B) Are pos-offsets degrade the CARM and DARM so much (See, the quated result below), is that true?

I add a flow-chart drawing what the scripts do and how the scripts calculate the LSC matrix.

(1) First, you calculate the LSC matrix WITHOUT RAM or anything, just for a reference. This is the first matrix shown in the quoted post.

(2) The script calculates the LSC matrix with RAM. Also, the heterodyne signals for all 5 DoF are calculated. The signals have offsets due to the RAM effect. The operating position offsets are saved for the next round.

(3) The script calculates the LSC matrix again, with RAM plus the offset of the operation points. The matrix is shown in the last part of the quoted post.

Now I am going to check (A) LSC matrices (matrix 2, the second matrix of above chart) with different RAM levels (B) Are pos-offsets degrade the CARM and DARM so much (See, the quated result below), is that true?

Quote:

Original matrixwithoutRAM:

REFL f1 : 1.000000 0.000000 0.000008 -0.000005 0.000003

AS f2 : 0.000001 1.000000 0.000005 -0.003523 -0.000001

POP f1 : -3956.958708 -0.000183 1.000000 0.019064 0.000055

POP f2 : -32.766392 -0.154433 -0.072624 1.000000 0.024289

POP f2 : 922.415913 -0.006625 1.488912 0.042962 1.000000

(MICH and SRCL uses the same sensor, with optimised demodulation phase for each DoF.)

Operation position offsets are:

PRCL -3.9125e-11 m

SRCL 9.1250e-12 m

CARM 5.0000e-15 m

and no position offsets for DARM and MICH (because they are differential sensor and not affected by RAM offsets).

I also would like to extend this script to use the DC readout, but don't know how to calculate the postion offset for AS_DC because the error signal is not zero-crossing for AS_DC anymore. Do you have any suggestions for me?

I don't think I understand the question. AS_DC should not have a zero crossing, correct?

That's right. I calculate the offset of the operation point (when you have RAM) from the zero-crossing point of the PDH signals. I don't know how to do that for AS_DC, because it doesn't cross zero anymore anytime.

Here's my first hysteresis model in Simulink. It's based on the equation y=Amplitude*sin(frequency*t+phase)+(hysteresis/frequency^{2}) as a solution to y''+frequency^{2}*y+hysteresis=0. All values in the model are variables that should be manipulated through the model workspace or external code.

I also would like to extend this script to use the DC readout, but don't know how to calculate the postion offset for AS_DC because the error signal is not zero-crossing for AS_DC anymore. Do you have any suggestions for me?

I don't think I understand the question. AS_DC should not have a zero crossing, correct?

I fitzed by hand with the numbers for the incident angles on MMT1 and MMT2, and then let the code optimize the position of MMT1 and MMT2.

Here I have set the incident angle for MMT1 = 25deg, and MMT2 = 12deg (should be 3.5deg, 1deg by design). The length of the telescope doesn't want to change by more than 7mm, but the position of the telescope wants to change by 1.3meters. Is it possible that the distances on the Monday IPPOS measurements aren't actually correct?

I am trying to track down possible errors in our measurements.

So as a first step I am recomputing the IPPOS waist location with respect to the MC waist, using the same optical layout diagram as the one used by Jenne in her calculations. Pic of Jenne's lab notebook showing location of optics is attached.

Note that there is a discrepancy of about 3.2 m in the waist location for the vertical profile and about 3.5 m for the horizontal profile between these two measurements.

Let us compare these measurements with what is expected from calculations. Jenne uses the known parameters of MC waist and the locations of the MMT optics to compute the parameters for the IPPOS beam:

As the 2010 measurements are reported wrt to MMT2 and calculations are wrt MCwaist, I have used the distance between the MCwaist to MMT2 = 3.910 m to shift the reference from MMT2 to MC waist. Refer to the attached diagram from Jenne's notes for this MMT2 <--> MC waist distance.

There is a discrepancy of 1.5 meters between the calculations and recently measured waist location. The discrepancy with the 18Jun2010 measurement is much larger, about 3 meters in both v and h.

Are such variations to be expected between two successive measurements? I looked at another case where we have two measurements of a beam to see what to expect.

I looked at the REFL (Reflection from PRM) case, where we repeated a measurement, to see how much variation could happen in w0 and zr, between repeated measurements. This was a particularly bad case as our first attempt had problems due to OL servo loop oscillations in the PRM suspension damping. We fixed that later and measurement 2 has smaller residuals. And I think we are doing okay in IPPOS case as seen by the reduced scatter of the residuals.

These are the fits from the REFL beam measurement 1

Note that between these two measurements the beam waist location has shifted by 0.5 m for the vertical and about 1.3 m for the horizontal cases. So variations of 1.5 m in the waist locations are possible if we are not careful. But this is a particularly extreme example, I think we are doing better now and the measurement is unlikely to change significantly if we repeat it.

Some notes:

Fits for IPPOS and both REFL measurements 1 and 2 are attached.

The zero reference for the z axis of the IPPOS beam plot is at a distance of 6.719 m from MC waist for a beam propagating towards the IPPOS QPD.

The zero reference for the z axis of the REFL beam plots is at a distance of 5.741 m from the MMT2 in the direction of a beam reflected by PRM and propagating towards the REFL port.

Suresh noted that I never wrote down the waist positions of the beam propagated through the MMT (based on where we think it is from ruler-based measurements). This uses the MC waist measured beam as the starting point, and just propagates through the MMT, out to the IPPOS port.

Yq:

Properties:
q: 2.2488 +23.8777i
lambda: 1.0640e-06
waistSize: 0.0028 (at z = 13.2676 meters)
waistZ: 2.2488 (relative to z = 13.2676 meters)
divergenceAngle: 1.1910e-04
radiusOfCurvature: 255.7849
beamWidth: 0.0029
rayleighRange: 23.8777

So, to sum up, the vertical beam waist is 2.8438 mm at 11.0188 meters from the MC waist.

Xq:

Properties:
q: 5.1953 +24.7342i
lambda: 1.0640e-06
waistSize: 0.0029 (at z = 13.2676 meters)
waistZ: 5.1953 (relative to z = 13.2676 meters)
divergenceAngle: 1.1702e-04
radiusOfCurvature: 122.9525
beamWidth: 0.0030
rayleighRange: 24.7342

So, to sum up, the horizontal beam waist is 2.8943 mm at 8.0723 meters from the MC waist.

I extended my RAM script from DRMI (3DoF) to the full IFO (5DoF).

Again, it calculates the operation point offsets for each DoF from the opt model with RAM. Then the position offsets are added to the model, and calculates the LSC matrix. RAM level is assumed as 0.1% of the PM modulation level, as usual, and lossless for a simple model.

Original matrixwithoutRAM:

REFL f1 : 1.000000 0.000000 0.000008 -0.000005 0.000003

AS f2 : 0.000001 1.000000 0.000005 -0.003523 -0.000001

POP f1 : -3956.958708 -0.000183 1.000000 0.019064 0.000055

POP f2 : -32.766392 -0.154433 -0.072624 1.000000 0.024289

POP f2 : 922.415913 -0.006625 1.488912 0.042962 1.000000

(MICH and SRCL uses the same sensor, with optimised demodulation phase for each DoF.)

Operation position offsets are:

PRCL -3.9125e-11 m

SRCL 9.1250e-12 m

CARM 5.0000e-15 m

and no position offsets for DARM and MICH (because they are differential sensor and not affected by RAM offsets).

REFL f1 : 0.001663 -0.000000 0.003519 0.000005 -0.000003

AS f2 : 0.000004 0.514424 0.000004 -0.001676 -0.000001

POP f1 : 7.140984 -0.001205 15.051807 0.019254 0.000417

POP f2 : 0.029112 -0.319792 0.042583 1.000460 0.024298

POP f2 : -0.310318 -0.014385 -1.761519 0.043005 0.999819

As you can see in the second matrix, the CARM and DARM rows are completely destroyed by the RAM offsets! The signals are half reduced in the DARM case, so the mixture between DARM and MICH are about 50% degraded.

I also would like to extend this script to use the DC readout, but don't know how to calculate the postion offset for AS_DC because the error signal is not zero-crossing for AS_DC anymore. Do you have any suggestions for me?