I have just received the scheduling of the PSL self work for tomorrow. Gautam and I agreed that if it is needed I will shut the laser off and cover the hole table with plastic.

As we do not have legs for Trillium, I was advised to use shims to adjust the levels. However, they produce extra resonance at ~30 Hz + harmonics. Coherence is lost at these frequencies.

 Brian Lantz / Dan Clark are looking around their lab to see if they forgot to ship the feet with the T-240.  They had taken the feet off to put it in a pod. 

Apparently its possible to have working models get into a bad state in regards to shared memory, which prevents the model from working after killing it and restarting it.  We found that by shutting all the models down, and then killing and restarting the setup_shmem process, it allowed models to function properly again.

The symptom was getting stuck at the burt restore step, according the log files (/opt/rtcds/caltech/c1/target/c1SYS/logs/log.txt).

CALIFORNIA INSTITUTE OF TECHNOLOGY

                 FACILITIES MANAGEMENT

**PLEASE POST**

Building:         Campus

Date:             Thursday October 04,2012

This morning at 2:17 a.m. much of the City of Pasadena including our Campus experienced a electric power sag of short duration, approximately 1/10 of a second. The cause was a fault on one of Pasadena’s 17KV circuits. Some sensitive equipment have been impacted.

Contact:          Mike Anchondo x-4999

I wanted to measure the RF transimpedance of the WFS heads, as outlined above.

Summary: Measurement is not done.

Details:

• closed the PSL shutter
• taped over the WFS 2 opening with frosted scotch tape
• illuminated the QPD with an incandescent flashlight.
  • All of the D batteries were close to dead, so it seemed dimmer than usual
• Observed the WFS2 segment 1 RF spectrum on the Agilent, but saw no difference between the spectrum with and without the flashlight. Must need a brighter light, and possibly also better alignment.
• Needed to skype someone and pass off the IFO to gautam, so I untaped the QPD, returned the appropriate LEMO connector, and opened the PSL shutter.

Uniblitz mechanical shutter installed in the green beam path at ETMY-ISCT  The remote control cable has not been connected.

 We have tried to ssh into c1iscey yesterday morning. It just did not work. We have just tried it again (now) and it did work.

Lesson learned: always shut down the computer from a TERMINAL Do not turn it off by the manual power switch.

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 power ratio of the beatnote signal vs. the 216kHz sideband has been measured.

The measured ratio was -55 dB, which is smaller by about 20 dB than Aidan's estimation.

To confirm this fact we should check the modulation depth of the end PDH somehow.

The below is a picture showing the sidebands around the beatnote locked at 66.45 MHz.

Other than the +/-216 kHz sidebands, we can see some funny peaks at +/- 50 kHz and +/-150 kHz

I wonder if they come from the servo oscillation of the MC servo whose UGF is at 24 kHz.  We can check it by unlocking the MC.

Can we set up a fiber-PD on the end table to look at the beat between the "end laser IR beam" and the "PSL IR beam fiber-transmitted end beam"? 

We should see the same thing on that PD that we see on the green PD (plus any fiber noise and I'm not really sure how much that'll be off the top of my head). If we unlock the lasers from the arm cavity then the free-running noise of the lasers wrt to each other will probably swamp the 50kHz and 150kHz signals. Maybe we could lock the end laser to the free-running PSL by demodulating the beat note signal from the fiber-PD and then we could look for the extra sidebands in the IN-LOOP signal. Then we could progressively lock the PSL to the MC and arm cavity and see if the sidebands appear on the fiber-PD at some point in that process. 

It's possible that the 216kHz drive of the PZT on the Innolight is somehow driving up some sub-harmonics in the crystal. I think this is unlikely though: if you look at Mott's measurements of the Innolight PZT response, there are no significant PM resonances at 50 or 150kHz.

When Koji and I were massaging the MC, we noticed that the oscillations were at 48.5 kHz. They were pretty huge and are probably what you're seeing on the beat. My guess is that they are the PZT resonances of the PSL 2W NPRO; we need to put a notch in the FSS box - it still has the notch from the old NPRO.

I made a simple PD test circuit which may allow to test PD response up to few 100MHz.

Its not for low noise, only for characterising PD response.

