We have figured out that some of these measurements, those with the WFS off, were also not allowing the dither lines through, so no dither, so no actual measurement.

Jamie is fixing up the model so we can force the WFS to stay off, but allow the dither lines to go through.  He'll elog things later.

The "red for FB connection" issue was probably a dead mx_stream on c1lsc.  That can usually be fixed by just restarting mx_stream.

There is definitely a problem with c1oaf, though.  It crashes immediately after attempting to start.  kernel log for a crash included below.

We will leave c1oaf off until we have time to debug.

[83752.505720] c1oaf: Send Computer Number  = 0
[83752.505720] c1oaf: entering the loop
[83752.505720] c1oaf: waiting to sync 19520
[83753.207372] c1oaf: Synched 701492
[83753.207372] general protection fault: 0000 [#2] SMP 
[83753.207372] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:2e:01.0/class
[83753.207372] CPU 4 
[83753.207372] Modules linked in: c1oaf c1ass c1sup c1lsp c1cal c1lsc c1x04 open_mx dis_irm dis_dx dis_kosif mbuf [last unloaded: c1oaf]
[83753.207372] 
[83753.207372] Pid: 0, comm: swapper Tainted: G      D    2.6.34.1 #5 X7DWU/X7DWU
[83753.207372] RIP: 0010:[<ffffffffa1bf7567>]  [<ffffffffa1bf7567>] T.2870+0x27/0xbf0 [c1oaf]
[83753.207372] RSP: 0000:ffff88023ecc1aa8  EFLAGS: 00010092
[83753.207372] RAX: ffff88023ecc1af8 RBX: ffff88023ecc1ae8 RCX: ffffffffa1c35e48
[83753.207372] RDX: 0000000000000000 RSI: 0000000000000020 RDI: ffffffffa1c21360
[83753.207372] RBP: ffff88023ecc1bb8 R08: 0000000000000000 R09: 0000000000175f60
[83753.207372] R10: 0000000000000000 R11: ffffffffa1c2a640 R12: ffff88023ecc1b38
[83753.207372] R13: ffffffffa1c2a640 R14: 0000000000007fff R15: 0000000000000000
[83753.207372] FS:  0000000000000000(0000) GS:ffff880001f00000(0000) knlGS:0000000000000000
[83753.207372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[83753.207372] CR2: 000000000378a040 CR3: 0000000001a09000 CR4: 00000000000406e0
[83753.207372] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[83753.207372] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[83753.207372] Process swapper (pid: 0, threadinfo ffff88023ecc0000, task ffff88023ec7eae0)
[83753.207372] Stack:
[83753.207372]  ffff88023ecc1ab8 0000000000000096 0000000000000019 ffff88023ecc1b18
[83753.207372] <0> 0000000000014729 0000000000032a0c ffff880001e12d90 000000000000000a
[83753.207372] <0> ffff88023ecc1bb8 ffffffffa1c06cad ffff88023ecc1be8 000000000000000f
[83753.207372] Call Trace:
[83753.207372]  [<ffffffffa1c06cad>] ? filterModuleD+0xd6d/0xe40 [c1oaf]
[83753.207372]  [<ffffffffa1c07ae3>] feCode+0xd63/0x129b0 [c1oaf]
[83753.207372]  [<ffffffffa1c00dc6>] ? T.2888+0x1966/0x1f10 [c1oaf]
[83753.207372]  [<ffffffffa1c1b3bf>] fe_start+0x1c8f/0x3060 [c1oaf]
[83753.207372]  [<ffffffff8102ce57>] ? select_task_rq_fair+0x2c8/0x821
[83753.207372]  [<ffffffff8104cd8b>] ? enqueue_hrtimer+0x65/0x72
[83753.207372]  [<ffffffff8104d8f6>] ? __hrtimer_start_range_ns+0x2d6/0x2e8
[83753.207372]  [<ffffffff8104d91b>] ? hrtimer_start+0x13/0x15
[83753.207372]  [<ffffffff810173df>] play_dead_common+0x6e/0x70
[83753.207372]  [<ffffffff810173ea>] native_play_dead+0x9/0x20
[83753.207372]  [<ffffffff81001c38>] cpu_idle+0x46/0x8d
[83753.207372]  [<ffffffff814ec523>] start_secondary+0x192/0x196
[83753.207372] Code: 1f 44 00 00 55 66 0f 57 c0 48 89 e5 41 57 41 56 41 55 41 54 53 48 8d 9d 30 ff ff ff 48 8d 43 10 4c 8d 63 50 48 81 ec e8 00 00 00 <66> 0f 29 85 30 ff ff ff 48 89 85 18 ff ff ff 31 c0 48 8d 53 78 
[83753.207372] RIP  [<ffffffffa1bf7567>] T.2870+0x27/0xbf0 [c1oaf]
[83753.207372]  RSP <ffff88023ecc1aa8>
[83753.207372] ---[ end trace df3ef089d7e64971 ]---
[83753.207372] Kernel panic - not syncing: Attempted to kill the idle task!
[83753.207372] Pid: 0, comm: swapper Tainted: G      D    2.6.34.1 #5
[83753.207372] Call Trace:
[83753.207372]  [<ffffffff814ef6f4>] panic+0x73/0xe8
[83753.207372]  [<ffffffff81063c19>] ? crash_kexec+0xef/0xf9
[83753.207372]  [<ffffffff8103a386>] do_exit+0x6d/0x712
[83753.207372]  [<ffffffff81037311>] ? spin_unlock_irqrestore+0x9/0xb
[83753.207372]  [<ffffffff81037f1b>] ? kmsg_dump+0x115/0x12f
[83753.207372]  [<ffffffff81006583>] oops_end+0xb1/0xb9
[83753.207372]  [<ffffffff8100674e>] die+0x55/0x5e
[83753.207372]  [<ffffffff81004496>] do_general_protection+0x12a/0x132
[83753.207372]  [<ffffffff814f17af>] general_protection+0x1f/0x30
[83753.207372]  [<ffffffffa1bf7567>] ? T.2870+0x27/0xbf0 [c1oaf]
[83753.207372]  [<ffffffffa1c06cad>] ? filterModuleD+0xd6d/0xe40 [c1oaf]
[83753.207372]  [<ffffffffa1c07ae3>] feCode+0xd63/0x129b0 [c1oaf]
[83753.207372]  [<ffffffffa1c00dc6>] ? T.2888+0x1966/0x1f10 [c1oaf]
[83753.207372]  [<ffffffffa1c1b3bf>] fe_start+0x1c8f/0x3060 [c1oaf]
[83753.207372]  [<ffffffff8102ce57>] ? select_task_rq_fair+0x2c8/0x821
[83753.207372]  [<ffffffff8104cd8b>] ? enqueue_hrtimer+0x65/0x72
[83753.207372]  [<ffffffff8104d8f6>] ? __hrtimer_start_range_ns+0x2d6/0x2e8
[83753.207372]  [<ffffffff8104d91b>] ? hrtimer_start+0x13/0x15
[83753.207372]  [<ffffffff810173df>] play_dead_common+0x6e/0x70
[83753.207372]  [<ffffffff810173ea>] native_play_dead+0x9/0x20
[83753.207372]  [<ffffffff81001c38>] cpu_idle+0x46/0x8d
[83753.207372]  [<ffffffff814ec523>] start_secondary+0x192/0x196

I tried to take some photos through the window of ETMX's chamber, to see if I could see any magnets.  What we have learned is that Jenne is still not the world's best photographer.  I was holding the camera at ~max zoom inside the beam tube between the table and the window, so that's my excuse for the photos being fuzzy.  The only thing that I can really conclude is that the magnets look like they are still there, but Jamie thinks they may be stuck on the PDs/LEDs (now looking at the photos myself, I agree, especially with UL and LR). 

It looks like the best thing to do at this point, since Koji already tried jerking ETMX around in yaw a little bit, is just wait and open the door, to see what's going on in there.  I posted the photos on Picasa:

https://picasaweb.google.com/foteee/ETMX_MaybeStuck_ThroughWindow_27Aug2012

I propose that, if the magnets are broken, we pull the ETM out of the camber and fix it up in the cleanroom while we pump back down.  This would restrict us from doing any Xarm work, but will force me to focus on DRMI, and we can put the ETM back when we vent to install the tip tilts.

 Rijuparna Chakraborty and Elli Elenora King received 40m specific  basic safety training in the 40mLab

The MC REFL path was checked. ==> Some clippings were fixed. MC WFS is working now.

- MC was aligned manually

- The steering mirror for the WFS and camera was clipping the beam. => FIxed

- The WFS spots were realigned.

- There was small clipping on the MC REFL RFPD. ==> Fixed

After shaking ITMX by the alignment bias in yaw, it came back.

As ETMX seems to be largely misaligned yaw (and did not come back with the alignment impact),
the condition of the magnets are not clear. Only the side OSEM is responding nicely.

  It looks like we may lost 1 (or 3 )  magnets? Do not panic, it's not for sure

Shasky day yesterday postpones venting. We had about 11 shakes larger than mag 4.0 Mag5.5 was the largest at  13:58 Sunday, Aug 26 at  the Salton Sea area.

Atm3,  ITMX and ETMX  did not come back to it's position

I came in to the lab in the evening and found c1lsc had "red" for FB connection.
I restarted c1lsc models and it kept hung the machine everytime.

I decided to kill all of the model during the startup sequence right after the reboot.
Then run only c1x04 and c1lsc. It seems that c1oaf was the cause, but it wasn't clear.

[Koji, Jenne]

Steve, do not vent tomorrow morning!  We are still not prepared, and will not finish the preparation tonight.  Hopefully we can finish the prep tomorrow, and then vent Tues.

Things we need to do before the vent:

MC spots centered [Jenne, tonight]

Use PZT2, BS to hit ~center of ETMs.

Realign arms, measure spot positions.

Make sure BS, ITMs are good - we want a good AS spot since we'll likely have to adjust some AS optics while we're inside

Insert attenuation optics, recover MC trans by rotating PBS cube to translate beam slightly

 We are being riddled with earthquakes.  Brawley, CA (~150 miles from here) has had 9 earthquakes in the last hour, and they're getting bigger (the last 4 have been 4-point-somethings).  I may try to come back later, but right now the MC won't stay locked for the ~5 minutes it takes to measure spot positions.  Koji and Jamie said they were coming in today, so they can call me if they want help.

We need to re-look at this new MC autolocker stuff, and the new MCL filters.

MC2 is getting kicked up (sometimes the watchdog trips, sometimes it just comes close) pretty regularly.  I'm not sure yet what is causing this, but we need to deal with it since it's pretty obnoxious.

I am getting closer with the MC spot centering.  I had everything but MC1 really great, but then I tweaked MC1's pointing, and things all went to hell. 

I have to go home to let Butter out, but I'll be back tomorrow, and I'll try to get back to where I was in the 2nd to last measurement in the plot below.

I recenterd the WFS after moving the input beam, so that the beam was hitting the WFS at all.

I checked and fixed the X end green situation. Now the X green beam is locked with TEM00.

There are various reasons it did not lock nicely.

• The IR beam axis was changed by Yoichi and Rana (ELOG #7169). So the green axis also had to be changed.
• The end green optics is really "BS". Anytime I see it, I feel disgusted. Because of 3D steering mirrors, cross couplings
  between yaw and pitch are big. This makes the alignment hard.
• Even with acceptable alignment, the lock was only momentarily. I found the slow control was on. This pushed the frequency
  too much and made the lock unstable.
• The slow control screen was broken as Jamie changed the model names but did not fix the slow screens.
  
  • Jamie saids (ELOG #7011): Fix the c1sc{x,y}/master/C1SC{X,Y}_GC{X,Y}_SLOW.adl screens. 
    I need to figure out a more consistent place for those screens.

Now some action items are left:

- IR TRX is not aligned.
- X end green needs precise alignment.
- PSL GR TRX is not aligned.

These will be checked on Sunday.

- End green setup is horrible. => Manasa and I should work on this together.

as usual.

Vacuum related work at atmosphere:

Atm1,  Check all chamber dog clamps tightness with torque wrench,

Atm2,  Replace old, black molibdenum disulfite bolts -nut with new silicon bronze nuts and clean SS bolts.

Atm3,  Replace CC1 cold cathode gauges: horizontal and vertical.

Friday / pre-vent:

[done] Align the MC mirrors for the incident beam so that the mirrors can be the alignment reference [Koji]

[in progress] Center spots on MC mirrors [Jenne]

Put beam attenuator optics (PBS + waveplate) on PSL table, realign input beam to MC mirror centers

[In progress] See if we can design a set of nuts and bolts to use at bottom of tiptilt optic ring, to do small adjustments of pitch alignment [Steve]

After doors open:

Use CCD (Watek, with AGC on) to take images of everything we can think of, to see current status of clipping

Check that we get through the Faraday without clipping

Move PZT1 and MMT mirrors to get good spot positions on PR3, PR2.  Make sure we're clearing the Faraday's housing

Install dichroic optics, perhaps completely readjust pitch alignment of those tiptilts (we will measure the spares later, and call that good enough for our phase mapping).

Use some kind of oplev setup to check pitch alignment of PR2, PR3.

Tweak (if necessary) PR2 & PR3 pitch to go through center of PRM, BS, hit center of ITMY

Check that we're not clipping on the BS cage anywhere

Use CCD to take images with Sensoray of everything we can think of, to confirm we don't have clipping anywhere.  Want to see the edges of the beam on the targets, which would mean that the beam is hitting the center of the optic.  If necessary, we'll stay open an extra day to get good camera images everywhere, so we have a good record of what's going on inside.

Note:  While having good arm alignment would be good, we're willing to sacrifice some arm alignment to have good DRMI alignment, since we're re-venting and installing the new active tiptilts in another month or so. 

Things I'm leaving for Jamie-the-Vent-Czar to plan:

Order of door opening

Beam dump assembly and placement

I did a simulation of a cavity, feedback signal was calculated using LQG controller. I assumed that there is not length -> angle coupling and 2 mirrors that form the cavity have the same equation of motions (Q and eigen frequencies are the same). Cost functional was chosen in such a way that frequencies below 15 Hz contribute much more then other frequencies.

Gains in the controller are calculated to minimize the cost functional.

This technique works well, but it requires full information about the system states. If we do not assume that cavity mirrors have the same equations of motion then we need to apply Kalman filter to approximate the position of one of the mirrors.

I recently realized that I may have over-trained my classification neural network and used too many parameters, so that my weight vectors are too fine-tuned to my particular data set and do not generalize well. I lowered the number of hidden neurons in the network to 15, and the number of epochs to 25000, and regularized based on the deltas (the gradient). Here is the most recent learning curve:

The old weights and code are saved in the c1pem directory in the file "classify_seismic_20neurons.c", while the current 15 neuron network is saved as "classify_seismic.c". I'll monitor the performance of this current network throughout the day, and decide which one we should keep.

I did a simulation of linear quadratic gaussian (LQG) controller applied to local damping. The cost function was frequency shaped to have a peak at 1 Hz. This technique prevents the controller from adding sensor noise at high and very low frequencies.

Noise was simulated to have 1/f spectrum (seismic) multiplied by stack with a resonance at 4 Hz with Q=5.

 I tweaked the alignment of ITMX and ETMX a teeny bit to get the TEM00 flashes back (the work in the previous elog was pre-dinner, so it had been a few hours), then took a screenshot of the error signal and refl dc power on the photodiode for the green xend setup.

The error signal is certainly noisy, although I think when Jamie and I were looking at it earlier this evening, the SNR was a little better.

I need to look at the modulation depth, to see if it's correct, ... maybe lock the Xarm on IR and scan the green laser PZT to check the sideband heights.

I should also check to make sure that the PD is powered, and the gain is high enough (currently the PD gain is set to 20dB).  Earlier today, when I set the gain to 30dB, Jamie said that it was saturating, so I put it back down to the 20dB where we found it.

Still no lock of the green though :(

Edit: realized I was bad and didn't label the traces on the plot:  green is refl dc power, blue is demodulated error signal.

[Koji Rana]

The FSS Slow DC servo was turned off.

As MCL stabilizes the MC_F (Fast PZT), we no longer need to use the laser temp to do so.

In other word, if you like to turn off the MCL servo for some reason, we need to turn it on in order to keep the MC locked.

[Koji Rana]

MC Autolocker was updated. (i.e. mcup and mcdown were updated)

mcup:

• Turn on the MCL input and output switches
• Change the MCL gain from 0 to -300 with nominal ramp time of 5sec
• Turn on FM2, FM5, MF7 after a sleep of 5sec. Note: FM1 FM8 FM9 are always on.
• Set the offset of 42 counts
• Turn on the offset

# Turn on MCL servo loop
echo mcup: Turning on MCL servo loop...
date
ezcaswitch C1:SUS-MC2_MCL INPUT OUTPUT ON
ezcawrite C1:SUS-MC2_MCL_GAIN -300
sleep 5
ezcaswitch C1:SUS-MC2_MCL FM2 FM5 FM7 ON
# Offset to take off the ADC offset of MC_F
ezcawrite C1:SUS-MC2_MCL_OFFSET 42
ezcaswitch C1:SUS-MC2_MCL OFFSET ON


This offset of 42 count is applied in order to compensate the ADC offset of MC_F channel.
The MCL servo squishes the MC_F signal. i.e. The DC component of MC_F goes to zero.
However, if the ADC of MC_F has an offset, the actual analog MC_F signal, which is fed to FSS BOX,
still keep some offset. This analog offset causes deviation from the operating point of the FSS (i.e. 5V).

mcdown:

• Basically the revese process of mcup.
• This script keeps FM1 FM8 FM9 turned on.

# Turn off MCL servo loop
echo mcdown: Turning off MCL servo loop...
date
ezcawrite C1:SUS-MC2_MCL_GAIN 0
ezcaswitch C1:SUS-MC2_MCL INPUT OUTPUT OFFSET FMALL OFF FM1 FM8 FM9 ON
# Remove Offset to take off the ADC offset of MC_F
ezcawrite C1:SUS-MC2_MCL_OFFSET 0

I turned on some filters and gain in the SUS-MC2_MCL filter bank tonight so as suppress the seismic noise influence on MC_F. This may help the MC stay in lock in the daytime.

Koji updated the mcdown and mcup scripts to turn the MCL path on and off and to engage the Boost filters at the right time.

The attached PNG shows the MCL screen with the filters all ON. In this state the crossover frequency is ~45 Hz. MC_F at low frequencies is reduced by more than 10x.

I also think that this may help the X-Arm lock. The number of fringes per second should be 2-3x less.

The MC1 accelerometer cube (3 accelerometers arranged in x,y,z) is under the PSL table, as I found it at the beginning of the summer.

The MC2 accelerometer cube is on the table where I worked on the STACIS, right when you walk into the lab from the main entrance. Their cables are dangling near the end of the mode cleaner, so the accelerometers are ready to be placed there if wanted.

All accelerometers are also plugged into their ADC channels.

[Jenne, Jamie]

We took a look at the Xend green, and we weren't able to make it lock.  We improved the alignment a little bit, and when we looked at the error signal, it looked nice and PDH-y, but for whatever reason, the cavity won't catch lock.

While aligning the green to the arm, Jamie noticed that the reflection from the intracavity power (not the prompt reflection) was not overlapping with the input beam or prompt reflection.  This means that the cavity axis and the input green beam were not co-linear.  I adjusted the BS and ITMX to get the IR transmitted beam (which had been near clipping on the top edge of the first (2 inch) optic it sees out of the vacuum) back near the input green beam spot on the combining beam splitter.  Then we continued tweaking the green alignment until we saw nice TEM00 flashes in the cavity.  The SNR of the error signal increased significantly after this work, since the cavity buildup was much higher.  But alas, still no lock. 

The huge kick observed in the MC sus sensors seem to last for ~10usec; almost matching the observed ringdown decay time. We should find a way to record the ringdown and the MC sus sensor data simultaneously to know when the mirrors are exactly moving during the measurement process. It could also be that the moving mirrors were responsible for the ripples observed later during the ringdown as well.

* How fast do the WFS respond to the frequency switching (time taken by WFS to turn off)? I think this information will help in narrowing down the many possible explanations to a few.

I cleaned up my directory (/users/masha) today. A lot of the files are just code that I experimented with, but the important files for training the classification neural network are in "neural_network_classification". The "EarthquakeData" subdirectory contains my entire dataset. Files of the form "GenerateRNNInput" are used to create input vector sets to the network, while files of the "*NeuralNetworkClassification* actually run the code that generates the neural network vectors for the classification code block in the c1pem model.

Also, the folder "feed_c", which can also be found in Den's directory, contains the neural network controller code we played around with.

 I found this entry in the old 40m ilog which describes the STACIS performance. It shows that even though the STACIS is bad for the differential arm motion below 3 Hz. It has quite a big and positive effect at 10-30 Hz. The OSEMs show a bigger effect than what the single arm does. I think this is because the single arm is limited by the MC frequency noise above 10 Hz.

We should figure out how to turn on the STACIS but set the lower UGF to be ~5 Hz.

 It is HIGHLY unlikely that the IMC mirrors are having any effect on the ringdown. The ringdowns take ~20 usec to happen. The mirrors are 0.25 kg and you can calculate that its very hard to get enough force to move them any appreciable distance in that time.

The ringdown measurements are in progress. But it seems that the MC mirrors are getting kicked everytime the cavity is unlocked by either changing the frequency at the MC servo or by shutting down the input to the MC. This means what we've been observing is not the ringdown of the IMC alone. Attached are MC sus sensor data and the observed ringdown on the oscilloscope.  I think we need to find a way to unlock the cavity without the mirrors getting kicked....in which case we should think about including an AOM or using a fast shutter before the IMC.

P.S. The origin of the ripples at the end of the ringdown still are of unknown origin. As of now, I don't think it is because of the mirrors moving but something else that should figured out.

 Bob is back. Cleaning and baking all our posts and clamps. They will be ready for use Tuesday next week. Therefore beam dumps will be available for installation.

Atm1,  I'm not sure about the seismic data.   Baja earthquake magnitude 3.0 at  yesterday morning.Seismometers do not see them !

Atm2,  No posted seismic activity.  Someone is jump walking in the lab? Why are there time delays between the suspensions?

Jenne and I did adaptive filtering of MC_L and measured how X and Y ARM control signals change compared to non-filtered MC_L. We did the test during 1.5 Hz seismic noise activity and adaptive filter was able to subtract it. However, it adds noise at high frequencies, It is not seen in MC_L but it is present in the ARMs control signals.

I'll investigate this problem. May be we need to reduce adaptation gain. In this experiment it was 0.1 and adaptive filter convergence time was equal to 1-2 mins.

It seems as though there is something funny going on around ~1.5 Hz, starting a little over an hour ago.

We see it in the BLRMS channels, the raw seismometer time series, as well as in various suspensions and LSC control signals.  It's also pretty easy to see on the camera views of all the spots (MC, arms, transmissions....AS is a little harder to tell since it's flashing, but it's there too).

The plots I'm attaching are only for ~10min after the jump happened, but there has been no change in the BLRMS since it started.  Usually, we'd see an earthquake in all the channels, and even big ones ring down after a little while.  This is concentrated at a pretty narrow frequency (some of Den's plots for later have this peak), and it's not ringing down, so it's not clear what is going on.

Here is a whole pile of plots.  Recall that the T-240 is plugged into the "STS_3" channels, and we don't have BLRMS for it, so you can look at the time series, but not any frequency specific stuff.

Last week, Rana changed the integrators in the arm LSC servo filters to be double integrators with complex poles. 

Yesterday, I found that using the "timeout" feature of Foton (at filter ON/OFF request, waits for zero crossing, or T seconds, whichever comes first) is useful for turning on the integrators, but bad for turning them off.  When we're locked, the error signal is oscillating around zero, so there is often a zero crossing.  When we lose lock, we want to turn off the filter immediately.  But, as soon as lock is lost, the input signal gets large, and doesn't often cross zero, so the filter waits 8 seconds until actually turning off.  If the arm flashes any time during that 8 sec, we send a big kick to the optics.

An alternative option could be ramping the filter on.  However, since the double integrator has -180deg phase at low frequencies (until the poles at ~5Hz), the transition between no filter (0deg phase) and integrator on could be problematic.  I simulated this, and find that for the very beginning of the ramping process, we would have a problem. 

The filter is defined as:  NoFilter * (1 - R) + Integrator * (R), so for R=0, the integrator is off, and for R=1, the integrator is fully on.  R can be any value [0,1]. 

The first figure is the time series (1 second, 16kHz), ramp goes from 0->1 or 1->0 in 1 second:

The second figure is bode plots for selected values of R:

As R gets smaller and smaller, the notch goes to lower frequency, and becomes higher Q.  So perhaps ramping is not a good answer here. 

What if we go for single or triple integrator, to get rid of the (+1) + (-1) problem?

We are discussing venting first thing next week, with the goal of
diagnosing what's going on in the PRC.

Reminder of the overall vent plan:

https://wiki-40m.ligo.caltech.edu/vent

Since we won't be prepared for tip-tilt installation (item 2), we should
focus most of the effort on diagnosing what's going on in the PRC.  Of
the other planned activities:

(1) dichroic mirror replacement for PR3 and SR3

  Given that we'll be working on the PRC, we might consider going ahead
  with this replacement, especially if the folding mirror becomes
  suspect for whatever reason.  In any case we should have the new
  mirrors ready to install, which means we should get the phase map
  measurements asap.

(3) black glass beam dumps:

  Install as time and manpower permits.  We need to make sure all needed
  components are baked and ready to install.

(4) OSEM mount screws:

  Delay until next vent.

(5) new periscope plate:

  Delay until next vent.

(6) cavity scattering measurement setup

  Delay until next vent.

Reinforced concrete grout plate for existing carbon steel stands at the ends.

While meditating on other things, I have noticed / found the following today:

YARM ASS works okay.  Yesterday I measured the sensing matrix for the ASS for both arms (although I forgot to copy one of the matrix elements to my text file for Xarm - needs remeasuring).  I put the Yarm matrix in (after appropriate inversion, only non-zero pitch-to-pitch, yaw-to-yaw elements).  I turned on the Yarm ASS, and  the yaw converged pretty quickly (couple of minutes), with gains of -1 in the servos, overall gain of anywhere between 0.005 and 0.010.  The pitch took much longer, and I had to 'pause' several times by turning off the overall gain for the yarm ass when the MC lost lock (which has happened several times tonight - unknown cause).  Eventually, the pitch settled out, and quit changing, but the lockin outputs weren't zero, even though the error signal for the servos were almost zero (gains for the pitch servos were -0.5, overall gain ~0.005 was better than 0.01 - higher gain caused oscillations in the lockin outputs).  I think this means that I need to remeasure the yarm pitch ass matrix.  It's still much, much faster to just turn on the dithers, watch the striptool of the lockin outputs, and align the cavity by hand.

I think the ETMX Trans camera view is clipped a little bit.  I went down there, and it doesn't seem to be on the last optic before the camera, and moving the spot on the camera doesn't change the shape of the image, so I don't think it's on the camera.  We should look into this, since it's either clipping on the BS that separates some camera beam from the TRX beam, or TRX is getting a clipped beam too.  If the clipping is any earlier in the Trans path, the Trans QPD could also have some clipping.  This requires investigation.  The xarm trigger needs to be reset/disabled so we don't lose lock every time we block the TRX beam (as was happening to me).

XARM really doesn't like to relock unless the POX whitening is turned off.  Good flashes, doesn't really catch (10+ min waiting (while working on Yarm stuff) ).  After turning off the whitening, it catches almost immediately. Even though it's on the to-do list to rethink the tuning of our whitening, we should probably implement the whitening triggering now anyway.  It'll make things easier.

The double integrator that Rana implemented in the X and Y arm servo filters last week take 8 seconds to turn off (due to Foton settings), so even though they are triggered to turn off immediately upon lockloss, they sit around and integrate for 8 seconds, so have huge signals.  If the cavity flashes and the locking trigger engages during that 8 seconds, we send a huge kick to the ETMs.  I'm modeling the response of the filters to an impulse and noise, particularly in the case of ramping on the double integrators.  The problem is that a flat filter has 0deg phase, but the double integrator has 180deg phase at low frequencies, so there's some weird sign flipping that can happen as we ramp - this is part of what I'm modeling.

MC is losing lock unusually often tonight.  Everything on the servo board screen looks normal (which is good since that's all set by the autolocker).  I just disabled the test exc in, but that's been left enabled for a while now, and it hasn't (I think?) been a problem since there shouldn't be anything connected to the board there.  PMC transmission is a little low, 0.816, and FSS is starting to get near -1 on the slow actuator adjust, but we've seen locking of the PMC problems around -1.5 or -2 of the FSS, and the adjust value was at -0.8 earlier tonight and we still had MC locking problems.  I have had the seismic channels open on Dataviewer for the last several hours, and I'm not seeing any spikes in any of the Guralp channels which correspond to the times that the MC loses lock.  BLRMS don't seem particularly high, so MC lockloss cause is still a mystery for today.

The ETMX monitor selector on the VIDEO screen seems not to be switching the actual camera that's shown on the monitor.  Using the script command itself works, so my screen is wrong.

POY was looking funny, and the YARM wasn't locking.  It looked like POY wasn't seeing any light at all.  I went to check, and it looks like a beam dump got accidentally placed in the POY path during oplev adjustments this morning.  POY is back, locking continues.

Optical layout of the current endtable at ETMX has been updated in the svn repository (directory: 40M_Optical Layout). This layout will help in redesigning the table for the proposed replacement.

Some part numbers of mounts/optics are missing and will be updated once I find them. If you find anything wrong with the layout, do let me know.

Temperature sensor for vacuum. How many : 2 or 3 ?  $350 each

Glass encapsulated thermistor #55007  with Ceramabond 835-m glued onto spade connector and hooked up to controller DP25-TH-A with analoge output.

This zero to 10Vdc can go to ADC

I installed pyepics version 3 (http://cars9.uchicago.edu/software/python/pyepics3/overview.html) in ..../scripts/pylibs    .   I also added an "epics.conf" file to /etc/ld.so.conf.d/ , which points to the place in /ligo/apps/epics/base/lib/linux-x86_64/ where the DLLs live.  All .conf files in /etc/ld.so.conf.d/   get included in the path, so python should always automatically be able to use epics now, after you "import epics" in a script.

This is supposed to give us direct channel access to all epics channels, rather than using Yuta's wrapper scripts for ezca stuff.  I was going to write a tdsavg equivalent using camonitor, since it's unclear whether tds tools are being supported anymore.

However, I'm not getting it to connect to the server that serves epics, so I can't get the values of any channels.  All of the info in the link above assumes that you automatically get a connection, and I'm out of ideas right now of things to try.  Does anyone else have any ideas?

Oplevs centered in flashing condition, except PRM and SRM.  IP POS centered also,

I like this new summing screen of Jenne.

The green beam for the Xarm is flashing a pretty nice 00 mode, but isn't catching lock.

The green beam for the Yarm isn't flashing at all that I can tell from just the camera views.  I don't have energy to start this sometimes monumental task tonight, so I leave it for Future Jenne to work on.

I (for the first time personally) locked the FPMI.  I have data for the POX11I, POY11I, AS55Q error signals for each arm and the Michelson (JenneLockingDTT/FPMI_error_signals.xml), but I haven't calibrated the data yet - Self: do this!  FPMI with arms locked using IR has been happily locked for a long time now - this is good.

From elogs / my old MICH calibration script, I have the plant calibrations of:

POY:  1.4e12 cts/m

POX: 3.8e12 cts/m

AS55: 9.4e9 cts/m

MICH has FM 5 on, Xarm has FM4-10 all on, Yarm has FM3-10 all on. 

Post note: FM 3 - the integrator - for Xarm wasn't triggered.  It turns on just fine, so I've got it triggered just like Yarm.

Also, just remembered - I turned off the XARM TRX power normalization, since it was causing crazy numbers in the xarm servo.  The XARM locked pretty easily after that.

MC and PMC vis:

MC REFL Unlocked    = 4.4

MC REFL Locked      = 0.67

 1 - Locked/Unlocked = 85%

PMC REFL Unlocked   = 0.270

PMC REFL Locked     = 0.013

 1 - Locked/Unlocked = 95%

I checked (by looking through recent trends) that the zero level is zero on both channels. I tried to do a proper mode scan, but we have lost the PSL fast channels during the upgrade sadly. Also, the DC signal for the PMC REFL needs some gain. Unlocked level should be more like 3-5 V.

Also used the instructions from this page to add Google's sources to rosalba's apt-get list and then installed Chrome.