40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 213 of 339 Not logged in
ID Date Author Type Category Subject
202   Wed Dec 19 16:07:37 2007 AndreySummaryComputer Scripts / ProgramsResults of overnight measurements Tue/Wed night (entry #198)

As indicated in ELOG entry 198, I was making overnight measurements during last night from Tuesday to Wednesday.

I was changing the suspension damping gain in ETMX and ITMX in "position" degree of freedom between values of 1.00 and 4.50 with the step 0.25.

Results for RMS of peaks (A) at 0.8Hz, (B) at about 3.0Hz and (C) in the range from 0.6Hz to 3.7Hz ("RMS in a broad interval") are given below:

I plotted three results for RMS in the abovementioned three intervals in three different ways:

1) view from the top in the axes (Q_{ITMX}+Q_{ETMX})/2 and (Q_{ITMX}-Q_{ETMX}) -> first three graphs (attachments 1 -3);

2) view from the side in the same sum- and difference-axes -> next three graphs (attachments 4-6);

3) view from the side in Q_{ITMX} and Q_{ETMX} axes -> next three graphs (attachments 7-9)

Attachments 10 and 11 show ratios of accelerometer signals at different times of the night/morning.

A little discussion about these graphs:

1) The areas of minima and of rapid growth are the same for all the measurements during all three nights.

2) Tonight there was a strange spike for the values of Q_{ETMX}=2.5 and Q_{ITMX}=4.0. I interpret that as an error of experiment.

3) On all the plots from all three nights there is a wide area of minimum on the plots for RMS at 0.8Hz and for "RMS in the broad interval",
and the graph for "RMS at 3Hz" indicates a clearer minimum in a localized area for Q_{ITMX}=2+-1, Q_{ETMX}=2+-1. Note that this area 2+-1
is included into the wide region of minimum for "RMS at 0.8Hz" and "RMS in a broad range".

Therefore, my guess at this stage is that we can choose the optimized value of suspension damping gains for both Q_{ITMX} and Q_{ETMX} somewhere
around 2+-1. I would like to make another overnight measurement (tonight) in that narrowed region with a small step to have more certainty.

By the way, I realized that I was a little bit careless and at some plots Q_I stands for {Q_ITMX}, and Q_E stands for Q_{ETMX}.
Attachment 1: RMS_08Hz_Top_view.png
Attachment 2: RMS_3Hz_Top_view.png
Attachment 4: RMS_08Hz_Side_view.png
Attachment 5: RMS_3Hz_Side_view.png
Attachment 7: RMS_08Hz_Q_I-Q_E-axes.png
Attachment 8: RMS_3Hz_Q_I-Q_E-axes.png
Attachment 10: Accelerom_ETMX.png
Attachment 11: Accelerom_ITMX.png
15268   Thu Mar 12 01:33:21 2020 gautamUpdateLSCResuming locking activities

It's been a while since I've attempted any locking, so tonight was mostly getting the various subsystems back together.

