So apparently the themes/configurations didn't work so nicely on some of the logbooks with 2.8.0, so I'm reverting to 2.7.5 until I can figure out (assuming I can) how to get them to display properly.

[Hiroki, Paco, Yuta]

As mentioned in elog #17768, we are trying to lock PRFPMI.
To start with a simpler system step by step, we locked FPMI by revising the script for automated locking on Aug. 10th.

Revised automated locking of FPMI:

At first we tried to lock FPMI with the existing script and failed locking because of the changes of some gains.
We revised the script for the automation with the procedure explained in the Supplementary and succeeded in locking FPMI.
The script is easily accessed from the LSC - Actions submenu.
Locking configurations are saved in /opt/rtcds/caltech/c1/Git/40m/scripts/LSC/FPMI-AS55_REFL55.yml. 
The locking procedure by the script is as follows:

• Lock XARM and YARM with CARM and DARM using POX11_I and POY11_I.
• Lock MICH with REFL55_Q.
• Hand off the error signals of CARM and DARM from (POX11_I, POY11_I) to (REFL55_I, AS55_Q).

Attachment 1 shows the screenshot of the locked FPMI with the script above.
Attachment 2 shows the OLTF of MICH. UGF ~ 30 Hz.
 

Supplementary

Gain tuning of CARM and DARM with REFL55_I and AS55_Q:

Firstly, we used the existing script (/opt/rtcds/caltech/c1/Git/40m/scripts/LSC/FPMI-AS55_REFL55.yml) to lock FPMI and succeeded in locking with CARM and DARM by (POX11_I, POY11_I).
However, we failed in locking FPMI with CARM and DARM by (REFL55_I, AS55_Q).
So we measured the OLTF of CARM and DARM by (POX11_I, POY11_I) and that by (REFL55_I, AS55_Q) while FPMI is locked with (POX11_I, POY11_I) and REFL55_Q to see the difference of the OLTFs.

Attachment 3 shows the CARM OLTFs by (POX11_I, POY11_I) (red) and REFL55_I (blue).
UGF of POXY_CARM：~200Hz
UGF of REFL55_CARM: ~220Hz
Gain ratio at 200Hz: (POXY_CARM/REFL55_CARM) = (1.04/1.14) = 0.915

Attachment 4 shows the DARM OLTFs by (POX11_I, POY11_I) (red) and AS55_Q (blue).
UGF of POXY_DARM：~150Hz
UGF of AS55_DARM: ~90Hz
Gain ratio at 150Hz: (POXY_CARM/REFL55_CARM) = (0.9972/0.76)=1.31

In the existing script, CARM and DARM by (POX11_I, POY11_I) are assinged to CARM_A and DARM_A, and CARM and DARM by (REFL55_I, AS55_Q) are assinged to CARM_B and DARM_B.
To match the OLFTs of A and B above, we modified the following gains in the script using the results from the OLTFs measurement above:

CARM_B_GAIN: 1 -> 0.92  
DARM_B_GAIN: 1 -> 1.31

With this modification, we succeeded in locking the FPMI with (REFL55_I, AS55_Q).

Tips on aligning FPMI:

After locking the FPMI, you may find a higher order mode in the AS camera and the ASDC is not fully minimized.
If you misaligned ETMX and ETMY just before locking FPMI, the higher order mode may be produced by the misalignment in pitch for ETMX and ETMY because Misalign -> Restore command in the IFO window does not ensure the perfect restoration.
So you may minimize the ASDC by aligning the pitch of ETMX and ETMY.

The geophone noise in my last eLog was taken before any amplification of the signal, but what really matters is the noise after amplification, since it is this signal that the PZTs are driven by. The noise goes on to be amplified about 1000x before the geophone signal gets to the PZTs.

To obtain a more relevant noise plot, I multiplied the geophone noise by 1,000, the approximate gain of the amplification stage for the geophones (called the "compensator board", the semicircular board that sits toward the top of the STACIS). Below is a plot () that shows the noise for the geophones after amplification and the accelerometer noise (with accelerometers set with a gain of 100x, their highest).

The actual signal from both these sensors has the right magnitude to drive the PZTs (whereas it was much too small in my last plot, where I looked at the sensors before any gain)- this means that for these sensors, both of which are outputting signals that are ready to provide feedback to the STACIS, the accelerometer noise is significantly lower than the geophone noise. This is good news, because it means that there could be a real advantage to using the accelerometers instead of the geophones.

In the process of investigating further advantages of the accelerometers, I believe I killed one of the horizontal PZTs in the spare STACIS (the eBay one). The story: I had that axis in closed loop, and I saw the STACIS shudder, heard a noise, and there was a faint acrid smell. I shut the STACIS off and took out the high voltage card at the base but couldn't find any visible signs of damage (like the current-limiting resistors which burn when a PZT shorts, acc. to old STACIS records). I then tried driving the PZTs with a sine wave, and there was no response in that axis (the other axes looked fine), which leads me to believe I either did unseen damage to the high voltage amplifier (for the y-axis) or killed the PZT itself.

