40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 2 of 339 Not logged in
ID Date Author Type Category Subject
17013   Mon Jul 18 16:49:57 2022 YehonathanUpdateBHDadd Laser RIN to MICH budget

I measured the RIN by taking the spectrum of C1:MC_TRANS_SUMFILT_OUT and dividing it by the mean count on that channel (~13800 cts). Attachment 1 shows the result.

I updated the MICH AS55 noise budget but got a very low contribution (gold trace in attachment 2).

It seems too low I think. What could've gone wrong? Finesse calculates that the transfer function from laser amplitude modulation to AS55 is ~ 1.5e-9 at DC. If I turn off HOMs I get 1e-11 at DC, so this coupling is a result of some contrast defect. Should I include some RMS imbalances in the optics to account for this? Should I include it as a second-order effect due to MICH RMS deviation from zero crossing?

 Quote: the main laser noise coupling for a Michelson is because of the RIN, not the frequency noise. You can measure the RIN, in MC trans or at the AS port by getting a single bounce beam from a single ITM.

Attachment 1: Laser_RIN.pdf
Attachment 2: MICH_AS55_Noise_Budget.pdf
17012   Mon Jul 18 16:39:07 2022 PacoSummaryLSCFPMI locking procedure using REFL55 and AS55

[Yuta, Paco]

In summary, we locked FPMI using REFL55_I, REFL55_Q, and AS55_Q. The key to success was to mix POX11_I and POY11_I in the right way to emulate CARM/DARM, and to find out the correct demodulation phase for AS55.

Procedure

1. Close PSL shutter and zero offsets in AS55, REFL55, POX11, POY11, and ASDC
• For ASDC run python3 resetOffsets.py -c C1:LSC-ASDC_IN1, otherwise use the zer offsets on I and Q inputs from the RFPD medm screen.
2. Lock XARM/YARM using POX/POY to tune demodulation phase.
• Today, the demode phase in POX11 changed to 104.801, and POY11 to -11.256 deg.
3. XARM and YARM are used in the following configuration
• INMAT
• 0.5 * POX11_I - 0.5 * POY --> XARM
• 0.5 * POX + 0.5*POY --> YARM
• REFL55_Q --> MICH (** this should be turned on after POX11/POY11)
• LSC Filter gains
• XARM = 0.012
• YARM = 0.012
• MICH = +40 (note the sign flip from last time)
• OUTMAT
• XARM --> 0.5 * ETMX - 0.5 * ETMY
• YARM --> MC2
• MICH --> BS
• UGFs (sanity check)
• XARM (DARM) ~ 100 Hz
• YARM (CARM) ~ 200 Hz
• MICH (MICH) ~ 40 Hz
4. Run MICHOpticalGainCalibration.ipynb to see if ASDC vs REFL55_Q looks nice (ellipse in the XY plot), and find any residual offset in REFL55_Q.
• If the plot doesn't look nice in this regard, the IFO needs to be aligned.
5. Sensing matrix for CARM/DARM and MICH.
• With the DARM, CARM and MICH lines on, verify the demod error signals look ok both in mag and phase.
• For example, we found that CARM error signals were correctly represented by either 0.5 * POX11_I + 0.5 * POY11_I or 0.5 * REFL55_I.
• Similarly, we found that DARM error signal was correctly represented by either 0.5 * POX11_I - 0.5 * POY11_I or 2.5 * AS55_Q.
• To find this, we minimized CARM content in AS55_Q, as well as CARM content in REFL55_Q.
6. We acquired the lock by re-configuring the error point as below:
• INMAT
• 0.5*REFL55_I --> YARM (CARM)
• 2.5 * AS55_Q --> XARM (DARM)
• During the hand-off trials, we repeatedly ran the sensing matrix and UGF measurements while stopping at various intermediate mixed error points to check how the error signal calibrations changed if at all.
• Attachment #1 shows the DARM OLTF using POX/POY (blue), only with CARM handoff (green), and after DARM handoff (red)
• Attachment #2 shows the CARM OLTF using POX/POY (blue), only with CARM handoff (green), and after DARM handoff (red)
• Attachment #3 shows the MICH OLTF using POX/POY (blue), only with CARM handoff (green), and after DARM handoff (red)
• The sensing matrix after handoff is below:
Sensing Matrix with the following demodulation phases
{'AS55': 192.8, 'REFL55': 95.63177865911078, 'POX11': 104.80089727128349, 'POY11': -11.256509422276006}
Sensors          	           DARM     	           CARM     	            MICH
C1:LSC-AS55_I_ERR_DQ	5.09e-02 (89.6761 deg)	2.03e-01 (-114.513 deg)	1.28e-04 (-28.9254 deg)
C1:LSC-AS55_Q_ERR_DQ	4.78e-02 (88.7876 deg)	3.61e-03 (-68.7198 deg)	8.34e-05 (-39.193 deg)
C1:LSC-REFL55_I_ERR_DQ	5.18e-02 (-92.2555 deg)	1.20e+00 (65.2507 deg)	1.15e-04 (-102.027 deg)
C1:LSC-REFL55_Q_ERR_DQ	1.81e-04 (59.0854 deg)	1.09e-02 (-114.716 deg)	1.77e-05 (-23.6485 deg)
C1:LSC-POX11_I_ERR_DQ	8.51e-02 (91.2844 deg)	4.77e-01 (67.1709 deg)	7.97e-05 (-72.5252 deg)
C1:LSC-POX11_Q_ERR_DQ	2.63e-04 (114.584 deg)	1.32e-03 (-113.505 deg)	2.10e-06 (118.146 deg)
C1:LSC-POY11_I_ERR_DQ	1.58e-01 (-88.9295 deg)	6.16e-01 (67.6098 deg)	8.71e-05 (172.73 deg)
C1:LSC-POY11_Q_ERR_DQ	2.89e-04 (-89.1114 deg)	1.09e-03 (70.2784 deg)	3.77e-07 (110.206 deg)


Lock gpstimes:

1. [1342220242, 1342220260]
2. [1342220420, 1342220890]
3. [1342221426, 1342221574]
4. [1342222753, 1342223230]

### Sensitivity estimate (NANB)

Using diaggui, we look at the AS55_Q error point and the DARM control point (C1:LSC-XARM_OUT). We roughly calibrate the error point using the sensing matrix element and actuation gain at the DARM oscillator freq 4.78e-2 / (10.91e-9 / 307.880^2). The control point is calibrated with a 0.95 Hz SUS pole. Attachment #4 shows the sensitivity estimate.

Attachment 1: DARM_07_18_2022_FMPI.pdf
Attachment 2: CARM_07_18_2022_FPMI.pdf
Attachment 3: MICH_07_18_2022_FPMI.pdf
Attachment 4: fpmi_darm_nb_2022_07.pdf
17011   Mon Jul 18 15:17:51 2022 HangUpdateCalibrationError propagation to astrophysical parameters from detector calibration uncertainty

1. In the error propogation equation, it should be \Delta \Theta = -H^{-1} M \Delta \Lambda, instead of the fractional error.

2. For the astro parameters, in general you would need t_c for the time of coalescence and \phi_c for the phase. See, e.g., https://ui.adsabs.harvard.edu/abs/1994PhRvD..49.2658C/abstract.

3. Fig. 1 looks very nice to me, yet I don't understand Fig. 3... Why would phase or amplitude uncertainties at 30 Hz affect the tidal deformability? The tide should be visible only > 500 Hz.

4. For BBH, we don't measure individual spin well but only their mass-weighted sum, \chi_eff = (m_1*a_1 + m_2*a_2)/(m_1 + m_2). If you treat S1z and S2z as free parameters, your matrix is likely degenerate. Might want to double-check. Also, for a BBH, you don't need to extend the signal much higher than \omega ~ 0.4/M_tot ~ 10^4 Hz * (Ms/M_tot). So if the total mass is ~ 100 Ms, then the highest frequency should be ~ 100 Hz. Above this number there is no signal.

17010   Mon Jul 18 04:42:54 2022 AnchalUpdateCalibrationError propagation to astrophysical parameters from detector calibration uncertainty

We can calculate how much detector calibration uncertainty affects the estimation of astrophysical parameters using the following method:

Let $\overrightarrow{\Theta}$ be set of astrophysical parameters (like component masses, distance etc), $\overrightarrow{\Lambda}$be set of detector parameters (like detector pole, gain or simply transfer function vaue for each frequency bin). If true GW waveform is given by $h(f; \overrightarrow{\Theta})$, and the detector transfer function is given by $\mathcal{R}(f; \overrightarrow{\Lambda})$, then the detected gravitational waveform becomes:
$g(f; \Theta, \Lambda) = \frac{\mathcal{R}(f; \overrightarrow{\Lambda_t})}{\mathcal{R}(f; \overrightarrow{\Lambda})} h(f; \overrightarrow{\Theta})$

One can calculate a derivative of waveform with respect to the different parameters and calculate Fisher matrix as (see correction in 40m/17017):

$\Gamma_{ij} = \left( \frac{\partial g}{\partial \mu_i} | \frac{\partial g}{\partial \mu_j}\right )$

where the bracket denotes iner product defined as:

$\left( k_1 | k_2 \right) = 4 Re \left( \int df \frac{k_1(f)^* k_2(f))}{S_{det}(f)}\right)$

