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.

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.

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.

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.

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.

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.

Great, thanks!

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

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.

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.

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

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.

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

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

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.

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

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

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

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.

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.

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.

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 .
  • This results in transmitted power reduction by the gaussian factor of where is the beam waist of input mode (or nominal waist of cavity).
  • For some mismatch, we can approximate this to
                                                                            
• Angular mismatch of cavity mode axis:
  • The cavity mode axis could be tilted with respect to input mode by some angle .
  • This results in transmitted power reduction by the gaussian factor of   where is the beam divergence angle of input mode (or nominal waist of cavity) given by .
  • or some mismatch, we can approximate this to
                                                                             

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 .
  • 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 , we get:
                                  
  • 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 .
  • 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 .
  • So the overall coefficient would be:
                                  
  • 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 , we increase the YAW angle between MC1 and MC3 by .
  • Beam spot on both MC1 and MC3 moves by .
  • The beam angles on both arms get shifted by .
  • So the overall coefficient would be:
                                  
  • 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 .
  • While on MC1, the beam spot must change by and the MC1-MC2 arm should deflect by .
  • So the overall coefficient would be:
                                  

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 from these fits in units of 1/cts^2.
• The 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 .
• 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 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 .
• 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.

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

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.

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

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 :

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

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

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

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:

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.