The units were still off in my previous post. Here's the corrected, sanity-checked version:

I estimated the uncertainties based on a linear fit to the data I recorded with 75nW incident on the CCD and assumed a 5% uncertainty in that number. This is just an upper limit, to be safe. I had calibrated the power reading placing the Ophir power meter where the CCD would otherwise be and comparing it to the PD voltage of a picked off beam. In my previous figures the axes were mislabeled, so I reproduce them here:

Using the current camera position I recorded 50 exposures both with and without beam (XARM locked vs PSL shutter closed) and averaged the images to see how much the reading fluctuates. The exposure time was 10 ms, which left the maximum reported pixel value in all exposures below 3800 out of 4096. The gain setting was 100, which is what I used to calibrate the CCDs.

(*) I calculated the lens positions to focus at a plane 65cm from the front lens. We're pretty close to that, but I can't confirm the actual distance easily, so I assumed a 5cm error on the distance, which is where most of the error is coming from. This is also assuming uniform scatter.

(**) This is assuming 10W of circulating power

[ericq, Gautam, Lydia]

We spent some time tonight trying to revive the PRFPMI. (Why PR instead of DR? Not having to deal with SRM alignment and potentially get a better idea of our best-case PRG). After the usual set up and warm up, we found ourselves unable to hold on to the PRMI while the arms flash. In the past, this was generally solved through clever trigger matrix manipulations, but this didn't really work tonight. We will meditate on the solution.

Still no luck relocking, but got a little further. I disabled the output of the problematic PRM OSEM, it seems to work ok. Looking at the sensing of the PRMI with the arms held off, REFL165 has better MICH SNR due to its larger seperation in demod angle. So, I tried the slightly odd arrangement of 33I for PRCL and 165Q for MICH. This can indefinitely hold through the buzzing resonance. However, I haven't been able to find the sweet spot for turning on the CARM_B (CM_SLOW) integrator, which is neccesary for turning up the AO and overall CARM gain. This is a familiar problem, usually solved by looking at the value far from resonance on either side, and taking the midpoint as the filter module offset, but this didn't work tonight. Tried different gains and signs to no avail.

• 27 or 29 total ADC channels are used (depending whether we keep 2 spare adc chans)
  • 4 each go to ASC_QPD1/2 (8 chans total)
  • 5 go to TRANS_PD1, TRANS_PD2, REFL_PD, TRANS_PD1_UF, TRANS_PD2_UF. These PD are used for ASC and LSC.
  • 2 go to the LSC, one each for DVMDC, DVMAC, X3DC, and X4DC
  • 12 go to the ASC_PZT
  • 2 go to the SPARE_ADC (not sure what this is)
  • I think these channels are (or were at some point) defined in memory by /cvs/cds/caltech/chans/ipc/G1.ipc
    • I found this from elog 2860; it mentions that these should eventually be migrated over to a file C1.ipc, but I don't see any OMC channels in that file or any of the 'old' C1.ipc files, so I suppose it never happened or they were removed later
  • During this vent, we won't have ASC, so
• 10 or 14 DAC channels are used (depending whether we keep 4 spare dac chans)
  • 2 from the LSC, one for CLK_OUT and one for "LSC"
  • 8 from ASC, including P1A, P1B, P2A, P2B, P1OSC, Y1OSC, P2OSC, Y2OSC
  • I think these channels are (or were at some point) saved to frames due to /cvs/cds/caltech/chans/daq/C1OMC.ini, which I found from elog 2073
  • At some point, the 33MHz mod depth was controlled by one of the spare OMC chans, C1:OMC-SPARE_DAC_CH_15. See elog 2126. I assume this is no longer the case, since c1omc is defunct.
  • Durnig this vent, we won't have ASC and don't need to CLK_OUT the LSC, so we may just need one DAC channel

As of at least Nov 2009, the .par file for the OMC was located at /cvs/cds/gds/param/tpchn_C2 (see elog 2316)

• Kepco HV supply, "OMC-L-PZT", labels indicate it goes to 250V, needs to be tested  ("TESTED OK 2014OCT12")
• Tip/Tilt Piezo Driver, LIGO D060287
• HV Piezo Driver, LIGO D060283
• QPD Whitening Board, D060214
• LIGO D050374/D050387
• LIGO D050368/D050373

Need to check:

• Can the ADC/DAC adapter boards (eg D0902006) drive whatever ~10V control signal we need across ~10m of SCSI cable?
•  

