40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 233 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  5597   Sun Oct 2 18:33:36 2011 kiwamuUpdateSUSinversion of the input matrix on ETMX, ITMX and PRM

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 ETMX.png       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 ITMX.png     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 PRM.png       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.

  5596   Sun Oct 2 13:45:13 2011 ranaSummaryGeneralRecovery from the power shutdown: apache / svn

Restarted Apache on nodus using Yoichi's wiki instructions. SVN is back up.

  5595   Sun Oct 2 02:33:32 2011 kiwamuUpdateLSCsomething funny with AS55

Just a quick report.

The AS55 signal contains more noise than the REFL signals.

Why ? Is this the reason of the instability in PRMI ?

outofloop.png

 I locked the Power-Precycled ITMY with REFL33.

As shown in the plot above, I compared the in-loop signal (REFL33) and out-of-loop signals (REFL11 and AS55).

All the signals are calibrated into the displacements of the PR-ITMY cavity by injecting a calibration peak at 283 Hz through the actuator of PRM.

AS55 (blue curve) showed a structure around 3 Hz and higher flat noise below 1 Hz.

Quote from #5582
I am suspecting that something funny (or stupid) is going on with the MICH control rather than the PRCL control.

 

  5594   Sun Oct 2 02:21:27 2011 kiwamuUpdateSUSfree swinging test once more

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.

  5593   Sat Oct 1 22:53:49 2011 kiwamuSummaryGeneralRecovery from the power shutdown : lockable

