I thought I had, but apparently not, and I'd made another error or two in the complex version of my fitting routine. I've fixed them now, thanks! I'll put up the new fitting results tomorrow morning.

Here are the results of the complex fitting. The residuals are bigger this time, but still probably small enough to be ok(?), with the possible exception of ITMY PITCH (due again I think to the data points straddling the resonance).

ITMY YAW actuator response complex fit

-- Fit completed after 282 iterations--

 I thought it might be informative before trying to optimise the filter design to see how the current one performs with different gain settings. I've plotted the power spectra for ITMY yaw with filter gains of 0, 1, 2, 3 and 4.

All of the higher gains seem to perform better than the 0 gain, so can I deduce from this that so far the oplev control loop isn't adding excess noise at these frequencies?

Fitting results: 

 Pitch

It turned out the oplev controls on ETMY were just bad.

It looks like the whitening filters have been OFF and because of that the resultant open-loop was not crossing the unity gain.

I will check the whitening filters.

(open-loop transfer function)

The blue dots are the measured data points and the green curve is the fit.

Apparently the open-loop doesn't go above the unity gain, so the oplev had been doing nothing.

If we try to increase the overall gain it will oscillate because of the phase delay of more than 180 deg around 3 Hz.

The red curve is the expected one with the whitening filters (WFs) properly engaged.

Note that WF are supposed to have two zeros at 1 Hz and two poles at 10 Hz.

The whitening filters for the ETMY oplevs are back.

The whitening board had been in the rack but the ADC was connected directly to the oplev interface board without going through the whitening board.

In fact the interface board and the whitening board had been already connected. So the ADC was making a shortcut.

I disconnected the ADC from the interface board and plugged it to the output of the whitening board.

Here is an example of the new open-loop transfer function with the whitening filters.

 Note :

before the measurement I increased the control gain by an arbitrary number to obtain gain of more than 1 around 1 Hz.

I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.

I have a attached a plot showing the power spectrum and RMS curves for the optimization result for 2 zeros and 2 poles, optimized to give a minimal RMS below 20Hz.

I have also attached a plot showing the loop gain and the filter transfer function.

The noise spectrum shows that the optimised filter gives a better noise performance below 10Hz, but a servo oscillation at the UGF of 10 Hz means it injects a lot of motion around this frequency. Should I consider some more aggressive way to force the script to keep a decent phase margin?

The fminsearch results show that the 'optimized' solution is two resonant peaks:

 -- Optimisation completed after 571 iterations--

 Started with: 

 Pole 1 frequency = 1 Hz 

 Pole 2 frequency = 2 Hz 

 Zero 1 frequency = 0.1 Hz 

 Zero 2 frequency = 5 Hz 

Overall gain = 1 

 Finished with: 

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0497181 Hz 

 Zero 2 frequency = 2.01809 Hz 

Overall gain = 71970.1 

 Initial RMS below 10 Hz = 5.90134e-06

 Remaining RMS below 10 Hz = 8.42898e-07

As a suspension test I am leaving all of the suspensions restored and damped with OSEMS but without oplevs

I think this is a nice start. Its clear that we don't want to use this feedback law, but the technique can be tweaked to do what we want by just tweaking our cost function.

Let's move the scripts into the SUS/ scripts area and then start putting in weights that do what we want:

1) Limit the gain peaking at the upper UGF to 6 dB.

2) Minimum phase margin of 45 deg.

3) Minimum gain margin of 10 dB.

4) Lower UGF = 0.1 Hz / Upper UGF = 10 Hz.

5) Assume a A2L coupling of 0.003 m/rad and constrain the injected noise at the test mass to be less than the seismic + thermal level.

6) Looser noise contraint above 50 Hz for the non TM loops.

Good work for the oplev noise simulations. Here are some comments/questions:

 (A) The noise looks suppressed but the open-loop transfer function doesn't look so good, because it doesn't have sufficient phase margins at the UGFs (0.01 and 10 Hz).

      I guess it is better to have a phase margin detector in your code so that the code automatically rejects a bad phase margin case.

      Actually since the number of data points are finite, the rms detector in the simulation can not always find a sharp loop oscillation.

 (B) The resultant poles and zeros seem canceling each other but the filter still has a structure. Is something wrong ?

 Ah yes, well noticed. I think I have tracked this down to just a bug in printing of fitting results: It was just printing the pole results for the zeros too. The results for the same fit now read:

 Finished with: 

 Pole 1 frequency = 0.0497181 Hz 

 Pole 2 frequency = 2.01809 Hz 

 Zero 1 frequency = 0.0972455 Hz 

 Zero 2 frequency = 6.50126 Hz 

