I locked each arm, and the Michelson last night, no problems after I increased the Yarm gain from 0.1 to 0.2 .  I checked the green beam alignment just before going home, and both of the green beams are locking on ~03 or 04 modes, so aligning them is on the list for today.

Action Items:

IFO:

         Arm cavity sweeps, mode scan - JENNE

        Align AS OSA (others?) - JENNE       

        Investigate PRMI glitches, instability (take PRM oplev spectra locked, unlocked, to see if PRM is really moving) - KOJI, JENNE, DEN

         Connect up beatbox for Xarm use - KOJI with JENNE       

TT:

Prepare electronics for TTs (coil drivers) - JAMIE

In-air TT testing to confirm we can control / move TTs before we vent (starting in ~2 weeks) - SURESH

Connect TTs to digital system and controls, lay cables if needed - JAMIE with SURESH

OAF:

OAF comparison plot, both online and offline, comparing static, adaptive and static+adaptive - DEN

Static-only OAF noise budget (Adaptive noise budget as next step) - DEN

Build amplifiers for new small microphones - DEN 

SLC:

Black glass: to clean&bake - KOJI

Scattered light measurement at the end stations: design / confirmation of the mechanical parts/optics/cameras - JAN

MM:

IPPOS beam measurement - SURESH with JENNE

AS beam measurement (if beam is bright enough) - SURESH and JENNE

Mode matching calculations, sensitivity to MC waist measurement errors, PRM position - JENNE

Think up diagnostic measurement to determine mode matching to PRC while chambers are open, while we tweak MMT - JAMIE, JENNE, KOJI, SURESH

Computers:

       Upgrade Rossa, Allegra to Ubuntu, make sure Dataviewer and DTT work - JAMIE

[Jenne/Den/Koji]

We saw some white boxes on the LSC screens.
We found c1iscaux2 is not running.

Once the target was power-cycled, these epics channels are back.
Then c1iscaux2 were burtrestored using the snapshot at 5:07 on 4/16, a day before the power glitch.

epicsThreadOnceOsd epicsMutexLock failed.
Segmentation fault
Number found where operator expected at -e line 1, near "0 0"
        (Missing operator before  0?)
syntax error at -e line 1, near "0 0"
Execution of -e aborted due to compilation errors.
Number found where operator expected at (eval 1) line 1, near "*  * 50"
        (Missing operator before  50?)
epicsThreadOnceOsd epicsMutexLock failed.
Segmentation fault
Number found where operator expected at -e line 1, near "0 0"
        (Missing operator before  0?)
syntax error at -e line 1, near "0 0"
Execution of -e aborted due to compilation errors.
syntax error at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
Number found where operator expected at (eval 1) line 1, near "*  * 50"
        (Missing operator before  50?)
epicsThreadOnceOsd epicsMutexLock failed.
status : 0
I am going to execute the following commands
ezcastep -s 0.6 C1:SUS-ETMX_PIT_COMM +-0,50
ezcastep -s 0.6 C1:SUS-ITMX_PIT_COMM +,50
ezcastep -s 0.6 C1:SUS-ETMX_YAW_COMM +,50
ezcastep -s 0.6 C1:SUS-ITMX_YAW_COMM +-0,50
ezcastep -s 0.6 C1:SUS-BS_PIT_COMM +0,50
ezcastep -s 0.6 C1:SUS-BS_YAW_COMM +0,50
hit a key to execute the commands above


[Jenne/Den/Koji]

We locked Xarm/Yarm and manually alignmed ITMX/ITMY/BS/ETMX/ETMY/PZT1/PZT2.

ITMY OPLEV was largely misaligned ==> The beam was centered on the QPD.

----

Then we aligned PRM using SB locking PRMI.

We noticed that OPLEV servo does not work. It made the PRM just noiser.

We went into the PRM table and found that the OPLEV beam was clipped in the vacuum chamber.
We tried to maximize the reflected beam from the window by touching the steering mirrors at the injection side.

Then the reflected beam was introduced to the center of the QPD.

After the alignment, the OPLEV QPD SUM increased to 4000ish from 200ish.
According to the OPLEV trend data, this is a nominal value of the QPD SUM.

Now the OPLEV servo does not go crazy.

 --

BS OPLEV beam was centered on the QPD.

After fixing the PRM tonight, all of the oplevs look okay. 

.....except ITMX, which looks like it's power dropped significantly after the CDS upgrade.  To be investigated tomorrow.

 I had a look-see at ITMX's oplev.  I can't see any clipping, so maybe the power is just low?  One thing that was funny though is the beam coming directly from the laser.  There is the main, regular beam, and then there is a thin horizontal line of red light also coming straight out of the laser.  I don't know what to do about that, except perhaps put an iris right after the HeNe, to block the horizontal part?  I'm not sure that it's doing anything bad to the optic though, since the horizontal part gets clipped by other optics before the beam enters the vacuum, so there is no real irregularity on the beam incident on the QPD.

I realigned the oplev on the QPD, using last night's ITMX alignment + whatever drift it picked up over night, so it may need re-recentering after Xarm is nicely aligned.