• Reconnected SR785 at 1Y3 to CM board for TF measurements.
• POX/POY locking work fine
• Locked PRMI (no ETMs) with carrier resonant, fixed PRM and BS alignment.
• ALS-X noise is still elevated - disconnected it from the switchable delay line and now I'm directly piping the 3dB coupled part of the beat to the LO input of the demod board. But the high freq contribution to the RMS is still ~x2-x3 of what it was in November 2019. But the noise should only depend on the other (delayed) part of the beat (the discriminant is set thus).
• With arms POX/POY locked, checked that there was no elevated coherence between POX_I/POY_I signals between 800 Hz - 1.2 kHz, which is where I see the excess noise in the laser frequency control signal (see Attachment #1). So this suggests that the IMC locking loop suppresses the noise to a level that the arm cavities don't witness it. It's probably still worth checking this out and fixing it, but it wasn't a show stopper.
• Transition from POX/POY lock to ALS lock was smooth - I forgot to use the POX/POY photodiodes as OOL sensors to measure the noise in this config to see if it was elevated, but anyway, I was able to push on.
• PRMI 3f locking worked okay.
• Main thing I wanted to check today is to try the AO transition with a bit more IN1 gain on the CM board - hypothesis being the high frequency part of the CARM signal is buried in the noise if we run with -32dB of IN1 gain.
• Set IN1 gain to -10dB instead.
• In this config, I checked that with the CARM offset at 0 (CARM still under purely ALS control), the CM_SLOW path was registering ~4000 cts pk-pk, which is healthily within the ADC's range.
• I was able to engage the CARM_B path and semi-stabilize the arm powers (after compensating for the increased IN1 gain by decreasing the CARM_B gain) and turn on the integrator.
• However, before I could try any AO path action, the IMC loses lock - too tired to try more tonight, I'll try again tomrrow.
Attachment 1: ExcessFreqNoise_LSC.pdf
3191   Mon Jul 12 02:21:01 2010 KojiConfigurationASCResurrection of MC WFS

I have resurrected the MC WFS on Friday night.
I have uncommented the WFS part of the MC autolocker.
The WFS total gain was empirically set to 0.1 such that the loops have no instability.

The loops somewhat worked through the weekend although they seemed to have the drift of the operating points
in accordance with the WFS spot.

4697   Thu May 12 00:59:45 2011 ryan, ranaUpdatePSLReturn of the PSL temperature box

The PSL temperature box has returned to service, with some circuit modifications. The 1k resistors on all the temp. sensor inputs (R3, R4, R7, R8, R12, R12) were changed to 0 Ohm. Also, the 10k resistors R26, R28, R29, and R30 were changed to 10.2k metal film. The DCC document will be updated shortly. There is now an offset in the MINCOMEAS channel compared to the others, which will be corrected in the morning after looking at the overnight trend.

5071   Sat Jul 30 19:06:25 2011 ryan, ranaUpdatePSLReturn of the PSL temperature box

 Quote: The PSL temperature box has returned to service, with some circuit modifications. The 1k resistors on all the temp. sensor inputs (R3, R4, R7, R8, R12, R12) were changed to 0 Ohm. Also, the 10k resistors R26, R28, R29, and R30 were changed to 10.2k metal film. The DCC document will be updated shortly. There is now an offset in the MINCOMEAS channel compared to the others, which will be corrected in the morning after looking at the overnight trend.

Forgot to do this in May. Have just changed the values in the psl.db file now as well as updating them live via Probe.

To make the appropriate change, I took the measured offset (5.31 deg) and added 2x this to the EGUF and EGUL field for the MINCO_MEAS channel. (see instructions here)

Committed the .db file to the SVN.

attached plot shows 8 days of trend with 5.31 degC added to the black trace using the XMGRACE Data Set Transformations

Attachment 1: rctempbox.png
310   Tue Feb 12 13:53:27 2008 robOmnistructureVACReturn of the RGA

The new RGA head was installed a few days ago. I just ran the RGAlogger script to see if it works, which it does. I also edited the crontab file on op340m to run the RGAlogger script every night at 1:25 AM. It should run tonight.
Attachment 1: RGA-080212.png
9939   Fri May 9 21:18:51 2014 KojiUpdateGreen LockingReverted X green light power

It is actually very tricky to measure the green power at the output of the doubling crystal as the IR often leaks into the measurement.
I checked the green beam powers on the X/Y/PSL tables.

CONCLUSION: There is no green beam which exceeds 5mW anywhere in the 40m lab.

Note: The temperature of the doubling crystal at the X end was optimized to have maximum green power. It was 36.3degC and is now 36.7degC.

X END:

When the angles of the wave plates are optimized, we have 539mW input to the doubling crystal.
With the Xtal temperature of 36.7degC, where the green power is maximized, the power right after
the harmonic separator (H.S.) was 9.6mW.

Xtal temp 36.7degC   ~~~
                      |
 --539mW@IR-->{Xtal}-->/-->9.6mW-->{Mirror}-->4.69mW-->{Mirror}-->4.54mW-->{Faraday}                     (H.S.)

If we believe these 4.69mW and 4.54mW are purely from the green, we have 4.8mW right after the H.S.
This corresponds to the conversion efficiency of 1.6%/W (cf. theretical number 2%/W)

By disabling the heating of the crystal, we can reduce the green light by factor of 60. But still the reading right after the H.S. was 5.3mW

Xtal temp 29.2degC   ~~~
                      | --539mW@IR-->
{Xtal}-->/-->5.3mW-->{Mirror}-->285uW-->{Mirror}-->74.3uW-->{Faraday}                     (H.S.)

Naively taking the difference, the green beam right after the H.S. is 4.4mW.

In either cases, the green power right after the oven is slightly less than 5mW.

Y END:

When the angles of the wave plates are optimized, we have 287mW input to the doubling crystal.
With the Xtal temperature of 36.0degC, where the green power is maximized, the power right after
the harmonic separator (H.S.) was 0.86mW.

Xtal temp 36.0degC   ~~~
                      |
 --287mW@IR-->{Xtal}-->/-->0.86mW-->                     (H.S.)

When the temperature was shifted to 39.2degC, the reading after the H.S. was 70uW. Therefore the contamination by the IR is small
in this setup and we can believe the above reading in 70uW accuracy. This 0.86mW corresponds to the conversion efficiency of 1.2%/W.

PSL

The incident IR is 80mW. We have 170uW after the H.S., which corresponds to the conversion efficiency of 2.6%/W. Maybe there is some IR contamination?
From the vacuum chamber total 1mW of green is derivered when both arms are locked and aligned.

Thus the total green power at the PSL table is less than 5mW.

3468   Wed Aug 25 12:40:28 2010 josephbUpdateelogReverted back to 2.7.5 until further testing is done

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.

7053   Mon Jul 30 17:24:45 2012 YaakovUpdateSTACISRevised sensor noise plot; dead PZT

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.

Attachment 1: sensor_noise.bmp
13391   Wed Oct 18 15:26:58 2017 johannesHowToCamerasRevision: CCD calibration

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

 Camera IP Calibration Factor 192.168.113.152 85.8 +/- 4.3 pW*μs 192.168.113.153 78.3 +/- 3.9 pW*μs

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.

 Counts with XARM locked 2.799 +/- 0.027 x107 Counts with shutter closed 3.220 +/- 0.047 x106 Power on CCD 193.9 +/- 2.2 nW Power scattered into 2π (*) 254 +/- 39 μW ETMX scatter loss (**) 25.4 +/- 3.9 ppm

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

Attachment 1: calib_20170930_152.pdf
Attachment 2: calib_20170930_153.pdf
12535   Thu Oct 6 03:56:43 2016 ericqUpdateLSCRevival Attempt

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

12547   Tue Oct 11 02:48:43 2016 ericqUpdateLSCRevival Attempts

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.

14051   Wed Jul 11 15:57:00 2018 aaronUpdateOMCReviving OMC electronics
Gautam showed me the electronics racks for the OMC PZTs and DAQ. I'm in the process of chasing down what channels we need, and confirming that we'll be able to plug the old antialiasing/imaging boards into the current DAC/ADC boards. I found what I think was Rob Ward's simlink model for the omc, located at

Channels in this model:
• 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)

