Correction: Koji noted that Mirko actually reports a PM modulation index of 0.17 for the 11 MHz sideband (elog: http://nodus.ligo.caltech.edu:8080/40m/5462. This means

f) the amplitude ratio of the PM side-band to carrier is half of that = 0.084

g)  the PM to AM amplitude ratio as 0.084 / [4.0 x 10^(-4)]  = 209.

The MC was not damping earlier this morning around 11:45AM.  The reason was that the INMATRIX on all the three MC1, 2 and 3 were zero.   This was seen earlier when autoburt did not restore this.

This got fixed when I Burt-Restored c1mcsepics.snap

In the afternoon we had to restore c1mcs again to restore the MC_TRANS channels because its INMATRIX was also zero.

Can we do something to make sure this gets done in the autoburt properly?

I thought this problem might be arising because the MC2_TRANS QPD signals are not being passed from the c1mcs to c1ioo models over the rfm.   But there was no way to check if there is any data being picked up in c1mcs model.  So I copied the MCTRANS block from the c1ioo model into the c1mcs.  This block takes the four segments of the MC2_TRANS QPD and computes the pitch, yaw and sum signals from that.   It also exports these into epics channels.  I then recompiled and started the c1ioo c1mcs and c1rfm models. 

Restared fb at

Tue Oct  4 15:19:10 PDT 2011

Koji then noted that the MC2_TRANS filter banks in c1rfm and in c1ioo were showing nonzero values.   So the signals were infact reaching the c1ioo model.  They were being blocked by the INMATRIX (which the autoburt had not restored) of the MC_TRANS block, because all its elements were zero.  We burtrestored the c1iooepics to about 30hrs ago and then MC_TRANS signals were back in the LOCK_MC screen.

The shutter before the MC was closed at 3:30 as I started working on the RFAM.

MC REFL (INLOCK): 0.6~0.7
MC REFL (UNLOCK): 6.9
MC TRANS: 50000~52000

I relocked the PMC (why is it unlocking so much lately??), and then noticed that even though the MC is locked, MC Trans Sum, P, Y, are all seeing digital zero.  I'm putting Suresh, as IOO guy, in charge of figuring it out.

[Alex, Mirko]

Alex fixed the computers this morning. It was in fact a dolphin problem:

Hi Jenne,  figured it out. Even though dxadmin said the Dolphin net was fine, it wasn't. Something happeneed to DIS networkmanager and I had to restart it. It is running on fb: 

controls@fb ~ $ ps -e | grep dis 12280 ?        00:00:00 dis_networkmgr
controls@fb ~ $ sudo /etc/init.d/dis_networkmgr restart

Once the restart was done both c1lsc and c1sus nodes were configured correctly, they printed the usual "node 12 is OK" "node 8 is OK" messages into the dmesg and was able to run /etc/start_fes.sh on lsc and sus to load all the FEs.  Alex

Some lights on c1lsc were still red: C1:DAQ-FBO_C1SYS_SYS and the smaller red light left of it. Restarted the fb. Didn't help. Restarted c1lsc, all green now.
Restored autoburt from Oct 3. 19:07 on c1lsc and c1sus.

 c1lsc and c1sus are still down. Only ETMX and ETMY are damped

[Koji / Kiwamu]

 We did several tests to figure out what could be a source of the computer issue.

The Dolphin switch box looks suspicious, but not 100% sure.

(what we did)

 + Removed the pciRfm sentence from the c1x04 model to disable the Dolphin connection in the software.

 + Found no difference in the Makefile, which is supposed to comment out the Dolphin connection sentences.

   ==> So we had to edit the Makefile by ourselves

 + Did a hand-comilpe by editing the Makefile and running a make command.

 + Restarted the c1x04 process and it ran wihtout problems.

   ==> the Dolphin connection was somehow preventing the c1x04 process from runnning.

 +  Unplugged the Dolphin cables on the back side of the Dolphin box and re-plug them to other ports.

   ==> didn't improve the issue.

 + During those tests, c1lsc frequently became frozen. We disabled the automatic-start of c1lsc, c1ass, c1oaf by editting rtsystab.

  ==> after the test we reverted it.

 + We reverted all the things to the previous configuration.

[Jenne, Mirko, Kiwamu, Koji, and Jamie by phone]