where $S_{det}(f)$ is strain noise PSD of the detector.

With the gamma matrix in hand, the error propagation from detector parameter fractional errors $\frac{\Delta \Lambda_j}{\Lambda_j}$to astrophysical paramter fractional errors $\frac{\Delta \Theta_i}{\Theta_i}$is given by (eq 26 in Evan et al 2019 Class. Quantum Grav. 36 205006):

$\frac{\Delta \Theta_j}{\Theta_j} = - \mathbf{H}^{-1} \mathbf{M} \frac{\Delta \Lambda_j}{\Lambda_j}$

where $\mathbf{H}_{ij} = \left( \frac{\partial g}{\partial \Theta_i} | \frac{\partial g}{\partial \Theta_j}\right )$ and $\mathbf{M}_{ij} = \left( \frac{\partial g}{\partial \Lambda_i} | \frac{\partial g}{\partial \Theta_j}\right )$.

Using the above mentioned formalism, I looked into two ways of calculating error propagation from detector calibration error to astrophysical paramter estimations:

## Using detector response function model:

If we assume detector response function as a simple DC gain (4.2 W/nm) and one pole (500 Hz) transfer function, we can plot conversion of pole frequency error into astrophysical parameter errors. I took two cases:

• Binary Neutron Star merger with star masses of 1.3 and 1.35 solar masses at 100 Mpc distance with a $\tilde{\Lambda}$ of 500. (Attachment 1)
• Binary black hole merger with black masses of 35 and 30 at 400 MPc distance with spin along z direction of 0.5 and 0.8. (I do not fully understand the meaning of these spin components but a pycbc waveform generation model still lets me calculate the effect of detector errors) (Attachment 2)

The plots are plotted in both loglog and linear plots to show the order of magnitude effect and how the error propsagation slope is different for different parameters. 'm still not sure which way is the best to convey the information. The way to read this plot is for a given error say 4% in pole frequency determination, what is the expected error in component masses, merger distance etc. I

Note that the overall gain of detector response is not sensitive to astrophysical error estimation.

## Using detector transfer function as frequency bin wise multi-parameter function

Alternatively, we can choose to not fit any model to the detector transfer function and simply use the errors in magnitude and phase at each frequency point as an independent parameter in the above formalism. This then lets us see what is the error propagation slope for each frequency point. The hope is to identify which parts of the calibration function are more important to calibrate with low uncertainty to have the least effect on astrophysical parameter estimation. Attachment 3 and 4 show these plots for BNS and BBH cases mentioned above. The top panel is the error propagation slope at each frequency due to error in magnitude of the detector transfer function at that frequency and the bottom panel is the error propagation slope at each frequency due to error in phase of the detector transfer function.

The calibration error in magnitude and phase as a function of frequency would be multiplied by the curves and summed together, to get total uncertainty in each parameter estimation.

This is my first attempt at this problem, so I expect to have made some mistakes. Please let me know if you can point out any. Like, do the order of magnitude and shape of error propagation makes sense? Also, comments/suggestions on the inference of these plots would be helpful.

Finally, I haven't yet tried seeing how these curves change for different true values of the merger event parameters. I'm not yet sure what is the best way to extract some general information for a variety of merger parameters.

Future goals are to utilize this information in informing system identification method i.e. multicolor calibration scheme parameters like calibration line frequencies and strength.

Code location

Attachment 1: BNSparamsErrorwrtfdError-merged.pdf
Attachment 2: BBHparamsErrorwrtfdError-merged.pdf
Attachment 3: BNSparamsEPSwrtCalError.pdf
Attachment 4: BBHparamsEPSwrtCalError.pdf
17009   Sat Jul 16 02:44:10 2022 KojiUpdateIOOIMC servo tuning

I wasn't sure how the IMC servo was optimized recently. We used to have the FSS over all gain (C1:PSL-FSS_MGAIN) of +6dB a few years back. It is not 0dB. So I decided to do a couple of measurements.

1) Default setting:

C1:IOO-MC_REFL_GAIN +4
C1:IOO-MC_BOOST2 +3
C1:IOO-MC_VCO_GAIN +13
C1:PSL-FSS_MGAIN +0
C1:PSL-FSS_FASTGAIN +19

2) Looked at the power spectrum at TEST1A output (error signal)
TEST1A is the signal right after the input gain stage (C1:IOO-MC_REFL_GAIN). Prior to the measurement, I've confirmed that the UGF is ~100Hz even at +0dB (see next section). It was not too bad even with the current default. Just wanted to check if we can increase the gain a bit more.
The input gain was fixed at +4dB and the FSS overall gain C1:PSL-FSS_MGAIN was swept from +0 to +6.
At +5dB and +6dB, the servo bump was very much visible (Attachment 1).
I decided to set the default to be +4dB (Attachment 3).

3) Took OLTF at 0dB and 4dB for the FSS overall gain.

Now the comparison of the opel loop transfer functions (OLTF) for C1:PSL-FSS_MGAIN at 0dB and 4dB. The OLTF were taken by injectiong the network analyzer signal into EXCA and measure the ratio between TEST1A and TEST1B (A/B).

C1:PSL-FSS_MGAIN +0 -> UGF 100kHz / Phase Margin ~50deg
C1:PSL-FSS_MGAIN +4 -> UGF 200kHz / Phase Margin 25~30deg

The phase margin was a bit less but it was acceptable.

4) IMC FSR

Took the opportunity to check the FSR of the IMC. Connected a cable to the RF MON of the IMC REFL demod board. Looked at the peak at 40.56MHz (29.5MHz + 11.066MHz). The peak was not so clear at 11.066195MHz (see 40m ELOG 15845). The peak was anyway minimized and the new modulation frequency was set to be 11.066081MHz (new FSR). The change is 10ppm level and it is within the range of the temp drift.

Attachment 1: ErrorPSD.pdf
Attachment 2: OLTF.pdf
Attachment 3: Screen_Shot_2022-07-16_at_03.59.05.png
17008   Fri Jul 15 22:36:04 2022 ranaSummaryLSCFPMI with REFL/AS55 demod phase adjust

Very nice!

DARM feedback should go to ETMY - ETMX, not just a single mirror: Differential ARM.

For it to work with 1 mirror the UGF of the CARM loop must be much larger than DARM UGF. But in our case, both have a UGF of ~150 Hz.

In principle, you could run the CARM loop with higher gain by using the CM servo board, but maybe that can wait until the X,Y -> CARM, DARM handoff.

17007   Fri Jul 15 19:13:22 2022 PacoSummaryLSCFPMI with REFL/AS55 demod phase adjust

[Yuta, Paco]

• We first zero the offsets in ASDC, AS55, REFL55, POX11, and POY11 when PSL shutter is closed.
• After this, we checked the offsets with only ITMX aligned. Some of RFPDs had ~2 counts of offsets, which indicate some RFAM of sidebands, but we decided not to tune Marconi frequencies since the offsets were small enough.
• We went over the demod phases for AS55, REFL55, POX11, and POY11.
• For POX11/POY11 first we just minimized the Q in each locked XARM/YARM individually. The newfound values were
• C1:LSC-POX11_PHASE_R = 106.991
• C1:LSC-POY11_PHASE_R = -12.820
• Then we misaligned the XARM by getting rid of the MICH fringe in the ASDC port with ITMX yaw offset, and locked YARM using AS55_Q and REFL55_I and found the demod phase that minimized the AS55_I and REFL55_Q. The newfound values were
• C1:LSC-AS55_PHASE_R = -65.9586
• C1:LSC-REFL55_PHASE_R = -78.6254
• Repeating the above, but now misaligning YARM with ITMY yaw offset, locking XARM with AS55_Q and REFL55_I, we found the demod phases that minimized AS55_1 and REFL55_Q. The newfound values were
• C1:LSC-AS55_PHASE_R = -61.4361
• C1:LSC-REFL55_PHASE_R = -71.0434
• The above demod phases difference, Schnupp asymmetry between X and Y were measured. We repeated the measurement three times to derive the error.
• Optimal demod phase difference between X arm and Y arm for both AS55 and REFL55 were measured to be -4.5 +/- 0.1 deg, which means that lx-ly = 3.39 +/- 0.05 cm (Marconi frequency: 11.066195 MHz).
• We measured the gain difference between AS55_Q and POX11/POY11 = -0.5
• We measured the gain difference between REFL55_I and POX11/POY11 = -2.5

After this, we locked DARM, CARM and MICH using POX11_I, POY11_I and AS55 error signals respectively, and actuating on ETMX, MC2, and BS with NO TRIGGERS (but FM triggers were on for boosts as usual). Under this condition, FM5 is used for lock acquisition, and FM1, FM2, FM3, FM6 are turned on with FM triggers. No FM4 was on. We also noticed:

• CARM FM6 "BounceRoll" is slightly different than "YARM" FM6 "Bounce". The absent roll resonant gain actually makes it easier to control the CARM, we just had to use YARM filter for locking it.
• When CARM is controlled, we often just kick the ETMX to bring it near resonance, since the frequency noise drops and we otherwise have to wait long.
17006   Fri Jul 15 16:20:16 2022 Cici HannaUpdateGeneralFinding UGF