Electronics inventory:
• 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?
•
11482   Thu Aug 6 04:36:41 2015 ericqUpdateASCReviving PRC angular feedforward

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.

14816   Mon Jul 29 19:08:55 2019 yehonathanUpdateLoss MeasurementReviving loss measurement by reflection

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.

14664   Tue Jun 11 19:25:58 2019 aaronConfigurationBHDReviving the single OMC BHD design?

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.

Attachment 1: singleOMC.pdf
14685   Fri Jun 21 19:22:40 2019 KojiConfigurationBHDReviving the single OMC BHD design?

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.

9565   Wed Jan 22 15:24:11 2014 SteveSummaryVACRga scan after reboot

 Quote: [Jenne, Steve] Steve noticed that the RGA was not logging data and that not all the correct connection lights were on, and he wasn't able to run the "RGAset.py" script (in ...../scripts/RGA/) that sets up the proper parameters.  I looked, and the computer was not mounting the file system.  I did a remote shutdown, then Steve went in and pushed the power button to turn the machine back on.  After it booted up, it was able to talk to the file system, so I started ..../scripts/RGA/RGAset.py .  The first 2 times I ran the script, it reported errors, but the 3rd time, it reported no communication errors.  So, now that the computer can again talk to the file system, it should be able to run the cronjob, which is set to take data at 4am every day.  Steve will check in the morning to confirm that the data is there.  (The last data that's logged is 22Dec2013, 4am, which is right around when Koji reported and then fixed the file system).

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.

