Under LSC controls, I claimed that we should revert the PRCL loop design, however Gabriele reminded me that the new PRCL design has better suppression, see alog 68817. We should keep this new design, but we should still determine how/if we need to change the gain to ensure the loop UGF is around 30 Hz.

Under LSC feedforward, I forgot to mention that we did not run with PRCL feedforward at 60W, so we can turn that back off at 60W.

I have also recovered the old MICH FF filter that was in FM9, called "May_d". At 60W, we will need to engage FM6-9. labeled May a-d.

We will need to update the violin mode threshhold checker. The counts value for the DARM offset was hard coded, and will be different at 60W. This value will only need to change if we change the DARM offset.

Tagging a lot of the teams who will either need to be involved in these changes, or at least be impacted by these changes when/while we revert.

J. Kissel, J. Driggers, N. Aritomi, S. Dwyer

Just FYI I brought up the open question in Elenna's aLOG about 
    DARM offset: 20 mA, not sure if we want to revert this value

The quick consensus (without agreeing to write it in stone) is that we "plan" to *not* revert the DARM offset, leaving us with 40 mA of current on the DCPDs, as has been the case since May 05 2023 (see LHO:69358).

J. Kissel, J. Driggers, S. Dwyer

Regarding the following setting suggestions in this bullet point,
    SRCL offset: we had been running with an offset of -175. 
    This was also with the previous LSC-POP_RF45 whitening at 21 dB. 
    We could revert the whitening change as well if we think it's better 
    for noise considerations

The plan is to *definitely* go to the -175 ct SRCL offset, however -- upon discussion this morning -- we've decided *not* to revert the reduction in POP A RF45 whitening gain from +21 dB to +15 dB. Said with all positives to avoid confusion, we'll continue to reduce the gain to +15 dB rather than revert to +21 dB.

We think
    - the extra ADC range head room is nice, 
    - the sacrifice in SRCL / PRCL sensing noise is minimal, and/or has minimal impact***
    - for now, today, when we power down, we want to change as little as is need to achieve stability, rather than revert absolutely everything.

***One may find the assessment of the noise impact in LHO:69350.

I forgot to include this in this alog, but the CSOFT P gain should probably be reduced to 20 again. This was a change made late last week.

I've added in a test for PI mode 28 into verbal alarms with an RMS threshold of 1 for now (the same as mode 29).

Just checking in, looks like PI28 does at least see a mode come through ~1-2 hours into lock (RMSMON spikes just before NLN b/c OMC whitening, the second peak is the real one), but this hasn't run away yet. Then ~10 min after PI28, looks like PI29 sees something pass through.

Looking at disaggregated temperature trends across the EX VEA over the last year, it might be a bit misleading to only look at the "average EX VEA" temperature. Temperatures in some parts of the EX VEA seem to have drifted by up to 0.5-2 deg F over the past few months. Temps now seem to be returning to where they were about 6mo - 1 year ago.

I think Robert and Aidan have both made the point that, to understand temperature drifts, it's helpful to look at the individual temperature sensors across the VEA, rather than the average VEA temperature. For example, see Aidan's alog LLO:25785 where he also thought about stabilizing the VEA temperatures to a different sensor, which is better correlated with the test mass temperature. For this 80 kHz PI though, Aidan's also said that the temperature dependence of the mechanical mode freq is about 80ppm/K, so for ~0.5K (delta~1degF), the HOM frequency changes by ~3 Hz for the 80 kHz mechanical mode, and it seems unlikely we're just within 3 Hz of the PI going unstable -- so it's not totally convincing that our recent 80 kHz PI ring ups are simply b/c VEA temperature drifts. But at least, at LLO, he found their ETMY is most correlated with the EY VEA_202B sensor. 

I'm not sure which of LHO's EX VEA sensors are most correlated with ETMX. But, it may be worth considering more than the average VEA temperature. Especially since the individual temperature sensors have seen some drifts over the past year, which aren't seen by trends of the average VEA temperature.

deleted

Here are some plots of the cross correlation for this time.  

The first is a comparison of the pyDARM model of the OLG to the measured OLG. At 24Hz, the model was predicting 2% less gain than the measurement, so here I've scaled the model up by 2% and used that for the estiamtion of the correlated noise. 

The second plot is the DCPD sum ASD loop corrected compared to the cross correlation.  You can see that the cross correlation is above the DCPD sum by 7% at 24Hz, which is incorrect.  I thought about if this could be because of the imbalance of the DCPDs, I will attach a note here that explains how I attempted to handle this imbalance in estimating the cross correlation.  (The DCPD_A and B channels are recorded before mulitplying by the balance matrix, the sum channel is after that matrix.)  In the end this did not make a significant difference, the cross correlation is still nearly 7% overestimating DARM at 24Hz when I corrected for this. 

The third plot shows the cross correlation compared to an estimate of the correlated noise obtained by subtracting the calculated shot noise from the DCPD SUM asd in quadrature, this mostly agrees with the cross correlation except at low frequencies. 

These plots were made using the code https://git.ligo.org/sheila-dwyer/cross-corelation commit 3c60740b  I will attempt to make a comparison of this code with Craig's cross correlation code to see if this problem is still present there. 

Here is a note describing how I corrected for the DCPD imbalance.  Once the matrix was reset as above, things become simple.  I will add a diagram to this note if I have time.

Daniel raised the point that perhaps a phase difference between the two PDs could explain a discrepancy at low frequency, in the correction I did I assumed that the two paths were only imbalanced by a scalar gain. The attached png shows a transfer function between the two DCPD channels, taken at the time of one of yesterday's broadband pcal injections. The frequency dependence of this at first glance doesn't seem right to explain what we see, ie, the error in the cross correlation doesn't have a wiggle between 20-30 Hz, although the error does seem to happen around the frequency of the cross correlation problem.