I have temporarily abandoned vectfit and aaa since I've been pretty unsuccessful with them and I don't need poles/zeroes to find the unity gain frequency. Instead I'm just fitting the transfer function linearly (on a log-log scale). I've found the UGF at about 5.5 kHz right now, using old data - next step is to get the Red Pitaya working so I can take data with that. Also need to move this code from matlab to python. Uncertainty's propagated using the 95% confidence bounds given by the fit, using curvefit - so just from the standard error, and all points are weighted equally. Ideally would like to propagate uncertainty accounting for the coherence data too, but haven't figured out how to do that correctly yet.

[UPDATE 7/22/2022: added raw data files]

Attachment 1: UGF_4042.png
Attachment 2: UGF_5650.png
Attachment 3: TFSR785_29-06-2022_114042.txt
# SR785 Measurement - Timestamp: Jun 29 2022 - 11:40:42
# Parameter File: TFSR785template.yml
#---------- Measurement Setup ------------
# Start frequency (Hz) = 100000.000000
# Stop frequency (Hz) = 100.000000
# Number of frequency points = 30
# Excitation amplitude (mV) = 10.000000
# Settling cycles = 5
# Integration cycles = 100
#---------- Measurement Parameters ----------

... 52 more lines ...
Attachment 4: TFSR785_29-06-2022_115650.txt
# SR785 Measurement - Timestamp: Jun 29 2022 - 11:56:50
# Parameter File: TFSR785template.yml
#---------- Measurement Setup ------------
# Start frequency (Hz) = 100000.000000
# Stop frequency (Hz) = 2000.000000
# Number of frequency points = 300
# Excitation amplitude (mV) = 5.000000
# Settling cycles = 5
# Integration cycles = 200
#---------- Measurement Parameters ----------

... 322 more lines ...
17005   Fri Jul 15 12:21:58 2022 JCUpdateElectronicsChecking Sorensen Power Supplies

Of the 7 Sorenson Power Supplies I tested, 5 are working fine, 1 cannot output voltage more than 20 Volts before shorting, and other does not output current. Six Sorensons are behind the X-Arm.

 Quote: [JC] I went around 40m picking up any Sorensens that were laying around to test if they worked, or in need of repair. I gathered up a total of 7 Sorensens and each one with a Voltmeter. I made sure the voltage would rise on the Sorenson as well as the voltmeter, maxing out at ~33.4 Volts. For the current, the voltmeter can only rise to 10 Amps before it is fused. Many of the Sorensons that I found did not have their own wall connection, so I had to use the same one for multiple. From these 7, I have found 5 that are well. One Sorenson I have tested has a output shortage above 20V and the other has yet to be tested.

Attachment 2: FA4CF579-6C1E-48D5-B152-74F35B4EE90B.jpeg
17004   Thu Jul 14 19:56:15 2022 ranaUpdateIOOmc wfs demod

It looks like Tomislav's measurements of the WFS demod board noise were actually of the cable that goes from the whitening to the ADC. So the huge low frequency excess that he saw is not due to wind, but just the inverse whitening of the digital system?

In any case, today, I looked at the connections from the Whitening to the ADC. It goes through an interface chassis to go from ribbon to SCSI. The D-Sub connectors there have the common problem in many of the LIGO D-sub connectors: namely that the strain relief nuts are too tall and so the D connector doesn't seat firmly - its always about to fall out. JC, can you please take a look at this and order a set of low profile nuts so that we can rework this chassis? Its the one between the WFS whitening and the SCSI cables which go to the ADCs.

After pushing them in, I confirmed that the WFS are working, by moving all 6 DoF of the MC mirrors via bias slider, and looking at the step responses (attached). As you can see, all sensors see all mirrors, even if they are noisy.

Next up: get a breakout for the demod output connector and measure the noise there.

For today, I aligned the IMC by hand, then centred the WFS beams by unlocking the IMC and aligning the bright beam. I noticed that the WFS1 beam was being dumped randomly, so I angled the WFS1 by ~3 deg and dumped the specular reflection on a razor blade dump. To handle the sign change in the MC1 actuation (?), I changed the sign in the MC1 ASC filter banks. MCWFS loops still nto closing, but they respond to mirror alignment.

Attachment 1: mcwfs-steps.pdf
17003   Thu Jul 14 19:09:51 2022 ranaUpdateGeneralEQ recovery

There was a EQ in Ridgecrest (approximately 200 km north of Caltech). It was around 6:20 PM local time.

All the suspensions tripped. I have recovered them (after some struggle with the weird profusion of multiple conflicting scripts/ directories that have appeared in the recent past...)

ETMY is still giving me some trouble. Maybe because of the HUGE bias on that within the fast CDS system, it had some trouble damping. Also the 'reenable watchdog' script in one of the many scripts directories seems to do a bad job. It re-enables optics, btu doesn't make sure that the beams are on the optical lever QPD, and so the OL servo can smash the optic around. This is not good.

Also what's up with the bashrc.d/ in some workstations and not others? Was there something wrong with the .bashrc files we had for the past 15 years? I will revert them unless someone puts in an elog with some justification for this "upgrade".

This new SUS screen is coming along well, but some of the fields are white. Are they omitted or is there something non-functional in the CDS? Also, the PD variances should not be in the line between the servo outputs and the coil. It may mislead people into thinking that the variances are of the coils. Instead, they should be placed elsewhere as we had it in the old screens.

Attachment 1: ETMY-screen.png
17002   Thu Jul 14 00:10:08 2022 yutaSummaryLSCFPMI with REFL/AS55 trial continued

[Paco, Koji, Yuta]

We managed to lock MICH using REFL55_Q by setting the demodulation phases and offsets right.
The following is the current FPMI locking configuration we achieved so far.

DARM: POX11_I / gain 0.007 / 0.5*ETMX-0.5*ETMY (or 1*ETMX) / UGF of ~100 Hz
CARM: POY11_I / gain 0.018 / 1*MC2 / UGF of ~200 Hz
MICH: REFL55_Q / gain -10 / 0.5*BS / UGF of ~30 Hz

Transitioning DARM error signal from POX11_I to 0.5*POX11_I+0.5*POY11_I was possible with FM4 filter off in DARM filter bank, but not to AS55_Q yet.

REFL55 and AS55 demodulation phase tuning:
- We found that both AS55 and REFL55 are contaminated by large non-MICH signal, by making a ASDC vs RF plot (see 40m/16929).
- After both arms are locked with POX and POY, MICH was locked with AS55_Q. ASDC was minimized by putting an offset to MICH filter.
- With this, REFL55 offsets were zeroed and demodulation phase was tuned to minimize REFL55_Q.
- Locked MICH with REFL55_Q, and did the same thing for AS55_Q.
- Resulting ASDC vs RF plots were attached. REFL55_Q now looks great, but REFL55_I and AS55 are noisy (due to signals from the arms?).

Jupyter notebook: https://git.ligo.org/40m/scripts/-/blob/main/CAL/MICH/MICHOpticalGainCalibration.ipynb

Sensing matrix:
- With FPMI locked using POX/POY, DARM and CARM lines were injected at around 300 Hz to measure the sensing gains. For line injection, C1:CAL-SENSMAT was used, but for the demodulation we used a script. The following is the result.

 Sensors              DARM (ETMX)         CARM (MC2)         C1:LSC-AS55_I_ERR    3.10e+00 (-34.1143 deg)    1.09e+01 (-14.907 deg)     C1:LSC-AS55_Q_ERR    9.96e-01 (-33.9848 deg)    3.30e+00 (-27.9468 deg)     C1:LSC-REFL55_I_ERR    6.75e+00 (-33.7723 deg)    2.92e+01 (-34.0958 deg)     C1:LSC-REFL55_Q_ERR    7.07e-01 (-33.4296 deg)    3.08e+00 (-33.4437 deg)     C1:LSC-POX11_I_ERR    3.97e+00 (-33.9164 deg)    1.51e+01 (-30.7586 deg)     C1:LSC-POY11_I_ERR    6.25e-02 (-20.3946 deg)    3.59e+00 (38.4207 deg)

Jupyter notebook: https://git.ligo.org/40m/scripts/-/blob/main/CAL/SensingMatrix/MeasureSensMat.ipynb

- By taking the ratios of POX11_I and AS55_Q for DARM, POY11_I and REFL55_I for CARM, we tried to find the correct gains for REFL55 and AS55 for DARM and CARM. x3.96 more gain for AS55_Q than POX11_I and x0.123 less gain for REFL55_I than POY11_I.

Next:
- Try locking the arms with no triggering, and then try locking FPMI with REFL/AS without triggering. No FM4 for this, since FM4 kills gain margin.
- Lock single arm with AS55_Q and make a noise budget. Make sure to misalign ITMX(Y) completely when locking Y(X)arm.
- Lock single arm with REFL55_I and make a noise budget.
- Repeat Xarm noise budget with Yarm locked with POY11_I and MC2 (40m/16975).
- Check IMC to reduce frequency noise (40m/17001)

Attachment 1: AS55_I.png
Attachment 2: AS55_Q.png
Attachment 3: REFL55_I.png
Attachment 4: REFL55_Q.png
17001   Wed Jul 13 18:58:17 2022 KojiUpdateIOOIMC suspecion