We just got off the phone with Jamie.  In addition to all the stuff that Kiwamu mentioned, Mirko reverted the c1oaf model and C-code to stuff that was working successfully on Friday (using "svn export, rev # 1134) since that's what we were working on when all hell broke loose.

We did a few rounds of "sudo shutdown -h now" on c1lsc and c1sus machines, and pulled the power cords out.  

We also switched the c1ioo and c1lsc 1PPS fibers in the fanout chassis, to see if that would fix the problem.  Nope.  c1ioo is still fine, and c1lsc is still not fine.

Still getting "No Sync".

We're going to call in Alex in the morning, if we can't figure it out soon.

[Mirko / Jenne / Kiwamu]

Just a quick update. All the realtime processes on the c1lsc and c1sus machine didn't run at all.

Somehow the c1xxxfe.ko kernel module, where xxx is x04, x02, lsc, ass, sus, mcs, pem and rfm failed to be insmod.

The timing indicators on the c1lsc and c1sus machine are saying NO SYNC.

- According to log files (target/c1lsc/logs/log.txt)

insmod: error inserting '/opt/rtcds/caltech/c1/target/c1lsc/bin/c1lscfe.ko': -1 Unknown symbol in module

- dmesg on c1lsc (c1sus also dumps the same error message):

[   45.831507] DXH Adapter 0 : sci_map_segment - Failed to map segment - error=0x40000d01
[   45.833006] c1x04: DIS segment mapping status 1073745153

DXH dapter is a part of the Dolphine connections.

When a realtime codes is waking up, the code checks the Dolphin connections.

The checking procedure is defined by dolphin.c (/src/fe/doplhin.c).

According to a printk sentence in dolphin.c the second error message listed above will return status "0" if everything is fine.

The first error above is an error vector from a special dolphin's function called sci_map_segment, which is called in dolphin.c.

So something failed in this sci_map_segment function and is preventing the realtime code from waking up.

Note that sci_map_segment is defined in genif.h and genif.c which reside in /opt/srcdis/src/IRM_DSX/drv/src.

[Koji, Suresh]

In the previous measurement, the PDA 255 had most probably saturated at DC, since the maximum ouput voltage of PDA255 is 5V when it is driving a 50 Ohm load.  It has a bandwidth of 0 to 50MHz and so can be reliably used to measure only the 11 MHz AM peak.  In this band it has a conversion efficiency of 7000 V per Watt (optical power at 1064nm).  [Conversion efficiency:  From the data sheet we get 0.7 A/W of photo-current at 1064nm and 10^4 V/A of transimpedance]  The transimpedance at 55 MHz is not given in the data sheet.  Even if PDA255 is driving a high impedance load, at high incident power levels the bandwidth will be reduced due to finite gain x bandwidth product of the opamps involved, so the conversion efficiency at 11 MHz would not be equal to that at DC.

So Koji repeated the measurement with a lower incident light level:

**********************************

V_DC = 1.07 V  with 50 Ohm termination on the multimeter.

Peak height at 11 MHz on the spectrum analyzer (50 Ohm input termination) = -48.54 dBm

***********************************

Calculation: 

a) RF_Power at 11 MHz :  -48.45 dBm = 1.4 x 10^(-8) W

b) RF_Power = [(V_rms)^2] / 50_ohm  ==> V_rms = 8.4 x 10^(-4) V

c) Optical Power at 11 MHz: [V_rms / 7000] = 1.2 x 10^(-7) W

d) Optical Power at DC =  [V_DC / 7000] = 1.46 x 10^(-4) W

e) Intensity ratio:  I_AM / I_c = 7.9 x 10^(-4) . AM:Carrier amplitude ratio is half of the intensity ratio = 4.0 x 10^(-4)

f) PM amplitude ratio from Mirko's measurement is 0.2

g) The PM to AM amplitude ratio is 506

_________________________________

As the AM peak is highly dependent upon the drifting EOM position in yaw, it is quite likely that a higher PM/AM ratio could occur.  But this measurement shows how small it could get if the current situation is allowed to continue.

The input matrix of IPPOS were fixed so that the horizaontal motion correctly shows up in X and the vertial is Y.