Tonight, I've taken a bunch of data where the PRC is carrier locked and the ITM oplevs have the DC coupling FM turned on, as we use during locking. This is to inform new feedforward filters to stabilize the PRC angular motion, by using Wiener filtering with the POP QPD as the target, and local seismometers/accelerometers as witnesses. So far I've looked at the 1800 seconds leading up to GPS time 1122885600, but there has been plenty of locked time tonight if I need to retrieve more. 

I've also measured the PRM ASC output torque -> POP QPD spot motion with high (>0.95) coherence from 0.1Hz to 10Hz. 

Prefiltering so far consists of a 4th order elliptic LP at 5 Hz, with the target subtraction band being the 1-3Hz range. 

With offline FIR filtering, the RMS pitch motion is reduced by a factor of 3 just with the STS1_X data. IIR fitting remains to be done. 

The PRC yaw motion, which is marginally noisier, is a little more tangled up across X and Y. 

Plots / filters forthcoming pending more analysis. 

1. X arm is totally misaligned in order to measure the Y arm loss using the reflection method. Each measurement round consists of measuring the reflected power when the Y arm is aligned and when it is misaligned.

2. The measurement script used is /scripts/lossmap_scripts/armLoss/measureArmLoss.py. It generates a log file in the /logs folder specifying the alignment and misalignment times.

3. The data extraction script dlData.py processes the raw data in the log file and creates a hdf5 file in the /Data folder conataining the data of the measurement it self.

4. dlData.py labels the the aligned and misaligned datas incorrectly when the number of measurement is odd. I use only even number of measurements then.

5. In order to clip the chaotic transition between the aligned and misaligned states I use tDur attribute smaller than the actual sleep time used in the measurement script itself.

