40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 163 of 339 Not logged in
ID Date Author Type Category Subject
12904   Fri Mar 24 11:26:57 2017 gautamUpdateIMCMC SUS damping gains restored

I've restored the damping loop gains to their nominal values. Analysis of the coherence between MCL and seismometer channels under this reduced gain setting is underway, results to follow.

12906   Fri Mar 24 19:04:18 2017 gautamUpdateIMCSeismic feedforward and WFS

[valera, gautam]

On Wednesday at the meeting, we were discussing why we aren't able to achieve more seismic feedforward subtraction in MCL. We spent some time thinking about this yesterday, and this elog is meant to be a summary of the stuff we tried.

1. We let the WFS loops run for a while and settle, and then turned the input gain down to zero so that the integrators held the outputs to the suspension at a "good" alignment. If the WFS loop bandwidth is ~0.1 Hz, then they aren't helping us at 1Hz anyways. We then looked at coherence between the seismometer signals in this state compared to when the WFS loops were running, and noticed negligible difference. It doesn't seem like the WFS loops are injecting noise into MCL at ~1Hz.
2. We decided agains implementing the WFS sensing matrix I measured on Wednesday evening, as we found that the relative magnitudes of the matrix elements are virtually the same as in Koji's measurement back in December 2016. But looking at matrix elements like MC1P->WFS1P compared to MC3P->WFS1P - there is a difference of a factor of ~3. Why should there be? The response should be completely symmetric to MC1 and MC3?
3. While looking at the OSEM channels (i.e. SUSPIT_IN1_DQ, SUSYAW_IN1_DQ etc) for each of the MC optics, we noticed a dramatic difference between MC1 (factor of ~10 higher) and the other two MC optics.
4. Looking at coherence between MCL and the seismometer channels, we felt that there is less coherence at low frequencies (1Hz and lower) now than there was back in January when I took a measurement. However, there was coherence between the OSEM signals and the seismometers - so it doesn't look like the seismometer is to blame. To make an apples-to-apples comparison, I compared the MCL and Seismometer channel spectra from January to now (for the latter, at two different settings of the damping loop gains on the MC suspensions), and also the maximum predicted achievable subtraction (using EricQs frequency domain multicoherence tool). The two changes I can think of since January are that the MC1 satellite box has been interchanged with the SRM satellite box, and the IMC servo gains have been reallocated since the RF upgrade. My findings are summarized in attachments #1 and #2.

The seismometer spectra look similar enough to be explained by time of day variations, so perhaps the culprit is MC1. The ambient MCL spectrum is almost an order of magnitude higher above 4Hz now, with the nominal damping loop gains, as compared to back in January. I think the damping loops on MC1 need to be tweaked.

Attachment 1: MCL_comparison.pdf
Attachment 2: seis_comparison.pdf
13055   Fri Jun 9 15:31:45 2017 gautamUpdateIMCIMC wonkiness

### Once Steve restores the MC2 Trans cameras, I will hand-align the IMC again and see if the alignment holds for a few hours. If it does, I will reset all offsets for the WFS loops and see if they hold. In particular, the MC2 transmitted spot centering servo has a long time constant so could be something funny there.