Here is the circuit:

The 2 capacitor values (for bypassing) are kind of arbitrary, just what I found around

(one medium, one small capacity). Could be improved by better RF types (e.g. Mica).

The PD type has no meaning. I put in the Centronic 15-T5 for a start.

The bias can be up to 20V for this diode.

The signal appears across R1. It is small, to make a large bandwidth.

R2 is just for slightly decoupling the signal from the following RF amplifier.

The wire into the RF amplifier is short (~cm). And the amplifier is supposed to have 50 Ohm

input impedance.

I use a mini circuits ZFL 500 here.

power supply for this is 15V.

 I put matlab files and a summary into the 40m wiki for the fitting of the 40m Optickle transfer functions and generating digital filters for the simulated plant:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Generating_DOF-%3EPD_digital_filters_based_on_Optickle_modeling

The filters are not loaded yet. Joe and Alex will make a rcg code to make a matrix of filters (currently 5x15=75 elements) which will enable the simulated plant tf's.

Joe and I tried to put a signal through the DARM loop but the signal was not going through the memory location in the scx part of the simulated plant.

Edit by Joe:

I was able to track it down to the spx model not running properly.  It needed the Burt Restore flag set to 1.  I hadn't done that since the last rebuild, so it wasn't actually calculating anything until I flipped that flag.  The data is now circulating all the way around.  If I turn on the final input (the same one with the initial 1.0 offset), the data circulates completely around and starts integrating up.  So the loop has been closed, just without all the correct filters in.

To get the feeling of the master of IFO, I;

1. Stabilized both arm length using ALS.

2. Ran findIRresonance.py for both arms and find what offset gives me IR resonances.

3. Holded X arm to IR resonance, holded Y arm to IR resonance, and released both arms.

Below is the time series data of what I did.



Issues:
 - Currently ALS is not stable enough. It only stays for about few minutes. I think it is because of the bad alignment of green from each end.
 - We can't tell end green frequency is higher or PSL green frequency is higher. So, the sign of the servo filter sometimes flips.
 - Wobbliness of X end green transmission beam spot was from the ETMX oplev. When the oplev servo is on, it got more wobbly when X end table is opened. But when the oplev servo was off, wobbliness was same even if the presence of air flow.
 - MICH contrast in plot above seems like it somehow got better when two arms are at resonance by ALS. I think this is not real because reflection from both arms at AS port was not well aligned and beam was clipped. Koji and I measured contrast of FPMI and MI(ETMs misalined), and they were 99.6 % and 99.9 % respectively. Beam clipping seems like it comes from some where between BS to AS port. We need to figure out where and fix this.

Things need to be done to make ALS more concrete:
 - Align Y end green beam!
 - Look into Y end green frequency servo
 - How do we hand-off servo using ALS to IR lock?
 - Noise budgeting for new phase tracker scheme
 - Linearity check of the beat box and phase tracker

We have one single O-ring on the 40m vacuum envelope. It is on the OOC west side, facing the AP table. This O-ring has to be protected from the force of this

door. There should be 3 shims  ~120 degrees apart to carry the full load, so it is not the O-ring that is getting squashed.

This morning I found only one of these shims in place.

 In the previous elog we've proved that signals C1:SUS-MC3_LSC_EXCMON and  C1:SUS-MC3_LSC_OUTMON are in single precision. Now we try to understand if the precision is lost when the signals enter dtt tools or in the online code. For this measurement we just switch on one of the filters between the signals. By this we add mathematical operations inside the online code. If double precision is used there, then we'll see the same error as before, because the real error is still very small (~10^-15) and dtt tools add this 10^-7 error. But if the digital error will increase then no matter what kind of precision use dtt, online code uses single precision. At least at some points.

Test 1.   cheby1("LowPass",6,1,12) 

Test 2.  cheby1("Lowpass",2,0.1,3)

 Test 3. butter("LowPass",8,10)

Test 4.  butter("LowPass",2,10)

We can see that coherence become worse. And longer filter - more digital error. This means that single precision is used in calculations.

[Jamie, Xavi Siemens, Chris Pankow]