6. plotData.py (written by Gautam) and AnalyzeLossData.ipynb (written by me) can be used to calculate the loss and to plot some analyses (see https://nodus.ligo.caltech.edu:8081/40m/14568). They give roughly the same answer. The descripancy can be explained by the different modulation and ITM transmissions used.

7. I take a measurement of 8 repeatitions. I plot the measured reflected power alternating between the aligned and misaligned states. 

I find that the reflected power is repeatable to within 1%.

This is consistent with the transmission data plotted here which is also repeatable to within 1%.

8. I take an overnight measurement of 100 repeatitions.

I drew out some idea of how we might use a single OMC to clean both paths of the BHD after mixing, without being susceptible to polarization-dependent effects within the OMC. Basically, can we send the two legs of the BHD into the OMC counterpropagating. I've attached a diagram.

I think one issue would be scattered light, since any backscatter directly couples into the counterpropagating mode, and thus directly to the PD. However, unless the polarization of the scattered light rotates it would not scatter back to the IFO. And, since the LO and signal mix before the OMC, this scattered light would not directly add phase noise.

Maybe more problematic would be that if the rejection at the PBS (or the polarization rotation) isn't perfect, light from the LO directly couples into the dark port. Can we get away with a Faraday isolator before the OMC? 

Diagram attached.

I think a Faraday rotator rotates the polarizations in a same way for both forward and backward beam, and it's not like in this figure.
And the transmission through multiple faradays will also be a big issue.

 We are venting tomorrow. This give us an opportunity to fix sick vacuum controller computer. Jamie volunteered.

Remember to rough down cryo and ion pump volumes. Their pressure can be at 1 Torr range after years of accumulated outgassing.  Without total valve controls it is dangerous to have these air pockets. Some of their  gate valves can be leaking and that would explane the slower pumpdown speed. 

I had asked Chub to order 100ft ea of 9, 15 and 25 conductor ribbon cable. These arrived today and are stored in the VEA alongside the rest of the electronics/chassis awaiting assembly.

I installed a fast PDA10CF along the path of a leaking beam from one of the steering mirrors that direct the main beam to the PMC. This beam was dumped to a razor blade. I removed the razor blade and installed a Y1 to steer this beam through a lens on the PD.

Pics of the layout post-installation will be updated.

Also, I tested the AOM by giving it 0-1V modulation input from the AWG. This has been disconnected after the test. So everything should be as it was pre-testing.

I tried to make ringdown measurements at the IMC using the DC falling edge as the trigger. Input to the MC was switched off by changing the polarity of the MC servo. But it does not seem to give the needed data as there seem to be several DC falling edges as soon as the polarity is switched. We should think about a better trigger or try to setup data recording from the oscilloscope seamlessly.

Also an ethernet cable has been connected to the router from the oscilloscope at the MC trans, but has not been set up to record data yet.

Finally ringdown at IMC conquered and oopsie that came out so clean!

The finesse of the cavity from the current ringdown measurement, F= 453, differs from the measurements made in the document dated 10/1/02 on dcc...not sure if things have changed since then.

While I thought that the bumps observed at the end of the ringdown might be because of the cavity trying to lock itself, Jan commented that they have always existed in these measurements and their source is not known yet.

What I meant to say was that in all ringdown measurements that we observed today, the bumps were consistently part the ringdown, and that I have no explanation for the bumps. It should also be mentioned that fitting the bumpy part of the ringdown instead (we used the clean first 10us), the ringdown time is about twice as high. In either case, the ringdown time is significantly smaller than we have seen in documents about previous measurements.

We (basically I) also made one error when producing the plots. The yaxis label of the semi-logarithmic plot should be log(...), not log10(...).

 I thought about  why we do not find any bumps beyond the exponential fall. Could it be because we neglected fluctuations of voltage in the negative direction and plotted the absolute values?

I prepare for the ringdown measurement of the PMC according to Gautam's previous experiments.

1. I assembled the needed PDs and power supplies, lenses, beamsplitters and optomechanics needed for the measurement.

2. I surveyed the laser power with an Ophir power meter in the different parts of the experiment. All the measurements were done with the AOM driver excited with 1V DC.

For the PMC reflection, we chose to split off the beam that goes into the reflection camera. The power in that beam is ~ 0.11mW when the PMC is locked and 2.1mW otherwise.

For the PMC transmission, we chose to split the beam that is transmitted through the second steering mirror after the PMC. The power in that beam is 2mW.

For the peak off before the PMC, we chose to split the beam that goes into the fiber coupler. That path contains also the other AOM diffraction orders: 2.26mW in the 0th order beam, 6.5mW in the 1st order beam, 0.14mW in the 2nd order beam.

3. I placed a 10% beam splitter in the peak-off path such that 90% still goes into the fiber coupler (Attachment 1). I place a lens and PDA255 to measure the peak-off (Attachment 2).

It's getting late, I'll continue with the PD placements on Tuesday.

Zero order beam PMC ringdown

On Wednesday I installed 3 PDs (see attached photos) measuring: 

1. The input light to the PMC. Flip-mirror was installed (sorry Shruti) on the beam path to the fiber coupler.

2. Reflected light from the PMC.

3. PMC transmitted light.

I connected the three PDs to the oscilloscope and the AOM driver to a function generator. I drive the AOM with a square wave going from 1V to 0V.

I slowly increased the square wave frequency. The PMC servo doesn't seem to care. I reach 100KHz - it seems excessive but still works. In any case, I get the same results doing a single shut-down from a DC level.

I download the traces. I normalize the traces but I don't rescale them (Attachment 4) so that the small extinction can be investigated.

I notice now that the PDs show the same extinction. It probably means I should have taken dark currents data for the PDs.

Also, I forgot to take the reflected data when the PMC is out of resonance with the laser which could have helped us determine the PMC transmission.

Again, the shutdown is not as sharp as I want. There is a noticeable smoothening in the transition around t = 0 which makes the fit to an exponential difficult. I suspect that the function generator is the limiting device now. I hooked up the function generator to the oscilloscope which showed similar distortion (didn't save the trace)

I try to fit the transmission PD trace to a double exponential and to Zucker model (Attachment 5).

The two exponentials model, being much less restrictive, gives a better fit but the best fit gives two identical time constants of 92ns.

The Zucker model gives a time constant of 88ns. Both of these results are consistent with more or less with the linewidth measurement but this measurement is still ridden with systematics which hopefully will become minimized IMC ringdowns.

Zeroth order IMC ringdown setup

Following Gautam's IMC ringdown setup, I took the REFL PD form the PMC ringdown experiment and installed it in the IMC REFL path blocking WFS2 (Attachment 1).

I also ran a BNC cable from the transmission PD that Gautam installed on the IMC table to the vertex where the signals are measured on the scope. 

I offloaded the WFS servo output values onto the MC alignment (using the WFS servo relief script) so that its dc values would be correct when the servo is off.

Unfortunately, it seems like the script severely misaligned the MC mirrors at some point when the MC got unlocked. We should fix the script such that it stops when the offloading is complete.

We got the MC realigned but left it in a state where it is not locking easily.

It's fine to block the WFS while doing ringdowns but please return the config to normal so I don't have to spend time every night recovering the interferometer before doing the locking. As I mention in that post, it is possible to do this in a non-invasive way without having to run any extra cables / permanently block any beams. If there is some issue with the data quality, then we can consider a new setup. But I see no reason to re-invent the wheel.

The IMC was also massively misaligned. I had to re-align both MC1 and MC2 to recover the lock. I took this opportunity to reset the WFS offsets. Please do not disturb the alignment of the existing optical layout unless you verify that everything is working as it should be after your changes.

And for whatever reason, ITMX was misaligned. If you do something with the interferometer, no matter how minor it seems, please leave a note on the ELOG. It will save many painful debugging hours.

As I fix these, the seismic activity has gone up . I'll wait around for an hour, but not an encouraging restart to the locking 😢 

A recap of the ringdown measurements made at the 40m in mid 2012, the hardware that was installed for the same and results from the measurements.

IMC ringdown:

Hardware installed 
A trans PD was installed (elog 7122).
This PD does not exist in the trans path anymore.

Measurements
The polarity in the MC servo was flipped with the MC WFS disabled and the PD trans signal was used to look at the cavity ringdown. 
Ringdown time = 13 us
Cavity finesse from the measurement = 453 (inconsistent with actual finesse). 

Attachment: Ringdown measurement and fits

PMC ringdown:

Hardware installed
The AOM was installed before the PMC. The AOM was driven by the driver installed on the PSL table. (RF power ~1.5W @ 80MHz @1.0V modulation input). An RF switch was installed to control the AOM driver input. ZASWA-2-50DR+ was installed.
Note: The AOM was used by the ISS crew after this. So the RF switch has been removed and the AOM is no more a part of the ringdown setup.

Measurements
No measurements were made as we could not obtain relevant TTL signals to control the switch remotely.

To do this better:

1) Just step the analog input to the AOM (i.e. no RF switch) and measure the PMC trans output with a fast DC coupled PD. IMC should be unlocked and disable during this part. We want the PMC ringdown to be faster than 1 us.

2) Re-install a fast PD in the MC trans path without disrupting the existing MC trans QPD setup.