*Another issue with the IMC autolocker I've noticed in the recent past: sometimes, the mcup script doesn't get run even though the MC catches a TEM00 mode. So the IMC servo remains in acquisition state (e.g. boosts and WFS servos don't get turned on). Looking at the autolocker log doesn't shed much light - the "saw a flash" log message gets printed, but while normally the mcup script gets run at this point, in these cases, the MC just remains in this weird state.

Attachment 1: IMG_7409.JPG
13057   Fri Jun 9 17:45:21 2017 Gautam, KaustubhUpdateIMCIMC wonkiness

Quote:

### Once Steve restores the MC2 Trans cameras, I will hand-align the IMC again and see if the alignment holds for a few hours. If it does, I will reset all offsets for the WFS loops and see if they hold. In particular, the MC2 transmitted spot centering servo has a long time constant so could be something funny there.

Summary:

In order to switch on the angular alignment for the IMC mirrors, we needed to center the laser onto the quad-photodiodes at the IMC and the AS Table(WFS1 and WFS2)

I and Gautam went to the IMC table and did the dc centering for the quad-photodiode by varying the beamsplitter angles. After this, we turned the WFS loops off and performed beam centering for the Quad PDs at the AS Table, the WFS1 and WFS2.

Once we had the beam approximately centered for all of the above 3 PDs, we turned on the locking for IMC, and it seems to work just fine. We are waiting for another hour for switching on the angular allignment for the mirrors to make sure the alignment holds with WFS turned off.

13058   Fri Jun 9 19:18:10 2017 gautamUpdateIMCIMC wonkiness

It happened again. MC2 UL seems to have gotten the biggest glitch. It's a rather small jump in the signal level compared to what I have seen in the recent past in connection with suspect Satellite boxes, and LL and UR sensors barely see it.

I will squish Sat box cables and check the cabling at the coil driver board end as well, given that these are two areas where there has been some work recently. WFS loops will remain off till I figure this out. At least the (newly centered) DC spot positions on the WFS and MC2 TRANS QPD should serve as some kind of reference for good MC alignment.

GV edit 9pm: I tightened up all the cables, but doesn't seem to have helped. There was another, larger glitch just now. UR and LL basically don't see it at all (see Attachment #2). It also seems to be a much slower process than the glitches seen on MC1, with the misalignment happening over a few seconds (it is also a lot slower). I have to see if this is consistent with a glitch in the bias voltage to one of the coils which gets low passed by a 4xpole@1Hz filter.

 Quote: Once we had the beam approximately centered for all of the above 3 PDs, we turned on the locking for IMC, and it seems to work just fine. We are waiting for another hour for switching on the angular allignment for the mirrors to make sure the alignment holds with WFS turned off.

Attachment 1: MC2_UL_glitchy.png
Attachment 2: MC2_glitch_fast.png
13061   Mon Jun 12 22:23:20 2017 ranaUpdateIMCIMC wonkiness

wonder if its possible that the slow glitches in MC are just glitches in MC2 trans QPD? Steve sometimes dances on top of the MC2 chamber when he adjusts the MC2 camera.

I've re-enabled the WFS at 22:25 (I think Gautam had them off as part of the MC2 glitch investigation). WFS1 spot position seems way off in pitch & yaw.

From the turn on transient, it seems that the cross-coupled loops have a time constant of ~3 minutes for the MC2 spot, so maybe that's not consistent with the ~30 second long steps seen earlier.

13062   Tue Jun 13 08:40:32 2017 SteveUpdateIMCIMC wonkiness

Happy MC after last glitch at 10:28 so the credit goes to Rana

GV edit 11:30am: I think the stuff at 10:28 is not a glitch but just the WFS servos coming on - the IMC was only hand aligned before this.

Quote:

It happened again. MC2 UL seems to have gotten the biggest glitch. It's a rather small jump in the signal level compared to what I have seen in the recent past in connection with suspect Satellite boxes, and LL and UR sensors barely see it.

I will squish Sat box cables and check the cabling at the coil driver board end as well, given that these are two areas where there has been some work recently. WFS loops will remain off till I figure this out. At least the (newly centered) DC spot positions on the WFS and MC2 TRANS QPD should serve as some kind of reference for good MC alignment.

GV edit 9pm: I tightened up all the cables, but doesn't seem to have helped. There was another, larger glitch just now. UR and LL basically don't see it at all (see Attachment #2). It also seems to be a much slower process than the glitches seen on MC1, with the misalignment happening over a few seconds (it is also a lot slower). I have to see if this is consistent with a glitch in the bias voltage to one of the coils which gets low passed by a 4xpole@1Hz filter.

 Quote: Once we had the beam approximately centered for all of the above 3 PDs, we turned on the locking for IMC, and it seems to work just fine. We are waiting for another hour for switching on the angular allignment for the mirrors to make sure the alignment holds with WFS turned off.

Attachment 1: happy_MC.png
Attachment 2: last_glitch.png
14179   Thu Aug 23 15:26:54 2018 JonUpdateIMCMC/PMC trouble

I tried unsuccessfully to relock the MC this afternoon.

I came in to find it in a trouble state with a huge amount of noise on C1:PSL-FSS_PCDRIVE visible on the projector monitor. Light was reaching the MC but it was unable to lock.

• I checked the status of the fast machines on the CDS>FE STATUS page. All up.
• Then I checked the slow machine status. c1iscaux and c1psl were both down. I manually reset both machines. The large noise visible on C1:PSL-FSS_PCDRIVE disappeared.
• After the reset, light was no longer reaching the MC, which I take to mean the PMC was not locked. On the PSL>PMC page, I blanked the control signal, reenabled it, and attempted to relock by adjusting the servo gain as Gautam had showed me before. The PMC locks were unstable, with each one lasting only a second or so.
• Next I tried restoring the burt states for c1iscaux and c1psl from a snapshot taken earlier today, before the machine reboots. That did not solve the problem either.
14180   Thu Aug 23 16:05:24 2018 KojiUpdateIMCMC/PMC trouble

I don't know what had been wrong, but I could lock the PMC as usual.
The IMC got relocked by AutoLocker. I checked the LSC and confirmed at least Y arm could be locked just by turning on the LSC servos.

14181   Thu Aug 23 16:10:13 2018 not KojiUpdateIMCMC/PMC trouble

Great, thanks!

 Quote: I don't know what had been wrong, but I could lock the PMC as usual. The IMC got relocked by AutoLocker. I checked the LSC and confirmed at least Y arm could be locked just by turning on the LSC servos.

14328   Sun Dec 2 17:26:58 2018 gautamUpdateIMCIMC ringdown fitting

Recently we wondered at the meeting what the IMC round trip loss was. I had done several ringdowns in the winter of 2017, but because the incident light on the cavity wasn't being extinguished completely (the AOM 0th order beam is used), the full Isogaio et. al. analysis could not be applied (there were FSS induced features in the reflection ringdown signal). Nevertheless, I fitted the transmission ringdowns. They looked like clean exponentials, and judging by the reflection signals (see previous elogs in this thread), the first ~20us of data is a clean exponential, so I figured we may get some rough value of the loss by just fitting the transmission data.

The fitted storage time is $60.8 \pm 2.7 \mu s$.However, this number isn't commensurate with the 40m IMC spec of a critically coupled cavity with 2000ppm transmissivity for the input and output couplers.

Attachment #1: Expected storage time for a lossless cavity, with round-trip length ~27m. MC2 is assumed to be perfectly reflecting. The IMC length is known to better than 100 Hz uncertainty because the marconi RF modulation signal is set accordingly. For the 40m spec, I would expect storage times of ~40 usec, but I measure almost 30% longer, at ~60 usec.

Attachment #2: Fits and residuals from the 10 datasets I had collected. This isn't a super informative plot because there are 10 datasets and fits, but to eye, the fits are good, and the diagonal elements of the covariance matrix output by scipy's curve_fit back this up. The function used to fit the t > 0 portions of these signals (because the light was extinguished at t=0 by actuating on the AOM) is $\text{Transmission} = Ae^{-\frac{2t}{\tau_{\mathrm{storage}}}}$, where A and tau are the fitted parameters. In the residuals, the same artefacts visible in the reflection signal are seen.

Attachment #3: Scatter plot of the data. Width of circles are proportional to fit error on individual measurements (i just scaled the marker size arbitrarily to be able to visually see the difference in uncertainty, the width doesn't exactly indicate the error), while the dahsed lines are the global mean and +/- 1 sigma levels.

Attachment #4: Cavity pole measurement. Using this, I get an estimate of the loss that is a much more believable $300 \pm 20\, \mathrm{ppm}$.

Attachment 1: tauTheoretical.pdf
Attachment 2: ringdownFit.pdf
Attachment 3: ringdownScatter.pdf
Attachment 4: cavPole.pdf
14334   Fri Dec 7 12:51:06 2018 gautamUpdateIMCIMC ringdown fitting

I started putting together some code to implement some ideas we discussed at the Tuesday meeting here. Pipeline isn't setup yet, but i think it's commented okay so if people want to play around with it, the code lives on the 40m gitlab

Model parameters:

• T+ --- average transmission of MC1 and MC3.
• T- --- difference in transmission between MC1 and MC3 (this basis is used rather than T1 and T3, because the assumption is that since they were coated in the same coating run, the difference in transmission should be small, even if there is considerable uncertainty in the actual average transmission number.
• T2 --- MC2 transmission.
• Lrt --- Round trip loss in the cavity.
• "sigma" --- a nuisance parameter quantifying the error in the time domain ringdown data.

Simulation:

• Using these model parameters, calculate some simulated time-domain ringdowns. Optionally, add some noise (assumed Gaussian).
• Try and back out the true values of the model parameters using emcee - priors were assumed to be uniformly distributed, with a +/- 20% uncertainty around the central value.
• For a first test, see if there is any improvement in the parameter estimation uncertainty using only transmission ringdown vs both transmission and reflection.

Initial results and conclusions:

• Attachment #1 - Simulated time series used for this study. The "fit" trace is computed using the median values from the monte-carlo.
• Attachment #2 - Corner plots showing the distribution of the estimated parameter values, using only transmission ringdown. The "true" values are indicated using the thick blue lines.
• Attachment #3 - Corner plots showing the distribution of the estimated parameter values, using both transmission and reflection ringdowns.
• The overall approach seems to work okay. There seems to be only marginal improvement in the uncertainty in estimated parameters using both ringdown signals, at least in the simulation.
• However, everything seems pretty sensitive to the way the likelihood and priors are coded up - need to explore this a bit more.

Next steps:

• Add more simulated measurements, see if we can constrain these parameters more tightly.
• Use linear error analysis to see if that tells us which measurements we should do, without having to go through the emcee.

There still seems to be some data quality issues with the ringdown data I have, so I don't think we really gain anything from running this analysis on the data I have already collected - but in the future, we can do the ringdown with complete extinguishing of the input light, and repeat the analysis.

As for whether we should clean the IMC mirrors - I'm going to see how much power comes out at the REFL port (with PRM aligned) this afternoon, and compare to the input power. This technique suffers from uncertainty in the Faraday insertion loss, isolation and IMC parameters, but I am hoping we can at least set a bound on what the IMC loss is.

Attachment 1: time_reflAndTrans.pdf
Attachment 2: corner_transOnly.pdf
Attachment 3: corner_reflAndTrans.pdf
14818   Tue Jul 30 20:11:12 2019 ranaSummaryIMCIMC ASC: thoughts and hopes

One of the biggest challenges in LIGO is reducing the alignment control noise. If you haven't worked on it for at least a few years, it probably seems like a trivial problem. But all versions of LIGO since 2001 have been limited by ASC noise below ~50 Hz.

I think the 40m IMC is a good testbed for us to try a few approaches towards mitigating this noise in LIGO. The following is a list of steps to take to get there:

1. Using step responses and TF measurements, characterize the full existing system: SISO loop shapes, cross-couplings, and how diagnonal is the input and output matrices of the WFS. In principle, since we have 2 WFS in reflection and 1 DC QPD in the MC2 transmission, we should have full sensing of all angular DoFs.
2. Check the correct operation of the WFS heads and the whole RF chain. We want the gains in the system to be such that either the shot noise or the RF electronics noise of the head is the limiting broadband noise in the system.
3. Balancing the gains and phases of the demodulated signals is tricky, because we have no good reference. Should we use the JenneAM laser or the PSL beam?
4. Estimate the coupling from the angular feedback signal to the IMC length noise using (1) sine wave injections for linear coupling, and (2) broadband noise for nonlinear coupling.
5. We think the bilinear noise is due to the beam spot motion modulating the angle to length coupling as sensed by the laser beam. If this is true, we can increase the low frequency gain to minimize the beam spot motion (is this true?).
6. By sinusoidally driving the mirror angles we can measure the instantaneous beam spot positions. We can then derive the matrix required to convert from our angular sensors (WFS + QPD) into beam spot motion. We should modify our IMC-WFS real-time model to give us DAQ channels which are beam spot estimators.
7. Build a simulation of an IMC which has WFS, QPD, shot noise, and seismic noise.
8. Use our optimal linear-feedback design tools to make Angular loops which minimize the bilinear noise coupling.
9. Build a nonlinear controller (neural networks: dense + CNN) that outperforms the linear one by estimating the beam spot motion continuously and driving the cavity length to cancel the angle-to-length noise.

I think that steps 1-6 are well within our existing experience, but we should do it anyway so as to reduce the IMC beam motion at low frequencies, and also to reduce the 10-100 Hz frequency noise as seen by the rest of the interferometer.

Steps 7-8 are medium hard, but we can get some help from the CSWG in tackling it.

Step is pretty tough, but I would like to try it and also get some help from MLWG and CSWG to address it.

15055   Wed Nov 27 18:51:22 2019 Gavin WallaceUpdateIMCQ Measurement of Test Masses

[Yehonathan, Gavin]

As the resonant modes of the 40m TMs are at high frequencies (starting at 28.8 kHz) we started background checks to understand if we would be able to see resonant frequency excitations in the DCPD output. We used the SR785 in the Q_OUT_DEMODULATOR port of the INPUT_MODE_CLEANER to measure around this frequency. Currently we could not see any natural excitation about the noise floor indicating it may not be possible to see such a small excitation. In any case we are conducting additional measurements in the I_MON port of 1Y2_POY11 to understand if this is a certainty.

15065   Tue Dec 3 14:52:13 2019 ranaUpdateIMCQ Measurement of Test Masses

 Quote: [Yehonathan, Gavin]
1. Lock IMC
2. Lock one of the arms (only) using the IR PDH signal feeding back to an ETM.
3. Excite the ITM using the SR785 near 28.8 kHz
4. Look for the resulting peak using the SR785 spectra of the POX or POY error signal from the demod board
5. Based on the calibrated noise level of the POX/POY, estimate what the SNR will be of the internal mode peak.
15070   Wed Dec 4 08:54:07 2019 YehonathanUpdateIMCMirror analog shaking

{Yehonathan, Gavin}

Yesterday we tried to shake ITMX with a function generator in order to observe the 28.8kHz drum mode.

We laid a long BNC cable that runs from the YARM to the XARM. This cable either needs to be collected back to the BNC big plastic cable box under the IMC or be labeled so that it could be found easily in the future.

First, we tried to shake it at a lower frequency (100's of Hz) where the shaking should be easily observed in the POSX channel. We try driving the POS channel on the ITMX servo but nothing happens. Most likely it is disconnected.

While setting up for shaking the individual OSEM channels 4 CDSs crashed (c1lsc, c1ass, c1oaf, c1cal).

15851   Mon Mar 1 11:40:15 2021 Anchal, PacoSummaryIMCgetting familiar with IMC controls

[Paco, Anchal]

tl;dr: Done no harm, no lasting change.

### Learn burtgooey

- Use /cvs/cds/caltech/target/c1psl/autoBurt.req as input to test snapshot "/users/anchal/BURTsnaps/controls_1210301_101310_0.snap" on rossa after not succeeding in donatella

- Browse /opt/rtcds/caltech/c1/burt/autoburt/snapshots/TODAY just to know where the snapshots are living. Will store our morning work specific snapshots in local user directories (e.g. /users/anchal/BURTsnaps)

### Identifying video monitors

- Switched channels around on video controls; changed C1:VID-MON7 to 16, back to 30, then C1:VID-QUAD2_4 to 16, to 18, then 20, back to 16, to 14 (which identified as PMCT), to 1 (IMC). Anyways, looks like IMC is locked.

[Yehonathan, Paco, Anchal]

### Unlocking MC

- From IOO/LockMC, MC_Servo, FSS --> closed PSL shutter, reopen it and see the lock recovers almost instantly. Try MCRFL shutter, no effect. Toggled PSL shutter one more time, lock recovered.

- From IOO/LockMC, MC_Servo, toggle OPTION (after IP2A), lose and recover lock in similar fashion. MCRFL gets most of the light.

- Looked at IFO_OVERVIEW just to get familiar with the various signals.

15852   Mon Mar 1 12:36:38 2021 gautamSummaryIMCgetting familiar with IMC controls

Pretty minor thing - but PMCT and PMCR were switched on Quad 2 for whatever reason. I switched them back because I prefer the way it was. I have saved snapshots of the preferred monitor config for locking but I guess I didn't freeze the arrangement of the individual quadrants within a quad. This would be more of a problem if the ITMs and ETMs are shuffled around or something like that.

 Quote: - Switched channels around on video controls; changed C1:VID-MON7 to 16, back to 30, then C1:VID-QUAD2_4 to 16, to 18, then 20, back to 16, to 14 (which identified as PMCT), to 1 (IMC). Anyways, looks like IMC is locked.
15857   Wed Mar 3 12:00:58 2021 Paco, AnchalHowToIMCMC_F ASD

[Paco, Anchal]

- Saved BURT backup in /users/anchal/BURTsnaps/
- Copied existing code for mode cleaner noise budget from /users/rana/mat/mc. Will work on this from home to convert it inot new pynb way.

Get baseline IMC measurements (passive):
- MC_F:
- What is MC_F? Let's find out.
- On MC_F Cal window titled 'C1IOO-MC_FREQ', we turned off ON/OFF and back on again.
- Using diaggui, we measured ASD of MC_F channel in units of counts/rtHz.

[Rana, Paco]

- Using diaggui, measured ASD from a template (under /users/Templates) and overlay the 1/f noise of the NPRO (Attachment 1)

[Anchal, Paco]

- WFS Master
- Went through the schematic and tried to understand what is happening.
- Accidentally switched on MC WF relief (python 3). Bunch of things were displayed on a terminal for a while and then we Ctrl-C it.
- The only thing we noticed that change is a slight increase in WFS1 Yaw, and a corresponding decrease in WFS1 Pitch, WFS2 Pitch, and WFS2 Yaw.
- We need to find out what this script does.

Future work:

• Create an automated script for taking MC_F_DQ spectrum and refer it against reference trace.
• Use pynb to create a noise budget for mode cleaner.
• Identify excess noise between 10-40 Hz.
• Configure output matrix in WFS Master to reduce the noise. Automate this process as well.
Attachment 1: 20210303_MC_F_Spectrum.pdf
Attachment 2: 20210303_MC_F_Spectrum.tar.gz
15884   Tue Mar 9 10:57:06 2021 Paco, AnchalSummaryIMCXARM lock and POX spectra

[Paco, Anchal]

- Upon arrival, MC is locked, and we can see light in MON5 (PRM) (usually dark).

# XARM locking
- Read through "XARM POX" script (path='/cvs/cds/rtcds/caltech/c1/burt/c1configure/c1configureXarm')
- Before running the script, we noticed the PRM watchdog is down, so we manually repeat the procedure from last time, but see more swinging even though the watchdog is active.
- Run a reEnablePRMWatchdogs.py script (a copy of reEnableWatchdogs.py with optics=['PRM']), which had the same effect.
- We manually disable the watchdog to recover the state we first encountered, and wait for the beam in MON5 to come to rest.
- The question is; is it fine to lock Xarm with PRM watchdog down?
- To investigate this, we look at the effect of the offset on the unwatchdog-PRM.
- Manually change 'PRM_POS_OFFSET' to 200, and -800 (which is the value used in the script) with no effect on the PRM swinging.
- Moving on, run IFO > CONFIGURE > ! (X Arm) > RESTORE XARM (XARM POX), and ... success.

# MC-POX noise spectra
- With XARM locked, open diaggui and take spectra for C1:LSC-POX11_I_ERR_DQ, C1:LSC-POX11_Q_ERR_DQ, C1:IOO-MC_F_DQ
- Lost XARM lock while we were figuring out unit conversions...
- Assuming 2.631e-13 m/counts (6941) and using 37.79 m (arm length), 1064.1 nm wavelength, we get a calibration factor of 2.631e-13 * c / (2*L*lambda) ~ 0.9809 Hz/count
- (FAQ?, how to find/compute/measure the correct calibration factors?)
- Relock XARM, retake spectra. Attachment 1 has plots for POX11_I/Q_ERR_DQ spectrum (cts/rtHz, we couldn't find relevant calibration) and MC_F_DQ in (Hz/rtHz from referring to 15576, we couldn't get the units to show on y scale.)

# MC-POY noise spectra (attempt)
- Now, run IFO > CONFIGURE > ! (Y Arm) > RESTORE YARM (YARM POY), and XARM locks (why?)
- Could PRM watchdog being down be the cause?
- Try C1ASS > (YARM) ! More Scripts > ON, and looked at YARM PIT/YAW striptool.
- C1ASS > (YARM) ! Freeze Outputs, then OFF
- Go back to IFO > CONFIGURE > ! (Y Arm) > Align YARM  (ASS ON: Unfreeze), try running this then Freeze, then OFF Zero Outputs.
- Try RESTORE YARM (POY) again, still not working.
- Try RESTORE YARM ALS, then try again after opening the shutter, but also fail to lock AUX.
- Is the PRM WD behind some evil misalignment? Will move forward with XARM bc it is happy.

# ARM locking
- Attempted the IFO > CONFIGURE > ! (X Arm) > RESTORE Xarm (XARM ALS) but green failed to lock and we lost XARM lock.
- Try to recover XARM lock... success. It's nice to have a (repeatable) checkpoint.
- Attempt YARM lock. Not successful. It just seems like the lock Triggers are not raised (misalignment?)
- From C1SUS_ETMY, try changing the bias "C1:SUS-ETMY_YAW_OFFSET" manually to reduce the OPLEV_YERROR. Changed from -47 to -57.
- Retry YARM lock script... no luck
- From C1SUS_PRM, try changing the bias "C1:SUS-PRM_PIT_OFFSET" manually to reduce OPLEV errors. Changed from 34 to 22 with no effect, then realized the coil outputs are disabled because the WD is down...
- So we do the following BIAS changes "C1:SUS-PRM_PIT_OFFSET" = 34 > 770 and "C1:SUS-PRM_YAW_OFFSET" = 134 > -6
- Enable all Coil Outputs, turn WD to Normal, turn OPLEVs ON, (this time the beam does not swing like crazy).
- Fine tune BIASes "C1:SUS-PRM_PIT_OFFSET" = 770 > 805  and "C1:SUS-PRM_YAW_OFFSET" = -6 > 65
- Saw YARM locking briefly, then unlocking, but we stopped once the OPLEV_ERRs no longer overloaded (from magnitudes > 50 to ~ 40).
- Retry YARM lock... no luck
- From C1SUS_ETMY, try changing the bias "C1:SUS-ETMY_PIT_OFFSET" from -1 to 6.

Stop for the day. Leave XARM locked, MC locked.

Attachment 1: 20210309_POX11_Spec_XARMLocked.pdf
Attachment 2: 20210309_XARM_Locked.tar.gz
15893   Wed Mar 10 11:46:22 2021 Paco, AnchalSummaryIMCIMC free swinging prep

[Paco, Anchal]

# Initial State
- MC is locked. The PRM monitor shows some oscillations.
- POP monitor shows light flashing once in a while.
- AS monitor shows one beam along with some other flashing beam around it.
- PRM Watchdog is tripped and shutdown. Everything else is normal except for overload on SRM OpLevs.
- Donatella got a mouse promotion

# Reenabling PRM watchdog:
- The custom reEnablePRMWatchdog.py has been deleted.
- Tried enabling the coil outputs manually and switching watchdog to Normal.
- Again saw large fluctuations like yesterday.
- Probably still the same issue of how current calculated actuations to the coils is in range -600 to -900 and gives and impulse to the optics when suddenly turned on.
- Waiting for PRM to damp down a little.
- Today we plan to change the position bias on PRM C1:SUS-PRM_POS_OFFSET instead of changing biases in pitch and yaw.
- Changing C1:SUS-PRM_POS_OFFSET from 0 to +/- 100 without enabling the coils, it seems upper and lower coils are anticorrelated with just changing the position. So going back to changing pitch.
- Changing C1:SUS-PRM_PIT_OFFSET from 0 -> 780. Switched on watchdog to normal.
- PRM damped down. OpLev errors are also within range.
- Enabled both OpLevs.

# Try locking Y-Arm
- IFO>CONFIGURE>YARM>Restore YARM (POY) using Donatella. See a bunch of python error messages in the call complaining about unable to find some python 2 files. Closed it with Ctrl-C after a stuck state.
- Tried running it on Pianosa, the script ran without error but Y-Arm didn't lock.

# Try locking X-Arm
- IFO>CONFIGURE>XARM>Restore XARM (POX) on Donatella. Again a bunch of OSError messages. Donatella is not configured properly to run scripts.
- Tried running it on Piasnosa, the script ran without error but X-Arm didn't lock.
- This might mean that both arms are misaligned or the BS/PRM is misaligned.
- Moving around C1:SUS-PRM_PIT_OFFSET and C1:SUS-PRM_YAW_OFFSET in order to see if the transmitted light is misalgined. Both arms are set to acquire lock if possible. No luck.

# Hypothesis: The Arm cavity is not aligned within itself (ITM-ETM)
- Will try to lock X-Arm with green light while tuning the ETMX. Hopefully the BS and ITM are aligned so that once we align ETMX to get a green lock, the IR will also lock from the other side.
- Running IFO>CONFIGURE>XARM>Restore XARM (ALS) on Pianosa. No lock, moving forward with tunning ETMX pitch and yaw offsets. Nothing changed. Brought back to same values.

[Rana joined, Anchal moved to Rossa from Pianosa]

# Moving on to IMC suspensions characterization:
- Closed the PSL shutter, to our suprise, the MC was still locked. We thought this would take away any light from IMC but it doesn't. Maybe the IFO Overview needs to show the schematic in a way where this doesn't happen: "No light from any laser entering the MC but it still is locked with a resonating field inside."
- Shutting IMCR shutter (hoping that would unlock the IMC), still nothing happend.
- Tried shutting PSL shutter from Rossa, nothing happened to MC lock still.
- Closed shutter IOO>Lock MC> Close PSL and this unlocked the IMC. Found out that this shutter channel is C1:PSL-PSL_ShutterRqst while the one from the sitemap>Shutter>PSL changes C1:AUX-PSL_ShutterRqst. Some clarification on these medm screens would be nice.
- Disabled the MC autolocked from IOO>Lock MC screen (C1:IOO-MC_LOCK_ENABLE).
- Checked the scripts/SUS/freeswing.py to understand how kick is delivered and optic is left to swing freely.
- Next, we are looking at the C1SUS_MC1 screen to understand what channels to read during data acquisition.
- In sensor matrix, we see INMON for each sensor which is probably raw counts data from the OSEMs. Rana mentioned that OSEM data comes out in units of microns. These are C1:SUS-MC1_ULSEN_OUTPUT (and so on for UR, LL, LR, SD).

- In prep for finishing, recovered Autolocker by first opening the PSL mechanical shutter, then re-enabling the Autolocker. The IMC lock didn't immediately recover, and we saw some fuzz on the PSL-FSS_FAST trace, so we closed the shutter again, waited a minute, then re-opened it and MC caught its lock.

15895   Wed Mar 10 15:00:16 2021 gautamSummaryIMCIMC free swinging prep

Did you fix this issue? It is helpful to post a screenshot of the offending MEDM screen in addition to witticisms. The elog says "sitemap>Shutter>PSL" but I can't find PSL under the dropdown for shutters from Sitemap.

 # Moving on to IMC suspensions characterization: - Closed the PSL shutter, to our suprise, the MC was still locked. We thought this would take away any light from IMC but it doesn't. Maybe the IFO Overview needs to show the schematic in a way where this doesn't happen: "No light from any laser entering the MC but it still is locked with a resonating field inside."
15896   Wed Mar 10 15:29:58 2021 AnchalSummaryIMCIMC free swinging prep

No we didn't fix the issue. We'll post some screenshots tomorrow. From "sitemap>Shutter>PSL" we meant in Shutter medm window, we clicked on the PSL close button. As pointed later, it switches C1:AUX-PSL_ShutterRqst while the PSL shutter switch on Lock MC medm screen switches C1:PSL-PSL_ShutterRqst. We were not sure if this was intentional, so we didn't change anything.

15897   Wed Mar 10 15:35:25 2021 Paco, AnchalSummaryIMCIMC free swinging experiment set to trigger at 5:00 am

A tmux session named "MCFreeSwingTest" will run on Rossa. This session is running script scripts/SUS/freeSwingMC.py (also attached) which will trigger at 5:00 am to impart 30000 counts kick to MC1, MC2, and MC3 after shutting PSL shutter and disabling the MC autolocker. It will let them freely swing for 1050 sec and will repeat 15 times to allow some averaging. In the end, it will undo all the changes it does and switches on autolocker on IMC. The script is set to restore any changes in case it fails at any point or a Ctrl-C is detected.

Attachment 1: freeSwingMC.py.zip
16125   Thu May 6 16:13:39 2021 AnchalSummaryIMCAngular actuation calibration for IMC mirrors

Here's my first attempt at doing angular actuation calibration for IMC mirrors using the method descibed in /users/OLD/kakeru/oplev_calibration/oplev.pdf by Kakeru Takahashi. The key is to see how much is the cavity mode misaligned from the input mode of beam as the mirrors are moved along PIT or YAW.

There two possible kinds of mismatch:

• Parallel displacement of cavity mode axis:
• In this kind of mismatch, the cavity mode is simply away from input mode by some distance $\dpi{150} \large \beta$.
• This results in transmitted power reduction by the gaussian factor of $\dpi{150} \large e^{-\frac{\beta^2}{w_0^2}}$ where $\dpi{150} \large w_0$ is the beam waist of input mode (or nominal waist of cavity).
• For some mismatch, we can approximate this to
$\dpi{150} \large 1 - \frac{\beta^2}{w_0^2}$
• Angular mismatch of cavity mode axis:
• The cavity mode axis could be tilted with respect to input mode by some angle $\dpi{150} \large \alpha$.
• This results in transmitted power reduction by the gaussian factor of $\dpi{150} \large e^{- \frac{\alpha^2}{\alpha_0^2}}$  where $\dpi{150} \large \alpha_0$ is the beam divergence angle of input mode (or nominal waist of cavity) given by $\dpi{150} \large \frac{\lambda}{\pi w_0}$.
• or some mismatch, we can approximate this to
$\dpi{150} \large 1 - \frac{\alpha^2}{\alpha_0^2}$

Kakeru's document goes through cases for linear cavities. For IMC, the mode mismatches are bit different. Here's my take on them:

### MC2:

• MC2 is the easiest case in IMC as it is similar to the end mirror for linear cavity with plane input mirror (the case of which is already studies in sec 0.3.2 in Kaker's document).
• PIT:
• When MC2 PIT is changed, the cavity mode simple shifts upwards (or downwards) to the point where the normal from MC2 is horizontal.
• Since, MC1 and MC3 are plane mirrors, they support this mode just with a different beam spot position, shifted up by $\dpi{150} \large (R-L)\theta$.
• So the mismatch is simple of the first kind. In my calculations however, I counted the two beams on MC1 and MC3 separately, so the factor is twice as much.
• Calling the coefficient to square of angular change $\dpi{150} \large \eta$, we get:
$\dpi{150} \large \eta_{._{2P}} = \frac{2 (R-L)^2}{w_0^2}$
• Here, R is radius of curvature of MC1/3 taken as 21.21m and L is the cavity half-length of IMC taken as 13.545417m.
• YAW:
• For YAW, the case is bit more complicated. Similar to PIT, there will be a horizontal shift of the cavity mode by $\dpi{150} \large (R-L)\theta$.
• But since the MC1 and MC3 mirrors will be fixed, the angle of the two beams from MC1 and MC3 to MC2 will have to shift by $\dpi{150} \large \theta/2$.
• So the overall coefficient would be:
$\dpi{150} \large \eta_{._{2Y}} = \frac{2 (R-L)^2}{w_0^2} + \frac{2}{4\alpha_0^2}$
• The factor of 4 in denominator of seconf term on RHS above comes because only half og angular actuation is felt per arm. The factor of 2 in numerator for for the 2 arms.

### MC1/3:

• First, let's establish that the case of MC1 and MC3 is same as the cavity mode must change identically when the two mirrors are moved similarly.
• YAW:
• By tilting MC1 by $\dpi{150} \large \theta$, we increase the YAW angle between MC1 and MC3 by $\dpi{150} \large \theta$.
• Beam spot on both MC1 and MC3 moves by $\dpi{150} \large (R-L)\theta$.
• The beam angles on both arms get shifted by $\dpi{150} \large \theta/2$.
• So the overall coefficient would be:
$\dpi{150} \large \eta_{._{13Y}} = \frac{2 (R-L)^2}{w_0^2} + \frac{2}{4\alpha_0^2}$
• Note, this coefficient is same as MC2, so it si equivalent to moving teh MC2 by same angle in YAW.
• PIT:
• I'm not very sure of my caluculation here (hence presented last).
• Changing PIT on MC1, should change the beam spot on MC2 but not on MC3. Only the angle of MC3-MC2 arm should deflect by $\dpi{150} \large \theta/2$.
• While on MC1, the beam spot must change by $\dpi{150} \large (R-L)\theta/2$ and the MC1-MC2 arm should deflect by $\dpi{150} \large \theta/2$.
• So the overall coefficient would be:
$\dpi{150} \large \eta_{._{13P}} = \frac{(R-L)^2}{4 w_0^2} + \frac{2}{4\alpha_0^2}$

### Test procedure:

• We first clicked on MC WFS Relief (on C1:IOO-WFS_MASTER) to reduce the large offsets accumulated on WFS outputs. This script took 10 minutes and reduced the offsets to single digits and IMC remained locked throughout the process.
• Then we switched off the WFS to freeze the outputs.
• We moved the MC#_PIT/YAW_OFFSET up and down and measured the C1:IOO-MC_TRANS_SUMFILT_OUT channel as an indicater of IMC mode matching.
• Attachement 1 are the 6 measurements and there fits to a parabola. Fitting code and plots are thanks to Paco.
• We got the curvature of parabolas $\dpi{150} \large \gamma$from these fits in units of 1/cts^2.
• The $\dpi{150} \large \eta$ coefficients calculated above are in units of 1/rad^2.
• We got the angular actuation calibration from these offsets to physical angular dispalcement in units of rad/cts by $\dpi{150} \large \sqrt{\gamma / \eta}$.
• AC calibration:
• I parked the offset to some value to get to the side of parabola. I was trying to reduce transmission from about 14000 cts to 10000-12000 cts in each case.
• Sent excitation using MC#_ASCPIT/YAW_EXC using awg at 77 Hz and 10000 cts.
• Measured the cts on transmission channel at 77 Hz. Divided it by 2 and by the dc offset provided. And divided by the amplitude of cts set in excitation. This gives $\dpi{150} \large \eta_{ac}$ analogous to above DC case.
• Then angular actuation calibration at 77 Hz from these offsets to physical angular dispalcement in units of rad/cts by $\dpi{150} \large \sqrt{\gamma/\eta_{ac}}$.
• Following are the results:
Optic Act
Calibration factor at DC [µrad/cts]
Calibration factor at 77 Hz [prad/cts]
MC1 PIT 7.931+/-0.029 906.99
MC1 YAW 5.22+/-0.04 382.42
MC2 PIT 13.53+/-0.08 869.01
MC2 YAW 14.41+/-0.21 206.67
MC3 PIT 10.088+/-0.026 331.83
MC3 YAW 9.75+/-0.05 838.44

• Note these values are measured with the new settings in effect from 16120. If these are changed, this measurement will not be valid anymore.
• I believe the small values for MC1 actuation have to do with the fact that coil output gains for MC1 are very weird and small, which limit the actuation strength.
• TAbove the resonance frequencies, they will fall off by 1/f^2 from the DC value. I've confirmed that the above numbers are of correct order of magnitude atleast.
• Please let me know if you can point out any mistakes in the calculations above.
Attachment 1: IMC_Ang_Act_Cal_Kakeru_Tests.pdf
16163   Wed May 26 11:45:57 2021 Anchal, PacoConfigurationIMCMC2 analog camera

[Anchal, Paco]

We went near the MC2 area and opened the lid to inspect the GigE and analog video monitors for MC2. Looked like whatever image is coming through the viewport is split into the GigE (for beam tracking) and the analog monitor. We hooked the monitor found on the floor nearby and tweaked the analog video camera around to get a feel for how the "ghost" image of the transmission moves around. It looks like in order to try and remove this "extra spots" we would need to tweak the beam tracking BS. We will consult the beam tracking authorities and return to this.

16179   Thu Jun 3 17:35:31 2021 AnchalSummaryIMCFixed medm button

I fixed the PSL shutter button on Shutters summary page C1IOO_Mech_Shutter.adl. Now PSL switch changes C1:PSL-PSL_ShutterRqst channel. Earlier it was C1:AUX-PSL_ShutterRqst which doesn't do anything.

Attachment 1: C1IOO_Mech_Shutters.png
16272   Fri Aug 6 17:10:19 2021 PacoUpdateIMCMC rollercoaster

[anchal, yehonatan, paco]

For whatever reason (i.e. we don't really know) the MC unlocked into a weird state at ~ 10:40 AM today. We first tried to find a likely cause as we saw it couldn't recover itself after ~ 40 min... so we decided to try a few things. First we verified that no suspensions were acting weird by looking at the OSEMs on MC1, MC2, and MC3. After validating that the sensors were acting normally, we moved on to the WFS. The WFS loops were disabled the moment the IMC unlocked, as they should. We then proceeded to the last resort of tweaking the MC alignment a bit, first with MC2 and then MC1 and MC3 in that order to see if we could help the MC catch its lock. This didn't help much initially and we paused at about noon.

At about 5 pm, we resumed since the IMC had remained locked to some higher order mode (TEM-01 by the looks of it). While looking at C1:IOO-MC_TRANS_SUMFILT_OUT on ndscope, we kept on shifting the MC2 Yaw alignment slider (steps = +-0.01 counts) slowly to help the right mode "hop". Once the right mode caught on, the WFS loops triggered and the IMC was restored. The transmission during this last stage is shown in Attachment #1.

Attachment 1: MC2_trans_sum_2021-08-06_17-18-54.png
16480   Tue Nov 23 18:02:05 2021 AnchalUpdateIMCMC autolocker shifted to python3 script running in docker

I finished copying over the current autolocker bash script functionality into a python script which runs using a simple configuration yaml file. To run this script, one needs to ssh into optimus and :

controls@optimus|~> cd /opt/rtcds/caltech/c1/Git/40m/scripts/MC
controls@optimus|MC> sudo docker-compose up -d
Creating mc_AL_MC_1 ... done

That's it. To check out running docker processes, one can:

controls@optimus|MC> sudo docker ps

And to shut down this particular script, in the same directory, one can

controls@optimus|MC> sudo docker-compose down
Removing mc_AL_MC_1 ... done

If the docker image requires to be rebuild in future, go to the directory where Dockerfile is present and run:

controls@optimus|MC> sudo docker build -t pyep .

I had to add PyYAML package in the pyepics docker image already present on docker hub, thanks to Andrew.

For now, I have disabled the MCautolocker service on Megatron. To start it back again, one would need to ssh into megatron and do following:

~> sudo systemctl enable MCautolocker
~> sudo systemctl start MCautolocker

Let's see for a day how this new script does. I've left PSL shutter open and autolocker engaged.

To do: Fix the C1:IFO-STATE epics channel definition so that it takes its bits from separate lock status channels instead of scripts writign the whole word arbitrarily.

16894   Mon Jun 6 21:01:22 2022 yutaUpdateIMCMC1 OSEM sensor sign flipped, MC1/2/3 free swinging overnight for inmat diagonalization

[Tomislav Andric, Rana, Yuta]

We put -1 to MC1 OSEM sensor gains and re-tuned MC1 damping.
We also kicked MC1, MC2, MC3 tonight for input matrix diagonalization.

MC1 damping investigations:
We put -1 to MC1 OSEM sensor gains so that UL/UR/LR/LL/SDSEN_OUT will be positive like other optics.
OSEM damping filter gains were adjusted.
We have also checked if having +1 for all UL/UR/LR/LL/SDCOIL_GAIN is correct or not. It has been like this at least for the past year.
It should be -1 for UR and LL to account for magnets, but if we did put -1 or them, kick in C1:SUS-MC1_PIT_OFFSET mostly gave yaw kick and kick in C1:SUS-MC1_YAW_OFFSET mostly give pitch kick.
So, we reverted them to be +1.

Input matrix diagonalization:
We also kicked MC1, MC2, MC3 tonight input matrix diagonalization.
Kick was done manually at the following times local.
- MC1 20:08 June 6th, 2022
- MC2 20:24 June 6th, 2022
- MC3 20:21 June 6th, 2022
We will leave watchdogs shutdown to free swing overnight (damping loops are "on").
This will help get better angular sensor from OSEMs to calibrate WFS signals.

Next:
- Investigate why MC1 coils gains have +1 for all
- Calculate input matrix. Make sure SUSPOS/PIT/YAW/SIDE_IN will be in the units of um or urad.

Suggestions:
- Add filter ramp time of 1sec for all by default
- Make null stream channel from input matrix for diagnostics

Attachment 1: Screenshot_2022-06-06_21-05-28.png
16895   Mon Jun 6 22:08:55 2022 KojiUpdateIMCMC1 OSEM sensor sign flipped, MC1/2/3 free swinging overnight for inmat diagonalization

Note that MC1 has a new style sat amp because the old one collapsed. The sign flip might have been the result of the replacement

18   Fri Oct 26 16:19:29 2007 Tobin FrickeRoutineIOOMC resonances
We would like to measure the absorption of the mode cleaner optics. The plan is to repeat <a href="http://ilog.ligo-wa.caltech.edu:7285/mLIGO/Cleaning_the_Mode_Cleaner">Valera's experiment</a> in which we track the MC's thermal resonances to infer their power absorption. Last night Rana and I hooked up a lock-in amplifier to heterodyne the MC servo signal by 28 kHz and piped the output into an ADC using the MC_AO channel. We did not find any resonances.

Valera recommends we drive the POS of the three MC optics with bandlimited noise to excite the resonances.
22   Sun Oct 28 03:03:42 2007 ranaConfigurationIOOThree Way Excitement
We've been trying to measure the MC mirror internal mode frequencies so that we can measure
their absorption before and after drag wiping.

It looked nearly impossible to see these modes as driven by their thermal excitation level;
we're looking at the "MC_F" or 'servo' output directly on the MC servo board.

Today, I set up a band limited noise drive into the 'Fast POS' inputs of the 3 MC coil
driver boards (turns out you can do this with either the old HP or the SR785).

Frequencies:
MC1     28.21625 kHz
MC2     28.036   kHz
MC3     28.21637 kHz


I don't really have this kind of absolute accuracy. These are just numbers read off of the SR785.

The other side of the setup is that the same "MC_F" signal is going into the SR830 Lock-In which
is set to 'lock-in' at 27.8 kHz. The resulting demodulated 'R" signal (magnitude) is going into

As you can see from the above table, MC1 and MC3 are astonishingly and annoyingly very close in
frequency. I identified mirrors with peaks by driving one at a time and measuring on the spectrum
analyzer. I repeated it several times to make sure I wasn't fooling myself; it seems like they
are really very close
but distinct peaks. I really wish we had chipped one of these mirrors
before installing them.

Because of the closeness of these drumhead modes, we will have to measure the absorption by making long
measurements of this channel.
29   Tue Oct 30 00:47:29 2007 ranaOtherIOOMC Ringdowns
I did a bunch of MC ringdown measurements using the PD that Rob set up. The idea is to put a fast PD (PDA255)
looking at the transmission through MC2 after focusing by a fast lens. The input to the MC is turned off fast
by flipping the sign of the FSS (Andri Gretarsson's technique).

With the laptop sitting on the MC can, its easy to repeat many ringdowns fast:
- Turn off the MC autolocker. Relock the MC with only the acquisition settings; no boosts
and no RGs. This makes it re-acquire fast. Turn the MC-WFS gain down to 0.001 so that
it keeps it slowly aligned but does not drift off when you lose lock.

- Use low-ish gain on the FSS. 10 dB lower than nominal is fine.

- Setup the o'scope (100 MHz BW or greater) to do single shot trigger on the MC2 trans.

- Flip FSS sign.

- Quickly flip sign back and waggle common gain to get FSS to stop oscillating. MC
should relock in seconds.

Clearly one can scriptify this all just by hooking up the scope to the ethernet port.

Attached are a bunch of PNG of the ringdowns as well as a tarball with the actual data. A sugar
napoleon to whomever can explain the 7 us period of the wiggle before the vent!
Attachment 1: tek00000.png
Attachment 2: tek00001.png
Attachment 3: tek00004.png
Attachment 4: MC2ringdown.tar.gz
30   Tue Oct 30 13:58:07 2007 ajwConfigurationIOOMC Ringdowns
Here's a quick fit-by-eye to the latter part of the data from tek00000.xls.

The prediction (blue) is eqn 41 of
http://www.ligo.caltech.edu/docs/P/P000017-A.pdf

T1 = T2 = 0.002. Loss1 = Loss2 = 150 ppm.
MC3 assumed perfectly reflecting.
Velocity = 320 um/s (assumed constant), 2 usec into the ringdown.

OK, there's one little fudge factor in the prediction:
I multiplied D by 2.
Attachment 1: CavityRingdown.png
Attachment 2: CavityRingdown.m
% CavityRingdown.m
% Eqn 41 of
% "Doppler-induced dynamics of fields in Fabry–Perot
% cavities with suspended mirrors", Malik Rakhmanov (2000).
% http://www.ligo.caltech.edu/docs/P/P000017-A.pdf

clear all

at = importdata('tek00000.csv');

... 121 more lines ...
35   Wed Oct 31 08:34:35 2007 ranaOtherIOOloss measurements
In the end, we were unable to get a good scatter measurement just because we ran out of steam. The idea was to get a frame
grab image of MC2 but that involves getting an unsaturated image.

In the end we settle for the ringdowns, Rob's (so far unlogged) cavity pole measurement, and the MC transmission numbers. They
all point to ~100-150 ppm scatter loss per mirror. We'll see what happens after wiping.
36   Wed Oct 31 08:38:35 2007 ranaProblem FixedIOOMC autolocker
The MC was having some trouble staying locked yesterday. I tracked this down to some steps in the last
half of the mcup script; not sure exactly which ones.

It was doing something that made the FAST of the PSL go to a rail too fast for the SLOW to fix.
So, I broke the script in half so that the autolocker only runs the first part. We'll need to
fix this before any CM locking can occur.

We also need someone to take a look at the FSS Autolocker; its ill.
39   Wed Oct 31 15:02:59 2007 tobinRoutineIOOMode Cleaner Mode Tracking
I processed the heterodyned mode cleaner data yesterday, tracking the three 28 kHz modes corresponding to MC1, MC2, and MC3. Unfortuntately the effect of our MC power chopping is totally swamped by ambient temperature changes. Attached are two plots, one with the tracked mode frequencies, and the other containing dataviewer trends with the MC transmitted power and the room temperature. Additionally, the matlab scripts are attached in a zip file.
Attachment 1: mode-track.pdf
Attachment 2: trends.pdf
Attachment 3: mcmodetrack.zip
40   Wed Oct 31 15:22:59 2007 robConfigurationIOOMode Cleaner transfer function
I measured the transfer function of the input mode cleaner using a PDA255 and the ISS. First I put the PD in front of the ISS out-of-loop monitor diode and used an SR785 to measure the swept sine transfer function from the Analog IN port of the ISS to the intensity at the PD. Then I moved the PD to detect the light leaking out from behind MC2, using ND filters to get the same DC voltage, and measured the same transfer function. Dividing these two transfer functions should take out the response of the ISS and the PD, and leave just the transfer function of the MC. A plot of the data, along with a single-pole fit, are attached.

The fit is pretty good for a single pole at 3.79 kHz. There's a little wiggle around 9kHz due to ISS weirdness (as Tobin has not been giving it the attention it requires), but this shouldn't affect this result too much. Using the known MC length of 27.0955m, and assuming that MC1 and MC3 have a power transmissivity of 2000ppm and MC2 is perfectly reflecting, the total round trip loss should be about 300ppm. The fitted finesse is 1460.
Attachment 1: MCtf.pdf
45   Thu Nov 1 11:45:30 2007 tobinConfigurationIOOMode cleaner drag-wiping
Andrey, Bob, David, John Miller, Rana, Rob, Steve, Tobin

Yesterday we vented the vacuum enclosure and opened up the chamber containing MC1 & MC3 by removing the access connector between that chamber and the OMC chamber. Rana marked MC1's location with dogs and then slid the suspension horizontally to the table edge for easy drag-wiping access. The optic was thoroughly hosed-down with the dionizer, in part in an effort to remove dust from the cage and the top of the optic. Drag-wiping commenced with Rob squirting (using the 50 microliter syringe) and Tobin dragging (using half-sheets of Kodak lens tissue). We drag-wiped the optic many (~10) times, concentrating on the center but also chasing around various particles and a smudge on the periphery. There remains one tiny speck at about the 7:30 position, outside of the resonant spot area, that we could not dislodge with three wipes.

Today we drag-wiped MC3. First we slid MC1 back and then slid MC3 out to the edge of the table. We disconnected the OSEM cables in the process for accessibility, and MC1 is perched at an angle, resting on a dog. We did not blow MC3 with the deonizer, not wanting to blow particles from MC3 to the already-cleaned MC1. We drag-wiped MC3 only three times, all downward drags through the optic center, with Steve squirting and Tobin dragging. Some particles are still visible around the periphery, and there appears to be a small fiber lodged near the optic center on the reverse face.

Andrey and Steve have opened up MC2 in preparation for drag-wiping that optic after lunch.
61   Sun Nov 4 23:55:24 2007 ranaUpdateIOOFriday's In-Vac work
On Friday morning when closing up we noticed that we could not get the MC to flash any modes.
We tracked this down to a misalignment of MC3. Rob went in and noticed that the stops were
still touching. Even after backing those off the beam from MC3 was hitting the east edge of
the MC tube within 12" of MC3.

This implied a misalignment of MC of ~5 mrad which is quite
large. At the end our best guess is that either I didn't put the indicator blocks in the
right place or that the MC3 tower was not slid all the way back into place. Since there
is such a strong stickiness between the table and the base of the tower its easy to
imagine the tower was misplaced.

So we looked at the beam on MC2 and twisted the MC3 tower. This got the beam back onto the
MC2 cage and required ~1/3 if the MC3 bias range to get the beam onto the center. We used
a good technique of finding that accurately: put an IR card in front of MC2 and then look
in from the south viewport of the MC2 chamber to eyeball the spot relative to the OSEMs.

Hitting MC2 in the middle instantly got us multiple round trips of the beam so we decided
to close up. First thing Monday we will put on the MC1/MC3 access connector and then
pump down.

Its possible that the MC length has changed by ~1-2 mm. So we should remeasure the length
and see if we need to reset frequencies and rephase stuff.
62   Mon Nov 5 07:29:35 2007 ranaUpdateIOOFriday's In-Vac work
Liyuan recently did some of his pencil beam scatterometer measurements measuring not the
BRDF but instead the total integrated power radiated from each surface point
of some of the spare small optics (e.g. MMT, MC1, etc.).

The results are here on the iLIGO Wiki.

So some of our loss might just be part of the coating.
67   Tue Nov 6 10:42:01 2007 robConfigurationIOOmode cleaner locked
Increased the power exiting the PSL by turning the half-wave plate after the MOPA, opened the PSL shutter, and aligned the mode cleaner to the input beam. It wasn't that hard to find the beam with the aperture open all the way on the MC2 camera. The transmitted power is now 2.9 arbitrary units, while the input power is 1.2 arbitrary units. Not sure yet if that's an increase or decrease in efficiency, since no one posted numbers before the vent. Also turned on the input-steering PZTs and saw a REFL beam on the camera.
68   Tue Nov 6 14:51:03 2007 tobin, robUpdateIOOMode cleaner length
Using the Ward-Fricke variant* of the Sigg-Frolov method, we found the length of the mode cleaner to be 27.0934020183 meters, a difference of -2.7mm from Andrey, Keita, and Rana's measurement on August 30th.

The updated RF frequencies are:
3  fsr =  33 195 439 Hz
12 fsr = 132 781 756 Hz
15 fsr = 165 977 195 Hz
18 fsr = 199 172 634 Hz
* We did the usual scheme of connecting a 20mVpp, 2 kHz sinusoid into MC AO. Instead of scanning the RF frequency by turning the dial on the 166 MHz signal generator ("marconi"), we connected a DAC channel into its external modulation port (set to 5000 Hz/volt FM deviation). We then scanned the RF frequency from the control room, minimizing the height of the 2 kHz line in LSC-PD11. In principle one could write a little dither servo to lock onto the 15fsr, but in practice simply cursoring the slider bar around while watching a dtt display worked just fine.
74   Wed Nov 7 00:51:33 2007 andrey, rob, tobinConfigurationIOOMC ringdowns
We completed several ringdown measurements this afternoon; Andrey is currently processing the data.
As Tobin wrote two hours ago, we (Andrey, Tobin, Robert) made a series of ringdown measurements for MC2
in the spirit of the measurement described by Rana -> see
entry from Mon Oct 29 23:47:29 2007, rana, Other, IOO, MC Ringdowns.

I attach here some pictures that we saw on the screen of the scope, but I need to admit that I am not experienced enough to present a nice fit to these data, although I attach fits that I am able to do today.

I definitely learned a lot of new Matlab functions from Tobin - thanks to him!, but I need to learn two more things:

Firstly, I do not know how to delete "flat" region (regions before the ringdown starts) in Matlab ->
I needed to delete the entries for times before the ringdown ("negative times") by hand in the text-file, which is extremely non-elegant method;

Secondly, I tried to approximate the ringdown curve by a function ydata=a*exp(b*xdata) but I am not exactly sure if this equation of the fitting curve is a good fit or if a better equation can be used.

It seems, in this situation it is better for me to ask more experienced "comrades" on November 7th.

P.S. It seems I really like the type of message "Bureaucracy" - I put it for every message. As Alain noted, maybe that is because some things are very bureacratized in the former USSR / Russia. By the way, when I was young, November 7th was one of two most important holidays in the USSR - I liked that holiday because I really liked military parades on the red square. I attach a couple of pictures. November 7 is the anniversary of the Revolution of 1917.
Attachment 1: image-attempt_1.png
Attachment 2: image-attempt_2.png
Attachment 3: image-attempt_3.png
Attachment 4: image-attempt_4.png
Attachment 5: image-attempt_5.png
Attachment 6: Fit-1st_attempt.jpg
Attachment 7: Fit-5th_attempt.jpg
78   Wed Nov 7 13:54:44 2007 robConfigurationIOOMode Cleaner transfer function
I performed the same procedure described here, and re-measured the transfer function of the mode cleaner to see the effect of the drag-wiping. The results are attached in a pdf. We don't seem to have done any damage, but the improvements are barely measurable.

 What Then Now pole frequency 3.789kHz 3.765kHz loss per optic 99ppm 91ppm finesse 1460 1470 trans 86.7% 87.7%
Attachment 1: mctf.pdf
80   Wed Nov 7 14:05:59 2007 tobinConfigurationIOOMC ringdown
Modeling the mode cleaner as a simple cavity with all losses lumped together, we expect the cavity power to be
attenuated by a factor (1-L) after each interval (2l/c)=1/fsr. Therefore we can get the cavity loss L
(including power lost through transmission) from the ringdown time constant tau as:

L = 1 - exp[ - 1/(tau * fsr) ]

From this we have to subtract the 2000 ppm transmission for each of MC1 and MC3, and divide by three to spread
the losses across the three optics.

I get 168 ± 39 ppm loss per optic based on a very simple exponential fit to the tails (t>0) of four of Andrey's data files.

By comparison, I get 154 ± 37 ppm from Rana's data files from before the vent.
125   Tue Nov 27 15:47:17 2007 robConfigurationIOOMC loop
After the FSS running pretty quick, I checked the MC loop. I used TPA 1&2.

MC loop
UGF: 70kHz
Input Gain: 29dB
Boost Level: 2
phase: 40 deg
Attachment 1: MCsmall.jpg
126   Tue Nov 27 16:18:58 2007 robConfigurationIOOMC loop
Reduced the common gain to 22dB in the mcup script, so that the WFS would not blow the lock. The above measure of the OLG was done without the mcWFS running, so may be a low estimate as compared to when the alignment is perfect.
ELOG V3.1.3-