(what I did)

 + The data base file, QPD.db, were edited.

  QPD.db is a part of the c1isxaux slow machine and it determines the input matrix for deriving the X/Y signals from each quadrant element.

 + The previous input matrix was :

      X = (SEG1 + SEG4) - (SEG2 + SEG3)

      Y = (SEG1 + SEG2) - (SEG3 + SEG4)

 + The new matrix which I set is :

     X = (SEG1 + SEG2) - (SEG3 + SEG4)

     Y = (SEG1 + SEG4) - (SEG2 + SEG3)

    The new matrix is a just swap of the previous X and Y.

 + Then c1isxaux was rebooted by :

     telnet  c1iscaux

     reboot          

 + The I did the burt restore it to this morning.

 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.

 I copied the Kissel button generator scripts folder into scripts:

/opt/rtcds/caltech/c1/scripts/KisselButtonGenerator/

Maybe this isn't the most intuitive place ever, since it's a script that only has to do with medm screens, but at least it's better than hidden in the depths of Koji's LSC medm path.....

 More meditations...

Mirko and I were talking about the tunability required for each DoF.  For right now, we're going to give each DoF its own mu and tau (adaptation gain and adaptation decay), but we're leaving all of the other things (number of taps, number of witnesses, delay, downsample rate) the same for each DoF's adaptation.  This may need to change later, but we'll get there when we get there. 

The one I'm most concerned about is the number of witnesses...  Mirko is suggesting that we give each adaptation algorithm all witnesses, and unused ones should converge to ~0.  I agree in principle, but I'm not sure that it's actually going to work that way.  I think we may need to be able to tell the algorithm which witnesses to look at for which DoF. 

Also, the Delay.... we may need to adjust it for each DoF.  In Matt's OAF "manual" in elog 395, he mentions the need to calculate the delay based on a plant TF.  Presumably since (except for the MC) all the witnesses come in together, and all the DoFs come in together, the delay should be about the same for all?  We'll have to see...

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

 [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 failed to start Rana's favorit anciant desktop computer at the vac rack. He has to baby this old beast just a little bit more.

Vacuum status: Vac Normal was reached through Farfalla: Rga was switched back to IFO and and Annuloses are beeing pumped now.

V1 was closed for about a day and the pressure reached  ~2.8 mTorr in the IFO.  This leakrate plus outgassing is normal

The ref cavity 5000V was turned on.

The only thing that has to be done is to restart the RGA. I forgat to turn it off on Friday.

My goal of today was to lock PRMI without using AS55 and it is 50% successful.

The sideband-resonance PRMI (SB-PRMI) was locked with REFL33_I and REFL55_Q for the PRCL and MICH control respectively.

The carrier-resonance PRMI wasn't able to be locked without AS55.

     (it looked no clean MICH signals at the REFL ports.)

(Motivation)

 The motivation of not to use AS55 came from the suspicion that AS55 was injecting some noise into MICH (#5595).

So I wanted to try another RFPD to see if it helps the stability or not. 

(locking activity)

  The lock of SB-PRMI was quite stable so that it stayed locked more than 30 minutes (it ended because I turned off the servos.)

Then I briefly tried DRMI while PRCL and MICH kept locked by the same control loops, namely REFL33_I and REFL55_Q.

The lock of MICH and PRCL looked reasonably robust against the SRCL fringes, but wasn't able to find a good signal for SRCL.

I think I am going to try locking DRMI tomorrow.

 - - settings

    Demod phase for REFL55 = -45.3 deg

    Demod phase for REFL33 = -14.5 deg

    Whitening gain for REFL55 = 4 (12 dB)

    Whitening gain for REFL33 = 10 (30 dB)

    MICH gain = 100

    PRCL gain = 8

(misc.)

 + I removed an iris on the ITMY table because it was in the way of POY. See the picture below.

  + I found that burtrestore for the ETMX DC coil forces were not functional.

  => currently ETMX's "restore" and "mislalign" buttons on the C1IFO_ALIGN screen are not working.

  => According to the error messages, something seemed wrong on c1auxex, which is a slow machine controlling the DC force.

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.

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

Just a quick report.

The AS55 signal contains more noise than the REFL signals.

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

 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.

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.

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.

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

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

 [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)

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.

[Mirko / Kiwamu]

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

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 10³

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

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.

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

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

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

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.

.

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

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

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.

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

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

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

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.

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.

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

 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.

[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

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

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

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.