3) Measure IMC ringdown and fit the data to find the cavity losses.

4) Think about how to use the Isogai, et. al (2013) technique to better measure the losses, taking into account the mirror transmissions.

 [Jenne, EricQ, Nic, MattA]

* TT1 is in place, aligned so beam hits center of TT1, hits center of MMT1 (used pitch biases to finish pitch).

      * Riser installed, dogged down with 1 dog.

      * TT1 sitting on top of riser, 3 dogs holding TT to table, with riser squished in between.

* IOO table leveled.

      * Almost all of the weights on the IOO table were just sitting there, not screwed down!  One didn't even have a screw, 3 had screws, but they were totally loose.  2 of those screws were in as far as they could go, but they weren't holding the weight.  This means the screw was too long, and should have been replaced (which I did today).  Just because the existing screw was too long, doesn't mean it should be left as-is.  Everything in the chambers must be tightly clamped down, as soon as work on that item is complete!  Anyhow, after finalizing the leveling, I tightened down all of the weights on the IOO table.

* MMT1 tweaked so beam hits center of MMT2. 

* MMT2 tweaked so beam hits center of PZT2.

* Light access connector installed.

Sadface notes:

* I dropped a Class B golden-colored 3/16 allen key to the bottom of the IOO chamber.  I can't see it, but Nic thinks he might be able to see it with a mirror, from the BS chamber.  We should look for it when we look for the IR card that is still down there.

* We have an ant in the IOO chamber.  Unfortunately my hands were on the TT1 optic holder ring when I saw it, so I couldn't dash quickly enough to grab it.  I saw it run over the side of the table, and down, but looked under the table and couldn't find him.  Not so good, but I don't know what to do about it right now.  If anyone sees it, get it out please.

[Jenne, with backup from Koji and Steve]

Short version:

TT1 was installed without a riser, optic is too low, riser we have doesn't fit, cannot proceed with alignment.  Sadface.

Long version:

I had gotten to the point of checking that the beam coming out of the Faraday was hitting the center of TT1, when I realized that we had forgotten to install the risers.  The TTs are designed for 4" beam height, but we have a beam height of 5.5" in-vac.  This means that the beam out of the Faraday was hitting the top of the optic / the optic holder.

Steve showed me where all of the active TT equipment is stored (down the X arm, almost all the way to the flow bench...there is a plastic tub full of baked items (individually wrapped and bagged)), and I got one of the 1.5" risers.

Upon opening the riser package, and comparing it with the base plate of the active tip tilt, the screw holes don't match!

It looks like for the passive tip tilts, we had holes machined at the far corners of the base plate, then had these risers made.  You can see in the photo of SR3 below that the original holes are there, but we are using 1/4-20 holes at the far corners of the base plate.

Unfortunately, without checking the base plate, I had asked Steve to get 4 more of the same risers we used for the passive tip tilts.  So, now the base plate holes and the riser holes don't match up.  In a perfect world, we would have installed the risers on the TTs as soon as they were baked and ready, and would have discovered this a while ago....but we don't live in that world.

 The reason we had originally chosen to put the new 1/4-20 holes on the corners of the passive tip tilts was so that when we tightened the screws, we wouldn't bend the base plate, due to the groove at the bottom of the base plate being directly under the screws.  Since the new aLIGO TT base plates have the groove underneath going the opposite direction, we didn't need to move the holes to the corners.