Attachment 1: Rgascan169dwarmingup.png
Attachment 2: BlankMedmMustBeFixed.png
15933   Wed Mar 17 15:04:20 2021 gautamUpdateElectronicsRibbon cable for chassis

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.

Attachment 1: IMG_9139.jpg
10091   Tue Jun 24 13:02:54 2014 ManasaUpdatePSLRingdown PD installed

 Quote: I would like to measure the switching time of the AOM. So I have disconnected the modulation input to the AOM that comes from the ISS. I have also turned OFF the SR560's and the AWG that belong to ISS.  Pics and cable connections of the state in which the ISS setup was left at, will be updated soon.

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.

Attachment 1: PSL_ringdown.png
7164   Mon Aug 13 19:29:10 2012 ManasaSummary Ringdown measurements

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.

7196   Wed Aug 15 17:17:58 2012 Manasa, JanUpdateIOORingdown measurements

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.

7199   Wed Aug 15 20:15:51 2012 JanUpdateIOORingdown measurements

 Quote: 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(...).

7200   Wed Aug 15 20:53:48 2012 ManasaUpdateIOORingdown measurements

Quote:

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

15132   Fri Jan 17 22:11:19 2020 YehonathanUpdatePSLRingdown measurements

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.

Attachment 1: 20200117_192455.jpg
Attachment 2: 20200117_192448.jpg
15154   Sat Jan 25 11:54:42 2020 YehonathanUpdatePSLRingdown measurements

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.

Attachment 1: Input_beam_path.jpg
Attachment 2: Reflected_Beam_Path.jpg
Attachment 3: Transmitted_Beam_Path.jpg
Attachment 4: PMCRingdownNormalizedRawdata.pdf
Attachment 5: TransPDFits.pdf
15160   Mon Jan 27 21:35:06 2020 YehonathanUpdatePSLRingdown measurements

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.

Attachment 1: IMC_REFL_Beam_Path.jpg
15161   Mon Jan 27 21:48:49 2020 gautamUpdatePSLRingdown measurements

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 😢

 Quote: Zeroth order IMC ringdown Following Gautam's IMC ringdown setup, I took the the REFL PD form the PMC ringdown experiment and installed it in the IMC REFL path blocking WFS2 (Attachment 1).
Attachment 1: elevatedSeis.pdf
10042   Mon Jun 16 12:58:50 2014 manasaSummaryIOORingdown recap

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.

Attachment 1: Ringdown_815.pdf
Attachment 2: MCringdown_cum.pdf
Attachment 3: cum_plot.png
10043   Mon Jun 16 15:32:12 2014 ranaSummaryIOORingdown recap

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.

7883   Tue Jan 8 17:54:34 2013 JenneUpdateAlignmentRisers to bring TTs to correct beam height are in use

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

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

7878   Mon Jan 7 16:45:30 2013 JenneUpdateAlignmentRisers to bring TTs to correct beam height are wrong

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

2014   Mon Sep 28 23:13:14 2009 JenneConfigurationElectronicsRob is breaking stuff....

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.

2019   Tue Sep 29 16:14:44 2009 robConfigurationElectronicsRob is breaking stuff....

 Quote: 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.