This is just my intuition but the IMC servo seems not so optimized. I can increase the servo gain by 6~10dB easily. And I couldn't see that the PC drive went mad (red) as I increase the gain (=UGF).
The IMC needs careful OLTF measurements as well as the high freq spectrum observation.

It seems that I have worked on the IMC servo tuning in 2014 July/Aug. Checking these elogs would be helpful.

17000   Wed Jul 13 17:30:19 2022 KojiUpdateCDSToo huge script_archive

I wanted to check the script archive to see some old settings. I found that the script archive inflated to huge volume (~1TB).
The size of the common NFS volume (/cvs/cds) is 3TB. So it is really significant.

- The scripts living in /opt/rtcds/caltech/c1/scripts are archived daily in /cvs/cds/caltech/scripts_archive as bz2 files. This is done by crontab of megatron (see https://wiki-40m.ligo.caltech.edu/Computers_and_Scripts/CRON)

- In fact, the script folder (say old script folder) /opt/rtcds/caltech/c1/scripts has the size of 10GB. And we have the compressed copy of thi s everyday.

- This large script folder is due to a couple of huge files/folders listed below

• (scripts)/MEDMtab is 5.3GB / This is probably related to the web MEDM view (on nodus) but I don't think the web page is not updated. (i.e. the images are unused)
• (scripts)/MC/logs/AutoLocker.log 2.9GB / This is just the accumulated MC autolocker log.
• (scripts)/GigE 780M / This does not look like scripts but source and object files
• (scripts)/Admin/n2Check.log 224M / This is important but increases every minute.
• (scripts)/ZI 316MB / Zurich Instrument installation. This should not be here.

Here I propose some changes.
For the script archive

• We can remove most of the scripts for the past (say ~2019). We leave an archive file per month.
• For the scripts in 2020, we leave a weekly archive.
• For 2021 and 2022, we leave all the archive files.

For the existing large files/folders

• MEDMtab: the stored files are redundant with the burt snapshots. Remove the image files. Also, we want to move the image-saving location.
• Autolocker.log: simply zap it
• n2Check.log: we should move the saving location
• GigE /ZI: they need a new home where the daily copy is not taken.
16999   Wed Jul 13 13:30:48 2022 YehonathanUpdateBHDadd Laser RIN to MICH budget

the main laser noise coupling for a Michelson is because of the RIN, not the frequency noise. You can measure the RIN, in MC trans or at the AS port by getting a single bounce beam from a single ITM.

16998   Wed Jul 13 13:26:44 2022 ranaSummaryElectronicsElectronics noise measurements

as I said to you yesterday, I don't think image 2a shows the output of the demod board. The output of the demod board is actually the output connector ON the demod board. What you are showing in 2a, is the signal that goes from the whitening board to the ADC I believe. I may be msitaken, so please check with Tega for the signal chain.

16997   Wed Jul 13 12:49:25 2022 PacoSummarySUSSUS frozen

[Paco, JC, Yuta]

This morning, while investigating the source of a burning smell, we turned off the c1SUS 1X4 power strip powering the sorensens. After this, we noticed the MC1 refl was not on the camera, and in general other vertex SUS were misaligned even though JC had aligned the IFO in the morning to almost optimum arm cavity flashing. After a c1susaux modbusIOC service restart and burt restore, the problem persisted.

We started to debug the sus rack chain for PRM since the oplev beam was still near its alignment so we could use it as a sensor. The first weird thing we noticed was that no matter how much we "kicked" PRM, we wouldn't see any motion on the oplev. We repeatedly kicked UL coil and looked at the coil driver inputs and outputs, and also verified the eurocard had DC power on which it did. Somehow disconnecting the acromag inputs didn't affect the medm screen values, so that made us suspicious that something was weird with these ADCs.

Because all the slow channels were in a frozen state, we tried restarting c1susaux and the acromag chassis and this fixed the issue.

16996   Wed Jul 13 10:54:39 2022 YehonathanUpdateBHDMICH AS55 noise budget

I fixed some mistakes in the budget:

1. The BS pendulum resonance was corrected from 0.8Hz to 1Hz

2. Added missing X3 filter in the coil filters

3. Optical gain is now computed from MICH to AS55 instead of BS to AS55 and is calculated to be: 9.95e8 cts/m.

4. Coil driver gain is still unmeasured but it is found to be 1.333 to make the actuation calibration from BS to MICH match the measurement (see attachment 1).

Attachment 2 shows the resulting MICH OLTF.

Laser noise was added to the budget in a slightly ad-hoc fashion (will fix later): Yuta and I measured MC_F and computed MC_F*(Schnupp asymmetry)/(Laser frequency). Attachment 3 shows the updated noise budget.

Attachment 1: BS_MICH_ACtuation_Calibration.pdf
Attachment 2: MICH_AS55_Model_Measurement_Comparison.pdf
Attachment 3: MICH_AS55_Noise_Budget.pdf
16995   Wed Jul 13 07:16:48 2022 JCUpdateElectronicsChecking Sorensen Power Supplies

[JC]

I went around 40m picking up any Sorensens that were laying around to test if they worked, or in need of repair. I gathered up a total of 7 Sorensens and each one with a Voltmeter. I made sure the voltage would rise on the Sorenson as well as the voltmeter, maxing out at ~33.4 Volts. For the current, the voltmeter can only rise to 10 Amps before it is fused. Many of the Sorensons that I found did not have their own wall connection, so I had to use the same one for multiple.

From these 7, I have found 5 that are well. One Sorenson I have tested has a output shortage above 20V and the other has yet to be tested.

Attachment 1: 658C5D39-11BD-4EE3-90E2-34CBBC1DBD3C.jpeg
Attachment 2: 5328312A-7918-44CC-82B7-54B57840A336.jpeg
16994   Tue Jul 12 19:46:54 2022 PacoSummaryALSHow (not) to take NPRO PZT transfer function

[Paco, Deeksha, rana]

Quick elog for this evening:

• Rana disabled MC servo .
• Slow loop also got disengaged.
• AUX PSL beatnote is best taken with *free running lasers* since their relative frequency fluctuations are lowest than when locked to cavities.
• DFD may be better to get PZT transfer funcs, or get higher bandwidth phase meter.
• Multi instrument to be done with updated moku
• Deeksha will take care of updated moku
16993   Tue Jul 12 18:35:31 2022 Cici HannaSummaryGeneralFinding Zeros/Poles With Vectfit

Am still working on using vectfit to find my zeros/poles of a transfer function - now have a more specific project in mind, which is to have a Red Pitaya use the zero/pole data of the transfer function to find the UGF, so we can check what the UGF is at any given time and plot it as a function of time to see if it drifts (hopefully it doesn't). Wrestled with vectfit more on matlab, found out I was converting from dB's incorrectly (should be 10^(dB/20)....) Intend to read a bit of a book by Bendat and Piersol to learn a bit more about how I should be weighting my vectfit. May also check out an algorithm called AAA for fitting instead.

16992   Tue Jul 12 14:56:17 2022 TomislavSummaryElectronicsElectronics noise measurements

[Paco, Tomislav]

We measured the electronics noise of the demodulation board, whitening board, and ADC for WFSs, and OPLEV board and ADC for DC QPD in MC2 transmission. We were using SR785.

Regarding the demodulation board, we did 2 series of measurements. For the first series of measurements, we were blocking WFS (attachment 1) and measuring noise at the output of the demod board (attachment 2a). This measurement includes dark noise of the WFS, electronics noise of demod board, and phase noise from LO. For the second series of the measurements, we were unplugging input to the demod board (attachment 2b & 2c is how they looked like before unplugging) (the mistake we made here is not putting 50-ohm terminator) and again measuring at the output of the demod board. This measurement doesn't include the dark noise of the WFS. We were measuring it for all 8 segments (I1, I2, I3, I4, Q1, Q2, Q3, Q4). The dark noise contribution is negligible with respect to demod board noise. In attachments 3 & 4 please find plots that include detection and demodulation contributions for both WFSs.

For whitening board electronics noise measurement, we were terminating the inputs (attachment 5) and measuring the outputs (attachment 6). Electronics noise of the whitening board is in the attachments 7 & 8.

For ADC electronics noise we terminated ADC input and measured noise using diaggui (attachments 9 & 10). Please find these spectra for WFS1, WFS2, and MC TRANS in attachments 11, 12 & 13.

For MC2 TRANS we measured OPLEV board noise. We did two sets of measurements, as for demod board of WFSs (with and without QPD dark noise) (attachments 14, 15 & 16). In the case of OPLEV board noise without dark noise, we were terminating the OPLEV input. Please find the electronics noise of OPLEV's segment 1 (including dark noise which is again much smaller with respect to the OPLEV's electronics noise) in attachment 17.

For the transfer functions, demod board has flat tf, whitening board tf please find in attachment 18, ADC tf is flat and it is (2**16 - 1)/20 [cts/V], and dewhitening tf please find in attachment 19. Also please find the ASD of the spectral analyzer noise (attachment_20).

Measurements for WFS1 demod and whitening were done on 5th of July between 15h and 18h local time. Measurements for WFS2 demod and whitening were done on 6th of July between 15h and 17h local time. All the rest were done on July 7th between 14h and 19h. In attachment 21 also find the comparison between electronics noise for WFSs and cds error signal (taken on the 28th of June between 17h and 18h). Sorry for bad quality of some pictures.

Attachment 1: attachment_1.jpg
Attachment 2: attachment_2a.jpg
Attachment 3: attachment_2b.jpg
Attachment 4: attachment_2c.jpg
Attachment 5: attachment_3.png
Attachment 6: attachment_4.png
Attachment 7: attachment_5.jpg
Attachment 8: attachment_6.jpg
Attachment 9: attachment_7.png
Attachment 10: attachment_8.png
Attachment 11: attachment_9.jpg
Attachment 12: attachment_10.jpg
Attachment 13: attachment_11.png
Attachment 14: attachment_12.png
Attachment 15: attachment_13.png
Attachment 16: attachment_14.jpg
Attachment 17: attachment_15.jpg
Attachment 18: attachment_16.jpg
Attachment 19: attachment_17.png
Attachment 20: attachment_18.png
Attachment 21: attachment_19.png
Attachment 22: attachment_20.png
Attachment 23: attachment_21.png
16991   Tue Jul 12 13:59:12 2022 ranaSummaryComputersprocess monitoring: Monit

I've installed Monit on megatron and nodus just now, and will set it up to monitor some of our common processes. I'm hoping that it can give us a nice web view of what's running where in the Martian network.

16990   Tue Jul 12 09:25:09 2022 ranaUpdateIOOIMC WFS

MC WFS Demod board needs some attention.

Tomislav has been measuring a very high noise level in the MC WFS demod output (which he promised to elog today!). I thought this was a bogus measurement, but when he, and Paco and I tried to measure the MC WFS sensing matrix, we noticed that there is no response in any WFS, although there are beams on the WFS heads. There is a large response in MC2 TRANS QPD, so we know that there is real motion.

I suspect that the demod board needs to be reset somehow. Maybe the PLL is unlocked or some cable is wonky. Hopefully not both demod boards are fried.

Please leave the WFS loops off until demod board has been assessed.

16989   Tue Jul 12 09:14:50 2022 ranaUpdateBHDMICH AS55 noise budget

Looking good:

• I think the notches you see in he measured noise are a clue as to the excess noise source. You can try turning some notches on/off.
• Laser noise does matter a bit more subtley: the low freq noise couples to AS55 through the RMS deviation of the MICH loop from the zero crossing, and the noise of the 55 MHz modulation.
• Jitter in the IMC couples to MICH through the misalignment of the Michelson.
• As you rightly note, the optical lever feedback on the ITMs and BS also make length noise through the suspension actuator imbalance and the spot mis-centering.
16988   Mon Jul 11 19:29:23 2022 PacoSummaryGeneralFinalizing recovery -- timing issues, cds, MC1

[Yuta, Koji, Paco]

## Restarting CDS

We were having some trouble restarting all the models on the FEs. The error was the famous 0x4000 DC error, which has to do with time de-synchronization between fb1 and a given FE. We tried a combination of things haphazardly, such as reloading the gpstime process using

controls@fb1:~ 0$sudo systemctl stop daqd_* controls@fb1 :~ 0$ sudo modprobe -r gpstime
controls@fb1:~ 0$sudo modprobe gpstime controls@fb1:~ 0$ sudo systemctl start daqd_*
controls@fb1:~ 0$sudo systemctl restart open-mx.service without much success, even when doing this again after hard rebooting FE + IO chassis combinations around the lab. Koji prompted us to check the local times as reported by the gpstime module, and comparing it to network reported times we saw the expected offset of ~ 3.5 s. On a given FE ("c1***") and fb1 separately, we ran: controls@c1***:~ 0$ timedatectl
Local time: Mon 2022-07-11 16:22:39 PDT
Universal time: Tue 2022-07-11 23:22:39 UTC
Time zone: America/Los_Angeles (PDT, -0700)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2022-03-13 01:59:59 PST
Sun 2022-03-13 03:00:00 PDT
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2022-11-06 01:59:59 PDT
Sun 2022-11-06 01:00:00 PST
controls@fb1:~ 0$ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 192.168.123.255 .BCST. 16 u - 64 0 0.000 0.000 0.000 which meant a couple of things: 1. fb1 was serving its time (broadcast to local (martian) network) 2. fb1 was not getting its time from the internet 3. c1*** was not synchronized even though fb1 was serving the time By looking at previous elogs with similar issues, we tried two things; 1. First, from the FEs, run sudo systemctl restart systemd-timesyncd to get the FE in sync; this didn't immediately solve anything. 2. Then, from fb1, we tried pinging google.com and failed! The fb1 was not connected to the internet!!! We tried rebooting fb1 to see if it connected, but eventually what solved this was restarting the bind9 service on chiara! Now we could ping google, and saw this output controls@fb1:~ 0$ ntpq -p
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+tor.viarouge.ne 85.199.214.102   2 u  244 1024  377  144.478    0.761   0.566
*ntp.exact-time. .GPS.            1 u   93 1024  377  174.450   -1.741   0.613
time.nullrouten .STEP.          16 u    - 1024    0    0.000    0.000   0.000
+ntp.as43588.net 129.6.15.28      2 u  39m 1024  314  189.152    4.244   0.733
192.168.123.255 .BCST.          16 u    -   64    0    0.000    0.000   0.000

meaning fb1 was getting its time served. Going back to the FEs, we still couldn't see the ntp synchronized flag up, but it just took time after a few minutes we saw the FEs in sync! This also meant that we could finally restart all FE models, which we successfully did following the script described in the wiki. Then we had to reload the modbusIOC service in all the slow machines (sometimes this required us to call sudo systemctl daemon-reload) and performed burt restore to a last Friday's snap file collection.

## IMC realign and MC1 glitch?

With Koji's help PMC locked, and then Yuta and Paco manually increased the input power to the IFO by rotating the waveplate picomotor to 37.0 deg. After this, we noticed that the MC REFL spot was not hitting the camera, so maybe MC1 was misaligned. Paco checked the AP table and saw the spot horizontally misaligned on the camera, which gave us the initial YAW correction on MC1. After some IMC recovery, we saw only MC1 got spontaneously kicked along both PIT and YAW, making our alignment futile. Though not hard to recover, we wondered why this happened.

We went into the 1X4 rack and pushed MC1 suspension cables in to disregard loose connections, but as we came back into the control room we again saw it being kicked randomly! We even turned damping off for a little while and this random kicking didn't stop. There was no significant seismic motion at the time so it is still unclear of what is happening.

16987   Mon Jul 11 17:41:52 2022 KojiHowToVACStartup after Power Outage

- Once the FRG gauge readings are back (see next elog by Tega), I could open V1 to pump down the main vacuum manifold.
- TP2/TP3 were brought back to stand-by mode (slower spinning)
- V7 was closed to separate the annuli side and TP1

During the vacuum recovery, I saw TPs were automatically turned on as soon as the backing pumps were engaged. I could not figure out what caused this automation.

Also, I saw some gate valve states changed while I was not touching them. e.g. V7 was close / VM3 was open / etc
I really had no idea what/who was handling these.

As of ~18:00 local, the main volume pressure is ~2e-5 torr and ready to open the PSL shutter.

Attachment 1: Screen_Shot_2022-07-11_at_18.13.00.png
16986   Mon Jul 11 17:25:43 2022 TegaUpdateVACfixed obsolete reference bug in serial_XGS600 service

Koji noticed that the FRG sensors were not updating due to reference to an obsolete modbusIOC_XGS service, which was used temporarily to test the operation of the serial XGS sensor readout to EPICS. The information in this service was later moved into modbusIOC.service but the dependence on the modbusIOC_XGS.service was not removed from the serial_XGS600.service. This did not present any issue before the shutdown, probably bcos the obsolete service was already loaded but after the restart of c1vac, the obsolete service file modbusIOC_XGS.service was no longer available. This resulted in  serial_XGS600.service throwing a failure to load error for the missing obsolete modbusIOC_XGS service. The fix involved replacing two references to 'modbusIOC_XGS' with 'modbusIOC' in  /opt/target/services/serial_XGS600.service.

I also noticed that the date logged in the commit message was Oct 2010 and that I could not do a push from c1vac due to an error in resolving git.ligo.org. I was able to push the commit from my laptop git repo but was unable to do a pull on c1vac to keep it synced with the remote repo.

16985   Mon Jul 11 15:26:12 2022 JCHowToVACStartup after Power Outage

[Koji, Jc]

Koji and I began starting that Vacuum system up.

1. Reverse order step 2 of shutting down electronics. Anthing after, turn on manually.
2. If C1vac does not come back, then restart by holding the reset button.
3. Open VA6
4. Open VASE, VASV,VABSSCI, VABS, VABSSCO, VAEV, and VAEE
5. Open V7
6. Check P3 and P2, if they are at high pressure, approx. 1 Torr range, then you must use the roughing pumps.
7. Connect Rotary pump tube. (Manually)
8. Turn on AUX Pump
9. Manually open TP2 and TP3 valves.
10. Turn on TP2 and TP3, when the pumps finish startup, turn off Standby to bring to nominal speed.
11. Turn on RP1 and RP3
12. Open V6
13. Once P3 reaches <<1 Torr, close V6 to isolate the Roughing pumps.
14. When TP2 and TP3 are at nominal speed, open V5 and V4.
15. Now TP1 is well backed, turn on TP1.
16. When TP1 is at nominal speed, Open V1.
16984   Mon Jul 11 11:56:40 2022 he YehonathanUpdateBHDMICH AS55 noise budget

I calculated a noise budget for the MICH using AS55 as a sensor. The calculation includes closed-loop TF calculations.

The notebook and associated files can be found on https://git.ligo.org/40m/bhd/-/blob/master/controls/compute_MICH_noisebudget.ipynb.

Attachment 1 shows the loop diagram I was using. The equation describing the steady-state of the loop is

$\left[\mathbb{I}-G \right]\begin{pmatrix} \gamma \\ \delta \\ \Delta\end{pmatrix} = \begin{pmatrix} \alpha \\ \beta \\ \epsilon\end{pmatrix}$

, where G is the adjacency matrix given by

$G=\begin{pmatrix} 0 & 0 & AE_2\\ 0 & 0 & BE_2 \\ E_1C & E_1D & 0 \end{pmatrix}$

First, the adjacency matrix G is constructed by stitching the small ABCDE matrices together. Once the inverse of (I-G) is calculated we can simply propagate any noise source to $\delta$ and then calculate $\left[\mathbb{I}-E(CA+DB)\right]B^{-1}\delta$ to estimate the displacement of the optics.

Attachment 2 shows the calculated noise budget together with Yuta's measurement.

All the input and output electronics are clumped together for now. Laser noise is irrelevant as this is a heterodyne measurement at 55MHz.

It seems like there is some mismatch in the calibration of the optical gain between the measurement and model. The missing noise at 3-30Hz could be due to angle-to-length coupling which I haven't included in the model.

Attachment 1: Control_Diagram.pdf
Attachment 2: MICH_AS55_Noise_Budget.pdf
16983   Mon Jul 11 11:16:45 2022 JCSummaryElectronicsStartup after Shutdown

[Paco, Yehonathan, JC]

We began starting up all the electronics this morning beginning in the Y-end. After following the steps on the Complete_Power_Shutdown_Procedures on the 40m wiki, we only came across 2 issues.

1. The Green beam at the Y-End : Turn on the controller and the indicator light began flashing. After waiting until the blinking light becomes constant, turn on the beam.
2. C1lsc "could not find operating system"-unable to SSH from Rossa : We found an Elog of how to restart Chiara and this worked. We proceeded by adding this to the procedures of startup.
16982   Fri Jul 8 23:10:04 2022 KojiSummaryGeneralJuly 9th, 2022 Power Outage Prep

The 40m team worked on the power outage preparation. The detailed is summarized on this wiki page. We will still be able to access the wiki page during the power outage as it is hosted some where in Downs.

https://wiki-40m.ligo.caltech.edu/Complete_power_shutdown_2022_07

16981   Fri Jul 8 16:18:35 2022 ranaUpdateLSCActuator calibration of MC2 using Yarm

although I know that Yuta knows this, I will just put this here to be clear: the NNN/f^2 calibration is only accurate abouve the pendulum POS eiegenfrequency, so when we estimate the DC part (in diaggui, for example), we have to assume that we have a pendulum with f = 1 Hz and Q ~5, to get the value of DC gain to put into the diaggui Gain field in the calibration tab.

16980   Fri Jul 8 14:03:33 2022 JCHowToVACVacuum Preparation for Power Shutdown

[Koji, JC]

Koji and I have prepared the vacuum system for the power outage on Saturday.

1. Closed V1 to isolate the main volume.
2. Closed of VASE, VASV, VABSSCI,VABS, VABSSCO, VAEV, and VAEE.
3. Closed V6, then close VM3 to isolate RGA
4. Turn off TP1 (You must check the RPMs on the TP1 Turbo Controller Module)
5. Close V5
6. Turn off TP3 (There is no way to check the RPMs, so be patient)
7. Close V4 (System State changes to 'All pneumatic valves are closed)
8. Turn off TP2 (There is no way to check the RPMs, so be patient)
9. Close Vacuum Valves (on TP2 and TP3) which connect to the AUX Pump.
10. Turn of AUX Pump with the breaker switch wall plug.

From here, we shutdown electronics.

1. Run /sbin/shutdown -h now on c1vac to shut the host down.
2. Manually turn off power to electronic modules on the rack.
• GP316a
• GP316b
• Vacuum Acromags
• PTP3
• PTP2
• TP1
• TP2 (Unplugged)
• TP3 (Unplugged)

Attachment 1: Screen_Shot_2022-07-12_at_7.02.14_AM.png
16979   Thu Jul 7 21:25:48 2022 TegaSummaryCDSUse osem variance to turn off SUS damping instead of coil outputs

[Anchal, Tega]

Implemented ramp down of coil bias voltage when the BHD optics watchdog is tripped. Also added a watchdog reset button to the SUS medm screen that turns on damping and ramps up the coil PIT/YAW bias voltages to their nominal values. I believe this concludes the watchdog work.

 Quote: TODO Figure out the next layer of watchdogging needed for the BHD optics.

16978   Thu Jul 7 18:22:12 2022 yutaUpdateLSCActuator calibration of MC2 using Yarm

(This is also a restore of elog 40m/16971 from Jul 5, 2022 at 17:36)

MC2 actuator calibration was also done using Yarm in the same way as we did in 40m/16970 (now 40m/16977).
The result is the following;
MC2 : -14.17e-9 /f^2 m/counts in arm length (-2.9905 times ITMY) MC2 :   5.06e-9 /f^2 m/counts in IMC length MC2 :  1.06e+05 /f^2 Hz/counts in IR laser frequency

What we did:
- Measured TF from C1:LSC-MC2_EXC to C1:LSC-YARM_IN1 during YARM lock using ETMY (see Attachment #1). Note that the sign of MC2 actuation and ITMY actuation is flipped.
- Took the ratio between ITM actuation and MC2 actuation to calculate MC2 actuation. For ITM actuation, we used the value measured using MICH (see 40m/16929). The average of the ratio in the frequency range 70-150 Hz was used (see Attachment #2).
- The actuation efficiency in meters in arm length was converted into meters in IMC length by multiplying it by IMCLength/ArmLength, where IMCLength=13.5 m is half of IMC round-trip length, ArmLength=37.79 m is the arm length.
- The actuation efficiency in meters in arm length was converted into Hz in IR laser frequency by multiplying it by LaserFreq/ArmLength, where LaserFreq=1064 nm / c is the laser frequency.

Files:
- Measurement files live in https://git.ligo.org/40m/measurements/-/tree/main/LSC/YARM
- Script for calculation lives at https://git.ligo.org/40m/scripts/-/blob/main/CAL/ARM/ETMActuatorCalibration.ipynb

Summary of actuation calibration so far:
BS   : 26.08e-9 /f^2 m/counts (see 40m/16929)
ITMX :  5.29e-9 /f^2 m/counts (see
40m/16929)
ITMY :  4.74e-9 /f^2 m/counts (see
40m/16929)
ETMX :  2.65e-9 /f^2 m/counts (0.5007 times ITMX) ETMY : 10.91e-9 /f^2 m/counts (2.3017 times ITMY)
MC2 : -14.17e-9 /f^2 m/counts in arm length (-2.9905 times ITMY) MC2 :   5.06e-9 /f^2 m/counts in IMC length

NOTE ADDED by YM on July 7, 2022

To account for the gain imbalance in ETMX, ETMY, MC2, LSC violin filter gains were set to: C1:LSC-ETMX_GAIN = 4.12 C1:LSC-MC2_GAIN = -0.77 This is a temporary solution to make ETMX and MC2 actuation efficiencies from LSC in terms of arm length to be the same as ETMY 10.91e-9 /f^2 m/counts.

I think it is better to make C1:LSC-ETMX_GAIN = 1, and put 4.12 in C1:SUS-ETMX_TO_COIL gains. We need to adjust local damping gains and XARM ASS afterwards. As for MC2, it is better to put -0.77 in LSC output matrix, since this balancing depends on LSC topology.

Attachment 1: TF.png
Attachment 2: MC2.png
16977   Thu Jul 7 18:18:19 2022 yutaUpdateLSCActuator calibration of ETMX and ETMX

(This is a complete restore of elog 40m/16970 from July 5, 2022 at 14:34)

ETMX and ETMY actuators were calibrated using single arm lock by taking the actuation efficiency ratio between ITMs. Below is the result.

ETMX :  2.65e-9 /f^2 m/counts (0.5007 times ITMX)
ETMY : 10.91e-9 /f^2 m/counts (2.3017 times ITMY)

Motivation:
- ETMX and ETMY actuators seemed to be unbalanced when locking DARM (see 40m/16968)

What we did:
- Reverted to C1:LSC-ETMX_GAIN = 1
- XARM was locked using POX11_I_ERR (42dB whitening gain, 132.95 deg for demod phase) with ETMX and C1:LSC-XARM_GAIN=0.06
- YARM was locked using POY11_I_ERR (18dB whitening gain, -66.00 deg for demod phase) with ETMX and C1:LSC-YARM_GAIN=0.02
- OLTFs for each was measured to be Attachment #1; UGF was ~180 Hz for XARM, ~200 Hz for YARM.
- Measured TF from C1:LSC-(E|I)TM(X|Y)_EXC to C1:LSC-(X|Y)ARM_IN1 (see Attachment #2)
- Took the ratio between ITM actuation and ETM actuation to calculate ETM actuation. For ITM actuation, we used the value measured using MICH (see 40m/16929). The average of the ratio in the frequency range 70-150 Hz was used.

Files:
- Measurement files live in https://git.ligo.org/40m/measurements/-/tree/main/LSC/XARM and YARM
- Script for calculation lives at https://git.ligo.org/40m/scripts/-/blob/main/CAL/ARM/ETMActuatorCalibration.ipynb

Discussion:
- ETMX actuation is 4.12 times less compared with ETMY. This is more or less consistent with what we measured in 40m/16968, but we didn't do loop-correction at that time.
- We should check if this imbalance is as expected or not.

Summary of actuation calibration so far:
BS   : 26.08e-9 /f^2 m/counts (see 40m/16929)
ITMX :  5.29e-9 /f^2 m/counts (see 40m/16929)
ITMY :  4.74e-9 /f^2 m/counts (see 40m/16929)
ETMX :  2.65e-9 /f^2 m/counts (0.5007 times ITMX) ETMY : 10.91e-9 /f^2 m/counts (2.3017 times ITMY)

Attachment 1: Screenshot_2022-07-05_14-52-01_OLTF.png
Attachment 2: Screenshot_2022-07-05_14-54-03_TF.png
Attachment 3: Screenshot_2022-07-05_14-56-41_Ratio.png
16976   Wed Jul 6 22:40:03 2022 TegaSummaryCDSUse osem variance to turn off SUS damping instead of coil outputs

I updated the database files for the 7 BHD optics to separate the OSEM variance trigger and the LATCH_OFF trigger operations so that an OSEM variance value exceeding the max of say 200 cnts turns off the damping loop whereas pressing the LATCH_OFF button cuts power to the coil. I restarted the modbusIOC service on c1susaux2 and checked that the new functionality is behaving as expected. So far so good.

TODO

Figure out the next layer of watchdogging needed for the BHD optics.

 Quote: [Anchal, JC, Ian, Paco] We have now fixed all issues with the PD mons of c1susaux2 chassis. The slow channels are now reading same values as the fast channels and there is no arbitrary offset. The binary channels are all working now except for LO2 UL which keeps showing ENABLE OFF. This was an issue earlier on LO1 UR and it magically disappeared and now is on LO2. I think the optical isolators aren't very robust. But anyways, now our watchdog system is fully functional for all BHD suspended optics.

16975   Wed Jul 6 19:58:16 2022 PacoSummaryNoiseBudgetXARM noise budget

[Anchal, Paco, Rana]

We locked the XARM using POX11 and made a noise budget for the single arm displacement; see Attachment #1. The noise budget is rough in that we use simple calibrations to get it going; for example we calibrate the measured error point C1:LSC-XARM_IN1_DQ using the single cavity pole and some dc gain to match the UGF point. The control point C1:LSC-XARM_OUT_DQ is calibrated using the actuator gain measured recently by Yuta. We also overlay an estimate of the seismic motion using C1:PEM-SEIS_BS_X_OUT_DQ (calibrated using a few poles to account for stack and pendulum), and finally the laser frequency noise as proxied by the mode cleaner C1:IOO-MC_F_DQ.

A couple of points are taken with this noise budget, apart from it needing a better calibration;

1. Overall the inferred residual displacement noise is high, even for our single arm cavity.
1. By looking at the sim OLTF in foton, it seemed that the single arm cavity loop TF could easily become unstable due to some near-UGF-funkiness likely from FM3 (higher freq boost), so we disabled the automatic triggering on it; the arm stayed locked and we changed the error signal (light blue vs gold (REF1) trace)
2. The arm cavity is potentially seeing too much noise from the IMC in the 1 to 30 Hz band in the form of laser frequency noise.
1. Need IMC noise budget to properly debug.
3. At high frequency (>UGF), there seem to be a bunch of "wiggles" which remain unidentified.
1. We actually tried to investigate a bit into these features, thinking they might have something to do with misalignment, but we couldn't really find significant correlation.

RXA edit:

1. we also noticed some weirdness in the calibration of MC_F v. Arm. We think MC_F should be in units of Hz, and Paco calculated the resulting motion as seen by the arm, but there was a factor of several between these two. Need to calibrate MC_F and check. In principle, MC_F will show up directly in ALS_BEATX (with the green PDH lock off), and I assume that one is accurately calibrated. Somehow we should get MC_F, XARM, and ALS_BEAT to all agree. JC is working on calibrating the Mini-Circuits frequency counter, so once that is done we will be in good shape.
2. we may need to turn on some MC_L feedback for the IMC, so that the MC length follows the NPRO frequency below ~20 Hz.
3. Need to estimate where the IMC WFS noise is in all of this. Does it limit the MC length stability in any frequency band? How do we determine this?
4. Also, we want to redo this noise budget today, whilst using AS55 instead of POX. Please measure the Schnupp asymmetry by checking the optimum demod phase in AS55 for locking Xarm v Yarm.
Attachment 1: xarm_nb_2022_07.pdf
16974   Wed Jul 6 18:51:20 2022 DeekshaUpdateElectronicsMeasuring the Transfer Function of the PZT

Yesterday, we set up the loop to measure the PZT of the transfer function - the MokuLab sends an excitation (note - a swept sine of 1.0 V) to the PZT. The cavity is locked to the PSL and the AUX is locked to the cavity. In order to measure the effect of our excitation, we take the beat note of the PSL and the AUX. This gives us a transfer function as seen in Attachment 1. The sampling rate of the MokuLab is set to 'ultrafast' (125kHz), so we can expect accurate performance upto 62.5kHz, however, in order to improve our readings beyond this frequency, modifications must be made to the script (MokuPhaseMeterTF) to avoid aliasing of the signal. A script should also be written to obtain and plot the coherence between the excitation and our output.

Also attached are - Attachment 2 -  the circuit diagram of the setup, and Attachment 3 - the TF data calculated.

Edit - the SR560 as shown in the circuit diagram has since been replaced by a broadband splitter (Minicircuits ZFRSC-42-S+).

Attachment 1: pzt_transfer_fn.png
Attachment 2: ckt_diagram.jpeg
Attachment 3: MokuPhaseMeterTFData_20220706_174753_TF_Data.txt
2.000000000000000364e+04 1.764209350625748560e+07 2.715833132756984014e+00
1.928351995884991265e+04 1.695301366919569671e+07 1.509398637395631626e+00
1.859270710016814337e+04 1.647055321367538907e+07 -2.571975165101855865e+00
1.792664192275710593e+04 1.558169995329630189e+07 6.272729335836754183e-01
1.728443786563210961e+04 1.500850042360494658e+07 -1.500422400597591466e+00
1.666524012797089381e+04 1.456986577652360499e+07 2.046163000975175894e+00
1.606822453133765885e+04 1.376167843637173250e+07 1.736835046956476614e+00
1.549259642266657283e+04 1.326192932667389885e+07 -1.272425049850132606e+00
1.493758961654484847e+04 1.283127345074228011e+07 -2.026149685362535369e+00
1.440246537538758821e+04 1.208854709974890016e+07 -3.248352694840740407e-01

... 11 more lines ...
16973   Wed Jul 6 15:28:18 2022 TegaUpdateSUSOutput matrix diagonalisation : F2P coil balancing

local dir:  /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/OutMatCalc

Here is an update on our recent attempt at diagonalization of the SUS output matrices. There are two different parts to this: the first is coil balancing using existing F2P code which stopped working because of an old-style use of the print function and the second which should now focus on the mixing amongst the various degrees of freedoms (dof) without a DC/AC split I believe. The F2P codes are now working and have been consolidated in the git repo.

TODO:

• The remaining task is to make it so that we only call a single file that combines the characterization code and filter generation code, preferably with the addition of a safety feature that restores any changed values in case of an error or interruption from the user. The safety functionality is already implemented in the output matrix diagonalization stem of the code, so we just need to copy this over.
• Improve the error minimization algorithm for minimizing the cross-coupling between the various dof by adjusting the elements of the output matrix.

Previous work

https://nodus.ligo.caltech.edu:8081/40m/4762

https://nodus.ligo.caltech.edu:8081/40m/4719

https://nodus.ligo.caltech.edu:8081/40m/4688

https://nodus.ligo.caltech.edu:8081/40m/4682

https://nodus.ligo.caltech.edu:8081/40m/4673

https://nodus.ligo.caltech.edu:8081/40m/4327

https://nodus.ligo.caltech.edu:8081/40m/4326

https://nodus.ligo.caltech.edu:8081/40m/4762

16972   Tue Jul 5 20:05:06 2022 TomislavUpdateElectronicsWhitening electronics noise

For whitening electronics noise for WFS1, I get (attachment). This doesn't seem right, right?

Attachment 1: whitening_noises.png
16969   Fri Jul 1 12:49:52 2022 KojiUpdateIOOMC2 seemed misaligned / fixed

I found the IMC was largely misaligned and was not locking. The WFS feedback signals were saturated and MC2 was still largely misaligned in yaw after resetting the saturation.
It seemed that the MC WFS started to put the large offset at 6:30AM~7:00AM (local).
MC2 was aligned and the lock was recovered then the MC WFS seems working for ~10min now.

Attachment 1: C1-MULTI_FBDB3F_TIMESERIES-1340668818-86400.png
Attachment 2: C1-LOCKED_MC_5E4267_TIMESERIES-1340668818-86400.png
16968   Fri Jul 1 08:50:48 2022 yutaSummaryLSCFPMI with REFL/AS55 trial

[Anchal, Paco, Yuta]

We tried to lock FPMI with REFL55 and AS55 this week, but no success yet.
FPMI locks with POX11, POY11 and ASDC for MICH stably, but handing over to 55's couldn't be done yet.

What we did:
- REFL55: Increased the whitening gain to 24dB. Demodulation phase tuned to minimize MICH signal in I when both arms are locked with POX and POY. REFL55 is noisier than AS55. Demodulation phase and amplitude of the signal seem to drift a lot also. Might need investigation.
- AS55: Demodulation phase tuned to minimize MICH signal in I when both arms are locked with POX and POY. Whitening gain is 24dB.
- Script for demodulation phase tuning lives in https://git.ligo.org/40m/scripts/-/blob/main/RFPD/getPhaseAngle.py
- Locking MICH with REFL55 Q: Kicks BS much and not so stable probably because of noisy REFL55. Offtet also needs to be adjusted to lock MICH to dark fringe.
- BS coil balancing: When MICH is "locked" with REFL55 Q, TRX drops rapidly and AS fringe gets worse, indicating BS coil balancing is not good. We balanced the coils by dithering POS with different coil output matrix gains to minimize oplev PIT and YAW output manually using LOCKINs.
- Locking MICH with ASDC: Works nicely. Offset is set to -0.1 in MICH filter and reduced to -0.03 after lock acquisition.
- ETMX/ETMY actuation balancing: We found that feedback signal to ETMX and ETMY at LSC output is unbalanced when locking with POX and POY. We dithered MC2 at 71 Hz, and checked feedback signals when Xarm/Yarm are locked to find out actuation efficiency imbalance. A gain of 2.9874 is put into C1:LSC-ETMX filter to balance ETMX/ETMY. I think we need to check this factor carefully again.
- TRX and TRY: We normalized TRX and TRY to give 1 when arms are aligned. Before doing this, we also checked the alignment of TRX and TRY DC PDs (also reduced green scattering for TRY). Together with ETMX/ETMY balancing, this helped making filter gains the same for POX and POY lock to be 0.02 (See, also 40m/16888).
- Single arm with REFL55/AS55: We checked that single arm locking with both REFL55_I and AS55_Q works. Single arm locking feeding back to MC2 also worked.
- Handing over to REFL55/AS55: After locking Xarm and Yarm using POX to ETMX and POY to ETMY, MICH is locked with ASDC to BS. Handing over to REFL55_I for CARM using ETMX+ETMY and AS55_Q for DARM using -ETMX+ETMY was not successful. Changing an actuator for CARM to MC2 also didn't work. There might be an unstable point when turning off XARM/YARM filter modules and switching on DARM/CARM filter modules with a ramp time. We also need to re-investigate correct gains and signs for DARM and CARM. (Right now, gains are 0.02 for POX and POY, -0.02 for DARM with AS55_Q (-ETMX+ETMY), -0.02 for CARM with REFL55_I with MC2 are the best we found so far)

Next:
- Measure ETMX and ETMY actuation efficiencies with Xarm/Yarm to balance the output matrix for DARM.
- Measure optical gains of POX11, POY11, AS55 and REFL55 when FPMI is locked with POX/POY/ASDC to find out correct filter gains for them.
- Make sure to measure OLTFs when doing above to correct for loop gains.
- Lock CARM with POY11 to MC2, DARM with POX11 to ETMX. Use input matrix to hand over instead of changing filter modules from XARM/YARM to DARM/CARM.
- Try using ALS to lock FPMI.

16967   Thu Jun 30 19:24:24 2022 ranaSummaryPEMeffect of nearby CES construction

For the proposed construction in the NW corner of the CES building (near the 40m BS chamber), they did a simulated construction activity on Wednesday from 12-1.

In the attached image, you can see the effect as seen in our seismometers:

this image is calculated by the 40m summary pages codes that Tega has been shepherding back to life, luckily just in time for this test.

Since our local time PDT = UTC - 7 hours, 1900 UTC = noon local. So most of the disturbance happens from 1130-1200, presumably while they are setting up the heavy equipment. If you look in the summary pages for that day, you can also see the IM lost lock. Unclear if this was due to their work or if it was coincidence. Thoughts?

16966   Thu Jun 30 19:04:55 2022 ranaSummaryPSLPSL HEPA: How what when why

For the PSL HEPA, we wanted it to remain at full speed during the vent, when anyone is working on the PSL, or when there is a lot of dust due to outside conditions or cleaning in the lab.

For NORMAL conditions, the policy is to turn it to 30% for some flow, but low noise.

I think we ought to lock one of the arms on IR PDH and change the HEPA flow settings and plot the arm error signal, and transmitted power for each flow speed to see what's important. Record the times of each setting so that we can make a specgram later

16965   Thu Jun 30 18:06:22 2022 PacoUpdateALSOptimum ALS recovery - part I

[Paco]

In the morning I took some time to align the AUX beams in the XEND table. Later in the afternoon, I did the same on the YEND table. I then locked the AUX beams to the arm cavities while they were stabilized using POX/POY and turned off the PSL hepa off temporarily (this should be turned on after today's work).

After checking the the temperature slider sign on the spectrum analyzer of the control room I took some out-of-loop measurements of both ALS beatnotes (Attachment #1) by running diaggui /users/Templates/ALS/ALS_outOfLoop_Ref_DQ.xml and by comparing them against their old references (red vs magenta and blue vs cyan); it seems that YAUX is not doing too bad, but XAUX has increased residual noise around and above 100 Hz; perhaps as a result of the ongoing ALS SURF loop investigations? It does look like the OLTF UGF has dropped by half from ~ 11 kHz to ~ 5.5 kHz.

Anyways let this be a reference measurement for current locking tasks, as well as for ongoing SURF projects.

Attachment 1: als_ool_06_2022.png
16964   Thu Jun 30 17:19:55 2022 DeekshaSummaryElectronicsMeasured Transfer Functions of the Control Loop, Servo (OLTF); got Vectfit working

[Cici, Deeksha]

We were able to greatly improve the quality of our readings by changing the parameters in the config file (particularly increasing the integration and settle cycles, as well as gradually increasing our excitation signals' amplitude). Attached are the readings taken from the same (the files directly printed by ssh'ing the SR785 (apologies)) - Attachment 1 depicts the graph w/ 30 data points and attachment 2 depicts the graph with 300 data points.

Cici successfully vectfit to the data, as included in Attachment 3. (This is the vectfit of the entire control loop's OLTF). There are two main concerns that need to be looked into, firstly, the manner in which to get the poles and zeros to input into the vectfit program. Similarly, the program works best when the option to enforce stable poles is disabled, once again it may be worth looking into how the program works on a deeper level in order to understand how to proceed.

Just as the servo's individual transfer function was taken, we also came up with a  plan to measure the PZT's individual transfer function (using the MokuLab). The connections for the same have been made and the Moku is at the Xend (disconnected). We may also have to build a highpass filter (similar to the one whose signal enters the PZT) to facilitate taking readings at high frequencies using the Moku.

Attachment 1: TFSR785_29-06-2022_114042.pdf
Attachment 2: TFSR785_29-06-2022_114650.pdf
Attachment 3: TF_OLG_vectfit.png
16963   Wed Jun 29 18:53:38 2022 ranaUpdateElectronicsElectronics noise

this is just the CDS error signal, but is not the electronics noise. You have to go into the lab and measure the noise at several points. It can't be done from the control room. You must measure before and afte the whitening.

 Quote: I measured electronics noise of WFSs and QPD (of the WFS/QPD, whitening, ADC...) by closing PSL and measuring the error signal. It was needed to put the offset in C1:IOO-MC_TRANS_SUMFILT_OFFSET to 14000 cts (without offset the sum of quadrants would give zero, and 14000 cts is the value when the cavity is locked). For WFS that are RF, if there is intensity noise at low frequencies, it is not affecting the measurement. In the attachment please find the power spectrum of the error signal when the PSL shutter is on and off.

16962   Wed Jun 29 14:28:06 2022 PacoSummaryALSALS beat allan deviation (XARM)

I guess it didn't make sense since f_beat can be arbitrarily moved, but the beat is taken around the PSL freq ~ 281.73 THz. Attachment #1 shows the overlapping tau allan deviation for the exact same dataset but using the python package allantools, where this time I used the PSL freq as the base frequency. This time, I can see the minimum fractional deviation of 1.33e-13 happening at ~ 20 seconds.

 Quote: what's the reasoning behind using df/f_beat instead of df/f_laser ?

## Another, more familiar interpretation

The allan variance is related to the beatnote spectral density as a mean-square integral (the deviation is then like the rms) with a sinc window.

$\sigma^2_\nu = 2 \int_0^{\infty} S_\nu(f) \lvert \frac{\sin({\pi f \tau})}{\pi f \tau} \lvert ^2 df$