Found the Marconi for the 11 MHz source had been reset to its default.

 => reset the parameters. f = 11.065910 MHz (see #5530) amp = 13 dBm.

Interferometer became lockable. I checked the X/Y arm lock, and MICH lock, they all are fine.

  5592   Sat Oct 1 17:47:21 2011 KojiSummaryGeneralRecovery from the power shutdown

[Steve Koji Kiwamu]

- The storage on linux1 and linux1 itself (with this order) were turned on at 10:30am

- Kiwamu restored the vacuum system

   => opened V4, started TP1 (maglev) and opened V1.

      The pressure went downfrom 2.5 mTorr to the normal level in about 20 minutes.

- A regular fsck of linux1 was completed at 5pm

- Nodus was turned on. Mounting /cvs/cds succeeded

- The control room computers were turned on

- The rack power for FB turned on, FB and megatron started.

- Kiwamu and Koji went through all of the rack powers and started the slow and fast machines.
As we found Solensen for -15V at ETMX was current limited. +/-15V were turned off for now.
==> Kiwamu turned on Solensen again for investigation and found it became okay.
It's now ON.
 
- c1sus and c1ioo had many red lamps on the FE status screen.
Ran killc1XXX for all of the FE codes on c1lsc and c1ioo.
Then, made software reboot (sudo shutdown -r now)
All of the FEs shows green (after some randome clicking of DIAGRESETs)

- HVs on 1X1 were turned on. The are not vacuum HV, but used only in the air

- Turned on the RF generation box and the RF distribution box

- burtrestore slow machines (c1psl, c1susaux, c1iool0, c1iscaux, c1iscaux2, c1auxex, c1auxey)

  5591   Fri Sep 30 19:12:56 2011 KojiUpdateGeneralprep for poweroutage

 

 [Koji Jenne]

The lasers were shutdown

The racks were turned off

We could not figure out how to turn off JETSTOR

The control room machines were turned off

FInally we will turn off nodus and linux1 (with this order).

Hope everything comes back with no trouble

(Finger crossing)

  5590   Fri Sep 30 18:35:42 2011 steve, kiwamuUpdateVACvacuum set for poweroutage

We did the following:

1, closed V1, VM1,  annuloses: VASE, VASV, VABS, VAEV,  VAEE and VA6

2, stop rotation of Maglev-TP1, waited to decellerate and turned off power to it

3, closed V4,  stoped rotation of TP2, waited to decellerate and turned power off

4, opened VM3 to RGA that is still running

 

I will come in tomorrow 9-10am to restart pumping.

Attachment 1: prepforpoweroutage.png
prepforpoweroutage.png
  5589   Fri Sep 30 18:06:24 2011 kiwamuSummaryIOOPZTs straing guage

beforeOutage110930.png

  5588   Fri Sep 30 17:40:03 2011 kiwamuUpdateIOOAM / PM ratio

[Mirko / Kiwamu]

 We have reviewed the AM issue and confirmed the ratio of AM vs. PM had been about 6 x103.

The ratio sounds reasonably big, but in reality we still have some amount of offsets in the LSC demod signals.

Next week, Mirko will estimate the effect from a mismatch in the MC absolute length and the modulation frequency.

 


(Details)

 Please correct us if something is wrong in the calculations.

 According to the measurement done by Keiko (#5502):

        DC = 5.2 V

        AM @ 11 and 55 MHz = - 56 dBm = 0.35 mV (in 50 Ohm system)

Therefore the intensity modulation is 0.35 mV / 5.2 V = 6.7 x 10-5

Since the AM index is half of the intensity modulation index, our AM index is now about 3.4 x 10-5

According to Mirko's OSA measurement, the PM index have been about 0.2.

As a result,  PM/AM = 6 x 103

Quote from #5502

Measured values;

* DC power = 5.2V which is assumed to be 0.74mW according to the PDA255 manual.

*AM_f1 and AM_f2 power = -55.9 dBm = 2.5 * 10^(-9) W.

 

  5587   Fri Sep 30 17:01:29 2011 steveUpdateSUSETMX oplev intensity effect on noise

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

Attachment 1: ETMXoplintens.jpg
ETMXoplintens.jpg
Attachment 2: P1080267.JPG
P1080267.JPG
  5586   Fri Sep 30 16:17:10 2011 kiwamuUpdateGreen Lockingthings to be done for the Yarm green lock

Thank you for the summary.

I think now you are getting into a phase where you should start doing some quantitative and careful checks.

    1. Calculate how much light will be reflected from the cavity if the alignment is perfect.

    2. Investigate where those kHz oscillations are coming from.

    3. Estimate how much the 1.1 kHz corner frequency in LPF will reduce the phase margin around 10 kHz.

    4. Calculate the estimated amplitude of the PDH signal.

    5. Compute how big the gain of the PDH box should be.

Quote from #5585

 This is a kind of summary of what I have worked on this week. 

  • DC level of green PD when light resonates 75%
                    --> Not sure if this alignment is good enough
  • The PDH error signal was covered with oscillations of 3.3 kHz, 7.1 kHz and 35 kHz.
  • Designed and build a new LPF: second order, cut of frequency of 1.1 kHz (this is just the design value, haven't measured that so far)
  • Signal-to-noise ratio (SNR) could be improved to values between 7.8 and 11.1 (old SNR was 5 to 7)

  5585   Fri Sep 30 15:22:17 2011 KatrinUpdateGreen LockingWhat happened on green YARM?

 

This is a kind of summary of what I have worked on this week.

After all the changes made last week, I could not manage to lock the green light to the cavity, but the PDH error signal looks nicer.....at least something.

 

Alignment of the light to the cavity:

  • DC level of green PD when light is non-resonating 100%
  • DC level of green PD when light resonates 75%
  • --> Not sure if this alignment is good enough
  • In comparision to last week the cavity mirrors seem to move more or my alignment is way worse than last week. The bright spot on ETMY could not be observed for more than let's say a second in the unlocked configuration.

 

Low-pass filter (LPF)

  • The PDH error signal was covered with oscillations of 3.3 kHz, 7.1 kHz and 35 kHz.
  • Measured cut-off frequency of the LPF used so far is 35 kHz
  • Designed and build a new LPF: second order, cut of frequency of 1.1 kHz (this is just the design value, haven't measured that so far)
  • With the new LPF the PDH error signal is free of the above mentioned oscillations.
  • Impedance should be checked

 

PDH error signal

  • Signal-to-noise ratio (SNR) could be improved to values between 7.8 and 11.1 (old SNR was 5 to 7)
  • Looks more like a PDH signal than with the old LPF (now just derivative of the carrier and the first order sidebands show up)
  • Amplitude of the first order sidebands are smaller than the zero order, but are still too high (about 80% of the first order), need to work on the proper value of the LO amplitude an the voltage averager

 

Phase shift between green PD signal and LO

  • Phase shift is about 1MHz
  • Tried to find a capacity that compensates the phase shift. This was not successful since the PD frequency changed every now and than by +/- 20 kHz
  5584   Fri Sep 30 08:40:02 2011 KojiUpdateLSClength fluctuations in MICH and PRCL

Tip-Tilts has almost no isolation up to 3Hz, and isolation of about 0.5 up to 10Hz.
They have vertical resonances at around 20Hz.

See Nicole's entry

Quote:

noise.png

 

  5583   Fri Sep 30 06:25:20 2011 kiwamuUpdateLSCCalbiration of BS, ITMs and PRM actuators
The AC responses of the BS, ITMs and PRM actuators have been calibrated.
 
(Background)
 To perform some interferometric works such as #5582, the actuator responses must be measured.
 
(Results)
     BS = 2.190e-08 / f2     [m/counts]
     ITMX  = 4.913e-09 / f2   [m/counts]
     ITMY  = 4.832e-09 / f2   [m/counts]
     PRM   = 2.022e-08 / f2  [m/counts]
 
actuators.png
 
(Measurement)
The same technique as I reported some times ago (#4721) were used for measuring the BS and ITMs actuators.
In order to measure the PRM actuator, power-recycled ITMY (PR-ITMY) was locked and the same measurement was applied.
The sensor response of PR-ITMY was calibrated by exciting the ITMY actuator since the response of the ITMY had been already measured.
  5582   Fri Sep 30 05:35:42 2011 kiwamuUpdateLSClength fluctuations in MICH and PRCL

The MICH and PRCL motions have been measured in some different configurations.

According to the measurements :

      + PRCL is always noisier than MICH.

      + MICH motion becomes noisier when the configuration is Power-Recycled Michelson (PRMI).

The next actions are :

      + check the ASPD

      + check the demodulation phases

      + try different RFPDs to lock MICH

 


(Motivation)
 The lock of PRMI have been unstable for some reason.
One thing we wanted to check was the length fluctuations in MICH and PRCL.


(Measurement)
Four kinds of configuration were applied.
     (1) Power-recycled ITMX (PR-ITMX) locked with REFL33_I, acting on PRM.
     (2) Power-recycled ITMY (PR-ITMY) locked with REFL33_I, acting on PRM.
     (3) Michelson locked with AS55_Q, acting on BS.
     (4) Power-recycled Michelson locked with REFL33_I and AS55_Q, acting on PRM and BS.

In each configuration the spectrum of the length control signal was measured.
With the measured spectra the length motions were estimated by simply multiplying the actuator transfer function.
Therefore the resultant spectra are valid below the UGFs which were at about 200 Hz.
The BS and PRM actuator responses had been well-measured at AC (50 - 1000 Hz)
For the low frequency responses they were assumed to have the resonances at 1 Hz with Q of 5.
 

(Results)
The below plot shows the length noise spectra of four different configurations.
There are two things which we can easily notice from the plot.
    + PRCL (including the usual PRCL and PR-ITMs) is always noisier than MICH.
    + MICH became noisier when the power recycling was applied.
In addition to them, the MICH noise spectrum tended to have higher 3 Hz bump as the alignment gets improved.
In fact everytime when we tried to perfectly align PRMI it eventually unlocked.
I am suspecting that something funny (or stupid) is going on with the MICH control rather than the PRCL control.

noise.png

(Notes)
   BS actuator = 2.190150e-08 / f2
   PRM actuator = 2.022459e-08 /  f2
  5581   Fri Sep 30 03:36:19 2011 SureshUpdateComputer Scripts / ProgramsCIOO modified, but not yet compiled

I have added a switch in series with the WFS_GAIN. And I have also added a LKIN_OUT_MATRX between the lockin-outputs and the MC suspensions.  This will enable us to drive the MC mirrors in any combination so that we can (in principle) attain pure translations and rotations of the MC axis.

I will compile the model later during the day.  This is just in case anyone one else were to compile c1ioo.mdl before then.

.

  5580   Fri Sep 30 03:14:18 2011 kiwamuUpdateCDSsuspension became crazy : c1sus rebooted

Quote from #5579

Then we restarted daqd.

[Suresh / Kiwamu]

The c1lsc and c1sus machine were rebooted.

 

- - (CDS troubles)

 After we restarted daqd and pressed some DAQ RELOAD buttons the c1lsc machine crashed.

The machine didn't respond to ssh, so the machine was physically rebooted by pressing the reset button.

Then we found all the realtime processes on the c1sus machine became frozen, so we restarted them by sshing and typing the start scripts.

However after that, the vertex suspensions became undamped, even though we did the burt restore correctly.

This symptom was exactly the same as Jenne reported (#5571).

We tried the same technique as Jenne did ; hardware reboot of the c1sus machine. Then everything became okay.

The burt restore was done for c1lsc, c1asc, c1sus and c1mcs.

 

- - (ITMX trouble)

During the trial of damping recovery, the ITMX mirror seemed stacked to an OSEM. The UL readout became zero and the rest of them became full range.

Eventually introducing a small offset in C1:SUS-ITMX_YAW_COMM released the mirror. The amount of the offset we introduced was about +1.

  5579   Fri Sep 30 02:56:56 2011 kiwamuUpdateCDSC1IOO.ini and C1LSC.ini files reverted

[Suresh/Kiwamu]

We found that the C1LSC.ini and C1IOO.ini file had been refreshed and there were a few recorded channels in the files.

So we manually recovered C1LSC.ini file using the daqconfig GUI screen.

For the C1IOO.ini file we simply replaced it by the archived one which had been saved in 22nd of September.

Then we restarted daqd.

  5578   Fri Sep 30 01:18:39 2011 kiwamuUpdateASCC1ASS : status update

Now the C1ASS servos are working fine.

However at the end of the scripts sometimes it changes the DC force (e.g. C1:SUS-ITMX_PIT_COMM and so on) by a wrong amount.

So for this bug, it misaligns the suspensions a lot. I will take a look at the script tomorrow.

Quote from #5543

However then I found the ASS_Xarm servo was not healthy.

  5577   Thu Sep 29 20:37:12 2011 MirkoUpdateComputersNew c1oaf c-code: Breaking in new way

[Mirko, Jenne]

Programmed a new implementation of the LMS in C. Compiles fine in gcc. The full code still kills c1lsc computer. Tried to go through the code uncommenting more and more. Not perfect in reproducability. The attached version should compile and keep c1oaf running, but not actually produce an adaptive filter. At some point the code just keeps c1oaf from starting up. Leaves the c1lsc computer in working order. At some point I got error messages like ..................................................................
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:OAF-ADAPT_CORR_BS_Name08", Connecting to: 192.168.113.62:50970, Ignored: c1lsc:34533"
    Source File: ../cac.cpp line 1209
    Current Time: Thu Sep 29 2011 19:18:17.219208306
..................................................................
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:OAF-ADAPT_CORR_BS_Name09", Connecting to: 192.168.113.62:50970, Ignored: c1lsc:34533"
    Source File: ../cac.cpp line 1209
    Current Time: Thu Sep 29 2011 19:18:17.225999915
..................................................................
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:OAF-ADAPT_CORR_ETMX_SW1R", Connecting to: 192.168.113.62:50970, Ignored: c1lsc:34533"
    Source File: ../cac.cpp line 1209
    Current Time: Thu Sep 29 2011 19:18:17.243037042
..................................................................

This usually indicates that there are multiple carepeater running. Didn't find where that would be. After rebooting c1lsc and c1sus a couple of times everything seems fine.

Attachment 1: ADAPT_XFCODE11-09-29---20-12.c
// LMS algorithm adaptive filtering for the Caltech 40m -- Sept. 2011 by M. Prijatelj

#define nDOF 8
#define nWIT 21
#define nTAPS 1000

void ADAPT_XFCODE(double *in, int inSize, double *out, int outSize) {

//First the DOFs and their switches
//int nDOF=8;
... 136 more lines ...
  5576   Thu Sep 29 12:56:27 2011 JenneUpdateAdaptive FilteringMeditations on the OAF

[Mirko, Den, Jenne]

We're modifying the c1oaf model, and we got to talking about the "Fx" part of "FxLMS".  In the past, we put in a guess for the filter.  What if we use the static wiener filter as the F, and send the wiener filtered witness channels to the adaptation algorithm? 

Are the wiener filter and the plant compensation filter ("Fx") the same?  Will this work?  Or is there some reason that they must be different?

Also:  Notes to self:  Put in filtered witness channels as well as regular into Adapt block.  Make sure that the order/number of inputs is correct.

  5575   Thu Sep 29 11:25:55 2011 JenneUpdateAdaptive FilteringTried new c-code, Fail.

[Mirko, Jenne]

Mirko edited the c-code to use Den's stuff that he put in the elog last night.  We then tried to compile and install, but it crashed c1lsc again.  We reverted to the simple, working c-code, pushed the physical reset button on c1lsc, and things started getting better.  The suspensions had the same problem as last night...we had to do a soft shutdown of c1sus to get things better again. 

I did a by-hand burt restore for all of the models on c1lsc and c1sus, since the auto burt restore isn't working.

  5574   Thu Sep 29 03:43:20 2011 kiwamuUpdateASCwrong channel assignment on IPPOS

The channels for IPPOS had been assigned in a wrong way.

Because of this, C1:ASC-IP_POS_X_Calc corresponds to the actual vertical motion and C1:ASC-IP_POS_Y_Calc is for the horizontal motion.

We should fix the database file to get the correct vertical/horizontal corrdinate.

  5573   Thu Sep 29 00:16:35 2011 DenUpdateComputersSegmentation fault fixed.

The OAF c-code crashed because of the segmentation fault. We've created arrays of static variables

    static int pst[nDOF];
    static int isFirst[nDOF];
    static adaptive_filter_state state[nDOF];

an tried to give in the to the ITERATE - function their current values

        datOut[i] = ITERATE(iterateDatIn, iterateNIn, pst[i], isFirst[i], state[i]);

ITERATE function was declared as

double ITERATE(double *datIn, int nIn, int pst, int isFirst, adaptive_filter_state state) {}

Here the segmentation fault comes out. Static variables are meant to be created only once but here in the function ITERATE we try to create them once again in a local form, because we give the variables by their values.

Instead, we must give the variables by their pointer, then the variables won't be created again during the function call and will be changed in the function.

        datOut[i] = ITERATE(iterateDatIn, iterateNIn, &pst[i], &isFirst[i], &state[i]);

       double ITERATE(double *datIn, int nIn, int *pst_s, int *isFirst_s, adaptive_filter_state *state_s)

In order not to change significantly Matt's code and use his notations we can add in the ITERATE function

    int pst = *pst_s;
    int isFirst = *isFirst_s;
    static adaptive_filter_state state;
    state = *state_s;

..................................Matt's code.........................................

    *pst_s = pst;
    *isFirst_s = isFirst;
    *state_s = state;

I've tested the program, now it does not give any segmentation faults and conserves memory that it uses.

  5572   Wed Sep 28 22:30:01 2011 JenneUpdateAdaptive FilteringOAF is disabled

I am leaving the OAF disabled, so there should be nothing that goes to the suspensions from the OAF. 

Disabled for the OAF means all the outputs are multiplied by 0 just before the signals are sent back over to the LSC system to be summed in and sent to the suspensions.  So 0 times anything should mean that the OAF isn't injecting signals.

In other news, while Mirko was trying to figure out the c-code, I began making a new OAF screen.  It is still in progress, but it's in c1oaf/master/C1OAF_OVERVIEW.adl  If you open it up, you can see for yourself that the OAF is disabled.  (Eventually I'll put an enable/disable button on the LSC screen also, but that hasn't happened yet.)

  5571   Wed Sep 28 22:25:25 2011 JenneUpdateComputersTorturing control computers. Fine again now

Quote:

[Mirko, Jenne]

We tried to run an extended version of Matt's LMS adaptive filter c-code. We got the extension to compile separately in gcc first. Then after some tweaking of the code we could make-install c1oaf with the c-code.

This killed c1lsc (the FE computer running c1oaf). Not responding to ssh or even pings. We replaced the bad c-code with harmless code, then reset c1lsc via the hardware button. While looking for c1lsc we discovered the problem with c1iscy network card (see previous entry).

After c1lsc reboot, restart of the FB, and a BURT restore not ok yet

 We had lots of trouble damping the Vertex Suspensions after this craziness.  A symptom was that even if all of the damping servos on an optic were OFF, and I turned the watchdog on (LSC is disabled, so no OAF siganls, no LSC signals), there were signals going to the coils. 

We did a reboot of the c1sus computer, did another BURT restore, and the optics started damping happily.   Burt restore, at least for c1susepics and c1mcsepics, seems to not be happening automatically.  I thought it was supposed to happen when the model was restarted?

Things now appear to be normal again.

  5569   Wed Sep 28 21:28:34 2011 MirkoUpdateComputersTorturing control computers. Fine again now

[Mirko, Jenne]

We tried to run an extended version of Matt's LMS adaptive filter c-code. We got the extension to compile separately in gcc first. Then after some tweaking of the code we could make-install c1oaf with the c-code.

This killed c1lsc (the FE computer running c1oaf). Not responding to ssh or even pings. We replaced the bad c-code with harmless code, then reset c1lsc via the hardware button. While looking for c1lsc we discovered the problem with c1iscy network card (see previous entry).

After c1lsc reboot, restart of the FB, and a BURT restore not ok yet

  5568   Wed Sep 28 21:23:23 2011 MirkoUpdateComputersISCY FE network card / cable not ok

[Mirko,Jenne]

We discovered that the left network cable is not rigidly connected to the back of the ISCY FE computer. You can easily pull it out a mm disconnecting it. It should click rigidly in place. Not clear if it's the cable or the network card.

  5567   Wed Sep 28 18:39:50 2011 MirkoUpdatePEMBLRM seismic channels in c1pem

[Mirko,Jenne]

Created 5-band BLRMS for seismometer data (Gur1, Gur2 and STS1 each in x,y,z respectively) and accelerometer 1 through 6.

Bands are:
0.1Hz-0.3Hz
0.3Hz-1Hz
1Hz-3Hz
3Hz-10Hz
10Hz-30Hz
each with a fitting 4th order butterworth bandpass.

Data is recorded at 256Hz as e.g. C1:PEM-ACC1_RMS_RMS_0p3_1_OUT_DQ. For the 75 channels we have that corresponds to the data rate of just 1.2 16kHz channels.

c1pem execution time increased fom 6-7us to 15-16us out of 480us available.

  5566   Wed Sep 28 15:33:58 2011 SureshUpdateComputer Scripts / Programsediting database files for medm screens and restarting the slow c1psl machine

I changed the names on a switch(SW1) in the C1:PSL-FSS screen.  To do this I had to edit the psl.db database file in the directory /cvs/cds/caltech/target/c1psl.  After this change, when I executed this screen, all fields in the C1PSL_FSS screen went blank.  As the change to database file takes effect only after we restart the C1PSL machine (slow machine) I went ahead and reset the c1psl machine.  I then used the burttoday to locate the most recent snapshot files and then used burtgooey to restore all the values in the c1psl.snap file.

Everything back to normal now.

 

  5565   Wed Sep 28 14:15:40 2011 JenneUpdateComputersEdits to c1pem, c1oaf

[Mirko, Jenne]

Mirko edited c1pem to have some new BLRMS channels.

I added a master Enable switch to the c1oaf.

Both were compiled, and restarted.  fb rebooted.  All looks okay (hopefully)

  5564   Wed Sep 28 13:30:01 2011 JenneUpdatePSLPMC was unlocked

Relocked the PMC.  MC came back immediately.

  5563   Wed Sep 28 07:46:42 2011 steveUpdateSUSDsub connections at the back of 1X5 are fixed

 

 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

  5562   Wed Sep 28 07:36:41 2011 steveUpdateSUSITMY damping restored

ITMY suspention damping restored

  5561   Wed Sep 28 02:42:04 2011 kiwamuUpdateCDSsome DAQ channel lost in c1sus : fb, c1sus and c1pem restarted

Somehow some DAQ channels for C1SUS have disappeared from the DAQ channel list.

Indeed there are only a few DAQ channels listed in the C1SUS.ini file.

I ran the activateDQ.py and restarted daqd.

Everything looks okay.  C1SUS and C1PEM were restarted because they became frozen.

  5560   Wed Sep 28 00:06:21 2011 JenneUpdateSUSWatchdog rearmed

Quote:

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.

  5559   Tue Sep 27 20:02:19 2011 KojiUpdateSUSWatchdog rearmed

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.

  5558   Tue Sep 27 15:33:03 2011 JenneUpdateComputersMaking models, wreaking havoc

[Jenne, Mirko, Den]

We have entered into an adventure in model compiling.  What follows is a stream-of-consciousness report of what the hell we're doing, so Jamie can figure it out and fix it if everything goes to hell.

Note that for the first part of things, we have used a new version of the Adaptive XFCODE, which Mirko and Den modified last night to be able to handle multiple control signal inputs.  

On c1lsc, make uninstall-daq-c1oaf, make clean-c1oaf, make c1oaf.

***ERROR: The following IPCx RECEIVER module(s) not found in the file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc:

                C1:RFM_OAF_MCL

On c1sus, make uninstall-daq-c1sus, make clean-c1sus, make c1sus.  (This was an accident.  I should have been making c1rfm.  Oops.)  Then make install-c1sus.  It looks like this automatically did make install-daq-c1sus and make install-screens-c1sus, so I'm not doing those. 

On c1sus, make uninstall-daq-c1rfm, make clean-c1rfm, make c1rfm.

***ERROR: The following IPCx RECEIVER module(s) not found in the file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc:

                C1:IOO-RFM_MCL


On c1ioo, make uninstall-daq-c1ioo, make clean-c1ioo, make c1ioo.  No errors.

On c1lsc, make c1oaf.  Here's some of the ouptut, with some of the error stuff:

: warning: ISO C90 forbids mixed declarations and code
/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../controller.c:2954: warning: ISO C90 forbids mixed declarations and code
make[3]: *** [/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/c1oaffe.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf] Error 2
make[2]: Leaving directory `/usr/src/linux-2.6.34.1-cs'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf'
make: *** [c1oaf] Error 2

Again on c1lsc, make clean-c1oaf, make c1oaf.  Here are some things:

Warning:  variable "sysnum" is used but not declared.

In file included from build/c1oafepics/c1oaf.i:38:
src/include/fmReadCoeff.h:4:1: warning: "NO_FM10GEN_C_CODE" redefined
<command-line>: warning: this is the location of the previous definition

build/c1oafepics/c1oaf.i:5156: warning: passing argument 2 of 'strcpy' discards qualifiers from pointer target type
/usr/include/string.h:127: note: expected 'const char * __restrict__' but argument is of type 'volatile char *'

/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../../include/drv/inputFilterModule1.h:5: note: expected 'double *' but argument is of type 'long unsigned int *'

/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/../controller.c:2780: warning: ISO C90 forbids mixed declarations and code

make[3]: *** [/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf/c1oaffe.o] Error 1
make[2]: *** [_module_/opt/rtcds/caltech/c1/core/branches/branch-2.1/src/fe/c1oaf] Error 2
make[1]: *** [default] Error 2
make: *** [c1oaf] Error 2

Again, on c1lsc, make clean-c1oaf, make c1oaf.  More errors, pretty similar.  Then we changed the name of the adaptive filtering code, so maybe it will work now?  We had called the block "TOP_XFCODE", but that was the name of the old .c code.  The block used to be called "XFCODE", in a subsystem "TOP".  So now we named the .c code "ADAPT_XFCODE" since the block is "XFCODE", and the subsystem is "TOP".

Again, on c1lsc, make clean-c1oaf, make c1oaf.  Errors, they look the same.

Mirko is now modifying c1oaf.mdl to look more like the old version, with only one control signal input, so that we can use the old XFCODE that has been around for years.

First, we completely took out the .c code entirely.  Now the c1oaf.mdl is just signals and matricies, no c-code is called.  We did make clean-c1oaf, make c1oaf, and pretty much all of the same errors are present.
 

We took out the buses, and did make clean-c1oaf, make c1oaf, and we got a whole lot of warnings, but no "Error 2"'s.  This seems good.  We're going to try replacing those buses with Muxes, and see how that goes.

Now we're going to try to install the c1oaf, because maybe all the errors and shit we're seeing is just useless crap, and there aren't actually problems...here we go!

That seemed to work, and the c1oaf model on the GDS status screen seems happy.  Numbers are moving around, which is my only current diagnostic.

Okay, now Mirko is going back to the full, new c1oaf, but replacing the Buses with Muxes. 

Did a make clean-c1oaf, make c1oaf, got errors again.

Once again removed the .c code.  Just put in a matrix instead. Did make clean-c1oaf, make c1oaf.  No errors. 

Den did a reorganization of the .c code, and we put it back in to the simulink model.  Trying again the making stuff.  Fail..Basically the same errors as before.

Next up:  Putting in .c-code, but something which basically does nothing.  Just defines all the outs as zeros.  Make stuff.  Still had problems, same errors.  Grrrr, argh. 

Found the RCG manual:  T080135-v4.  In it, when talking about including c-code, it had an example of totally simple code.  We tried out their version of simple code, and it worked.  No errors!  Now to figure out what is same and different between our simple code and theirs.

 PUT THE RIGHT STUFF in the Block Properties for the c-code, including name of the .c file, and path to the .c file.  This is critical!!  Now we can make some of our simple versions work, but not all.  We're slowly increasing complexity of our c-code...

 At some point in the last hour, I tried a make install-c1oaf, and then checked the screens, and they all had bad white boxes.  So even though the model seemed to compile (at one point), the channels and screens aren't happy yet.  But that's really a project for after the code compiles happily.

Okay, some progress was made to get the c-code running, and compiling, but it's not all there yet.  We're putting in a simple, useless version of the c-code so we can try compiling everything else.

Everything is compiled, installed, there are no red lights on the GDS_STATUS screen.  All seems okay for locking for tonight.

 

  5557   Tue Sep 27 11:52:33 2011 JenneUpdateAdaptive FilteringPlan for making MC_F

Quote:

Quote:

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

 

Is it okay to have two names for the same signal?  We would have both MCS_MCL and MC_F referring to MC length signal.  This signal is picked up from the MC-Servo (analog) and brought into the CDS through the adc_0_0 channel in C1IOO.   Then this signal is sent from C1IOO to C1MCS model without going through the c1rfm model.  This seems to break the current protocol that signals passed between machines have to go through the c1rfm model.  It should be sufficient to send this signal to c1rfm once and from there redirect to MCS and OAF from there, with an appropriate name.

 Suresh makes a fine point.  I think the channel between c1ioo and c1mcs should always have had to go through the c1rfm model.  I don't know why it wasn't.  Anyhow, I have changed things so that there is one signal passing from c1ioo to c1rfm, and that signal is split in two, and goes to both c1oaf and c1mcs.  The naming convention I used last night is the one I kept:  C1:IOO-RFM_MCL goes from c1ioo to c1rfm, and then C1:RFM-OAF_MCL goes from c1rfm to c1oaf, and C1:RFM-MCS_MCL goes from c1rfm to c1mcs. 

We can't compile until Mirko and I figure out what to do with the OAF model though.  Mirko, Den and I were looking at the c1oaf model, to make sure it is ready to compile, and I'm not sure that it is.  And we need everything with common channel names to be compiled at the same time, so I can't compile any of the models today, until we get this figured out.

The problem is thus:  The old TOP_XFCODE that mevans wrote back in 2008 takes in a certain number of inputs, calculates the new filter coefficients, and spits out the filtered signals.  Back in those days, we only ever gave the adaptive system one control (target) signal at a time.  Now, we want to be able to do multiple, if we so desire.  I don't know exactly how to do this yet.  Either we need to modify the code to make it a super-code, or we can have one copy of the code for each control signal (MC_F, XARM, YARM, DARM, MICH, etc...).  Do we want to have one code adapt everything at once, and have a giant MIMO system, or do we want to have many SISO-like systems in parallel (SISO-like, because each one would take in one control signal, and many seismometer signals, and output many filtered seis signals, but it wouldn't be combining control signals together)? 

Either one of these options could be waaay to computationally tough for the computer.  The old computer was basically railed when we had one adaptive block, with one control signal and 7 seismometers.  7 was the max number of auxiliary channels we could use.  So, how much faster are the new computers?? Do we need to have one OAF per DoF that we want to filter? 

  5556   Tue Sep 27 11:43:59 2011 JenneUpdateelogElog has been dying a lot lately...

WTF?

  5555   Tue Sep 27 09:47:52 2011 SureshUpdateAdaptive FilteringPlan for making MC_F

Quote:

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

 

Is it okay to have two names for the same signal?  We would have both MCS_MCL and MC_F referring to MC length signal.  This signal is picked up from the MC-Servo (analog) and brought into the CDS through the adc_0_0 channel in C1IOO.   Then this signal is sent from C1IOO to C1MCS model without going through the c1rfm model.  This seems to break the current protocol that signals passed between machines have to go through the c1rfm model.  It should be sufficient to send this signal to c1rfm once and from there redirect to MCS and OAF from there, with an appropriate name.

  5554   Tue Sep 27 08:51:29 2011 PaulUpdateSUSOplev filter optimization for 2 poles and 2 zeros

Quote:

Quote:

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 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.

 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.

  5553   Tue Sep 27 04:13:22 2011 kiwamuUpdateLSCtonight's locking activity

The lock of PRMI wasn't so robust although it could stay locked for more than 10 minutes.

There have been 2-3Hz spikes in everywhere. It needs to be investigated.

 

(to do)

 + Diagnosis on the suspensions.

 + Check the beam centering on the RFPDs.

 + Check the f2a filters on PRM and BS.

 + Health check of the suspensions by locking some cavities and measuring the noise spectra for comparison.

 + Trying to use another signal port other than AS55.

 

(Spikes)

 The attached picture below is an example of the REFLDC and POXDC signals in time series.

This was when PRCL and MICH were locked by REFL33_I and AS55_Q respectively.

PRMI.png

Note that when PRMI is unlocked, REFLDC goes to ~ 5000 counts and POXDC goes within ADC noise of ~ 1 counts.

According to the POP camera it looked like something was oscillating in the YAW direction which coincided with the spikes.

I tried finding any suspicious angular motions in the ITMs, BS and PRM olevs, but none of them showed the 2-3 Hz feature.

  5552   Mon Sep 26 22:40:41 2011 JenneUpdateComputersWe now have BURT restore for slow channels
[Jenne, Koji]

After much Perl-learning and a few iterations, we have fixed the burt restore script, so that it actually does the slow channels. We have so far had one successful run, at 22:25, and the regular cron job should start doing the slow channels as of 23:07.
  5551   Mon Sep 26 20:04:03 2011 KojiUpdatePSLMC lock has been recovered

[Kiwamu Suresh Koji]

Some main parameters of the PSL has been recovered using Dataviewer and some screen snapshots, as seen in the screenshots below.

Attachment 1: snapshot1.png
snapshot1.png
Attachment 2: snapshot2.png
snapshot2.png
Attachment 3: snapshot3.png
snapshot3.png
  5550   Mon Sep 26 18:59:11 2011 JenneUpdateAdaptive FilteringPlan for making MC_F

Quote:

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

 [Jenne, Den]

Suresh tells us that he already has this channel physically plugged in.  Probably as a result of Valera's MCASS work.  Neat.  We just have to make the channel.  Right now the signal goes straight into some lockin stuff, so there is no actual "C1:IOO-MC_F" channel.

We don't want to make the new channel right now, since it is nighttime, and Kiwamu and Suresh are working on things.  So.  Tomorrow.  In the morning:

We will add a fast test point to the C1IOO model, and call it "C1:IOO-MC_F".  We will also route this signal via memory stuff over to the OAF model so that we can do adaptive filtering on the MC.  Then we will compile all the things.  Or at least all the things that we touched.  This will go hand-in-hand with the compling of Mirko's sweet new OAF model, which we were planning on compiling in the morning anyway.  Neat.

Things to compile tomorrow:  c1ioo and c1rfm, because of channel routing.  c1oaf because of all the new stuff.  That should be all.

  5549   Mon Sep 26 17:49:51 2011 KojiUpdatePSLc1psl

[Koji Suresh]

c1psl has got frozen during our ezcaread/write business.
After the target was rebooted and we lost the previous setting as there was no burt snapshot for the slow targets since Dec 13, 2010.

It seems that burtrestore is essential for the bootstrapping of the MC servo, as the auto locker script refers the locking parameters
from the PSL setting values (C1PSL_SETTINGS_SET.adl).

Jenne is working on the recovery of the snap-shotting for the slow targets.

  5548   Mon Sep 26 17:49:21 2011 JenneUpdateComputersWe now have BURT restore for slow channels

Koji and Suresh found that there have not been any autoburt snapshots taken of slow channels since ~December 13th 2010.  Not good!

We have found an elog from Joe talking about autoburt changes from that day:  elog 4046

Joe pointed all of the autoburt stuff to the new directory system, so it now decides to take a snapshot of every system in the *new* target directory.  This means, since all of the aux things were left in the *old* target directory that none of them were getting snapshots taken.  I have added the old target path back to the autoburt cron file so that every hour it will search through both old and new target directories and take snapshots of everything in both. 

So, the systems which will now once again have autoburt snapshots taken are the following:

c1aux

c1auxex

c1auxey

c1dcuepics

c1iool0

c1iscaux

c1iscaux2

c1iscepics

c1losepics

c1omcepics

c1psl

c1susaux

c1vac1

c1vac2

 

I moved some old stuff (and especially things which would conflict with the new stuff) to the old target directory/oldfe/ :  c1ass, c1assepics, c1susvme1, c1susvme2, c1sosvme, c1iovme.

The following systems don't have an autoburt.req file, so don't get snapshots:  c0daqawg, c1daqctrl, c1dcu1, c1iscex, c1iscey.  If any of these need autoburts, we should create them.

All the new systems in the new target directory still have their autoburts working.

The first test of this will be in a few minutes, at 18:07:00 Pacific during the regular cron job.  Hopefully nothing crashes....

  5547   Mon Sep 26 16:42:08 2011 kiwamuUpdateSUSITMX ULSEN : fixed

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.

connection.png

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)

ITMXsensors.png

 

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.

 

Quote from #5546

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

 

ELOG V3.1.3-