Also, you can't really see this from the photos, but the active TT base plate is slightly longer (in the beamline direction) than the riser, but only by a little bit.  Koji is currently trying to measure by how much from the CAD drawings.

Also, also, because of the way TT1 will hang off the table, I'm concerned about the underneath groove on the riser being the direction it is.  I'm concerned that the grooved part will be what wants to touch down on the back corner of the table, such that either the TT is insufficiently supported, or it is tilting backwards.  Neither of these will be acceptable.

I propose that we re-make the risers quickly.  We will have the holes match the active TT base plate, the size of the riser should match the size of the active TT base plate, and the underneath groove should be perpendicular to the way it is in the current version.

Koji and I were looking for an extender card to aid with MZ board testing.  Rob went off on a quest to find one.  He found 2 (in addition to the one in the drawer near the electronics bench which says "15V shorted"), and put them in some empty slots in 1X1 to test them out.  Somehow, this burned a few pins on each board (1 pin on one of them, and 3 pins on the other). We now have 0 functioning extender cards: unfortunately, both extender cards now need fixing.  The 2 slots that were used in 1X1 now have yellow electrical tape covering the connectors so that they do not get used, because the ends of the burnt-off pins may still be in there. 

In other, not-Rob's-fault news, the Martian network is down...we're going to try to reset it so that we have use of the laptops again.

This happened when I plugged the cards into a crate with computers, which apparently is a no-no.  The extender cards only go in VME crates full of in-house, LIGO-designed electronics.

We are celebrating Rob's promotion to thesis poetry.  These pictures were taken on December 9, 2009

Rob has finished all his measurements in the lab and is officially well prepared to graduate.

I assume it's the rock tumbler, although it could be something else, but the MC has had trouble staying locked yesterday and today (yesterday Yaakov and I went over there and they were doing stuff almost constantly - it's super loud over there), and today even the PMC has fallen out of lock twice.  I just relocked it again, since it went out of lock just after Journal club started.

Anyhow, I think this will be good data for Masha, and then also for the Masha+Yaakov triangulation project.

I think the "Rogue Master" setting on the RFM network may be doing some good. 5 mins, ago, all the CDS indicators were green, but I noticed an amber light on the c1rfm screen just now (amber = warning). Seems like at GPS time 1294691182, there was some kind of error on the RFM network. But the network hasn't gone down. I can clear the amber flag by running the global diag reset. Nevertheless, the upgrade of all RT systems to Dolphin should not be de-prioritized I think.

 Roscolux filter films  #74 night blue,  0.003" thick  and  #26 light red, 0.002" thick  were measured in the beam path of  ~6 mm diameter,  1W 1064 nm .

T 90%  + - 5% at 0-30 degrees of  incident angles and R ~10 % 

These sandwitched thin films of policarbonate-polyester filters are not available in thicker forms. Rosco is recommending them to be cooled by air if used in high power beam.

These filters did not get warm at all in 1W, so absorption must be very small.

When I came in, Rossa was booted to Ubuntu 10. I tried rebooting to select 12, but couldn't ever successfully boot again. Since Diego was setting up Allegra from scratch, I've wiped and done the same with Rossa. 

Allegra and Rossa wiped and updated to Ubuntu 12.04.5 by me and Ericq; the following procedure was followed:

1) create "controls" user with uid=1001, gid=1001
2) setup network configuration (IP, Mask, Gateway, DNS), .bashrc, /etc/resolv.conf
3) add synaptic package manager (Ubuntu Software Center used by default)
4) add package nfs-common (and possibly libnfs1) to mount nfs volumes; mount nfs volume adding the line "chiara:/home/cds/       /cvs/cds/       nfs     rw,bg   0    0" in /etc/fstab
5) add package firmware-linux-nonfree, needed for graphics hardware recognition (ATI Radeon HD 2400 Pro): due to kernel and xorg-server versions of 12.04.5, and because ATI dropped support for legacy cards in their proprietary driver fglrx the only solution is to keep Gallium drivers
6) add packages libmotif3 grace, needed by dataviewer
7) add repository from https://www.lsc-group.phys.uwm.edu/daswg/download/repositories.html (Debian Squeeze); install lcssoft-archive-keyring as first package or apt-get will complain
8) add package lscsoft-metaio libjpeg62, needed by diaggui/awggui (Ericq: used lalmetaio on rossa)
9) add packages python-numpy python-matplotlib python-scipy ipython
10) change ownership of /opt/ to controls:controls
11) add csh package
12) add t1-xfree86-nonfree ttf-xfree86-nonfree xfonts-75dpi xfonts-100dpi, needed by diaggui/awggui (needs reboot)
13) add openssh-server