While walking past the PSL, I noticed that the PSL's doubling oven's heater was still disabled from the power outage.  As with the ETMY heater, I hit the Enable button, and it started warming up (according to the front panel at least).

I was interested what whitening filter do we have between MC servo and ADC. The shape is in the figure below, SR provided 1 V white noise. Before the whitening filter MC_F is measured in Volts with SR and ADC (for ADC the shape is calculated using the whitening filter form):

I also wondered if FSS or PZT servo can add noise to the mode cleaner length signal and what is their gain. It should be big, as the laser's calibration is ~1 MHz/V => to account for seismic noise of 10^-6 m at 1 Hz, the voltage given to the laser should be ~ 1 V. And it is indeed the case. The gain is ~1000. I measured the coherence between MC_F and the laser fast input. It is 1 in the range measured (0.05 - 100 Hz). FSS and PZT do not add significant noise.

Unfortunately, after the measurement when I unplugged BNS connector from the laser, I misaligned PMC. For several hours I adjusted the mirrors but could not significantly improve transmitted signal. I'll return to this issue tomorrow.

I suspect that it was just unlocked when you had disconnected the cable.

There is not reflection now. It seems that it is now misaligned after the alignment work.

So what you need is "align while scanning PZT -> lock -> align".

 No, no, it was unlocked after I connected the cable back. The beam was even not on the PMC. I'll try PZT -> lock -> align.

No matter how you connect/disconnect, touching the laser may cause the PMC unlocked.

At least, I don't see the PMC reflection on the PD.
This means that the beam towards the PMC is largely misaligned.

If you are not sure what is misaligned, stop touching the table.
Close the shutter of the laser on the laser housing and leave the optics as they are.

[Koji, Den]

Koji was right that I misaligned everything during the alignment work. I assumed that PMC should autolock and when I saw that it did not, I thought the laser is misaligned.

What we did:

1. Aligned mirrors to get the beam on the PD PMC REFL and PMCR camera. The PSL-PMC_RFPDDC was ~800 mV.

2. We disabled PMC servo, switching it to test position and changed "DC output adjust" by 0.01 in a loop

while true
do
    ezcawrite "C1:PSL-PMC_RAMP" -4.50
    ezcastep "C1:PSL-PMC_RAMP" "+0.01,450" -s "0.1"
    ezcawrite "C1:PSL-PMC_RAMP" 0.0
    ezcastep -s "0.1" -- "C1:PSL-PMC_RAMP" "-0.01,450"
done

3. While the script was running we adjusted the position of the beam on the far PMC mirror looking at an IR viewer. The goal is to align two steering mirrors to catch some resonances. We monitored them on the oscilloscope and on the PMCT camera.

4. We locked PMC and aligned steering mirrors.

c1sus and c1iscex computers could not connect to framebuilder, I restarted it, did not help. Then I restarted mx_stream daemon on each of the computers and this fixed the problem.

sudo /etc/init.d/mx_stream restart

I locked x,y arms and measured coherence between POS{X,Y}11_I_ERR, MC_F and seismometer signals.

Surprisingly, coherence between POSY and GUR1Y is low, but with GUR1X is relatively high. I wonder if this is due to MC that brings this x-axis noise to the arms.

I tried to figure out where additional (to seismic) noise enters to MC_F, so the coherence below 1 Hz is low (~0.2-0.5). I've examined noise in the path

PD -> DEMOD -> MC BOARD -> FSS -> PZT Controller -> LASER

• I terminated ADC and measured its noise
• connected MC BOARD OUT to ADC, terminated INPUT1 of the MC BOARD and measured noise
• connected DEMOD Q OUT to MC BOARD INPUT1, terminated PD INPUT on the DEMODULATOR and measured noise
• connected PD to DEMOD, blocked the beam incident to the PD and measured noise

 MC BOARD noise shows up only below 0.1 Hz and at 10 Hz where the whitening filter starts to work. SNR is ~2 at 4 Hz, so we might want to slightly improve whitening filter. But other then that path PD->DEMOD->MC BOARD is not responsible for additional noises below 1 Hz.

Next I connected SR785 to the laser and measured the closed loop feedback signal while MC was locked.

Coherence between MC BOARD OUT1 and feedback signal is high enough to assume that FSS and PZT controller are also not responsible for additional noise.

From the other hand MC2 SUSPOS measured by OSEMS shows good coherence with GUR1_X

That means that MC2 is indeed driven by seismic motion. In order to figure out if this is the case for MC1 and MC3, I rotated GUR2 by 45 degrees. When it will calm down, I'll measure coherence between OSEMs and seismic motion.

I've measured coherence between seismometer signals and OSEMS of MC 1,2,3

GUR1 was rotated on the angle pi / 4 relative to x arm to match suspos axis of MC1 and MC3. Coherence between MC2 and GUR2_X is high, between MC3 and GUR1_X is ~0.2 but is compensated by GUR1_Y, between MC1 and GUR1_Y below 1Hz is ~0.5 and is not compensated by GUR1_X.

Then I measured coherence between GUR1_Y and MC3 OSEMS in 3 regimes :

• FEEDBACK OFF, WFS OFF
• FEEDBACK ON, WFS OFF
• FEEDBACK ON, WFS ON