We built the skeleton of a new calibration model for the LSC degrees of freedom.  I named it "c1cal".  It will run on the c1lsc FE machine, in CPU slot 4, and has been given DCUID 50.

Right now there's not much in the model, just inputs for DARM_ERR and DARM_CTRL, filters for each input, and the sum of the two channels that is h(t).

Tomorrow we'll extract all the needed signals from c1lsc, and see if we can generate something resembling a calibrated signal for one of the IFO DOFs.

So it turns out that the card that Rolf had given me was not a Dolphin host adapter after all.  He did have an actual host adapter board on hand, though, and kindly let us take it.  And this one works!

I installed the new board in c1ioo, and it recognized it.  Upon boot, the dolphin configuration scripts managed to automatically recognize the card, load the necessary kernel modules, and configure it.  I'll describe below how I got everything working.

However, at some point mx_stream stopped working on c1ioo.  I have no idea why, and it shouldn't be related to any of this dolphin stuff at all.  But given that mx_stream stopped working at the same time the dolphin stuff started working, I didn't take any chances and completely backed out all the dolphin stuff on c1ioo, including removing the dolphin host adapter from the chassis all together.  Unfortunately that didn't fix any of the mx_stream issues, so mx_stream continues to not work on c1ioo.  I'll follow up in a separate post about that.  In the meantime, here's what I did to get dolphin working on c1ioo:

c1ioo Dolphin configuration

To get the new host recognized on the Dolphin network, I had to make a couple of changes to the dolphin manager setup on fb.  I referenced the following page:

https://cdswiki.ligo-la.caltech.edu/foswiki/bin/view/CDS/DolphinHowTo

Below are the two patches I made to the dolphin ("dis") config files on fb:

--- /etc/dis/dishosts.conf.bak    2014-04-17 09:31:08.000000000 -0700
+++ /etc/dis/dishosts.conf    2014-04-17 09:28:27.000000000 -0700
@@ -26,6 +26,8 @@
 ADAPTER:  c1sus_a0 8 0 4
 HOSTNAME: c1lsc
 ADAPTER:  c1lsc_a0 12 0 4
+HOSTNAME: c1ioo
+ADAPTER:  c1ioo_a0 16 0 4
 
 # Here we define a socket adapter in single mode.
 #SOCKETADAPTER: sockad_0 SINGLE 0

--- /etc/dis/networkmanager.conf.bak    2014-04-17 09:30:40.000000000 -0700
+++ /etc/dis/networkmanager.conf    2014-04-17 09:30:48.000000000 -0700
@@ -39,7 +39,7 @@
 # Number of nodes in X Dimension. If you are using a single ring, please 
 # specify number of nodes in ring.
 
--dimensionX 2;
+-dimensionX 3;
 
 # Number of nodes in Y Dimension. 

I then had to restart the DIS network manager to see these changes take affect:

$ sudo /etc/init.d/dis_networkmgr restart

I then rebooted c1ioo one more time, after which c1ioo showed up in the dxadmin GUI.

At this point I tried adding a dolphin IPC connection between c1als and c1lsc to see if it worked.  Unfortunately everything crashed every time I tried to run the models (including models on other machines!).  The problem was that I had forgotten to tell the c1ioo IOP (c1x03) to use PCIe RFM (i.e. Dolphin).  This is done by adding the following flag to the cdsParamters block in the IOP:

pciRfm=1

Once this was added, and the IOP was rebuilt/installed/restarted and came back up fine.  The c1als model with the dolphin output also came up fine.

However, at this point I ran into the c1ioo mx_stream problem and started backing everything out.

I added all the _OUT16, _INMON, _EXCMON channels associated with the BS, ITMX, and ITMY channels in SUS_SLOW.ini in the /opt/rtcds/caltech/c1/chans/daq directory.  Similarly, I added the channels associated with MC1, MC2, and MC3 to MCS_SLOW.ini and those associated with PRM and the SRM to RMS_SLOW.ini. 

Lines pointing to these files were then added to the /opt/rtcds/caltech/c1/target/fb/master file and the frame builder restarted.  It took about 4 tries before the frame builder stayed up using ./daqd -c ./daqdrc.