Ubuntu creates the first user during installation with uid=1000 and gid=1000; if needed, they could be changed afterwards using a second user account and the following procedure (twice, if the second users gets the 1001 uid and gid):

sudo usermod -u <NEWUID> <LOGIN>   
sudo groupmod -g <NEWGID> <GROUP>
sudo find /home/ -user <OLDUID> -exec chown -h <NEWUID> {} \;
sudo find /home/ -group <OLDGID> -exec chgrp -h <NEWGID> {} \;
sudo usermod -g <NEWGID> <LOGIN>

I am getting tired of having to restart Rossa all the time.  She freezes almost once per day now.  Jamie has looked at it with me in the past, and we (a) don't know why exactly it's happening and (b) have determined that we can't un-freeze it by ssh-ing from another machine.

I wonder if it's because I start to have too many different windows open?  Even if that's the cause, that's stupid, and we shouldn't have to deal with it.

\end{vent}

[Jenne, Rana]

Today, Rossa has been hanging at bootup.  You get the desktop, and most of the gui things, and can move the mouse pointer around, but clicking the mouse or using the keyboard have no effect.  Once you try clicking something, the mouse pointer turns into the spinning ball, and stays like that.

If, upon rebooting (soft rebooting from another machine, through an ssh session), you hold down the Shift key, you should get to a Grub menu.  If you arrow-key down and select the next-most-recent version (not the recovery mode, but just the regular earlier version), and press Enter, Rossa starts up nice and happily.

I am not sure how to make Rossa always boot into this version of things, or how to get rid of the newest version so that the version that works is the most recent, but I'm hoping one of my Linux buddies will help me out on this one.  I think (maybe) that I need to find out what package was recently updated and could have caused problems, and then revert that one package.  (I think I can look at tail /var/log/apt/history.log to tell me what has recently been updated).

I have modified the /etc/default/grub file, so that we're loading up the previous linux kernel version on reboot.  Now Rossa boots up (at least one time so far) without any fancy button-pushing.

