Gabriele refit the 11/15 LSC FF data 74220, allowing a higher magnitude at low frequency to give us a better fit, fit attached. I lowered the Q of the 17.7Hz feature and added this filter to MICHFF FM8 as "11-15-23B". We'll want to turn this FF slowly or before Tuesday Maintenance, as the excess low frequency could cause instability.
Plot attached, red is current MICHFF FM7, blue is new FM8 (double the strength of current FF <8Hz), green is Gabirele's original design before adjusting Q of 17.7Hz feature (all including the high pass filter in FM10).
I lowered the 17.7Hz Q's by a factor of 4 from the original design, to minimize effect on KAPPA_TST error 74259:
Turning this FM8 MICHFF on 2023/12/05 16:07:00 UTC to 2023/12/05 16:09:00 UTC, did not cause a lockloss. Comparing to 2 minutes before with current MICHFF FM7 16:02:00 UTC to 2023/12/05 16:04:00 UTC, DARM looks better with new FF but this was only a couple of minutes into NLN when the ADS lines were turning off, low frequency DARM shows no obvious change. As this new FF has higher gain at low frequency, you can see this as a factor of ~5 higher output on MICHFF_OUT, trend attached.
R. Short, with guidance from K. Kawabe and J. Oberling
I've made some updates to the 'CLOSE_ISS' state in the IMC_LOCK Guardian, which handles the closing of the ISS second loop, that should make the closing of the second loop more consistent.
When the second loop is engaged, the DC working point of the ISS is determined by the output of the second loop's digital AC coupling (H1:PSL-ISS_SECONDLOOP_AC_COUPLING_DRIVE). This output is held when the second loop is closed, but it can occasionally be held far from the average of its oscillations before the second loop is engaged, which in the past has caused locklosses and was mitigated earlier this year (see alog 67347). While the second loop isn't causing locklosses anymore (that I can recall), we do still see the digital AC coupling output being held slightly off from the mean, causing the diffracted power to jump. I've expanded upon Georgia's logic by changing the way the output of the AC coupling drive is held to be more consistent. Instead of waiting to hold the output until it's near the mean over the past 10 seconds (a calculation that itself can take several seconds), the process is now as follows:
I was able to test this logic during the maintenance period today, both with the IMC locked at 2W and 60W, with great success. We'll run with this for a while to see if over several lock acquisitions the second loop is being engaged with a more consistent digital AC coupling drive. The updated IMC_LOCK Guardian code is loaded and committed to SVN.
I added roughly 5 meters of LMR 195 to the cable sending the 3MHz local oscillator to the demod for the OMC 3MHz signal. This should add roughly 21ns of delay, or roughly 23 degrees of phase for the 3MHz signal.
We are hoping that this will shift the turn around point of the ADF sqz angle readback so that our operating point is at a better place to use this readback to adjust the sqz angle. (for background see 74256
This means we will need to retune the SQZ angle before we to observing today.
The SQZ angle will have to be retuned when we relock today. To do this, from the sitemap choose SQZ > SQZ overview to pull up the scren shown in the screenshot. You can then adjust the slider circled in red (H1:SQZ-CLF_REFL_RF6_PHASE_PHASEDEG) looking at the FOMs on NUC33 to tune the squeezing. Try to minimize the black trace on the spectrum on the bottom of NUC33.
Maintenance tasks have wrapped up but team CDS and SEI are trying to solve a problem that showed up at 19:29UTC on EndX where we lost all SEI signals (went to exactly zero). Microseis remains elevated, above the 90th percentile for the past ~16 hours and based on its trend visually it will probably take another 6 hours to get fully below that mark.
Once this issue is resolved we will resume attempting to lock.
Fil Daniel
PMC install preparation:
Auxiliary Signals Concentrator 11 PD Monitors (D2300326) installed in SQZ-R2, slot U3.
Serial Number: S2300254
Tue Nov 21 10:14:21 2023 INFO: Fill completed in 14min 16secs
I grabbed an ETMY OPLEV charge measurement this morning before the cleanroom work started.
TITLE: 11/21 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.93 μm/s
QUICK SUMMARY:
Workstations were updated and rebooted. This was an OS package update. Conda packages were not affected.
H1 called for assistance this morning at 10:13 UTC when the 40 minute initial alignment timer expired; it looks like following the earlier lockloss, H1 was struggling to lock (I suspect due to the very elevated secondary microsiesm, plot attached) and started an initial alignment. It took a while to align the arms in green, which caused IA to take longer than usual. I responded to the call right as the SRC was finishing its alignment (IA finished on its own), but when I selected 'INIT' to clear the alert on H1_MANAGER, this caused H1_MANAGER to jump to the 'RELOCKING' state and requested ISC_LOCK to start initial alignment over again. I didn't realize this until IA was a good way through, so I decided to let it finish (meaning IA was run twice in a row). I imagine one could add a check into H1_MANAGER to not re-request an initial alignment if one is already underway to avoid restarting the alignment process when an alert is acknowledged.
Following the most recent IA, H1 has been relocking smoothly and is currently up to POWER_10W.
TITLE: 11/21 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
The entire night was very quiet... until:
07:59:44 UTC LOCKLOSS.... yes it was 16 seconds before my shift ended. There was an earthquake passing through at the time but it was a very small earthquake.
Microseism is still elevated.
ALS-X and ASL-Y guardians were reloaded.
IFO Current Status: Increase Flashes.
LOG:
No log
TITLE: 11/21 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 159Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: SEISMON_ALERT
Wind: 12mph Gusts, 9mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 1.01 μm/s
QUICK SUMMARY:
Incoming 5.5M Earthquake in the central mid atlantic ridge.
Microseism had been climbing back up for the last few hours too.
PSL_FSS_TPD: RefCav transmission low, fix alignment message on DIAG_MAIN now.
Otherwise, Very Quiet night. Locked for 13 hour and 48 Min. OBSERVING.
Over the weekend we've been having some trouble with low ALSX beatnote and other ALS issues causing locking trouble (See 74310, 74289). There was also a XVEA temperature change that happened Friday evening (picture here). Looking back at past changed of the ALSX laser we have June 30th alog70976 which had similar symptoms and was maybe fixed with a laser current and temperature change. Before that in Aug 2022 Daniel (alog64752) did a similar fix.
Plots attached have a dozen ALSX channels trended over 3.5years, 2years, 21 months, 65 days. The only bit that stands out to me is that the green power has started to trend down ~20 days ago, but it's a small amount (0.83 -> 0.80mW).
Artem, Gabriele, Sheila, Louis Plots and Jupyter notebook with these results are also available here.ESD quadratic noise
This is a follow up on investigation of potential non-stationary noise at Handford introduced by the ESD drive, reported in 73913 and previous entries linked from there. The idea is that from the ESD signal, Vs, and bias, Vb, voltages we can reconstruct ESD force applied to the mirror, using equations in LIGO-T1700446. The force component linear in Vs gets subtracted by the control loop and therefore does not affect DARM. But the force component quadratic in Vb and both linear and quadratic in Vb can couple to DARM. Therefore in this report, we are calculating respective force components and projecting them to DARM. Then respective ASDs and spectrograms are compared.Selection of input channels
The ESD drive voltages are recorded by Monitors, H1:SUS-ETMX_L3_LVESDAMON_LL_OUT_DQ for Vs and H1:SUS-ETMX_L3_ESDAMON_DC_OUT_DQ for Vb. Important note here: we initially tried channel H1:SUS-ETMX_L3_ESDAMON_UL_OUT_DQ to get Vb, but it looks like it's not connected to anything and recording ASD noise... The H1:SUS-ETMX_L3_ESDAMON_DC_OUT_DQ seems to be fine. Also, LIGO-T1700446 specifies calibrations for voltage channels (equations 13 and 16), but currently the channels mentioned above are already calibrated to voltage.![]()
Calculating force terms
Calculation is based on equation 3 in LIGO-T1700446, but this equation is modified in the following way:
I did the same exercise but now for GPS time 1382909598 (and up to +22 mins from it), where bias voltage was set at 409V. Below you find plots where you can see that noise went up* (ASD) but apparent non-stationarity is reduced (spectrograms), which is consistent with Gabriele's findings in comment in 73935, specifically this and this plots.![]()
* Currently noise ASD is actually higher than DARM, this is not realistic but the modelling is not 100% precise. What is important here is relative changes with respect to results with "standard" level of bias voltage. Plots and Jupyter notebook with these results are also available here.
Another way to look at ESD quadratic noise. The DARM strain band-limited RMS (computed between 16 and 30 Hz and normalized to the median over time) is correlated to the total RMS of the ESD drive (dominated by the low frequency component, below 10 Hz)
TITLE: 11/21 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 9mph Gusts, 6mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.64 μm/s
QUICK SUMMARY:
Current Status of H1: Locked for 8 hours 29 minutes and OBSERVING.
I will reload ALS-X and Y if a lock loss happnens to load in Mr. Crouch's Changes.
TITLE: 11/21 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Observing and Locked for 8.5 hours. Been a quiet day.
LOG:
16:00UTC In NOMINAL_LOW_NOISE, I rejected the ASC-X_FIBR_LOCK_BEAT_RFMIN value change of -10 so it is still at -20dB, and put us into Observing.
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 18:51 | FAC | Randy | EX | n | Delivery | 20:21 |
| 19:24 | FAC | Chris, locksmith | OSB, EY, EX | n | Changing external locks | 22:28 |
Naoki, Sheila
In the AS72 sensing matrix measurement in alog74106, Daniel suggested to increase the whitening gain of AS72 since it could be limited by ADC noise. We checked the whitening filter of AS72 A and B. Both of them have 12dB whitening gain, but one stage whitening is engaged for AS72 A, while two stage whitening is engaged for AS72 B. We decided to engage the 2 stage whitening for AS72 A, which is used in SRC1. The IFO locks without any problem with this additional whitening. We accepted some SDFs as shown in the attached figures. We will try to increase the whitening gain later.
I think the attached plot shows this was a good idea. I have some old data measuring whitening and no whitening on at RF72, but I never posted it because I couldn't figure out the correct RF72 transimpedance. The attached plot shows an estimation of the ADC noise level comparison with the noise spectrum in lock. Naoki and Daniel were kind enough to help me figure out the proper transimpedance for the RF72 (see 37065).
The measurement procedure and calculation procedure is detailed in alog 66734. At the time, RF72 was using 1 stage of whitening with 12 dB whitening gain.
I think it's likely my shot noise calculation here is incorrect. Correcting that calcuation is in progress...
During Tuesday maintenance and IMC_LOCK is OFFLINE, I measured the AS72 dark noise with different whitening setting. The attached figure shows the dark noise of AS72 A Q PIT/YAW, which are used in SRC1. The 2 stage whitening and 12 dB whitening gain are the current nominal setting. In the previous Elenna's measurement, there was a bump around 25 Hz, but there is no bump in today's measurement.
I went back and forth (~5 mins each) with the BS M2 coil drivers between their nominal low noise state, and their higher noise higher range state.
When in the higher noise state (state 2), there seems to be consistently higher noise between about 55 Hz up to 100 Hz. In the attached plot the blue / green is the nominal low noise state, while red / pink is the high noise state.
I'll work on making this an actual noise projection that we can include in the noise budget, using Craig's code for quad PUM noise as a guide.
We were in the high noise state 2 from 20:56:45 - 21:04:00. Then in low noise state from 21:06:10 - 21:11:15 (there's a glitch during this time). Back to high noise from 21:13:20 - 21:19:40 (there's a small glitch during this time). Back to low noise from 21:21:50 - 21:28:00. All times UTC on 8 Nov 2023. After this I handed back to Robert.
I've finally had a look at projecting this noise to what it looks like in our nominal state.
I'm 'following along' the philosophy of Craig's quad coil driver noise projections in https://git.ligo.org/aligo_commissioning/labutils/-/blob/master/coil_drivers_state_switch/plot_all_quad_pum_switch.py
I take an average of the ASDs of the noisy time (blue trace), and an average of the nominal quiet time (orange trace), then subtract them to get the excess power (green trace). I then take the residual excess power, and divide by the ratio of filters that are different between the two times, and that gives the projection of this excess power to our nominal state (red trace).
The attached plot shows that the projected noise (red) is more than a factor of 100x below our nominal sensitivity (orange), so BS M2 coil driver noise should not be an (immediate) issue for us.
The notebook is in /ligo/home/jenne.driggers/LHO_work/2023_11_21_BS_coil_driver_noise_budget/BS_coil_driver_noise_projection.ipynb