I generated the .ini files with a python script.  Its at /opt/rtcds/caltech/c1/scripts/daqscripts/create_inmon_out16_daq_ini.py. It checks the C0EDCU.ini to find what slow channels already exist, then goes through a medm directory given at the command line looking for all _OUT16, _INMON, and _EXCMON channels, adding them if they aren't already accounted for, and then writing out the new file to the location of your choice.

Why EXCMON? I think that we should modify the filter coefficients so that the decimation filter that makes OUT16 is a 2nd order Butterworth at 1 Hz instead of whatever bogus thing it is now. Then we can delete the EXCMON from the DAQ and add either OUTPUT or OUTMON. That way we will have a low frequency signal (OUT16) and a sort of aliased RMS (OUTMON).

ALS looks OK. I tried to lock FPMI using ALS, but I feel like I need 6 hands to do it with current ALS stability. Now I have all computers being so slow.

It was fine for 7 hours after Jamie the Great fixed this, but fb went down couple times and DAQ status for all models now shows 0x4000. I tried restarting mx_stream and restarting fb, but they didn't help.

[gautam, lydia]

We rebooted c1psl, c1iscaux and c1aux which were all showing the typical symptom of responding to ping but not to telnet (and also blanked out epics fields on the MEDM screens). Keyed all these crates.

Restored burt snapshots for c1psl, PMC locked fine, and IMC is also locked now.

Johannes forgot to elog this yesterday, but he rebooted c1susaux following the usual procedure to avoid getting ITMX stuck. 

Rebooted c1iscaux, c1auxex and c1auxey which were all not reponding to telnet. The watchdogs for the ETMs were turned off and then I keyed all 3 crates. All slow machines are reponding to telnet now. Both green lasers locked to the arms so I didn't do any burt restore.

Had to reboot c1psl, c1susaux, c1auxex, c1auxey and c1iscaux today. PMC has been relocked. ITMX didn't get stuck. According to this thread, there have been two instances in the last 10 days in which c1psl and c1susaux have failed. Since we seem to be doing this often lately, I've made a little script that uses the netcat utility to check which slow machines respond to telnet, it is located at /opt/rtcds/caltech/c1/scripts/cds/testSlowMachines.bash.

The script can be executed by ./testSlowMachines.bash.

After ~3months without any problems on the slow machine front, I had to reboot c1psl, c1susaux and c1iscaux today. The control room StripTool traces were not being displayed for all the PSL channels so I ran testSlowMachines.bash to check the status of the slow machines, which indicated that these three slow machines were dead. After rebooting the slow machines, I had to burt-restore the c1psl snapshot as usual to get the PMC to lock. Now, both PMC and IMC are locked. I also had to restart the StripTool traces (using scripts/general/startStrip.sh) to get the unresponsive traces back online.

Steve tells me that we probably have to do a reboot of the vacuum slow machines sometime soon too, as the MEDM screen for the Vacuum indicator channels are unresponsive.

Steve alerted me that the IMC wouldn't lock. Reboots for c1susaux, c1iool0 today. I tried using the reset button instead of keying the crates. This worked for c1iool0, but not for c1susaux. So I had to key the latter crate. The machine took a good 5-10 minutes before coming back up, but eventually it did. Now IMC locks fine.

Reboots for c1susaux, c1iscaux, c1auxex today. I took this opportunity to squish the Sat. Box. Cabling for MC2 (both on the Sat box end and also the vacuum feedthrough) as some work has been recently ongoing there, maybe something got accidently jiggled during the process and was causing MC2 alignment to jump around.

Relocked PMC to offload some of the DC offset, and re-aligned IMC after c1susaux reboot. PMC and IMC transmission back to nominal levels now. Let's see if MC2 is better behaved after this sat. box. voodoo.

Interestingly, since Feb 6, there were no slow machine reboots for almost 3 months, while there have been three reboots in the last three weeks. Not sure what (if anything) to make of that.

Reboots for c1psl, c1iool0, c1iscaux today. MC autolocker log was complaining that the C1:IOO-MC_AUTOLOCK_BEAT EPICS channel did not exist, and running the usual slow machine check script revealed that these three machines required reboots. PMC was relocked, IMC Autolocker was restarted on Megatron and everything seems fine now.

Reboots for c1susaux, c1iscaux today.

