TITLE: 07/24 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 1mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.06 μm/s
QUICK SUMMARY: Locked for 13 hours. Temps look good, no alarms, calm environment. Planned calibration and commissioning time today from 1500-1930UTC (0800-1230PT).
TITLE: 07/24 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 148Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: One lockloss with an automated recovery. We've been locked for 3.5 hours.
LOG: NO log.
These are the remainder of the noise comparison plots for before and after the sat amp swaps for TMSX and ETMX M0/R0/L1. These swaps were done for TMSX, ETMX M0/R0/L1, MC2, and PR2 on July 15 (85770). I posted noise comparison plots for MC2 and PR2 (85786), but we didn't yet have a good 'after' time where End X wasn't in maintenance, going through an earthquake, or moving stuff around for relocking. Now we have had a good time stretch, so here are the results:
Note: For ETMX L1, there are no DAMP channels, so instead I looked at the WIT_{L,P,Y} channels. Not sure how accurate these are. The edits to make this possible in the script /ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/damp_regression_compare.m have been svn'd as r12483
TMSX
Results
/ligo/svncommon/SusSVN/sus/trunk/TMTS/H1/TMSX/SAGM1/Results/allDampRegressCompare_H1SUSTMSX_M1_NoiseComparison_1435150628vs1437199319-1200.pdf
r12479
Data
/ligo/svncommon/SusSVN/sus/trunk/TMTS/H1/TMSX/SAGM1/Data/dampRegress_H1SUSTMSX_M1_1435150628_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/TMTS/H1/TMSX/SAGM1/Data/dampRegress_H1SUSTMSX_M1_1437199319_1200.mat
r12479
ETMX
M0
Results
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Results/allDampRegressCompare_H1SUSETMX_M0_NoiseComparison_1435060998vs1436769334-1200.pdf
r12480
Data
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/dampRegress_H1SUSETMX_M0_1435060998_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/dampRegress_H1SUSETMX_M0_1436769334_1200.mat
r12480
R0
Results
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Results/allDampRegressCompare_H1SUSETMX_R0_NoiseComparison_1435060998vs1436769334-1200.pdf
r12841
Data
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/dampRegress_H1SUSETMX_R0_1435060998_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/dampRegress_H1SUSETMX_R0_1436769334_1200.mat
r12481
L1
Results
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGL1/Results/allDampRegressCompare_H1SUSETMX_L1_NoiseComparison_1435060998vs1436769334-1200.pdf
r12482
Data
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGL1/Data/dampRegress_H1SUSETMX_L1_1435060998_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGL1/Data/dampRegress_H1SUSETMX_L1_1436769334_1200.mat
r12482
00:08 UTC lockloss after only 4 minutes, wiggle in PR_GAIN right before we lost lock
PRC2 and CSOFT Yaw stepped out right before the LL. TMSX_Y started to oscillate 4 seconds before the LL, PM1_Y had an excursion ~3 seconds before the LL.
Looking at all the suspicious things together, it looks like TMSX_Y started moving first before any of the ASC loops? Only ~100ms before CSOFT started moving.
TITLE: 07/23 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Two lock losses and a longer recovery for the second thanks to an earthquake. We are on our way back right now, locking DRMI.
LOG:
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
21:06 | SAF | LVEA IS LASER HAZARD | LVEA | Y | LVEA IS LASER HAZARD | 22:03 |
16:15 | CDS | Fil, Marc | MY | n | Pick up from H2, drop off at MY | 16:52 |
17:14 | - | Betsy | Opt Lab | n | Parts and such | 17:43 |
20:13 | - | Randy | EX | n | Checking in lab space | 20:49 |
TITLE: 07/23 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 18mph Gusts, 12mph 3min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY:
No immediate, obvious cause.
I'm followed the pydarm deployment instructions here, to update the LHO pydarm install. This is the 20250723.0 tag for pydarm, which includes an option to not generate the broadband vs sweep vs uncertainty budget plot. This is intended to be only used if for some reason NDS is unable to serve the H1:GDS-CALIB_STRAIN data used in the plot, which would crash or hang the code. If NDS is having issues, a problem report should be made to the CDS group. This is not the default cds conda environment, but the default you get when typing pydarm at a command line, or specifically invoking by running "conda activate /ligo/groups/cal/conda/pydarm".
Lockloss at 2025-07-23 18:15 UTC after almost 5.5 hours locked
Writting this down for tomorow because we may have to repeat this at some point. We'd like to get a cross correlation measurement to high frequency when the IFO has been thermalized for 4+ hous. Tomorow we can do this earlier in the lock if need be to make sure that everything works.
From sitemap OMC > DCPD TEST (at the bottom of list), open the INMTRX circled here, add a 1 where shown here
Take SQZ_MANAGER to NO_SQUEEZING
cd /ligo/home/sheila.dwyer/Noise_Budget_repos/quantumnoisebudgeting
open dtt template in /data_files/higher_order_modes.xml run it at roughly the same time that you run this script adapted from Elena 85817
conda activate labutils
python get_OMCDCPS_524kHz.py
save the dtt template when finished.
Side note, it seems that we can only access two of these 524kHz test points with the script, and also only two at a time with dtt. So we will use dtt to save the sum spectra and the script to save the inidividual PDs.
The python script wouldn't run at first, narrowed it down to the channels it uses. Since these are test points, they were already opened by something else and so the script couldn't use it. I had to clear the test points, via "diag -l -c" then "tpclear 179 *" then it would run. The script and dtt were run at 821PT and saved in the same template.
Wed Jul 23 10:09:09 2025 INFO: Fill completed in 9min 5secs
Richard confirmed a good fill via camera.
In 85846 on Friday 18th, Elenna notes a lockloss after YAW ASC excursion, we have been having very short locks and I see evidence of two more of these yaw excursion in the last 24 hours:
Seen in CSOFT, SRC1, PRC2 and mainly on the L2 stage of quads. In the last 1-2 seconds before LL.
The lockloss that Ryan S. reports as being from a sitewide power glitch in this alog had a similar behavior in the suspension channels and yaw loops. Apparently the power glitch that caused the lockloss also tripped the HEPI pumps, but I'm not sure how that relates to the control loop behavior. I'm not sure if this is useful to link with these other locklosses or not.
Generally, every yaw ASC loops sees this behavior, but it's hard to tell what is moving first, or the most, since the channels are not calibrated into useful units. As a note, the soft loops are not DC coupled, so I imagine they are just following the other loops. Our lockloss scopes plot the very slow ASC channels, so here is a faster plot of some of the ASC channels before one of these locklosses. The centering loop signals are moving away from zero, but not large enough that the beam is at the edge of the WFS.
I broke out my old TMS servo scope to see if we are being pulled off the TMS QPDs. Clearly the X TR B yaw signal is increasing, but it may be because it's trying to follow a large movement in the hard loops. TMS X yaw moves about 1 urad before the lockloss as well.
In the first yaw excursion lockloss Camilla notes above, the ETMX HEPI RZ appears to oscillate in the two seconds before lockloss. I don't see that in the other yaw excursion lockloss though.
Both of these YAW ASC locklosses saw TMSX_Y start oscillating a few seconds before the lockloss.
Follow up to add that although the lockloss that Ryan S noted on 7/13 had an ASC excursion, the TMSX yaw suspension did not have the similar strange behavior that these other few locklosses have (ndscope). It's possible that this TMSX yaw behavior is linked to the sat amp change on 7/15, 85770.
This work was completed with help from Sheila Dwyer, Derek Davis, and Vicky Xu.
Sheila and Oli took 3000 seconds of no squeezing data on June 25 which I have used to run a correlated noise budget. This alog is long, but it details my methods to take this measurement while accounting for glitches, excess jitter noise and unsubtracted noise. I then discuss generating a noise budget using this data, and investigate the thermal noise level. There are many great background references for how the correlated noise is measured, but one of my favorites is Martynov et al. (2017).
I used the OMC DCPD A and B channels at 16 kHz, so this alog focuses on the correlated noise up to 5 kHz. Sheila is currently working on correlated noise measurements at higher frequency using the full-rate DCPD channels.
Executive summary:
These results show that above 1 kHz, the correlated noise is well-estimated by jitter noise from 1-2 kHz and our current frequency noise projection from 2-4 kHz. Above 4 kHz it appears we are overestimating the frequency noise, something that we could improve with a model of the CARM loop. Above 2 kHz, the frequency noise level is roughly a factor of 6-7 below DARM in amplitude. Jitter peaks are within a factor of 2-3 in amplitude from 1-2 kHz. The classical noise floor from 100-300 Hz appears similar to coating thermal noise with an amplitude that is 35% higher than our noise budget estimates. Below 100 Hz, we have not fully estimated our classical noise in the budget.
Jitter subtraction:
From 100-1000 Hz, I was able to use a strong jitter injection to estimate a transfer function and subtract the jitter noise from OMC DCPD A and B using IMC WFS A yaw as a single witness. The subtraction performed fairly well, with the exception that it injected a large peak just above 300 Hz where the jitter noise injection coherence dropped. I was also unable to get a strong enough measurement of the jitter coupling above 1 kHz so two broad jitter peaks remain in the data from 1-2 Hz. I applied a 1 kHz low pass to the subtraction to ensure that I only subtracted in the region with a high-fidelity measurement of the jitter transfer function.
Calculating the correlated noise:
I used a function written by Sheila and Vicky that applies the DARM OLG and sensing function using pydarm and the calibration model. The DARM OLG is applied to the correlated noise calculation using a formula written by Kiwamu Izumi in T1700131, equation 10. The resulting noise is calibrated into meters using the sensing function. I applied this correlated noise estimation method to the DCPD signals with and without jitter subtraction.
Managing bias from glitches:
Since the correlated noise budget requires taking a long data set, it is likely that the data will capture glitches which can bias the PSD and CSD estimates for the calculation, and possibly inflate the noise estimate. There are several methods that can be used to overcome this bias (gating, median averaging, etc). First, I found it useful to plot a whitened timeseries of each DCPD using the gwpy whitening function. This made it evident that there was one large glitch about halfway through the dataset. The gwpy gating function identified a 2 second period over which to gate. However, since the gating period was of a similar length to my fft length, I ended up choosing to reject the fft segments that included the glitch completely. I took a mean average of the remaining fft segments for the PSD and CSD estimates. Note that my method includes no overlap, which loses some resolution, but makes this calculation easier.
Accounting for unsubtracted incoherent noise:
For 3000 seconds of data, an fft length of 2 seconds, and two rejected PSD segments, the total number of averages is 1498. The largest possible amount of noise reduction in this method is sqrt(sqrt(1498)) = 6.2. This is sufficient to resolve the classical noise below 1 kHz, but not above. There are a few ways to improve the resolution for a fixed length. One is to reduce the fft length further to increase averages, since less frequency resolution is required at high frequency anyway (this is only useful if you don't care about your low frequency resolution). This plot shows a test of that, using different fft lengths for the same data length, with incoherent noise reduction ranging from a factor of 4.1 (fft length 10 s) to 8.8 (fft length 0.5 s).
You can also compare the correlated noise of the DCPDs (XCOR) with the noise in DCPD sum (SUM). The difference between these two noise estimates is the reduction of the incoherent noise (n), achieved in the correlated noise by the known factor of the number of averages (N). In other words, both noise estimates contain the same amount of classical noise (c).
SUM = c + n
XCOR = c + n/sqrt(N)
c = (XCOR - SUM/sqrt(N)) / (1 - 1/sqrt(N))
Without sacrificing the frequency resolution below 1 kHz, we can measure the classical noise above 1 kHz by accounting for any un-reduced incoherent noise. I compare a correlated noise estimate using this formula with my shortest fft length from above. For the rest of this post, I refer to this as the "full classical noise estimate"
Therefore, this work includes three different estimates of the correlated noise, one without jitter subtraction, one with jitter subtraction from 100-1000 Hz, and one with jitter subtraction and the application of my equation above. This plot compares these estimates with the unsqueezed DARM (aka SUM). All of these estimates use what I am referring to as the "excised mean average", which is the process I detailed above of excising ffts with glitches and mean-averaging the remainder.
Creating the noise budget:
I then added some of our noise budget traces: thermal noise, laser noise (frequency and intensity), controls noise (ASC and LSC), residual gas noise, and a correlated quantum noise trace generated using SQZ parameters from Sept 2024 (some likely out of date). Comparing these traces, it is evident that we have a large gap between our full classical noise estimate and our estimate of our known noises. First noise budget plot here
Evan Hall and Kevin Kuns did a similar exercise using pre-O4 data, alog 68482, and calculated that the thermal noise is approximately 30% higher than our estimate. I find a similar result using the jitter-subtracted correlated noise- the noise level from 100-300 Hz matches well with a thermal noise that is about 35% higher than our noise budget estimate, here is a ratio of the full classical noise estimate with the CTN estimate. I also find that the noise in this region is fairly gaussian. For example, I plotted the distribution of the ffts of the jitter-subtracted correlated noise at 105 Hz and their distribution matches a chi-squared distribution with two degrees of freedom (of course, this ignores the two outlier fft segments that contain the glitch). I referenced Craig Cahillane's dissertation appendix D: the PSD sample mean for gaussian noise with n samples follows a chi-squared distribution of 2n degrees of freedom. This should at least help convince us that the noise level here isn't being biased by some non-gaussian source; this was a concern that Vicky and I had when generating the correlated noise budget in the O4 detector paper.
I also recreated the noise budget with the thermal noise trace inflated by 35% here. Except for some unsubtracted jitter noise that I did not include in the budget, this effectively reconciles the correlated noise budget above 100 Hz.
These results show that we have also underestimated the noise below 100 Hz. It is not clear to me yet how much of that noise can be explained with a better estimate of the correlated quantum noise. Sheila and I are hoping to use some of the parameters she is generating from her sqz modeling to calculate possible lower and upper bounds of the correlated quantum noise and compare them with the entire correlated noise budget.
As another follow up on the gaussianity of the data, I made a spectrogram of the rayleigh statistic of each DCPD signal. Based on my (relatively new) understanding of the rayleigh statistic, I believe these plots are indicating that the DCPD data is fairly gaussian in the broadband, with one large glitch about halfway through the data set. This is the glitch that I discuss excising above.
And here is a text file that contains the frequency vector and correlated noise ASD (the red trace in this plot) in units of strain.
I am adding a comment to clarify that the thermal noise budget uses a Ti:Ta loss angle of 3.89e-4 rad, in line with the Gras 2020 paper, to calculate the coating thermal noise. My 35% increase estimate is therefore 1.35 * 1.13e-20 m/rtHz (at 100 Hz) = 1.52e-20 m/rtHz (at 100 Hz).
The O4 detector paper includes a full demonstration of the thermal noise budget, where the thermal noise is dominated by coating brownian noise, which is determined partially by the Ti:Ta loss angle. Therefore, I am assuming that if the overall thermal noise is higher by 35%, it is because the coating thermal noise is higher by 35%. I didn't make any fit of the slope, but the ratio of the noise with the thermal noise trace is fairly flat from 100-300 Hz.
Elenna noticed that pimon that we run on nuc25 hadn't been consistently saving data. There were large periods of time that didn't have anything recorded. I first verified that it would still write log and npz files, then I redirected them to /ligo/data/pimon/locklosses/ where it will now put all of the npz files. Elenna also asked that the script saves the time series and not the PSDs, so I made that change as well. I'm not sure the file size difference, the PSDs were about 3.6Mb, so we should keep an eye on that and get rid of old ones.
Operators, please verify that pimon is running on nuc25, and restart it if necessary. The normal launch script will start it up.
Apparently, it struggles to save the time series data and will freeze up. I've changed it back to only save the PSDs on lockloss and we'll see if it survives better.
A partial continuation of showing the characterization of the OSEM noise before versus after the satellite amplifier swaps. Today, PR2, MC2, TMSX, and ETMX M0 R0 L1 were swapped out (85770), but here I am only showing the comparison plots for PR2 and MC2. I will have to wait until we have a longer period of being in DOWN before I can get good comparisons for TMSX and ETMX because there has not been very much time after the swaps where we weren't locking or where the seismic environment wasn't set to maintenance, which results in a ton of extra noise that isn't able to be properly regressed out.
Here are the previous comparisons: 85485, 85699
PR2
Results
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PR2/SAGM1/Results/allDampRegressCompare_H1SUSPR2_M1_NoiseComparison_1435154988vs1436654703-1200.pdf
r12453
Data
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PR2/SAGM1/Data/dampRegress_H1SUSPR2_M1_1435154988_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PR2/SAGM1/Data/dampRegress_H1SUSPR2_M1_1436654703_1200.mat
r12453
MC2
Results
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/SAGM1/Results/allDampRegressCompare_H1SUSMC2_M1_NoiseComparison_1436631330vs1436638358-1200.pdf
r12454
Data
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/SAGM1/Data/dampRegress_H1SUSMC2_M1_1436631330_1200.mat
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/SAGM1/Data/dampRegress_H1SUSMC2_M1_1436638358_1200.mat
r12454
The comparisons for the rest of this swap set (TMSX, ETMX M0/R0/L0) have been posted as 85952