[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

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

I turned on WFS on IMC at:

PDT: 2022-10-01 13:09:18.378404 PDT
UTC: 2022-10-01 20:09:18.378404 UTC
GPS: 1348690176.378404

The following channels are being saved in frames at 1024 Hz rate:

• C1:IOO-MC_TRANS_PIT_ERR (Same as C1:IOO-MC_TRANS_PIT_OUT)
• C1:IOO-MC_TRANS_YAW_ERR (Same as C1:IOO-MC_TRANS_YAW_OUT)
• C1:IOO-MC_TRANS_SUM_ERR (Same as C1:IOO-MC_TRANS_SUMFILT_OUT)

We can keep it running over the weekend as we will not use the interferometer. I'll keep an eye on it with occasional log in. We'll post the time when we switch it off again.

The IMC lost lock at:

UTC    Oct 03, 2022    01:04:16    UTC
Central    Oct 02, 2022    20:04:16    CDT
Pacific    Oct 02, 2022    18:04:16    PDT

GPS Time = 1348794274

The WFS loops kept running and thus took IMC to a misaligned state. Between the above two times, IMC was locked continuously with very brief lock loss events, and had all WFS loops running.

[Rana]

For the upcoming NN test on the IMC, we need to add some more channels to the frames. Can someone please add the MC2 TRANS SUM, PIT, YAW at 256 Hz? and then make sure they're in frames.

and even though its not working correctly, it would be good if someone can turn the MC WFS on for a little while. I'd just like to get some data to test some code. If its easy to roughly close the loops, that would be helpful too.

[Anchal]

Currently, none of these channels are being written on frames. From simulink model, it seems the channels:

• C1:IOO-MC_TRANS_SUMFILT_OUT_DQ

• C1:IOO-MC_TRANS_PIT_OUT_DQ

• C1:IOO-MC_TRANS_YAW_OUT_DQ

are supposed to be DQed but are not present in the /opt/rtcds/caltech/c1/chans/daq/C1MCS.ini file. I tried simply adding these channels to the file and rerunning the daqd_ services but that caused 0x2000 error on c1mcs model. In my attempt, I did not know what chnnum to give for these channels so I omitted that and maybe that is the issue.

The only way I know to fix this is to make and install c1mcs model again which would bring these channels into C1MCS.ini file. But We'll have to run activateDQ.py if we do that which I am not totally sure if it is in running condition right now. @Christopher Wipf do you have any suggestions?

[Rana]

aren't they all filtered? If so, perhaps we can choose whatever is the equivalent naming at the LIGO sites rather than roll our own again.

@Tega Edo can we run activateDQ.py or will that break everything now?

[Tega]

@Rana Adhikari Looking into this now.

@Anchal Gupta The only problem I see with activateDQ.py is the use of the deprecated print function, i.e. print var instead of print(var). After fixing that, it runs OK and does not change the input INI files as they already have the required channel names. I have created a temporary folder, /opt/rtcds/caltech/c1/chans/daq/activateDQtests/, which is populated with copies of the original INI files, a modified version of activateDQ.py that does not overwrite the original input files, and a script file difftest.sh that compares the input and output files so we can test the functionality of activateDQ.py in isolation. Furthermore, looking through the code suggests that all is well. Can you look at what I have done to check that this is indeed the case? If so, your suggestion of rebuilding and installing the updated c1mcs model and running activateDQ.py afterward should do the trick.

I tested the code with:

which creates output files with an _ prefix, for example _C1MCS.ini is the output file for C1MCS.ini, then I ran

to compare all the input and corresponding output files.

Note that the channel names you are proposing would change after running activateDQ.py, i.e.

My question is this: why aren't we using the correct channel names in the first place so that we have less work to do later on when we finally decide to stop using this postbuild script?

[Anchal]

Yeah I found that these ERR channels are acquired and stored. I don't think we should do this either. Not sure what was the original motivation for this change. I tried commenting out this part of activateDQ.py and remaking and reinstalled c1mcs but it seems that activateDQ.py is called as postbuild script automatically on install and it uses some other copy of this file as my changes did not take affect and the DQ name change still happened.

[Tega]

Ah, we encountered the same puzzle as well. Chris found out that our models have `SCRIPT=activateDQ.py` embedded in the cds parameter block description, see attached image. We believe this is what triggers the postbuild script call to `activateDQ.py`. As for the file location, modern rtcds would have it in /opt/rtcds/caltech/c1/post_build, but I am not sure where ours is located. I did a quick search for this but could not find it in the usual place so I looked around for a bit and found this:

My guess is the last one /opt/rtcds/userapps/trunk/cds/c1/scripts/activateDQ.py.

Maybe we can ask @Yuta Michimura since he wrote this script?

Anyway, we could also try removing SCRIPT=activateDQ.py from the cds parameter block description to see if that stops the postbuild script call, but keep in mind that doing so would also stop the update of the OSEM and oplev channel names. This way we know what script is being used since we will have to run it after every install (this is a bad idea).

It looks like the guess was correct. Note that in the newer version of rtcds, we can use `rtcds env` instead of `env` to see what is going on.

Tega has kindly made a summary page for the IMC WFS. Its in a tab on the usual summary pages.

One thing I notice is that the feedback to MC2 YAW seems to have very little noise. What's up with that?

The output matrix (attached) shows that the WFS have very little feedback to MC2 in YAW, but normal feedback in PIT. Has anyone recalculated this output matrix in the past ~1-2 years?

I'm going to read Prof. Izumi's paper (https://arxiv.org/abs/2002.02703) to get some insight.

The output matrix doesn't seem to have any special thing to make this happen. Any ideas on what this could be?

The output matrices have been calculated on Aug 4, 2022 by me. [40m ELOG 17060]

Regarding the noise see [40m ELOG 17061]

With regard to the current IMC WFS design, a SURF student in 2014 (Andres Medina) and Nick Smith made the revision.
The telescope design was described in the elogs [40m ELOG 10410] [40m ELOG 10427] and also T1400670.

Also reply to: 40m/17352

Tomohiro, Anchal, and I did the following to make updates to the calibration constants for pitch and yaw on MC1, MC2 and MC3.

To acquire the data used for fitting a curve respective to the change in counts per change in mirror pitch and yaw, we utilized some code that Anchal has already developed.

The scripts used to take time averaged data points of the IMC mirrors can be found by entering the command $ s into a terminal window to enter the scripts folder. Then enter the path "SUS/angActCal"

The following scripts will be found there to be used for this experiment:

angActCal.py & parabolaFit.py

To take data we used the angActCal.py function with set values for the time averaging = 5 s, settle time = 5 s, and adjusted the offset such that we would acquire approximately 20 data points given our ASC Bias limits. We defined the limits for each plot based on where the transmission fall off from the maximum value reached an average range of 10,000 counts.

The "readChannel" for each was the "C1:IOO-MC_TRANS_SUMFILT_OUTPUT" and can be found from the site map at IOO>Lock MC> see MC2_TRANS

The adjustment channels for Pitch and yaw on each IMC mirror were entered as the offset value found in the IMC screen at ALIGNMENT OFFSETS > BIASPIT/BIASYAW > OFFSET

For the code to work, the offset switch must be turned on. parabolaFit.py 

The data from MC1, MC2, and MC3 for pitch and yaw was saved to individual text files which were then entered into the parabolaFit.py function to get the results seen in attachment 1 and 2.

The above images show the printout from the plot fitting function and one of the graphs produced.

From the fitted curve values we then derived the equations that will soon be described further by Tomohiro (see entry _____) to arrive at the final callibration constants.

Final Calibration Constants for MC1, MC2, & MC3

We then utilized our calculated calibration constants (as seen bellow) to adjust the following filter parameters in the IMC control panel.

To make the updates such that the IMC screens show the correct urad values at the output of the filter banks, we must do the following steps to MC1, MC2, and MC3:

First, to make changes to our calibration filters, we must first shut off the pitch and yaw feedback loop controls.

TO do so for the Lock Filters, we will set the pitch and yaw SUS ASC inputs to 0 but entering the sitemap > IOO > C1IOO_WFS_MASTER

Nex head to action at the top right, and we can select "MC WFS relief 60s", this will relieve the values from the pitch and yaw inputs to the 40m Mode Cleaner Alignment settings to save the overall alignment and allow us to turn off the WFS servos to make the necessary adjustments on the lock filters.

Once we have waited a sufficient amount of time for the values on the ASC inputs to hover around 0, select Turn WFS ON/OFF button and choose "Turn OFF MCWFS Servo"

Next, we will press on the "on/off" button (see attachment 3 - circled in orange) for pitch and yaw found in just the LOCK FILTERS windows.

Once these are off we will stay in the same screen and adjust the gain values (boxed in yellow) for pitch and yaw.

Next, we will take the current value and divide it by the newly found corresponding calibration constant. This is to adjust for the changes we will be making on the output end of the filter banks such that all values in the feedback controls are normalized to the same scale.

The changes made here can be seen bellow:

Now that these changes have been made in the damp and lock filter banks, with the pitch and yaw feedback loops STILL OFF, we may adjust the newly made calibration filters for pitch and yaw (as seen in attachment 4).

The "P" and "Y" filters may be opened (boxed in red) and we may adjust the gain (circled in yellow). Because each of these filters have just been created, the value is set to 1. This value can be completely replaced with the calibration constant found in our table above. Thus we will now change MC1 Pitch to have a "gain" of 12.66 and so forth.

Once each of the calibration filters have been updated, you may go back into the damp filters and reinitiate the feedback loops.

Once all values have been entered,

This concludes the updating of the IMC filter calibration constants at DC.

Alex, Anchal, and I did the following to make updated angular actuation calibration for IMC mirrors. This is the revised version of Anchal's: 40m/16125.

In order to make the calibration formulas, we consider a matrix : connecting displacements and rotations of the IMC's beam waist to PIT and YAW rotations of every mirror

The parameters used in the above equation are listed in the next table.

	horizontal displacement of beam waist position
	vertical displacement of beam waist position
	PIT of the beam axis and/or each mirror
	YAW of the beam axis and/or each mirror
(subscript)	parameters for the beam
(subscript)	parameters for

 are the flat mirrors and  is the curved mirror in IMC. Components in  are refered from F. Kawazoe+ 2011 (doi: 10.1088/2040-8978/13/5/055504). In the paper, displacement and/or rotation of the beam parameters obtained from the PIT and YAW of each mirror are obtained not by  but by common or differential rotation of both two flat mirrors . Therefore, we divide  into two parts  (relation ):

• : relation between the beam parameters and the PIT and YAW rotation with 

• : relation between  and 

 is represented by revewing F. Kawazoe+ (2011):

Here we use  as RoC of ,  as height from the shorter side of the isoscele triangle, and  as half-long length of the shorter side. Intuitive discussion about the components are written in the last of the log.

Transmitted power is reduced by the small displacement and/or the small rotation of the beam axis, and can be represented by the Gaussian factor. It is described in /users/OLD/kakeru/oplev_calibration/oplev.pdf by Takahashi-san:

• parallel displacement

where  is the small displacement of the beam waist. It corresponds to .  is beam waist diameter inside IMC.

• beam axis rotation

where  is the small rotation of the beam axis. It corresponds to .  is divergence angle of the beam and is written by  and wavelength of laser 

Total power reduction is measured by multiplied gaussian factor of the displacement and the rotation. We can obtain the calibration formulas  with summed reduction Gaussian factor

where  is the vector of the PIT and YAW rotation .  are the calibration fomulas of PIT and YAW in 40m/16125 defined by Anchal, respectively, and have a unit of . Every calibration fomula is expressed as follows:

We intuitively describe how to obtain the components in . The detail is discussed in F. Kawazoe+ (2011).

• : 2-flat mirrors rotate with differential YAW 

When the 2-flat mirrors rotate, the shape of the isoscele triangle is thick, that is, the beam waist does not rotate but slightly displaces from its original one. Considering that the longer side of the triangle are almost perpendicular to the shorter side and ,  can be obtained by focusing on the right triangle shown in the following picture

• : 2-flat mirrors rotate with common YAW 

From , new triangle beam line is very similar to the isoscele triangle by rotating  from original one. So  is approximated to , but actually the new one is breaked its symmetry. The result becomes as follows

• : curved mirror rotates by 

It is similar to the case of . But the pivot to rotate the triangle is near than the case , so  has bigger factor than that of 

• : curved mirror rotates by 

It is completely the same as the discussion of linear cavity which has flat end mirror and curved input mirror.

• : 2-flat mirrors rotate with common PIT 

It is also the same as the linear one except that 2-flat mirrors are angled by 45 degrees. Angled 45 degrees reduce the effective rotation by factor of . The detail is discussed in A. Freise (2010).

• : 2-flat mirrors rotate with differential PIT ​

The differential rotation with the effect of  directly reflects to the PIT rotation of the beam

Alex, Anchal, and I did the following experiment to obtain calibration constants by oscillating IMC mirrors.

Theory

In previous experiment, we measured transmission counts at some offset values, and fitted the curve in order to get the curvature of transmitted power at MC2. In this time, we use not offset but AC oscillation to get the curvature .

The shape of the transmitted power is quadratic with respect to the tilt of each mirror:

Here  is the parameter including the tilt of each mirror, and  is the signal of the transmitted power at MC2. Oscillating the mirror shows that  has a time-dependance  using an angular frequency , an initial phase , and an amplitude . What we want to get is the curvature of the quadratic function, that is, the coefficient . So we focus on the frequency-doubled term. By substituting  to , we get the time-dependent 

.

We can get  value as  by multipling  and taking time average. This  is the same as  used in 16125 by Anchal when the unit of  is cts.

Method

Before the experiment, we changed some settings

• Turn off servo in the WFS servo,
• Turn off limits in MC SUS ASC inputs,
• Turn off ELP28 FH6 in MC2 Damp Filter.

After the experiment, we restored all the changed settings.

We decided the oscillation frequency, 27.25 Hz and 37 Hz, by monitoring the background PSD at MC2. But we totally took the time-dependent datas using 37 Hz because the pole frequency of some filters is around 27.25 Hz. We used python script that Alex wrote (MC_TRANS_SUM_PLOTS.ipynb, URL: /opt/rtcds/caltech/c1/Git/40m/measurements/IMC) for taking the datas. We took each data by oscillating PIT or YAW of each mirror in IMC. Measuring time was set as 10 s. The time is longer than the 100 times of 1/37 Hz. Oscillating amplitude is tabled below.

In order to analyze the datas, we make python script named MC_TRANS_SUM_ANALYZE.ipynb (URL: /opt/rtcds/caltech/c1/Git/40m/measurements/IMC). We can get  but I have some questions as listed below:

• How can we treat error of ?
• What is the unit of ? and How much value is it? If the unit of  is cts, we can use each oscillating amplitude.

In this time, we use the error of  as the quadrature component. And we use  as the oscillating amplitude as listed above. 

Result

The result is shown in the table.

Comparing with the Anchal's result, we get much smaller error and different order... We have to reconsider the calculation method.

The following work has been done by Tomohiro, Anchal and I:

To acquire the transfer functions for each of the IMC mirrors, we utilized diaggui, the CDS Diagnostic Test tool. We would like to measure the open loop transfer function, which is the ratio of In1 and In2, corresponding to before and after the injection point of the excitation signal.

A sinusoidal excitation signal was swept from 0,2 Hz to 5 Hz and includes 11 data points from an average of 10 cylcles per point.

NOTE: the WFS gain must be adjusted from 1.0 to 4.0 for these measurements (this is the slider underneath the "Turn WFS ON/OFF" button in C1:IOO_WFS_MASTER.

For the three sets of data taken for Pitch in WFS1, WFS2, and MC2 Trans, the amplitude of the excitation wave was 30,000.

In each measurement, the injection point is "C1:IOO-X_EXCMON", where X is the WFS or MC2 + Pitch or Yaw.

We will be conculding our measurements tomorrow and will report the findings for YAW in WFS1, WFS2, and MC Trans2.

Summary

• Alex, Anchal, and I measure the open-loop transfer function for WFS and MC2_TRANS signal.
• We utilize Fourier transform of appropriately filtered Gaussian noise to obtain the transfer function.
• With appropriate frequency-dependant noise and appropriate overall gain, the transfer function at lower frequency around 1 Hz can be roughly measured in shorter time and with a narrower resolution than those of the swept sine.

Purpose

The purpose is to roughly measure the open-loop transfer function in shorter time and with a narrower resolution. The transfer function can usually be obtained the following process. We measure two points before (IN1) and after (IN2) the excitation signal injection point. We can get the transfer function by dividing IN1 signal by IN2 signal. However, this method has some difficulties: longer time to finish one measurement in lower frequency and less measuring points. These are because the frequency of excitation signal is fixed for every measuring point. The ordinary method is not suitable for rough measurement. Therefore, we try to utilize frequency-dependant noise for measuring the transfer function (Rana teaches us the method).

Method

We utilize the Gaussian noise instead of the fixed sine wave. We inject the noise, which is properly filtered, into the exciting point (such as C1:IOO-MC2_TRANS_YAW_EXC in C1IOO_WFS_MASTER window), and measure two signals in the points IN1 and IN2. The two signals are Fourier transformed. And we obtain the transfer function by dividing the transformed signal IN1 by that of IN2.

To get good SNR, the frequency dependence of the injecting noise signal is important. We use the awggui command to create the appropriately filtered noise. We decide the dependence from the coherence between the IN1 signal and the excitation signal. The coherence around 1 shows the good SNR. So the dependence is adjusted so that the coherence approaches 1 in the observation frequency range. Attachment 1 shows the frequency dependence of the filter. We cut the gain below 0.1 Hz and above 10 Hz to limit frequency range, and use Zero-Pole gain to treat the influence of the mirrors' suspension in the frequency range. The filter we used is 

• cheby1("BandPass", 6, 2, 0.1, 10)
• zpk([3], [0.3], 1, "n")
• zpk([0.375 + i*0.649519; 0.375 - i*0.649519], [0.75; 2.5 + i*14.7902; 2.5 - i*14.7902], 1, "n")gain(4.46889)
• zpk([13], [3], 1, "n")gain(1.05099)

The file is saved in /users/Templates/MC/wfsTFs/WFS_noise_injection_profile-230302, but the saved file loses some filter information... So we write all the filters above.

Note: The noise filter has a ripple around the cutoff frequency. It comes from cheby1. Chebyshev Type 1 filter can drop the gain rapidly but has the ripple around the cutoff frequency.

Longer averaging time is also important to get the better SNR. The time is estimated from the resolution frequency and overwrap of the time-series data. We set the resolution as 0.01 Hz and the overwrap as 50 %, so the 10 times averaging takes about 8 minutes. In contrast, it takes about 2 hours if we measure 10 cycles of sine wave for every frequency with the ordinary transfer function measurement. The method of using the noise signal can inject multiple frequencies simultaneously into the excitation points, and can reduce the total measuring time.

We use the diaggui command for measuring the transfer function. Fourier Tools in Measurement tab translates the time-series signals, and the transfer function is obtained by Graph, Transfer function, in Result tab. Fig 2 is an example. The settings are saved, for example, in /users/Templates/MC/wfsTFs/MC2-TRANS_YAW_230302.xml.

In every measurement, we inject the noise into every excitation point of WFS1, 2 and MC2_TRANS, and PIT and YAW, and take every transfer function. We change overall gain of the filter in every measurement. The values are listed as follows.

Note: The gain of the transfer function is changed from 0.7 to 21 in the WFS1_PIT case only. The value of the case is much bigger than other measurements. After the experiment, the gain is put back.

Result

We show some results (YAW of WFS1, 2, and MC2_TRANS) as an example. The MC2_TRANS_YAW data only has structures around 3 Hz and 7 Hz shown in Attachment 2. The coherence of all measurements in the frequency range [0.1 Hz, 10 Hz] is around 1 except for the pendulum frequency of IMC mirrors. All the results have similar trend, which is low-pass like frequency dependence and has resonant of the pendulum. The trend is also obtained in the previous measurement using the ordinary method such as 40m/17486 and 40m/17472.

Discussion

Phase margin result for every measurement is listed. MC2_PIT data is 'N/A' because the transfer function does not exceed 0 dB at the observation frequency range. The phase margin values except for WFS1_PIT case are small, that is, the servos are nearly unstable. In WFS1_PIT, the phase margin is larger than other data because we increase the overall gain of the loop from 0.7 to 21 during measurement. This indicates the overall gain of the loop should be increased.

The pendulum resonance reduces the coherence. The coherence shows the signal relevance at the excitation point (input) and the measurement point (output). We can estimate whether the injecting signal is buried by background noise. The noise filter is not optimized yet, and we use the same filter for all the measurements. It causes the reduction of the coherence around the pendulum resonance. To increase the coherence and take better measurement, we have to optimize the frequency-dependance of the noise filter and increase averaging times for every measurement.

Only in the case of MC2_TRANS_YAW, the sudden gain changes exist around 3 Hz and 7 Hz. The sudden change is small peak at 3 Hz and large dip at 7 Hz. The result in 40m/5928 has a structure at 3 Hz, but we cannot find the structure at 7 Hz in the past entry... But both sudden changes do not make the loop unstable because the gain at the frequencies are smaller than 0 dB. We will check the detail and the origin.

In Future

• The overall open-loop gain should be increased.
• If necessary, we have to optimize the noise filter for every measurement.
• If necessary, we will check the detail and the origin of the sudden gain changes around 3 Hz and 7 Hz in MC2_TRANS_YAW.

that is great

I think we would like to set the WFS1 P/Y UGFs to be ~2-3 Hz, and the MC_TRANS loops to have a UGF of ~0.1 Hz.

Could you use your loop gain measurements to set the _GAIN values for those UGFs? I am curious to see if the system is stable with that control.

Summary

• We do the step responce test on WFS 1, 2 and MC2_TRANS YAW for correcting the output matrix.
• We add each offset value to each YAW actuator in IMC, and measure the time-series of the signals.
• From the input offset value and the output values, we get the values in the output matrix.

Purpose

The purpose of the measurement is to correct the values in the output matrix between YAW actuator and YAW signals of WFS and MC2_TRANS.

Method

Alex, Anchal, and I did the following measurement. The method follows to the previous measurement held by Anchal in 40m/17311. Before we did the experiment, we took these actions.

• We reliefed MC SUS ASC Input values to zero
• We made the overall WFS gain to zero in C1IOO_WFS_MASTER window.
• We turned off (0; 0.8) FM3 filter of servo section in WFS1, 2_YAW and MC2_TRANS_YAW.
• We checked the ramp time is set as 2 s.

We set every offset value by monitoring the change in WFS and MC2 YAW signals due to the offset. The monitoring points are WFS1_IY_DQ, WFS2_IY_DQ, and MC_TRANS_Y_DQ. We got the offset values as listed. We also monitored TRANS_SUMFILT_OUTPUT because we check the transmitted light changes.

We used the python script toggleWFSoffsets.py to add the offset separately. The script is in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/. The averaging time is set as 120 s to reduce the influence of the dominant fluctuation by factor of 1/100. The dominant fluctuation has the frequency around 1 Hz.

For obtaining the time-series datas and caluclating the mean values of the changed WFS and MC2 YAW signals due to every offset, we created new python script named IOO_WFS_YAW_STEP_RESPONSE_TEST.py, which is saved in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/. The script uses the getdata function in cdsutils to get time-series data referring to GPS time.

We picked out a portion of the datas for step responce results. The selected time is [20 s, 120 s], [260 s, 360 s], and [500 s, 600 s]. Each time datas are averaged. The datas also have background offset, so the datas of time [140 s, 240 s], [380 s, 480 s], and [620 s, 720 s] are used to calculate the average of the background offset. The step responce results are obtained by the differential between the averaged datas in the picked out time and that of the background offset. And the results are normalized by the offset values.

The results make the matrix from injection points to measured points. The injection points are WFS1, 2_YAW and MC2_TRANS_YAW, thus the matrix is not the output matrix from the injection points to MC1, 2, 3_YAW. We get new output matrix by multiplying the inversed result matrix and the current output matrix.

Result

The Attachment 1 plots the time-series datas. For visibility and less file size, the figure is drawn with a reduced number of samples filtered by 2nd order Butterworth filter. We referenced to /measurements/AWS/YARM_WFS_DC_Sensitng_Matrix_New.ipynb to draw the figure. 

The new output matrix is written here.

• Current matrix

• New matrix

We temporarily replaced the new matrix from the current one. The loop was still stable and the matrix worked well. To know whether the matrix properly works or not, we will test the same step response to the new matrix. We will confirm that the measured matrix is diagonalized.

Summary

• Alex, Anchal, and I adjusted the every overall gain iin P/Y of WFS1, 2 and MC2_TRANS loop.
• We set the WFS1, 2 P/Y UGFs to be ~2-3 Hz, and the MC2_TRANS loops to have a UGF of ~0.1 Hz.

Method

From the previous results (40m/17489) and measuring the open-loop transfer function (OLTF) by broadband noise, we adjusted the overall gain in P/Y of WFS1, 2 and MC2_TRANS loop. The table represents the changed values.

We also note the overall gain of the injecting noise: WFS1_PIT 52345, WFS2_PIT 152345, MC2_TRANS_PIT 152345, WFS1_YAW 152345, WFS2_YAW 102345, and MC2_TRANS_YAW 102345. The values are used in the awggui window.

We measured the OLTF by the appropriately filtered noise. The filter we used is the same as that of the previous measurement.

Result

Attachment 1 shows the OLTF whose gain is adjusted.

this measured Yaw matrix seems very different from the previous one. How can they really both be stable?

WFS error signal spectra w loops ON (G=4) and OFF.

Current output matrix also attached.

does Anyone understand why the broadband noise injection is so bad around 1 Hz? we do not see this issue with swept sine. noise seems good at other frequencies.

Does it have anything to do with the time constant of the resonances?

Tomohiro, Anchal and I completed the following processs for acquiring a new Output Yaw matrix for the "C1IOO_WFS_OUTMATRIX".

To did this by following the same process in 17493 but instead of adding our offsets in the WFS1, WFS2 and MC Trans filter banks, offsets were added at the end of the feedback loop at the optics, MC1, MC2 and MC3 YAW.

Optimal offset values were found such that the offset change did not disrupt the output WFS transmission signal by more than about a one thousand counts. Each limit was set to come close to this limit.

Our final offset values were:

The step response was than observed in Diaggui, but the entire 800 s run was unable to be viewed at once. We then utilized our python script from the previous step response data that we took to develop the following:

The measured response from stepping the optics was:

*The values in this matrix represent the number of counts/offset count. Thus all ovalues found from the step response were divided by the number of counts on each offset.

To find the new yaw matrix, we then take the inverse of the step response output matrix to get:

The results from the step response may also be seen graphically in attachment 1. The first plot shows all 3 response signals. Then each following plot shows the individual signals and the step responses overlayed for each one.

The plots also include horizontal lines that represent the average for the stepped signals and the average of the signal at rest along with shading for their associated uncertainties.

This was then tested in C1IOO_WFS_BASIS Yaw matrix, and at first did not work well. The WFS1 Yaw output would rail toward the limits. To fix this, the sign of the gain was flipped (from 0.5 to -0.5) which seemed to solve this issue.

This was then transmitted to the matrix to give:

This did not solve all issues, the overall ouput signals from the WFS filters still seemed to have large fluctuations. I then began adjusting the gains of the WFS1, WFS2 and MC Trans yaw output filters and achieved much steadier signals.

The following table describes the current best gain valuse for our Yaw matrix:

The results from our found matrix and gain changes can be seen on the left of attachement 2 that displays the ouputs on the Error Signal Monitor. The original output yaw matrix signals can be seen on the right hand side. There is work to still be done on adressing these issues, but overall this may be improved by some additional changes in the gains on each channel.

Summary

• We compared the new output matrix with old one by the step response test.
• We focused on the off-diagonal components of the step response result to compare the output matrix.
• We found that the old one is relatively good to WFS1/2 and MC2_TRANS whereas the new one is useful only to WFS1.
• Also we found that the new output matrix made from the sensing matrix was not significantly better than the original one.

Purpose

Alex, Anchal, and I did the experiment to find out the better output matrix. We got the new output matrix from the step response test in 40m/17500, so we checked whether the output matrix is good or not.

Theory

We used the following method to check the output matrix. In the previous step response test, we applied the step offset to ``ExciteIn'' points, and measure the step response at ``SensOut'' points. These points are defined in Attatchment 4. From the test, we got the matrix . Thus, we derived the new output matrix  from taking the inverse of , . If the new output matrix is well derived, the matrix can diagonalize the product of  and , , where  is the identity matrix.  can be measured by the step response test from ``SensIn'' to ``SensOut.'' Therefore we checked the output matrix by measuring . We call the measured matrix  as a sensing matrix.

To evaluate that  is diagonalized, we computed the sum of the absolute values of the off-diagonal components in 

Note that each column of the matrix was normalized by its diagonal component.

We tried to find out the better output matrix as the following method. We created new output matrix  from , and did the same step response test with . Then we got the new sensing matrix . We computed the sum of the absolute values of the off-diagonal components in , . We can get the relation  if  is better than . Therefore we compared  with .

Note: If  and  have the relation , the output matrix  will get better and better.

We also did the step response test with , which is defined as the output matrix now used. Then we compare  with .

Method

Before doing each step response test, we did the following processes:

• MC WFS relief for 60 secs with closed loops,
• turn off the WFS servo,
• turn off all the filters (WFS1/2: FM3, 4, 6; MC2-TRANS: FM1, 3, 4, 6),
• change the output matrix,
• set all the gain as unity,
• adjust each step offset.

We used the python script, toggleWFSoffsets.py, for testing the step response. The script is stored in /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/. The time appling each step offset is set as 120 secs.  are specifically the following matrix:

Note:  is different from [-0.188, -0.009, ...] in 40m/17500 because the previous calculation had a mistake.

The step response data is analyzed for making plot and calculating  and  by the python script, /opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/IOO_WFS_YAW_RESPONSE_TEST_100323.ipynb. 

Result

The step response results for  are represented in Attachment 1, 2, 3, respectively. In each plot, upper left shows all the data for WFS1 (solid green), WFS2 (solid blue), and MC2_TRANS (solid brown). Also upper right, lower left, and lower right shows the result of WFS1, WFS2, and MC2_TRANS, respectively. The plots except for the upper left have the applied step offset drawed by dashed line. The three step offsets were applied in the order of WFS1 (dashed green in the upper right), WFS2 (dashed blue in the lower left), and MC2_TRANS (dashed brown in the lower right). The high-frequency components of all the plots are removed with a second-order Butterworth low-pass filter and then plotted. Dotted line and its surrounding area show the mean value for each step response or existing offset without the step offset, and its standard deviation, respectively.

We summarize each plot:

The matrix of  is written from Attachment 1:

Focusing on each column in  and the plot, only the step response for WFS1 is well diagonalized. The result of  is . Note that all the sign of the step offset in Attachment 1 is negative because we set each gain of the filter as -1.

The matrix of  is written from Attachment 2:

The output matrix  has worse normalization to WFS1 than  from comparing  with .  also gets worse value than : .

The matrix of  is written from Attachment 3:

Although  has relatively better normalization to WFS1 and 2 than , it is characterized by a large overall error.  has minimum value with relatively large uncertainty: .

Discussion

We compare each value , which is plotted in the left of Attachment 5. From the figure, we can find  and  agree within the margin of error, and  is significantly smaller than  and . Also we compare  focusing on WFS1 column shown in the right of Attachment 5.  have almost the same value, and  has slightly larger value than other. This result shows  is relatively good to WFS1/2 and MC2_TRANS whereas  is useful only to WFS1.

I tried a different method today to see if it works. Following are the steps:

• Run WFS relief.
• Turn off the WFS loops.
• Calculate the effective current YAW matrix by transferring C1:IOO-MC#_YAW_GAIN to respective rows of the matrix read from C1:IOO-OUTMATRIX_Y. No need to change the matrix itself.
  • This step should not be required. We should move these gains to the matrices as soon as we can.
• Put in the first column (corresponds to WFS1_YAW controller output) of this effective current YAW matrix to C1:IOO-LKIN_OUT_MTRX_4_1, C1:IOO-LKIN_OUT_MTRX_5_1, C1:IOO-LKIN_OUT_MTRX_6_1.
  • This is the output matrix of LOCKIN in WFS screens.
  • We are trying to actuate on what we think only affects WFS1_YAW and see if it is crosscoupled to WFS2_YAW or MC2_TRANS.
  • Then we can cancel coupling to the other two sensors by changing our couple vector.
• Turn on locking at 0.5 Hz with gain 1.
• Turn on BLP0.3 filter module. This is a 8th order 0.3 Hz butterworth filter.
• Adjust phases to get all signal in the I quadratures.
• Using ratio of C1:IOO-WFS_LKIN_I5_OUT16 to C1:IOO-WFS_LKIN_I4_OUTPUT, subtract or add this much factor of the WFS2_YAW column (the second column) of the effective YAW matrix to the column that is put in the LOCKIN output matrix.
  • I was able to subtract to less than 10% cross coupling with the intial matrix I started with.
• Repeat until no cross-coupling is seen between WFS1_YAW and WFS2_YAW.
• Repeat the above steps for WFS2_YAW column by putting that into the LOCKIN output matrix. Use the column calculated in last step for adding or subtracting WFS1 actuation.
  • I was able to make WFS2 column very clean with less than 1% measurable crosscoupling to other sensors.
• I repeated the step for WFS1 column again to remove the cross coupling to WFS2 further to less than 1%.
• For doing the above steps for MC2_TRANS column, the initial effective matrix column was very bad. The outputs were higher in WFS1 and WFS2 then MC2_TRANS output itself.
• So I made the first guess by taking a cross-product between the obtained WFS1_YAW and WFS2_YAW columns estimated earleir.
• Then I repeated the above steps to minimize coupling to WFS1 or WFS2 sensors to less than 10% of MC2_TRANS.
• THe three column vectors obtained represent the new outpute YAW matrix. I removed the normalization that would be applied by C1:IOO-MC#_YAW filter gains from the rows of this amtrix to get the output matrix that can be put into C1:IOO-OUTMATRIX_Y

Once this matrix was in, I quickly tested it by closing the loop and making gain sign flips if required. Then I took quick swept sine transfer functions to estimate UGFs and scaled the columns of the output matrix to get UGF of 2.5 Hs for WFS1_YAW and WFS2_YAW loops and 0.1 Hz for MC2_TRANS YAW loop when all filter gains are 1 and overall gain C1:IOO-WFS_GAIN is 4. See attached plots.

Old matrix:

-4.094  ,  -3.0383 ,  34.0917
-0.1259 ,   0.27008, -16.081  
-7.1811 ,   0.74271,  28.9458

This was used with gains: 0.5 for WFS1_YAW loop, 0.6 for WFS2_YAW loop and 0.3 for MC2_TRANS_YAW loop.

New matrix:

-1.48948, -1.3029 , -4.93096
-0.05839,  0.15206, -3.66245
-2.82285,  0.92391, -4.68009

All loop gains 1.

Alex and Tomohiro are characterizing this matrix with step response and UGF measurements.

From the work that Anchal has completed for diagnolizing the YAW ouput matrix, a step response was taken of this new matrix using our previous methodolgies and the following results:

The step response can be seen plotted in attachment 1. The off diagonal terms of this new matrix sum to 1.24, which is a large decrease from the current matrix and the matrices that were tested from our previous step responses. 

Tomohiro and I are now currently working futher to configure the UGF's for YAW given this new output matrix.

UPDATE:

Tomohiro and I have completed testing the YAW Sensor outputs with broadband noise injection and have confirmed that gains currently set on each filter module (which is 1.0 for WFS1, WFS2, and MC Trans) provides us with adequate UGF's. As seen bellow in attachment 2-3, WFS1 and WFS2 have UGF's between 2 and 3 Hz. MC Trans can be seen in attachment 4 and has been confirmed to have a UGF around 0.1 Hz.

Finally, attachment 5 displays the off diagnolized sums and uncertainties for each of our previous step response results and the newest result (labeled "new") for Anchal's OUTPUT YAW matrix. The first graph in blue displays the overall sum and uncertainty related to each step response taken. Then in the following 3 plots, the sum's and uncertaintes for each sensor are displayed individually for each step response test.

For reference:

New: corresponds to Anchal's YAW OUPUT MATRIX

D0: refers to the previously implemented matrix, prior to any testint or updates

D1: refers to the matrix that was computed based off of the first test Tomohiro and I performed

D2: refers to the matrix computed as a secondary result from D1. This matrix was thought to provide a lower off diagonal sum, but did not.

This thoroughly displays our results such that the newly computed matrix from Anchal is much more diagnolized then that of the step response matrices Tomohiro and I have computed.

I realized that for more phase margin, rana added 6:3lead filter on WFS PIT loops. Since we have increased the UGF on YAW loops too, I turned these on the YAW loops as well. The loops remain stable unlike with the previous matrix. Attachment 1 is the repeat of teh emasurement done by rana earlier but with the new matrix and updated gains in PIT loops. The dark green traces are the references from last measurment with higher gain and HEPA off. The remainging colored traces were measured today.

The WFS loops were not maximizing the IMC transmission. The transmission counts remained stuck at around 12500 counts. The reflection DCMON from IMC had reached above 0.35 while nominally it had been around 0.2. So today, I manuaaly aligned the IMC to best transmission and lowest reflection, then unlocked IMC and reset the offsets on WFS1 and WFS2 RF readouts. After the offsets were changed, the error singals were fluctuating around 0 in best algined state. Then turning on the WFS loops made the transmissions slighlty higher to 13250 counts.

Alex, Anchal, and I adjusted the number of the MC2-TRANS column in the YAW output matrix. We used the same method in 40m/17504 but the amplitude of oscillator for Lock In Amplifier is increased from 1 to 4.

The corrected numbers of the column in the output matrix is as follows:

We did the step response test for the corrected output matrix. The sum of off-diagonal terms was 0.62, which is the minimum value. Attachment 1 is the step response test result. From the figure, the reduction of the sum is because the column MC2_TRANS can diagonalize better. We can find out the property from Attachment 2.