Once WFS are ON, signal becomes noisy, FEEDBACK is OK. Then I measured coherence between MC_F and GUR2_X with WFS ON and OFF

Coherence between MC_F and GUR2_X is less when WFS are ON in the range 0.2 - 1 Hz and 4 - 10 Hz. Moreover PSD of MC_F seems to be higher at 10 - 100 Hz. But this may be caused by other reasons.

Then I measured the coherence between IN and OUT signals in WFS_SERVO

One filter bank adds noise to WFS signals and because of that we loose coherence between MC_F and seismic motion.

 This effect is due to C1:IOO-WFS1_PIT_LIMIT=2000. When I turned if off, coherence between C1:IOO-WFS_PIT input and output signals restored

The other thing is that WFS actuate on the angular motion, but this couples to the position motion. We need to diagonalize the actuator.

OK. Then we should make this number bigger such that the coherence is still completely maintained.
Is this set in the auto locker? Or manually set?

LIMIT is set manually, auto locker does not change it. I've put C1:IOO-WFS1_PIT_LIMIT=4000, it seems to be fine for now.

I wanted to switch the implementation of IIR_FILTER from DIRECT FORM II to BIQUAD form in C1IOO and C1SUS models. I modified RCG file /opt/rtcds/rtscore/release/src/fe/controller.c by adding #define CORE_BIQUAD line:

#ifdef OVERSAMPLE
#define CORE_BIQUAD      
#if defined(CORE_BIQUAD)

C1IOO model compiled, installed and is running now. C1SUS model compiled, but during installation I've got an error:

controls@c1sus ~ 0$ rtcds install c1sus

Installing system=c1sus site=caltech ifo=C1,c1
Installing /opt/rtcds/caltech/c1/chans/C1SUS.txt
Installing /opt/rtcds/caltech/c1/target/c1sus/c1susepics
Installing /opt/rtcds/caltech/c1/target/c1sus
Installing start and stop scripts
/opt/rtcds/caltech/c1/scripts/killc1sus
Performing install-daq
Updating testpoint.par config file
/opt/rtcds/caltech/c1/target/gds/param/testpoint.par
/opt/rtcds/rtscore/branches/branch-2.5/src/epics/util/updateTestpointPar.pl -par_file=/opt/rtcds/caltech/c1/target/gds/param/archive/testpoint_120507_205359.par -gds_node=21 -site_letter=C -system=c1sus -host=c1sus
Installing GDS node 21 configuration file
/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1sus.par
Installing auto-generated DAQ configuration file
/opt/rtcds/caltech/c1/chans/daq/C1SUS.ini
Installing EDCU ini file
/opt/rtcds/caltech/c1/chans/daq/C1EDCU_SUS.ini
Installing Epics MEDM screens
Running post-build script

ERROR: Could not find file: test.py
Searched path: :/opt/rtcds/userapps/release/cds/c1/scripts:/opt/rtcds/userapps/release/cds/common/scripts:/opt/rtcds/userapps/release/isc/c1/scripts:/opt/rtcds/userapps/release/isc/common/scripts:/opt/rtcds/userapps/release/sus/c1/scripts:/opt/rtcds/userapps/release/sus/common/scripts:/opt/rtcds/userapps/release/psl/c1/scripts:/opt/rtcds/userapps/release/psl/common/scripts
Exiting
make: *** [install-c1sus] Error 1

Jamie, what is this test.py?

I'm still not super happy with the low power level of the ETMX oplev, so I went to investigate.

This is a 3-year plot.  The first ~year in the plot, the oplev sum is ~15000 cts, and in the most recent year, it's ~1000 cts.  A new HeNe was installed in May 2011 (elog 4686), with an output of 2.6mW, after the old one had died.  When the new one was installed, Steve said that it was giving ~1400 counts, so maybe 1000 isn't too, too embarrassing.  There is, however, a lens on the injection side, which is AR coated for 1064.  The power before this lens (measured with the Ophir, set to 632nm) was ~2.6mW.  The power after this lens was ~1.5mW.  Now THAT is embarrassing.  I'm adding replacing that lens to the to-do list (elog 6595), although I don't want to do it until such a time (maybe in an hour, maybe in a few days?) when I've got the Xarm locked / aligned, so I can nicely re-center the oplev.  UPDATE:  The lens is a KBC 037 (-100) lens, and the sticker on the lens mount says coated for 1064.  We don't have any KBC037's in the visible lens kits, so we need to get one before I can do this replacement (PURCHASED 10pm).

There is an elog (elog 5004) from July 2011, which mentions that these channels have not been saved for a long time, so that's why there's the year-long gap. 

GUR1_XYZ_IN1 and GUR2_XYZ_IN1 are the same and equal to GUR2_XYZ.  This is bad since GUR1_XYZ_IN1 should be equal to GUR1_XYZ.  Note that GUR#_XYZ are copies of GUR#_XYZ_OUT, so there may be (although there isn't right now) filtering between the _IN1's and the _OUT's.  But certainly GUR1 should look like GUR1, not GUR2!!!