MC autolocker and FSS loops were stuck because c1psl was unresponsive. I rebooted it and did a burtrestore to enable PSL locking. Then the IMC locked fine.

c1susaux and c1iscaux were also unresponsive so I keyed those crates as well, after taking the usual steps to avoid ITMX getting stuck - but it still got stuck when the Sat. Box. connectors were reconnected after the reboot, so I had to shake it loose with bias slider jiggling. This is annoying and also not very robust. I am afraid we are going to knock the ITMX magnets off at some point. Is this problem indicative of the fact that the ITMX magnets were somehow glued on in a skewed way? Or can we make the situation better by just tweaking the OSEM-holding fixtures on the cage?

In any case, I've started listing stuff down here for things we may want to do when we vent next.

MC autolocker was not working - PCdrive was railed at its upper rail for ~2 hours judging by the wall StripTool trace. I tried restarting the init processes on megatron, but that didn't fix the problem. The reason seems to have been related to c1iool0 failing - after keying the crate, autolocker came back fine and MC caught lock almost immediately.

Additionally, c1susaux, c1auxex,c1auxey and c1iscaux are also down. I'm not planning on using the IFO tonight so I am not going to reboot these now.

Eurocrate key turning reboots for c1susaux, c1auxex,c1auxey, c1iscaux, c1iscaux2 and c1aux. Usual precautions were taken for ITMX. Did burtrestore for c1iscaux andc1iscaux2  in order to restore the LSC PD whitening gains.

Un-related to this work: input pointing into PMC was tweaked as the PMC_REFL spot was pretty bright.

MC Autolocker was umnhappy because c1iool0 was unresponsive and hence it couldn't write to the "C1:IOO-MC_AUTOLOCK_BEAT" channel. I keyed the crate and IMC locked almost immediately. I'm moving this channel into the RTCDS model as we did for the IFO_STATE EPICS channel so that the autolocker isn't dependant on c1iool0 (which was the whole point of migrating the IFO-STATE variable anyways). I also commented out all of these channels in /cvs/cds/caltech/target/c1iool0/autolocker.db so that there aren't duplicate channels.

Steve reported problems getting the X arm locked. Alignment sliders were inaccessible. Eurocrate key turning reboots for c1susaux, c1auxex,c1auxey, c1iscaux and c1aux. Usual precautions were taken for ITMX.

This is becoming a once-a-week thing .

[ Gautam , Steve ]

c1susaux & c1iscaux were rebooted manually.

Eurocrate key turning reboots today morning for and c1susaux, c1auxey and c1iscaux. These were responding to ping but not telnet-able. Usual precautions were taken to minimize risk of ITMX getting stuck.

MC autolocker got stuck (judging by wall StripTool traces, it has been this way for ~7 hours) because c1psl was unresponsive so I power cycled it. Now MC is locked.

c1psl, c1susaux, and c1auxey today

[johannes, gautam]

It's been a while - but today, all slow machines (with the exception of c1auxex) were un-telnetable. c1psl, c1iool0, c1susaux, c1iscaux1, c1iscaux2, c1aux and c1auxey were rebooted. Usual satellite box unplugging was done to avoid ITMX getting stuck.

All slow machines (except c1auxex) were dead today, so I had to key them all. While I was at it, I also decided to update MC autolocker screen. Kira pointed out that I needed to change the EPCIS input type (in the RTCDS model) to a "binary input", as opposed to an "analog input", which I did. Model recompilation and restart went smooth. I had to go into the epics record manually to change the two choices to "ENABLE" and "DISABLE" as opposed to the default "ON" and "OFF". Anyways, long story short, MC autolocker controls are a bit more intuitive now I think.

Reboot for c1susaux and c1iscaux today. ITMX precautions were followed. Reboots went smoothly.

IMC is shuttered while Jon does PLL characterization...

Now relocked.

FSS slow wasn't running so PSL PZT voltage was swinging around a lot. Reason was that was c1psl unresponsive. I keyed the crate, now it's okay. Now ITMX is stuck - Johannes just told be about an un-elogged c1susaux reboot. Seems that ITMX got stuck at ~4:30pm yesterday PT. After some shaking, the optic was loosened. Please follow the procedure in future and if you do a reboot, please elog it and verify that the optic didn't get stuck.