2489   Fri Jan 8 18:20:12 2010 steveMetaphysicsTreasureRob now can concentrate on his thesis

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.

51   Thu Nov 1 19:53:34 2007 Andrey RodionovBureaucracyPhotosRobert's photo
Attachment 1: DSC_0068.JPG
6975   Fri Jul 13 19:48:56 2012 JenneUpdateEnvironmentRocks - very loud

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.

15765   Thu Jan 14 12:32:28 2021 gautamUpdateCDSRogue master may be doing something good?

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.

Attachment 1: Screenshot_2021-01-14_12-35-52.png
419   Tue Apr 15 18:44:25 2008 ranaConfigurationComputersRosalba
There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.

Its a 64-bit Linux and so that's going to cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.

I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.

We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow.
421   Wed Apr 16 10:20:01 2008 AndreyUpdateComputersRosalba and linux3

 Quote: There is a new computer in the control room -- its called Rosalba, in keeping with our naming convention. Its a quad-core machine that Dmass found for cheap somewhere; we've installed the CentOS on it that Alex recommended. Its a 64-bit Linux and so that may cause some problems. Alex has done this before and so we have some confidence that we can get our regular tools (DTT, Dataviewer) to run on it. I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we will be forced to install more 64-bit Linux stuff. We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we should not ditch linux3 and so he will run another cable for it tomorrow.

The ethernet cable for linux3 was installed on Wednesday morning. Now linux3 has Internet connection again.
6237   Mon Jan 30 16:18:51 2012 steveUpdatePEMRoscolux colored film transmittance at 1064 nm

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.

10605   Tue Oct 14 17:38:31 2014 ericqUpdateComputer Scripts / ProgramsRossa and Allegra wiped, Ubuntu 12.04 installed

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.

10606   Tue Oct 14 23:44:42 2014 diegoUpdateComputer Scripts / ProgramsRossa and Allegra wiped, Ubuntu 12.04 installed

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)

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>

8643   Fri May 24 14:44:34 2013 JenneUpdateGeneralRossa freezes all the time

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}

10045   Mon Jun 16 21:22:16 2014 JenneUpdateComputer Scripts / ProgramsRossa having a bad day

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

10063   Wed Jun 18 19:30:28 2014 JenneUpdateComputer Scripts / ProgramsRossa having a better day

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

10540   Thu Sep 25 15:41:15 2014 ericqUpdateComputer Scripts / ProgramsRossa having a better day

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.

2229   Tue Nov 10 19:19:57 2009 AlbertoUpdateABSLRotated polarizer on the PSL table, along the MC input pick off beam

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

5541   Sat Sep 24 20:14:36 2011 KojiUpdateLSCRough estimation of the PR gain

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: TR=0.0575, tR=sqrt(TR)

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

PPRM_mialign = Pin tR2
PPRM_resonant = Pin [tR/(1-rR rMI)]2

G = tR2 PPRM_resonant / PPRM_mialign = 8000/70*0.0575 = 6.5

This is way too low compared with the design (G>40)
This corresponds to rMI2=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

Pin = Pjunk + (Pin-Pjunk)

PPRM_mialign = Pin tR2
PPRM_resonant = (Pin-Pjunk) [tR/(1-rR rMI)]2

PREFL_antires ~ Pin
PREFL_resonant = Pjunk+(Pin-Pjunk)[-rR+(tR2 rMI)/(1-rR rMI)]2

===>

PPRM_resonant / PPRM_mialign = (1-Rmm) /(1-rR rMI)2=8000/70
PREFL_resonant /PREFL_antires= Rmm+(1-Rmm)[-rR+(tR2 rMI)/(1-rR rMI)]2=0.6

here Rmm= Pjunk/Pin is the mode matching ratio

Solving the last two equations, we obtain

Rmm=0.6,
rMI2= 0.939 (loss of 4-5%)

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

7564   Wed Oct 17 08:04:31 2012 SteveUpdateVACRoughing pumps on for oil change

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

ELOG V3.1.3-