Looks like CDS problem, maybe some channel-hopping going on? I'm trying a restart of the c1sus computer right now, to see if that helps.....

Figure:  Green and red should be the same, yellow and blue should be the same.  Note however that green matches yellow and blue, not red.  Bad.

[Jenne, Den]

We decided to reboot C1SUS machine in hope that this will fix the problem with seismic channels. After reboot the machine could not connect to framebuilder. We restarted mx_stream but this did not relp. Then we manually executed

/opt/rtcds/caltech/c1/target/fb/mx_stream -s c1x02 c1sus c1mcs c1rfm c1pem -d fb:0 -l /opt/rtcds/caltech/c1/target/fb/mx_stream_logs/c1sus.log

but c1sus still could not connect to fb. This script returned the following error:

controls@c1sus ~ 128$ cat /opt/rtcds/caltech/c1/target/fb/mx_stream_logs/c1sus.log

c1x02
c1sus
c1mcs
c1rfm
c1pem
mmapped address is 0x7fb5ef8cc000
mapped at 0x7fb5ef8cc000
mmapped address is 0x7fb5eb8cc000
mapped at 0x7fb5eb8cc000
mmapped address is 0x7fb5e78cc000
mapped at 0x7fb5e78cc000
mmapped address is 0x7fb5e38cc000
mapped at 0x7fb5e38cc000
mmapped address is 0x7fb5df8cc000
mapped at 0x7fb5df8cc000
send len = 263596
OMX: Failed to find peer index of board 00:00:00:00:00:00 (Peer Not Found in the Table)
mx_connect failed

Looks like CDS error. We are leaving the WATCHDOGS OFF for the night.

Since Den wasn't able to fix c1sus (make it talk to the framebuilder) before he left a few hours ago, I decided to do some housekeeping rather than actual locking. 

I wrote new save / misalign / restore scripts for all of the suspended optics on the C1IFO_ALIGN screen.  Adding save / restore versions for the mode cleaner optics should be quick and easy.  Now when you use the ! button for each optic, it points you to the new scripts.  I still have the burt capabilities there, but the restore script has the burt-restore line commented out.

Functionality:

SAVE:  burt-save the PIT_COMM and YAW_COMM values, as well as write those values and the date to a text file.

MISALIGN:  Turn off oplevs, move 100 steps of 0.01 in the "+" direction.

RESTORE: Move ~100 steps toward the saved value, until you're within 0.001 of the saved value (step size is "saved val" minus "current val" divided by 100).  Then just write the saved value to the slider (otherwise if the slider were touched between the last "save" and the restore, we might not be able to step precisely to the value we want). Turn oplevs back on.

Scripts are in the same place the old ones used to live:  ...../caltech/c1/medm/c1ifo/cmd/   New scripts are C1IFO_OPTIC(save/restore/misalign)_soft.cmd

I'm checking this one off of the to-do list.

Good things:  (a) I remembered / re-learned / just plain learned a lot about scripting.  (b) the optics are now walked slowly over to their misaligned state, and slowly walked back.  The past regime had the optics suddenly kicked over by a lot, sometimes enough to trip / come close to tripping watchdogs, which was never good.

Bad things: it took a long time.  Now it's bedtime.