(Note, if things go south again, we have to push "shift" starting after the Dell screen is gone.  Holding it down while the Dell screen is still up doesn't seem to make it register that you want the grub menu).

The grub file USED to look like:

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

but now it looks like:

GRUB_DEFAULT=2
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=false
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Note that the first line, GRUB_DEFAULT has changed from 0 (first item in grub menu, if you successfully hit shift and get to it) to 2 (the third item in the list).  I think that the GRUB_HIDDEN_TIMEOUT_QUIET=false is supposed to force it to show the countdown time when you can push shift, but I didn't see any difference there.

To edit this file, you must use "sudo [text editor] grub".  I like emacs, so I used "sudo emacs grub".  After an edit, before a reboot, you must run "sudo update-grub".  Then you can reboot (sudo shutdown -r now is what I use), and hopefully it will boot as you directed.

Right now, the 0th (first) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic".  The 2nd (third) entry is "Ubuntu, with Linux 2.6.32-58-generic".  If we install a new kernel version, the 61 version will bump down in the list, and we'll be booting that, which I assume will fail.  We should not update Rossa until we're ready to go to Ubuntu 12, and when we do, we must ensure that the grub file first line reads GRUB_DEFAULT=0.  (As a side note, the 1st (really 2nd) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic (recovery mode)", which we don't want.  The 58 version has a recovery mode as the next line item, since it alternates version-N, version-N recovery mode, version-(N-1), version-(N-1) recovery mode, etc.)

I think I found out why rossa was mad. 

An apt-get update on the 18th downloaded kernel 2.6.32-65-generic, so 2.6.32-58-generic, which what was previously chosen as a working kernel, had moved down in the grub ordering.

It turns out the grub configuration accepts strings, so I changed it to GRUB_DEFAULT="Ubuntu, with Linux 2.6.32-58-generic", ran sudo update-grub, and Rossa now seems to boot happily. 

Aligning the beam for the PLL of the AbsL Experiement I rotated the polarizer along the path of the MC Input pick off beam (= the pick off coming from the MC periscope).

POXDC (i.e. POY DCout)
PRM misaligned: 70cnt
CA resonant PRMI: ~8000cnt (max)

REFLDC
PRMI antiresonant = 5200cnt
PRMI resonant = ~3000cnt
==> Visivility = 0.6

PRM
Transmissivity: T_R=0.0575, t_R=sqrt(T_R)

Rough estimation of the power recycling gain (assuming perfect mode matching)

P_{PRM_mialign} = P_in t_R²
P_{PRM_resonant} = P_in [t_R/(1-r_R r_MI)]²

G = t_R² P_{PRM_resonant} / P_{PRM_mialign} = 8000/70*0.0575 = 6.5

This is way too low compared with the design (G>40)
This corresponds to r_MI²=0.885 (loss of 10%) in the power recycling cavity.
But this yields visibility of 16%, instead of 60% which we saw. This is inconsistent.

If mode matching is not perfect, effective incident power of PRMI decreases
and this discrepancy may be explained

P_in = P_junk + (P_in-P_junk)

P_{PRM_mialign} = P_in t_R²
P_{PRM_resonant} = (P_in-P_junk) [t_R/(1-r_R r_MI)]²

P_{REFL_antires} ~ P_in
P_{REFL_resonant} = P_junk+(P_in-P_junk)[-r_R+(t_R² r_MI)/(1-r_R r_MI)]²

^===>

P_{PRM_resonant} / P_{PRM_mialign} = (1-R_mm) /(1-r_R r_MI)²=8000/70
P_{REFL_resonant} /P_{REFL_antires}= R_mm+(1-R_mm)[-r_R+(t_R² r_MI)/(1-r_R r_MI)]²=0.6

here R_mm= P_junk/P_in is the mode matching ratio

Solving the last two equations, we obtain

R_mm=0.6,
r_MI²= 0.939 (loss of 4-5%)

Can we believe that the mode matching is 60% and the loss is 5%???

PR1, PR2 and RP3 turned on for warming up for oil change. Oil changed with 3.2L of  MVT-19 fluid in each. This substitute for HE-175 will be used at the next oil change - it has 1E-6 Torr vapor pressure.

To finish this job tomorrow: 1, check oil creeping upstream  2, change air filter of air purge if pressure drops <350 mTorr  3, measure venting time of pump

 . Leybold D30A manual is here. Exhaust filter traps were drained. No oil creeping was found. The pump venting time is < 1 minute.

PR-2 needs new secu-valve. PR1 & 2 are in excellent condition.

1. Suresh and I completed the alignment of the fibre and the three mirrors on the ETMY table.

2. We managed to get an output beam power of around 60% using the Ophir(Orion/PD) power meter to finetune the alignment. The power of the input beam is 74.4 mW and of the output beam is 38.5 mW.

3. The coupler on the output side of the fibre which had been put there to help in the alignment has been removed.

4. The picture of the ETMY layout as of now has been attached.

5. The labels A stands for the mirror used to turn the beam direction and B and C stand for the three mirrors used in the alignment of the beam into the coupler,D.(attachment 3).

6. The fibre we used is 50m in length which was barely sufficient to reach the PSL table.

7. So, the fibre has been routed to the PSL table using the fibre tray running below the Y-arm tube as this was the shortest route possible(even though it is a rather acccident prone zone).

8. The fibre has been tied down at regular intervals so that it does not get snagged and pulled up inadvertently.

9. We will start with the preparation of the layout of the PSL table to superpose the two beams on Monday.

I took some measurements of the clock this morning, first without the box, then with the box, then without the box again. All the noise levels look pretty much the same. When I first put the box on, it was only propped up on one side, so I think the clocks got a bit overheated and the data looks ridiculous, which is the first plot. I took it off and let them cool down a bit, and then put the box on, this time with a generous 3 inch gap at the bottom all the way around, and it seemed to be fine after that.

The calibration for the data is pi (rad) /6415 (counts) /100.

Aidan: I edited this post to change the plots from Postscripts to PDFs.

We unsynched the clocks by unhooking the 1pps locking. I've added it to the plot of the other measurements here, and we've divided by a factor of sqrt(2) in the calibration to get the phase noise from just one clock, so the calibration is now

pi (rad) /6415 (counts) /100/sqrt(2).

I've also added the noise of the clock according to SRS to the plot.

The units of this plot are rad/rt(Hz). I've no idea why it just says magnitude.

 This is a known thing (at least to me and Rana), so it's not just you.  When you put in some points like your PD Spec, the units disappear, and I've never figured out how to get them back while keeping the points.  Thanks for putting the units in your entry though.  If anyone else does know how to get the units to 'stick' where they're supposed to be, that would be helpful. 

 Here's an overview of the rubidium measurement:

 We have two SRS FS275 Rubidium clocks which are locked together using the built-in PLL through the 1pps input/output. The default time constant for this locking is 18.2 hours because it's designed to be locked to a GPS. We changed this time constant to .57 hours (as decribed in this elog entry) to get the clocks to more reliably lock to each other. We then mix the 10MHz outputs together using a 7dbm mixer (see elog here and picture below)

The signal then goes through an AC-coupled SR560 with a gain of 100 and LPF at 10kHz, and is then fed into the DAQ. In the first picture below you can make out what all the lights are labeled, and in the second you can see what lights are on. I couldn't get a picture that did both in one, sadly.