Eurocrate key turning reboots today morning for and c1susaux, c1auxex and c1auxey. Usual precautions were taken to minimize risk of ITMX getting stuck.

The IFO hasn't been aligned in ~1week, so I recovered arm and PRM alignment by locking individual arms and also PRMI on carrier. I will try recovering DRMI locking in the evening.

As far as MC1 glitching is concerned, there hasn't been any major one (i.e. one in which MC1 is kicked by such a large amount that the autolocker can't lock the IMC) for the past 2 months - but the MC WFS offsets are an indication of when smaller glitches have taken place, and there were large DC offsets on the MC WFS servo outputs, which I offloaded to the DC MC suspension sliders using the MC WFS relief script.

I'd like for the save-restore routine that runs when the slow machines reboot to set the watchdog state default to OFF (currently, after a key-turning reboot, the watchdogs are enabled by default), but I'm not really sure how this whole system works. The relevant files seem to be in the directory /cvs/cds/caltech/target/c1susaux. There is a script in there called startup.cmd, which seems to be the initialization script that runs when the slow machine is rebooted. But looking at this file, it is not clear to me where the default values are loaded from? There are a few "saverestore" files in this directory as well:

• saverestore.sav
• saverestore.savB
• saverestore.sav.bu
• saverestore.req

Are the "default" channel values loaded from one of these?

Eurocrate key turning reboots today morning for c1psl and c1aux.c1auxex and c1auxey are also down but I didn't bother keying them for now. PSL FSS slow loop is now active again (its inactivity was what prompted me to check status of the slow machines).

Note that the EPCIS channels for PSL shutter are hosted on c1aux.But looks like the slow machine became unresponsive at some point during the weekend, so plotting the trend data for the PSL shutter channel would have you believe that the PSL shutter was open all the time. But the MC_REFL DC channel tells a different story - it suggests that the PSL shutter was closed at ~4AM on Sunday, presumably by the vacuum interlock system. I wonder:

1. How does the vacuum interlock close the PSL shutter? Is there a non-EPICS channel path? Because if the slow machine happens to be unresponsive when the interlock wants to close the PSL shutter via EPICS commands, it will be unable to. The fact that the PSL shutter did close suggests that there is indeed another path.
2. We should add some feature to the vacuum interlock (if it doesn't already exist) such that the PSL shutter isn't accidentally re-opened until any vacuum related issues are resolved. Steve was immediately able to identify that the problem was vacuum related, but I think I would have just re-opened the PSL shutter thinking that the issue was slow computer related.

The folding crane was fixed and tested this morning by the NNN rigging company. Pictures will be posted by Steve in the morning.

Afterwards, the ITM-east door was installed, jam-nuts checked. No high voltage was on for the in-vac PZTs.

The annulus spaces were roughed down to 350mTorr by Roughing Pump RP1. For this operation, we removed the low flow valve from the RP1 line.

After the spaces came down to ~400 mTorr, we closed their individual valves.

Warning: The VABSSC1 and VABSSC0 valves are incorrect and misleadingly drawn on the Vacuum overview screen.

We then:

1. Closed V6 (valve between RP1 and the annulus line).
2. Turned off RP1 from the MEDM screen.
3. Installed the soft -starting butterfly valve.
4. Turned on RP1.
5. Opened V3.
6. Closed VV1 (at the last minute - this is a vent valve and must be checked before each pumpdown)
7. and pumpdown was started with a 3/4 turn opening of manual valve RV1.

Our idea is to have a much slower pumpdown this time than the last time when we had a hurricane kick up the dust. Looks like it worked, but next time we should do only 1/2 turn.

The pumpdown started at 4 PM (2300 UTC). At 10 PM, we (Jenne, Jan, and I) opened up the RV1 valve to full open. That's the second inflection point in the plot.

As per Steve's instructions, at 12:43 AM, I used the following steps to stop the pumpdown until the morning:

1. Close RV1 using the 'steering-wheel' wrench.
2. Close V3.
3. Turn OFF RP1.
4. Disconnect RP1 hose at the plastic disconnect attached to the slow-start throttle valve.