We officially are *failures* at svn-ing our scripts and screens.  This is NOT OKAY.  I checked in a few things, since there were already folders on the svn, but many things don't have folders created.  It's a hot mess.  We need to get our shit together, and become as disciplined about MEDM and scripts as we have been (under Jamie's watchful eye) of the simulink models.

I'm not going to start fixing it all right now.  It might not even happen at this point until after GWADW, but it needs to happen.

 I am really not ok with anyone modifying controller.c.  If we're going to be messing around with that we need to change procedure significantly.  This is the code that runs all the models, and we don't currently have any way to track changes in the code.

Did you change it back?  If not, do so immediately and stop messing with it.  Please consult with us first before embarking on these kinds of severe changes to our code.  This is the kind of shit that other people have done that has bit us in the ass in the past.

Futhermore, there is already a way to enable biquad filters in the new version with out modifying the RCG source.  All you need to do is set biquad=1 in the cdsParameters block for you model.

DO NOT MESS WITH CONTROLLER.C!

 [Alex, Den] 

It was in vain to restart mx_stream yesterday as C1SUS did not see FB

After that C1SUS started to communicate with FB. But the reason why this happened and how to prevent from this in future Alex does not know.

Restarting DAQD process (or may be C1SUS) also solved the problem with guralp channels, now they are fine. Again, why this happened is unknown.

 ok

Rana theorized that we're having problems with the MC error signal in the OAF model (separate elog by Den to follow) because we've named a channel "C1:IOO-MC_F", and such a channel already used to exist.  So, Rana and I went out to do some brief cable tracing.

MC Servo Board has 3 outputs that are interesting:  "DAQ OUT" which is a 4-pin LEMO, "SERVO OUT" which is a 2-pin LEMO, and "OUT1", which is a BNC->2pin LEMO right now.

DAQ OUT should have the actal MC_F signal, which goes through to the laser's PZT.  This is the signal that we want to be using for the OAF model.

SERVO OUT should be a copy of this actual MC_F signal going to the laser's PZT.  This is also acceptable for use with the OAF model.

OUT1 is a monitor of the slow(er) MC_L signal, which used to be fed back to the MC2 suspension.  We want to keep this naming convention, in case we ever decide to go back and feed back to the suspensions for freq. stabilization.

Right now, OUT1 is going to the first channel of ADC0 on c1ioo.  SERVOout is going to the 7th channel on ADC0.  DAQout is going to the ~12th channel of ADC1 on c1ioo.  OUT1 and SERVOout both go to the 2-pin LEMO whitening board, which goes to some new aLIGO-style ADC breakout boards with ribbon cables, which then goes to ADC0.  DAQout goes to the 4pin LEMO ADC breakout, (J7 connector) which then directly goes to ADC1 on c1ioo.

So, to sum up, OUT1 should be "adc0_0" in the simulink model, SERVOout should be "adc0_6" on the simulink model, and DAQout should be "adc1_12" (or something....I always get mixed up with the channel counting on 4pin ADC breakout / AA boards). 

In the current simulink setup, OUT1 (adc0_0) is given the channel name C1:IOO-MC_F, and is fed to the OAF model.  We need to change it to C1:IOO-MC_L to be consistent with the old regime.

In the current simulink setup, SERVOout (adc0_6) is given the channel name C1:IOO-MC_SERVO.  It should be called C1:IOO-MC_F, and should go to the OAF model.

In the current simulink setup,DAQout (~adc1_12) doesn't go anywhere.  It's completely not in the system.  Since the cable in the back of this AA / ADC breakout board box goes directly to the c1ioo I/O chassis, I don't think we have a degenerate MC_F naming situation.  We've incorrectly labeled MC_L as MC_F, but we don't currently have 2 signals both called MC_F.

Okay, that doesn't explain precisely why we see funny business with the OAF model's version of MCL, but I think it goes in the direction of ruling out a degenerate MC_F name.

Problem:  If you look at the screen cap, both simulink models are running on the same computer (c1ioo), so when they both refer to ADC0, they're really referring to the same physical card.  Both of these models have adc0_6 defined, but they're defined as completely different things.  Since we can trace / see the cable going from the MC Servo Board to the whitening card, I think the MC_SERVO definition is correct.  Which means that this Green_PH_ADC is not really what it claims to be.  I'm not sure what this channel is used for, but I think we should be very cautious and look into this before doing any more green locking.  It would be dumb to fail because we're using the wrong signals.

Den noticed this, and will write more later, I just wanted to sum up what Alex said / did while he was here a few minutes ago....

Errors are probably really happening.... c1oaf computer status 4-bit thing:  GRGG.  The Red bit is indicating receiving errors.  Probably the oaf model is doing a sample-and-hold thing, sampling every time (~1 or 2 times per sec) it gets a successful receive, and then holding that value until it gets another successful receive. 

Den is adding EPICS channels to record the ERR out of the PCIE dolphin memory CDS_PART, so that we can see what the error is, not just that one happened.

Alex restarted oaf model:  sudo rmmod c1oaf.ko, sudo insmod c1oaf.ko .  Clicked "diag reset" on oaf cds screen several times, nothing changed.  Restarted c1oaf again, same rmmod, insmod commands.

Den, Alex and I went into the IFO room, and looked at the LSC computer, SUS computer, SUS I/O chassis, LSC I/O chassis and the dolphin switch that is on the back of the rack, behind the SUS IO chassis.  All were blinking happily, none showed symptoms of errors.

Alex restarted the IOP process:  sudo rmmod c1x04, sudo insmod c1x04.  Chans on dataviewer still bad, so this didn't help, i.e. it wasn't just a synchronization problem.  oaf status: RRGG. lsc status: RGGG. ass status: RGGG.

sudo insmod c1lsc.ko, sudo insmod c1ass.ko, sudo insmod c1oaf.ko .  oaf status: GRGG. lsc status: GGGG. ass status: GGGG.  This means probably lsc needs to send something to oaf, so that works now that lsc is restarted, although oaf still not receiving happily.

Alex left to go talk to Rolf again, because he's still confused.

Comment, while writing elog later:  c1rfm status is RRRG, c1sus status is RRGG, c1oaf status is GRGG, both c1scy and c1scx are RGRG.  All others are GGGG.

Upgrades suck.  Or at least making everything work again after the upgrade.

On the to-do list tonight:  look at OSEM sensor and OpLev spectra for PRM, when PRMI is locked and unlocked.  Goal is to see if the PRM is really moving wildly ("crazy" as Kiwamu always described it) when it's nicely aligned and PRMI is locked, or if it's an artifact of lever arm between PRM and the cameras (REFL and AS).

However, I can't get signals on DTT.  So far I've checked a bunch of signals for SUS-PRM, and they all either (a) are just digital 0 or (b) are ADC noise.  Lame.

Steve's elog 5630 shows what reasonable OpLev spectra should look like:  exactly what you'd expect.

Attached below is a small sampling of different SUS-PRM signals.  I'm going to check some other optics, other models on c1sus, etc, to see if I can narrow down where the problem is.  LSC signals are fine (I checked AS55Q, for example).

UPDATE:  SRM channels are same ADC noise.  MC1 channels are totally fine.  And Den had been looking at channels on the RFM model earlier today, which were fine.

ETMY channels - C1:SUS-ETMY_LLCOIL_IN1 and C1:SUS-ETMY_SUSPOS_IN1 both returned "unable to obtain measurement data".  OSEM sensor channels and OpLev _PERROR channel were digital zeros.

ETMX channels were fine

UPDATE UPDATE:  Genius me just checked the FE status screen again.  It was fine ~an hour ago when I sat down to start interferometer-izing for the night, but now the SUS model and both of the ETMY computer models are having problems connecting to the fb.  *sigh* 

 Restarted SUS model - it's now happy. 

c1iscey is much less happy - neither the IOP nor the scy model are willing to talk to fb.  I might give up on them after another few minutes, and wait for some daytime support, since I wanted to do DRMI stuff tonight.

Yeah, giving up now on c1iscey (Jamie....ideas are welcome).  I can lock just fine, including the Yarm, I just can't save data or see data about ETMY specifically.  But I can see LSC data, so I can lock, and I can now take spectra of corner optics.

A few things tonight.  Locked both arms simultaneously (IR only).  Locked MICH, Locked PRMI, although it doesn't like staying locked for more than a minute or so, and not always that long.

Locking PRCL was possible by getting rid of the power normalization.  We need to get some triggering going on for the power norm.  I think it's a good idea for after the cavity is locked, but when PRCL is not locked, POP22 is ~0, so Refl33/Pop22 is ~inf.  The PRCL loop kept railing at the Limit that was set.  Getting rid of the power normalization fixed this railing. 

I took some spectra of PRM's oplev, while PRMI was locked, and unlocked.  The PRM is definitely moving more when the cavity is locked.  I'm not sure yet what to do about this, but the result was repeatable many times (~6 or 7 over an hour or so).  The OpLev spectra when PRMI was locked didn't depend too strongly on the PRM's alignment, although I think that's partly because I wasn't able to really get the PRM to optimal alignment.  I think POP22I is supposed to get to 7 or so...last week with Koji it was at least flashing that high.  But tonight I couldn't get POP22I above 4, and most of the time it wouldn't go above 3.  As I was aligning PRM and the circulating SB power increased, POP22I fluctuations increased significantly, then the cavity unlocked.  So maybe this is because as I get closer, PRM gets more wiggly.  I tried playing 'chicken' with it, and took spectra as I was aligning PRM (align, get some improvement, stop to take spectra, then align more, stop to take spectra....) but usually it would fall out of lock after 1-2 iterations of this incremental alignment and I'd have to start over.  When it relocked, it usually wouldn't come back to the same level of POP22I, which was kind of disappointing. 

In the PDF attached, pink and light blue are when the PRMI is locked, and red and dark blue are no PRCL feedback.  The effect is more pronounced with Pitch, but it's there for both Pitch and Yaw.

Also, I need to relook at my new restore/misalign scripts.  They were acting funny tonight, so I'm taking back my "they're awesome, use them without thinking about it" certification.

 This is the mx_stream issue reported previously.  The symptom is that all models on a single front end loose contact with the frame builder, as opposed to *all* models on all front end loosing contact with the frame builder.  That indicates that the problem is a common fb communication issue on the single front end, and that's all handled with mx_stream.

ssh'ing into c1iscey and running "sudo /etc/init.d/mx_stream restart" fixed the problem.

Is this enhancement of spectrum caused by the lock? Or by the actuation?

If this is also seen with approximately same amount of actuation to PRM POS,
this is just a suspension problem.

If this is only seen with the PRM locked, this is somehow related to the opt-mechanical coupling.

 From my point of view during rfm -> oaf transmission through Dolphin we loose a significant part of the signal. To check that I've created MEDM screen to monitor the transmission errors in the OAF model. It shows how many errors occurs per second. For MCL channel this number turned out to be 2046 +/- 1. This makes sense to me as the sampling rate is 2048 Hz => then we actually receive only 1-3 data points per second. We can see this in the dataviewer.

C1:OAF-MCL_IN follows C1:IOO-MC_F in the sense that the scale of 2 signals are the same in 2 states: MC locked and unlocked. It seems that we loose 2046 out of 2048 points per second.

I added PCIE memory cache flushing to c1rfm model by changing 0 to 1 in /opt/rtcds/rtscore/release/src/fe/commData2.c on line 159, recompiled and restarted c1rfm.

Jamie, do not be mad at me, Alex told me do that!

However, this did not help, C1RFM did not start. I decided to restart all models on C1SUS machine in hope that C1RFM uses some other models and can't connect to them but this suspended C1SUS machine. After reboot encounted the same C1SUS -> FB communication error and fixed it in the same was as in the previous case of C1SUS reboot. This happens already the second time (out of 2) after C1SUS machine reboot.

I changed /opt/rtcds/rtscore/release/src/fe/commData2.c back, recompiled and restarted c1rfm. Now everything is back. C1RFM -> C1OAF is still bad.

Den and Alex left things not-burt restored, and Den mentioned to me that it might need doing.

I burt restored all of our epics.snaps to the 1am today snapshot.  We lost a few hours of striptool trends on the projector, but now they're back (things like the BLRMS don't work if the filters aren't engaged on the PEM model, so it makes sense).

 This happened because of the code bug -

After this bug was fixed and the code was recompiled, C1:OAF_MCL_IN is OK, no errors occur during the transmission C1:OAF-MCL_ERR=0.

So the problem was in the PCIE card that could not send such amount of data and the last channel (MCL is the last) was corrupted. Now, when Alex added cache flushing, the problem is fixed.

We should spend some more attention to such problems. This time 2046 out of 2048 points were lost per second. But what if 10-20 points are lost, we would not notice that in the dataviewer, but this will cause problems.

I'm combining the IFO check-up list (elog 6595) and last week's action items list (elog 6597).  I thought about making it a wiki page, but this way everyone has to at least scroll past the list ~1/week.

Feel free to cross things out as you complete them, but don't delete them.  Also, if there's a WHO?? and you feel inspired, just do it!

PRIORITY ITEMS:

Dither-align arm to get IR on actuation nodes, align green beam - JENNE

Arm cavity sweeps, mode scan - JENNE

ASS doesn't run on Ubuntu! or CentOS Fix it! - JENNE, JAMIE's help

Input matricies, output filters to tune SUS.  check after upgrade. - JENNE

POX11 whitening is not toggling the analog whitening??? - JAMIE, JENNE, KOJI

OAF comparison plot, both online and offline, comparing static, adaptive and static+adaptive - DEN

THE FULL LIST:

• General
  • Revamp control room - more monitors, maybe move TV shelves. - JENNE
  • Audio system for the signals!!!! Even a crappy one! - LEO
• SUS
  
  • ETMX oplev - replace 1064nm lens with 632nm lens (KBC037, -100) - JENNE
  • Input matricies, output filters to tune SUS.  check after upgrade. - JENNE
• IFO
  • Fix occasional common-mode power transient in the arm transmissions. Probably an alignment thing. Would ISS help? - WHO??
  • Drift of the green incident axis -> Assess the amount of the drift / replace the mount - JENNE, KOJI
  • Calibration of POP22 / AS110 - JENNE
  • PMC/IMC/ARM characterization (loss, finesse, reflectivity, etc) - JENNE
  • Dither-align arm to get IR on actuation nodes, align green beam - JENNE
  • Arm cavity sweeps, mode scan - JENNE
  • Align AS OSA (others?) - JENNE  
  • Investigate PRMI glitches, instability - JENNE
  • PZT or Picomotor mounts for PSL/ALS beams - WHO??
  • ALS on the both arm simultaneously / common / diff ALS scripts - JENNE
• CDS
  • Capture OSA signals in CDS (the 'scope TDS1001B has a USB port in the back for connecting to the computer) - WHO??
  • Transmon (arms) for high and low power - WHO??
  • POX11 whitening is not toggling the analog whitening??? - JAMIE, JENNE, KOJI
  • Install guardians to monitor EPICS values - WHO??
• Electronics
  • Actuator noise level characterization (coil driver response in V/m & coil driver noise level V/rtHz) - WHO??
  • Beat box - KOJI
  • I/Q DFD - WHO??
  • Improvement of POP22/110/AS110 RF circuits. - WHO??
• MEDM
  
  • Complete 40m overview screen - everything should be clickable with pseudo 3D icons - JENNE
  • Better suspension screen - copy from sites. - WHO??
  • Script to generate a MEDM tree - WHO??
  • Resurrect MEDM snapshots - WHO??
  • New ! buttons on every screen, include wiki page - WHO??
• SCRIPT
  • Locking scripts with integrator triggers / disabling when unlocked - JENNE
  • Daily diagnosis of the MC spot positions (there must be something already...) - SURESH?
  • Daily/occasional adjustment of the incident axis on the MC - SURESH?
  • IFO_CONFIGURE scripts still do a burt restore, so step the optics.  Need to remove optic alignment from config .snap files, use reg restore script instead. - JENNE
    
  • OPLEV/OSEM trending script before the IFO work for diagnosis. - JENNE
  • Auto-locker for arms - JENNE
  • Auto-locker for PMC, PSL things - DEN
  • Diagnostic script for CDS - mx_stream, other stuff. - WHO??
• Video
  • If each video screen has a caption, that would be great - WHO??
  • GUI interface of "videoswitch" - MIKEJ
  • Mouse Jiggler for Zita (called Swinput?) - JENNE
• Ubuntu vs. CentOS
  • burttoday is not aliased in ubuntu.    burttoday:      aliased to cd /opt/rtcds/caltech/c1/burt/autoburt/today/ - JAMIE

  • Upgrade Rossa, Allegra, make sure they connect to DTT, Dataviewer, AWG. - JAMIE
    
  • ASS doesn't run on Ubuntu! or CentOS Fix it! - JENNE, JAMIE's help
  • CentOS machines cannot open simulink models properly (get "Bad Link"s everywhere, so you can't do anything useful) - JAMIE
• MM
  • IPPOS beam measurement - SURESH with JENNE
  • AS beam measurement (if beam is bright enough) - SURESH and JENNE
  • Mode matching calculations, sensitivity to MC waist measurement errors, PRM position - JENNE
  • Think up diagnostic measurement to determine mode matching to PRC while chambers are open, while we tweak MMT - JAMIE, JENNE, KOJI, SURESH
  • Use sensoray to capture, measure beam mode at AS, POP - YUTA
• Stray Light
  • Scattered light measurement at the end stations: design / confirmation of the mechanical parts/optics/cameras - JAN
• OAF
  • OAF comparison plot, both online and offline, comparing static, adaptive and static+adaptive - DEN
  • Static-only OAF noise budget (Adaptive noise budget as next step) - DEN
  • Build amplifiers for new small microphones - DEN
  • Script for daily / weekly re-calculation of Wiener, post to elog if need changing - DEN
    
• Tip Tilts
  • Prepare electronics for TTs (coil drivers) - JAMIE
  • In-air TT testing to confirm we can control / move TTs before we vent - SURESH
  • Connect TTs to digital system and controls, lay cables if needed - JAMIE with SURESH
• RF Photodiodes
  • Opto Energy diode laser - look into buying - ERICG
  • Purchase fibers, splitters, other supplies - ERICG
  • Set everything up - ERICG

ADC 3 INPUT 4 (#3 in the c1pem model if you count from 0) is bad. It adds DC = ~1 V to the signal as well as noise. I plugged in GUR2 channels to STS1 channels (7-9).

Already for the second time today all computers loose connection to the framebuilder. When I ssh to framebuilder DAQD process was not running. I started it

controls@fb ~ 130$ sudo /sbin/init q

But I do not know what causes this problem. May be this is a memory issue. For FB

Mem:   7678472k total,  7598368k used,    80104k free

Practically all memory is used. If more is needed and swap is off, DAQD process may die.

Just to be clear, "init q" does not start the framebuilder.  It just tells the init process to reparse the /etc/inittab.  And since init is supposed to be configured to restart daqd when it dies, it restarted it after the reloading of /etc/inittab.  You and Alex must have forgot to do that after you modified the inittab when you're were trying to fix daqd last week.

daqd is known to crash without reason.  It usually just goes unnoticed because init always restarts it automatically.  But we've known about this problem for a while.

This doesn't really mean anything, since the computer always ends up using all available memory.  It doesn't indicate a lack of memory.  If the machine is really running out of memory you would see lots of ugly messages in dmesg.

No leaving the OAF running until you're sure (sure-sure, not kind of sure, not pretty sure, but I've enabled guardians to make sure nothing bad can happen, and I've been sitting here watching it for 24+ hours and it is fine) that it works okay.

OAF (both adaptive and static paths) were left enabled, which was kicking MC2 a lot.  Not quite enough that the watchdog tripped, but close.  The LSCPOS output for MC2 was in the 10's or 100's of thousands of counts.  Not okay.

This brings up the point though, which I hadn't actively thought through before, that we need an OAF watchdog.  An OAF ogre?  But a benevolent ogre.  If the OAF gets out of control, it's output should be shut off.  Eventually we can make it more sophisticated, so that it resets the adaptive filter, and lets things start over, or something. 

But until we have a reliable OAF ogre, no leaving the adaptive path enabled if you're not sitting in the control room.  The static path should be fine, since it can't get out of control on it's own.

Especially no leaving things like this enabled without a "I'm leaving this enabled, I'll be back in a few hours to check on it" elog! 

I've compared offline Wiener filtering with online static + adaptive filtering for MC_F with GUR1_XYZ and GUR2_XYZ as witness signals

Note: online filter works up to 32 Hz (AI filter at 32 Hz is used). There is no subtraction up from this frequency, just MC_F was measured in different times for online and offline filtering. This difference in MC_F in frequency range 20-100 Hz showed up again as before with microphone testing.  One can see it in 1 minute. Smth is noisy.

Reasons why online filter is worse then offline:

1. FIR -> IIR conversion produces error. Now I'm using VECTFIT approximation with 16 poles (splitting into 2 filter banks), this not enough. I tried to use 50 and split them into 5 filter banks, but this scheme is not working: zpk -> sos conversion produces error and the result filter works completely wrong.

2. Actuator TF. VECTFIT works very good here - we have only 1 resonance. However, it should be measured precisely.

3. Account for AA and AI filters that rotate the phase at 1-10 Hz by ~ 10 degrees.

ETMY sus damping restored.

ETMX sus damping restored

I acquired 2 raw frames of MC2 using "/users/mjenson/sensoray/sdk_2253_1.2.2_linux/capture -n -s 720x480 -f 1", one while the laser was off the mode cleaner and another while it was on:

I then used "/users/mjenson/sensoray/sdk_2253_1.2.2_linux/imsub/display-image.py" to generate bitmaps of the raw images, which I then subtracted using the Python Imaging Library to generate a new image:

It doesn't look all that different, but the first image didn't have that much lit up in it to begin with. I should be able to write a script that does all of this without needing to generate new files in between acquisition and subtraction.