My motivation for this test came from a bruco that I ran on the data from a long lock over the weekend: https://ldas-jobs.ligo-wa.caltech.edu/~elenna.capote/brucos/CAL_1370343461/

Specifically, the CHARD P, INP1 P and HAM1 TT L4C RY coherence were much higher than expected, and much higher than they had been in the past after successful HAM1 FF tuning and A2L gain adjustments.

The test first confirmed that we are still seeing decent subtraction of the HAM1 noise from the ASC loops, as seen in an OMC DCPD sum comparison with the feedforward on and off. I also grabbed spectra of each of the ASC loops with the feedforward on and off (in this plot the red, live traces are with the feedforward off, and the blue reference traces are with the feedforward on).

I used the feedforward off time to run the NonSENS training code and calculate a new feedforward for CHARD P, INP1 P and PRC2 P. The code also makes plots of the expected subtraction of the loops. I compared the expected subtraction plots (linked below) to the current subtraction plots linked above, and I conclude that:

• CHARD P feedforward currently is subtracting about as much as the code predicts, so an update of the feedforward will likely not change much
• PRC2 P is not subtracting as much as it can, and should be updated. This update might help
• INP1 P is almost not subtracting at all, but the code predicts it could subtract much more, so this should be updated

I didn't check any yaw loops because there is already decent noise removal, and coherences are low. I don't expect to see much improvement there.

I will install the new INP1 P and PRC2 P feedforward filters, labeled with today's date. I think they should be engaged for the next lock if possible.

I don't understand why the coupling has changed, but I think this is a similar mystery change that changed like several other things in the IFO changed recently- perhaps some new alignment from the PR3 move? In other words, unless we have to make another big alignment change like that, I don't expect us to need to update this feedforward for a while.

Turning off the HAM1 feedforward made the CHARD and PRC2 noise signficantly larger, by about a factor 10. The effect on DARM is significant, and consistent with the fact that CHARD or PRC2 are coupling more now than before, and when the FF was on were just below the measured DARM. This is consistent with the measured coherence between DARM and CHARD or HAM1 sensors.

One possible reason for the higher coupling of HAM1 noise to DARM is that the beam spot might have moved on PR2 (where PRC2 is driven) and therefore the A2L we tuned some time ago might be wrong. It's worth and quick retuning the PR2 A2L and see if that improves the coupling of PRC2 to DARM and maybe even DARM noise.

The new filters have not yet been installed because I am getting errors from foton when I try to copy them in. I will try again tomorrow.

I have installed the new feedforward filters for INP1 and PRC2. They are labeled with "0616" for today's date. They are currently not in use, but can be quickly tested during a commissioning period. A thermalized IFO is best for the test, but they can be tried at any time.

New filters implemented and SDFed.

Here are the plots of ASC-AS_C_NSUM, OMC-QPD_A_NSUM, OMC-QPD_B_NSUM and OMC-REFL_A_LF, during these measurements. ASC-AS_C_NSUM shows between 22.8 and 32.1mW, OMC-QPD_A_NSUM 23.4mW, OMC-QPD_B_NSUM 23.0mW, and OMC-REFL_A_LF 24.8mW. According to Keita OMC-REFL_A_DC has an incorrect calibration and shows 25.2mW. The average of the 2 QPDs would be 23.2mW, which is about 6.5% lower than 24.8mW.

Second screen shots shows a time when the IMC was unlocked. The DC offsets are in the 10s of uW at most.

Using data from the scan I adapted labutils/OMCscan class to plot the fitted scan and adapted labutils/fit_two_peaks.py to fit a sum of two lorentzians functions for distinguishing carrier 20/02 modes.

The first graph is the OMC scan plot, the second is the curvefit for the second order carrier modes.

We expect the HOM spacing to be 0.588 MHz as per this entry and DCC T1500060 Table 25.

The spacing for the modes measured is 0.592 MHz.

From the heights of the two peaks this suggests mode-mismatch of the OMC to be C02+C20/C00 = (0.83+1.158)/(15.32+0.83+1.158) = 11.0% mode mis-match.

From the locked/unlocked powers on the OMC REFL PD the visibility on resonance is 1-(3.51+0.03/24.73+0.03) = 85.7% visibility.

If the total loss is 14.3%, this implies that the other non mode-matching losses are roughly 1.3%.

To run the OMC scan code go to 

/ligo/gitcommon/labutils/omc_scan/ and run 

python OMCscan_nosidebands.py 1370712036 100 "Sidebands off, 10W input" "single bounce" --verbose --make_plot -o 2
in the labutils conda environment and on git branch dev.

To do the double peak fitting run:

python fit_two_peaks_no_sidebands.py  
in the labutils conda environment and on git branch dev.

These scans were done with OM2 cold.

For comparison with new OMC measurements I used Sheila's code to process the visibility, but updated dit to use nds2utils instead of gwpy as I was having trouble using it to get data.

The code is attached and should be run in the nds2utils conda environment on the CDS workstations.

Power on refl diode when cavity is off resonance: 24.757 mW

Incident power on OMC breadboard (before QPD pickoff): 25.239 mW

Power on refl diode on resonance: 3.525 mW

Measured effiency (DCPD current/responsivity if QE=1)/ incident power on OMC breadboard: 70.4 %

assumed QE: 100 %

power in transmission (for this QE) 17.760 mW

HOM content infered: 13.472 %

Cavity transmission infered: 82.111 %

predicted efficiency () (R_inputBS * mode_matching * cavity_transmission * QE): 70.367 %

omc efficency for 00 mode (including pick off BS, cavity transmission, and QE): 81.323 %

round trip loss: 1605 (ppm)

Finesse: 371.769