Overall gain = 71970.1

EDIT: sorry, I forgot that when you write a reply, the author is still by default the person you are replying to unless you change it!

According to the spectra, all of the suspensions had been damped with the OSEMs. The peaks around 1Hz are reasonably suppressed.

However the spectra from ITMX showed a noise floor at very high level. This is because of strange jumps in the signal of the UL shadow sensor.

I will check some analog circuits for the UL sensor.

(ITMX shadow sensors)

Here is the spectra of the ITMX shadow sensors taken during the damping test (#5534)- -

The UL sensor shows a unacceptable amount of noise.

Additionally I checked the time series of the ITMX shadow sensors and found ONLY the UL sensor frequently showed strange jumps in data.

Here is an example of the time series showing a jump ONLY in the UL sensor.

It is possible that the jumps are coming from some circuits, since the rest of the sensors (including the oplevs) don't detect the same jump.

Currently the damping of the ITMX suspension is intentionally disabled for the noise investigation.

The issue on the ITMX UL sensor has been fixed. It was because of a loose connection in the sensor signal path.

After the fix, the sensor responses completely changed and the suspension became unable to be damped with the new matrix.

At the moment the ITMX suspension is damped by the default input matrix.

we should do the free swinging test once again.

(details)

 The loose connection was found on the rear side of the 1X5 rack.

There is an adapter card on the rear side, where the driver and sensor signals are combined into a single cable.

I pushed the sensor cable (bottom right in the picture) and the noise disappeared.

Note that I changed the labels on the adapter cards from the old X/Y convention to the new one.

After fixing the loose cable the ITMX suspension became unable to be damped.

So I put the input matrix back to the default and it immediately started damping happily. It means our new matrix is not valid any more.

 Here is the latest noise spectra of the ITMX sensors damped with the default input matrix.

As usual all of them are limited by the ADC noise above 20 Hz. (ADC noise is plotted in purple curve)

During the work I also pushed not only ITMX ones but also the cable for the rest of the optics in the adapter cards.

Then PRM became unable to be damped, so it implies the PRM suspension also used to be the same situation.

The input matrix of PRM has been also back to the default.

 I moved two matlab scripts into the folder /cvs/cds/rtcds/caltech/c1/scripts/SUS/Oplev_filter_optimization

These are the function 'filter_optimiser_zeros_and_poles.m', and the example script to run the function 'run_filter_optimiser.m'. Type 'help filter_optimiser_zeros_and_poles.m' to get details about the function.

I haven't implemented the new weights yet. I've pasted them into the the file header to remind me/us of the work to be done on the function.

I came to the control room and found the PMC and IMC were unlocked. ==> Relocked
I found the watch dogs of the vertex suspensions are tripped.

I checked the data for the past 6 hours and found they are independent events.
The unlock of the MCs occured 4 hours ago and the watchdogs tripped 2 hours ago.

The suspension damping was restored at around 7:50PM PDT.

 Oops, I should have noticed all of those things.  Several hours of computer-battle exhausted me.  Thanks Koji.

ITMY suspention damping restored

 I'm turning  the sus damping  off for Dsub connection fix at  the back of 1X5 rack

The plan is to install 4-40 jack screws to lock connector positions.

All dewittening(or called coil driver) and wittening D sub connectors are locked with two 4-40 socket head screws

Kiwamu and Steve,

This is one of the better oplev set up we have. Single bounce from TM, no mirror on stack. One lens and one  mirror on ISCT. Old Uniphase 1103P laser on heafty 3" od mounts.

Somewhat  big ~5-6 mm spot on qpd in  1,300 counts.

The intensity noise effect can be seen at 1 Hz and 3-20 Hz

Oplev servo was OFF

The following optics were kicked:
MC1 MC2 MC3 ETMX ETMY ITMX ITMY PRM SRM BS
Sun Oct  2 02:13:40 PDT 2011
1001582036

They will automatically get back after 5 hours.

The input matrices of ETMX, ITMX and PRM have been newly inverted.

Those were the ones having some troubles (see #5444, #5547).

After a coarse adjustment of the damping Q factors, they look damping happily.

optic	spectra	inverted matrix	BADNESS
ETMX		pit     yaw     pos     side    butt UL    0.848   0.108   1.578   0.431   1.025  UR    0.182  -1.892   1.841  -0.128  -1.172  LR   -1.818  -1.948   0.422  -0.122   0.939  LL   -1.152   0.052   0.159   0.438  -0.864  SD    1.756  -3.794  -0.787   1.000  -0.132	5.37028
ITMX		pit     yaw     pos     side    butt UL    0.510   0.584   1.228   0.458   0.203  UR    0.783  -1.350   0.348  -0.050   0.555  LR   -1.217   0.065   0.772   0.264   0.312  LL   -1.490   2.000   1.652   0.772  -2.930  SD   -0.635   0.853  -1.799   1.000  -1.597	7.5125
PRM		pit     yaw     pos     side    butt UL    0.695   1.422   1.774  -0.333   0.954  UR    1.291  -0.578   0.674  -0.068  -0.939  LR   -0.709  -1.022   0.226   0.014   0.867  LL   -1.305   0.978   1.326  -0.251  -1.240  SD    0.392  -0.437  -0.500   1.000   0.420	5.09674

(some notes)

 Before running the peakFit scripts, I woke up the nds2 sever process on Mafalda because it hasn't been recovered from the power outage.

To start the nds2 process I followed the instruction by Jamie (#5094).

Then I started requesting the data of the last night's free swinging test (#5594)

However the NDS2_GetData command failed everytime when data with long duration were requested.

It maybe because some of the data are missing in sometimes, but I haven't seriously checked the data stored in fb.

So for the reason, I had to use a short duration of 1200 sec (default is 3600 sec). That's why spectra look noisier than usual.

 [Suresh, Jenne]

Suresh pointed out the oddity that all of the EX, EY slow channels were showing white boxes on the medm screens on all of the workstations except Rosalba.  I don't know why Rosalba seemed to be working, but whatever.  I'm not 100% sure that Rosalba was even working properly....I shutdown ETMX and ETMY's watchdogs before we went to boot computers, but when I came back to the control room the 2 optics were rung up anyway.  Turning back on the watchdogs, the optics immediately began to damp happily.

Since Kiwamu had trouble with the slow channels for EX, we decided to key some crates. 

We keyed the c1auxey, and c1auxex crates, waited a few seconds, and then things looked okay in medm-land.  I looked at the "View Backup" for ETMX, and there were no values for the DC sliders, so since the arms are both flashing right now, I did a "save", and then confirmed that I can misalign and restore the optic.  However, since I didn't fully align/lock the cavity, the saved value for right now shouldn't be fully trusted.  We might have to manually align the cavity using the BS.

I assume it's because the burt restore didn't work for the SUS summary screen, but all of the values for the ifo suspensions (not the MCs...they're okay) are red. 

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
  super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
  File "./setSensors.py", line 81, in ?
    mean = acquire(x)
  File "./setSensors.py", line 73, in acquire
    daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
    daq.request_channel(daq, str)
did not match C++ signature:
    request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

 My guess is that this has something to do with the NDS client version you're using.  Try running the script on a machine where pynds and nds-client are known to be compatible, like pianosa.

The He-Ne laser which has been used for the PRM and BS oplevs were found to be dead.

According to the trend data shown below, it became dead during the dolphin issue.

(During the dolphin issue the output from the oplev QPDs are digitally zero)

JDSU 1103P died after 4 years of service. It was replaced with new identical head of 2.9 mW output. The power supply was also changed.

The return spots of 0.04 mW  2.5 mm diameter on qpds are BS  3,700 counts and PRM 4,250 counts.

Kiwamu and Steve,

The He/Ne oplev shows no coherece so relative intensity noise is not limiting factor for the oplev servo

The SRM bounce peak 18.33 Hz. Suresh helped me to retune filter through Foton, but we failed to remove it.

ITMX_OPLEV_PERROR shows high coherence with oplev laser. This is our lousiest set up. I will work on it next week.

Generally speaking we can say that JDSU-Uniphase 1103P and 1125P laser intensity noise do not limit oplev servo performance.

However, the overall well being of filters, gain settings, beam sizes on qpds are poor.

Yesterday Koji was claiming that the rms monitor of ULSEN on ETMY didn't well go down.

Indeed something bad is happening on ULSEN of ETMY.

I guess it could be a loose connection.

(The unit of Y axis in the plot is not true. Don't believe it !)

The SRM oplevs were found to be oscillating because of a small phase margin.

I reduced the gains to the half of them. The peak which Steve found today maybe due to this oscillation.

 I lost UL osem voltage this morning when I was checking the actual connection at rack ETMY

This after noon I disconnected  the 64 pins IDE connector from satelite amp at the rack, and the two 25 pins Dsubs at this juction board.

UL OSEM recovered after reconnecting these three connectors.

Atm3, bad connection.........noisy UL

 Atm2 is before optical path adjustment. The idea was to remove possible clipping in vacuum.

Coherense significantly reduced below 4 Hz

Today I will replace the He/Ne laser 1125P with 1103P

 I replaced the JDSU-Uniphase 1125P by 1103P He/Ne laser. This new laser had 2.8 mW output yesterday. It degraded to 0.5 mW by this morning.

The beam size on the QPD is ~3 mm  This should give us  better sensitivity. These are not the perfect lenses at all, but we have them here.

On the other hand, there are still some coherence below 1 Hz, so the laser intensity noise or clipping dominating  this  part of the spectrum.

I offered to help Kiwamu with some of the 40m work. The first task was to figure out why the ETMX side OSEM monitor was so low, since we know that the depth is about right. It was showing ~0.13 V to the others' ~0.7 V.

TL,WR: There was a wire disconnected from the breakout panel on the side of the rack

I started by pulling the board out and checking to make sure that it was working properly. I injected a sine wave to the SIDE IN and found that it showed up in the signal coming out of the back (into the crate) just fine (see below). One strange thing I noticed while testing the board is that both inputs for each used channel of the MAX333 switches on the board are shorted to their respective outputs. That is, the switches seem to be open to BOTH 0 and 1 logic states. This seems counterintuitive, but perhaps there's something about how these work that I don't know.

Then I went about tracing the signal from the back of the crate to the breakout panel on the side of the rack. I opened it up, verified that the ribbon cable was transmitting correctly, and as I went to plug it back in I noticed that one of the wires---the correct one---had come completely undone.

The screw clamp appeared to be a bit finicky, as I had to loosen and tighten it a few times before it finally seemed to grab hold of the wire. It probably just wasn't tight in the first place and the wire was pulled out. Anyway, things are working now:

 Good job ! Thank you so much

 ETMX oplev had 6 mm diameter beam on the qpd.  I relayed the beam path with 2 lenses  to get back  3 mm beam on the qpd

BRC 037  -100 Bi _concave lens and PCX 25  200 VIS do the job. Unfortunately the concave lens has the AR 1064.

The following optics were kicked:
SRM
Wed Oct 19 04:22:53 PDT 2011
1003058589
 

I made some efforts to fix the situation of SRM but it is still bad.

The POS motion wasn't well damped. Something is wrong either (maybe both) sensing part or actuation part.

I am going to check the sensing matrix with the new free swinging spectra (#5690)

(Symptom)

 When I was trying to lock SRMI I found that the fringes observed at the AS camera didn't show spatial higher order modes, which is good.

So I thought the SRM suspension became quiet, but it actually wasn't. Because the RMS monitor of the SRM OSEMs already went to about 30 counts.

At the same time the opelev error signals were well suppressed. It means some DOFs which were insensitive to the oplev were ringing up, namely POS and SIDE.

According to the LSC error signal and the ASDC signal, I believe that the POS was going wild (although I didn't check the OSEM spectra).
 

(Some efforts)

 + Readjusted the f2a filters (see the attachment).

 + Tried to eliminate a coupling between the POS and SIDE drives by tweaking the output matrix.

    => In order to eliminate the coupling from the POS drive to SIDE sensor, I had to put a comparable factor into an element.

     So it might be possible that the POS sensor was showing the SIDE signal and vice versa.

      In order to check it I left SRM free swinging (#5690).

Sorry Kiwamu, I realized too late that you were freeswigging. Hopefully 4 hrs was enough.

 Coherence at 1 and 2-3 Hz only. He/Ne laser intensity noise is not an issue.

 Kiwamu removed the 18.3 Hz ocsillation by turning down the oplev servo gain.

The SRM input matrix has been readjusted.

However still there is the unwanted coupling from the POS drive to SIDE signal and from the SIDE drive to POS signal.

			BADNESS
SRM		pit     yaw     pos     side    butt UL    0.871   0.975   1.115  -0.295   1.096   UR    1.015  -1.025   1.128  -0.140  -1.053   LR   -0.985  -0.984   0.885  -0.088   0.831   LL   -1.129   1.016   0.872  -0.243  -1.020   SD    0.084   0.061   3.534   1.000  -0.018	4.24965

There looks some activity at around MC2 on Wednesday afternoon.
It caused the misalignment of MC2. Misalignment was not found in MC1/3.

It seems that the incident beam on the MC was aligned in the evening.
This increased the MC transmission but it is vibible that the spot on MC2 is shifted from the center.

We need an action on this issue tomorrow in the daytime.

I am working on fixing this.  You might some strange stuff going on in the control room screens.  Pls ignore it till I am done.

  I have realigned the MC by recentering the spots on all the MC optics.  The current spot positions (in mm) are:

MC1P     MC2P     MC3P      MC1Y      MC2Y     MC3Y

0.2245    0.3364   -0.2801   -1.8891    0.1631   -1.744

Initially the lockins 2 and 5 showed very small outputs.  This was traced to the fact that we have recently switched on a 28Hz ELP filter module in the MC2 ASC filter bank which introduces an extra phase of about 75deg..  See this elog.

When the MC ASS lockins were initially setup, the phase was set with this filter module switched off.  Since quite some time has passed since the last calibration of these phases, I readjusted the phases to minimise the  Q_OUTPUT and I also adjusted the GAINs in the SIG filter banks  of all the six lockins so that their I_OUT's drop by the calibration value of -2.65 when an offset of 0.1 is introduced into the MC suspension output matrices.  Two short scripts in the $scripts$/ASS/ directory help in setting and removing these offsets.  They are called MCxoffsetOn and MCxoffsetOff.   They have to be edited appropriately to address each DoF of the MC.

The $scripts$/ASS/mcassUp script., which sets up everything to make the MC spot decentering measurement, has been edited to set these new phases and gains.  The old settings have been commented out.

I then centered the spots on the WFS sensors and the MC_TRANS QPD.  We are now ready to make the MC WFS output matrix transfer coef measurement again, but this time with the WFS loops closed.

While chatting with Jenne I learnt that some substantial amount of work had taken place yesterday around the MC2 chamber.  This was associated with the relocating of seismometers.  ref elog. 

I reiterate what is well known for quite sometime:  MC2 table is not well isolated from the ground.  And we should not approach this chamber unless absolutely necessary. I have blocked off the area around it which we should avoid.  It is a serious waste of time and effort to realign the MC each time the MC2 table decides to settle into a new position.

Steve tells me that the mild-steel frame supporting the chamber+MC2_table sits with two legs on one concrete slab while the other two legs sit on another one.   The frame is also quite weak without sufficient gussets or cross connects.  The next time we have a major shutdown we must replace this frame with a more sturdy one which sits on one slab (preferably the one on which the rest of the MC sits).

Till we improve this mounting, I suggest that we avoid that area as much as possible.

 Thinks to do before the NEXT realignment:

B,  tie 4 ancher bolts on table legs to the floor

C,  tie 4 dog clamps between table and chamber

D,  check the locked position of the 4 x 4 positioning screws

E,  check bellow protecting 4 tubes are not shorting

A,  here is the concrete  slab cut

It reminds me to check the  IFO vacuum envelope dog clamps on the chambers to floor  with torque wrench.