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.
TITLE: 07/23 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 149Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 6mph Gusts, 2mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY: Locked for 1.5 hours, a few automated lock losses and reacquisitions over the last shift. Plans for today are...Observing!
TITLE: 07/23 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: Two locklosses, we're still coming back from the second one. We just lost it at CARM_OFFSET_REDUCTION at 04:57.
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 |
23:47 | CAL | Tony, Rick | PCAL lab | LOCAL | Checks | 00:26 |
03:50 UTC lockloss
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.
00:28 UTC lockloss potentially from a 5.5 from the eastern Russian peninsula.
02:46 UTC Observing
WP12691 Install production GC/CDS network switch
Jonathan, Nyath:
The production Juniper GC/CDS network switch was installed and the temporary Brocade switch removed. The control room phones were transferred one at a time to verify the switch port configuration.
WP12690 Vacuum HAM1 Ion Pump Readout
Gerardo, Patrick:
For the past few months the IP13 EPICS channels have actually been reading out IP1_B's signals, and IP7_A which has actually been reading out the new IP13 signals.
Patrick made the internal hardware mapping Beckhoff changes on h0vacmr to map IP13 with its signals.
In the new system there is no IP7, but we elected to keep these channels in place so that recent HAM1's Ion Pump data can be trended using the IP7_A chans.
Attached plot shows IP13 (blue) transistioning from IP1_B (orange) to IP7_A (green)
WP12689 Add two 512Hz fast channels for HLTS PR3,SR3
Jeff, Brian, Edgard, Oli, Dave:
This morning we started updating the h1suspr3 and h1sussr3 models but the number of DAQ changes was significantly more than the expected two additional fast channels per model so we needed to review the changes in detail. Here is what I found
In sus/common/models three files were changed (svn version numbers shown):
HLTS_MASTER_W_EST.mdl production=r31259 new=32426
SIXOSEM_T_STAGE_MASTER_W_EST.mdl production=r31287 new=32426
ESTIMATOR_PARTS.mdl production=r31241 new=32426
HLTS_MASTER_W_EST.mdl:
only change is to the DAQ_Channels list, added two chans M1_ADD_[P,Y]_TOTAL
SIXOSEM_T_STAGE_MASTER_W_EST.mdl:
At top level, change the names of the two ESTIMATOR_HXTS_M1_ONLY blocks:
PIT -> EST_P
YAW -> EST_Y
Inside the ADD block:
Add two testpoints P_TOTAL, Y_TOTAL (referenced by HLTS mdl)
ESTIMATOR_PARTS.mdl:
Rename block EST -> FUSION
Rename filtermodule DAMP_EST -> DAMP_FUSION
Rename epicspart DAMP_SIGMON -> OUT_DRIVEMON
Rename testpoint DAMP_SIG -> OUT_DRIVE
DAQ_Channels list changed according to the above renames.
DAQ Changes:
This results in a large number of DAQ changes for SR3 and PR3. For each model:
+496 slow chans, -496 slow chans (rename of 496 channels).
+64 fast chans, -62 fast chans (add 2 chans, rename 62 chans).
Work Rescheduled:
We ran out of time this morning so the h1suspr3, h1sussr3 model restarts and DAQ restart has been rescheduled for next Tuesday, 29th July.
The ETMY Sat Amp swap this morning was completed in 15 minutes, meaning the HWWD did not complete its 20 minute count-down.
It appears that the false-positive HWWD rate for ETMY increased with the new Sat Amps, unlike ETMX where they have disappeared, or the ITMs where the rates were unchanged.
ETMY HWWD STAT and COUNTDOWN trends show below.
Elenna, Camilla, TJ, Matt, Oli
A few hours into a lock stretch we suddenly had a couple of large oscillations come in (ndscope1). They happened at 1437260896 for 2 seconds and at 1437260919 for 2 seconds. There were no saturations and our range did not drop more than 10 Mpc the next minute.
In DARM (ndscope2), the frequency of these oscillations is between 5.7-6 Hz. In the QUAD MASTER_OUT (ndscope3) and ASC (ndscope4, ndscope5) channels, the oscillation frequency is around 2.5 Hz. In the QUAD oplev channels (ndscope6), the oscillation frequency is around 2.5 Hz, and it's seen in all quads except ITMX. There is also a slight delay between when the quads move, with ITMY looking like it moved first.
TITLE: 07/22 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 150Mpc
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY: Long list of maintenance activities checked off for the day (Trello board). Relocking was uneventful, I tried playing with some gains and timers to help catch DRMI faster but I'm unsure this actually helped. We've been observing for 3.5 hours.
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 |
14:58 | CDS/GC | Jonathan | MSR | n | GC switch swap | 15:24 |
15:01 | PCAL | Tony, Francisco | PCAL lab | yes | Prep for todays meas | 15:18 |
15:02 | FAC | Chris, Eric | Ends, Mids, Mech room | n | Fan lubing | 16:36 |
15:05 | FAC | Nelly | LVEA | yes | Tech clean | 16:16 |
15:06 | SEI | Jim | EY, EX | n | HEPI accumulator checks | 17:32 |
15:07 | FAC | Randy, Mitchell | high bay | n | Fork lift and crane equipment | 17:29 |
15:09 | VAC | Jordan, Janos | MY, EY | n | Turbopump functionality testing | 18:09 |
15:11 | - | Betsy | LVEA | yes | Parts hunt | 15:47 |
15:12 | IAS | Jason | LVEA | yes | FARO health check | 18:01 |
15:16 | CDS/SUS | Fil | EY | n | sat amp swap | 16:02 |
15:17 | SUS | Oli | CR | n | Sat amp swap tests, SR3 meas. | 18:26 |
15:22 | VAC | Norco | EX | n | LN2 fill | 17:17 |
15:26 | VAC | Gerardo | FCTE | n | Measuring cables | 16:03 |
15:28 | PCAL | Tony, Francisco, Tooba | EY | YES | PCAL meas. | 17:38 |
15:31 | CDS | Richard | CER Mezz, LVEA | Yes | Check on OMC PZT power supply | 16:03 |
15:32 | SQZ | Camilla, Leo, Jennie | LVEA | YES | SQZT7 work | 19:18 |
15:33 | CDS | Marc, Erik | CER Mezz | yes | Power supply swap for ITM esds | 16:26 |
15:42 | VAC | Janos | MX | n | Looking at LN2 with contractor | 16:06 |
15:47 | - | Betsy | EY, EX | n | Checking on safety space | 16:02 |
15:51 | CDS/VAC | Patrick | Office | n | PLC code update on h0vacmr | 16:31 |
16:06 | VAC | Janos | MY, MX | n | Checking on vac stuffs | 17:29 |
16:07 | VAC | Gerardo | EX | n | Checking and maybe fixing vac stuff | 16:36 |
16:17 | FAC | Nelly | EX | n | Tech clean | 17:16 |
16:38 | CDS/SUS | Fil, Marc | LVEA | yes | MC1,MC3 sat amp swap | 17:02 |
16:44 | FAC | Eric | MY | n | Damper fix | 18:02 |
17:13 | FAC | Chris | Mids, Ends, LVEA | YES | Checking for tanks | 18:45 |
17:16 | FAC | Nelly | FCES | n | Tech clean | 18:02 |
17:19 | - | Mike, Kim, guest | LVEA | yes | Tour | 18:36 |
17:28 | VAC | Gerardo, Jordan | LVEA | yes | Checking on AIP BSC | 18:03 |
17:34 | CDS | Fil, Marc | CER | yes | OMC PZT power supply swap | 18:02 |
17:34 | FAC | Tyler | Mids | n | 3IFO checks | 18:34 |
17:53 | PCAL | Tony, Francisco | PCAL lab | yes | Setup meas. | 18:06 |
18:11 | CDS | Marc | LVEA | yes | Check on beir garten sat boxes | 18:59 |
18:14 | FAC | Nelly | EY | n | Tech clean | 18:48 |
18:54 | OPS | Tony | LVEA | yes | LVEA sweep | 18:59 |
20:00 | FAC | Eric | EY | n | Check on hvac | 20:40 |
22:46 | - | Camilla, Leo, Leo's family | OSB roof | n | Looking out from the roof | 23:02 |
TITLE: 07/22 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 12mph Gusts, 6mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.07 μm/s
QUICK SUMMARY:
Closes FAMIS28415, last checked in alog85784.
All 4 charge measurements were able to run this morning. ETMX has a fairly large error for it Veff and Veff2, everything else looks similar to the last measurement.
WP 12696
ECR E2400330
Drawing D0901284-v5
Modified List T2500232
The following SUS SAT Amps were upgraded per ECR E2400330. Modification improves the whitening stage to reduce ADC noise from 0.05 to 10 Hz. The EY PUM and UIM SAT Amps were NOT upgraded.
Suspension | Old | New | OSEM |
ETMY MO | S1100098 | S1100088 | F1F2F3SD |
ETMY MO/RO | S1100079 | S1100083 | RTLF/RTLF |
ETMY RO | S1100087 | S1000281 | F1F2F3SD |
TMSY | S1100172 | S1100148 | F1F2F3LF |
TMSY | S1100107 | S1100172 | RTSD |
MC1 | S1100128 | S1100118 | T1T2T3LF |
MC1/MC3 | S1000292 | S1000287 | RTSD/T1T2 |
MC3 | S1000297 | S1100119 | T3LFRTSD |
F. Clara, J. Kissel, O. Patane, M. Pirello
Once the new satamps were installed, I ran the script satampswap_bestpossible_filterupdate_ECR_E2400330.py to update the compensation filters for these suspensions. These 'best possible' compensation gains come from the tests Jeff did on each satamp before installation, which are found in /ligo/svncommon/SusSVN/sus/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Results/.
My input and the corresponding output is below:
oli.patane@cdsws27:/ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools$ py satampswap_bestpossible_filterupdate_ECR_E2400330.py -o TMSY ETMY_M0_R0
All updated filters grabbed for TMSY
TMSY M1 F1 compensation filter updated to zpk([5.3],[0.0969],1,"n")
TMSY M1 F2 compensation filter updated to zpk([5.28],[0.0964],1,"n")
TMSY M1 F3 compensation filter updated to zpk([5.2],[0.095],1,"n")
TMSY M1 LF compensation filter updated to zpk([5.26],[0.096],1,"n")
TMSY M1 RT compensation filter updated to zpk([5.17],[0.0945],1,"n")
TMSY M1 SD compensation filter updated to zpk([5.26],[0.0961],1,"n")
write /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSTMSY.txt
Done writing updated filters for TMSY
All updated filters grabbed for ETMY
ETMY R0 F1 compensation filter updated to zpk([5.2],[0.0951],1,"n")
ETMY R0 F2 compensation filter updated to zpk([5.2],[0.0951],1,"n")
ETMY R0 F3 compensation filter updated to zpk([5.25],[0.0959],1,"n")
ETMY R0 SD compensation filter updated to zpk([5.35],[0.098],1,"n")
ETMY M0 F1 compensation filter updated to zpk([5.31],[0.0971],1,"n")
ETMY M0 F2 compensation filter updated to zpk([5.27],[0.0965],1,"n")
ETMY M0 F3 compensation filter updated to zpk([5.22],[0.0955],1,"n")
ETMY M0 SD compensation filter updated to zpk([5.17],[0.0946],1,"n")
ETMY M0 LF compensation filter updated to zpk([5.2],[0.0951],1,"n")
ETMY M0 RT compensation filter updated to zpk([5.28],[0.0965],1,"n")
ETMY R0 LF compensation filter updated to zpk([5.29],[0.0967],1,"n")
ETMY R0 RT compensation filter updated to zpk([5.26],[0.0962],1,"n")
write /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSETMY.txt
Done writing updated filters for ETMY
All done! Remember to double check and load in the filters for ['TMSY', 'ETMY_M0_R0']
oli.patane@cdsws27:/ligo/svncommon/SusSVN/sus/trunk/Common/PythonTools$ py satampswap_bestpossible_filterupdate_ECR_E2400330.py -o MC1 MC3
All updated filters grabbed for MC1
MC1 M1 RT compensation filter updated to zpk([5.13],[0.0937],1,"n")
MC1 M1 SD compensation filter updated to zpk([5.25],[0.096],1,"n")
MC1 M1 T1 compensation filter updated to zpk([5.26],[0.0962],1,"n")
MC1 M1 T2 compensation filter updated to zpk([5.18],[0.0947],1,"n")
MC1 M1 T3 compensation filter updated to zpk([5.32],[0.0972],1,"n")
MC1 M1 LF compensation filter updated to zpk([5.12],[0.0938],1,"n")
write /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSMC1.txt
Done writing updated filters for MC1
All updated filters grabbed for MC3
MC3 M1 T3 compensation filter updated to zpk([5.32],[0.0972],1,"n")
MC3 M1 LF compensation filter updated to zpk([5.19],[0.0949],1,"n")
MC3 M1 RT compensation filter updated to zpk([5.35],[0.0979],1,"n")
MC3 M1 SD compensation filter updated to zpk([5.19],[0.0949],1,"n")
MC3 M1 T1 compensation filter updated to zpk([5.31],[0.097],1,"n")
MC3 M1 T2 compensation filter updated to zpk([5.24],[0.0958],1,"n")
write /opt/rtcds/userapps/release/sus/h1/filterfiles/H1SUSMC3.txt
Done writing updated filters for MC3
All done! Remember to double check and load in the filters for ['MC1', 'MC3']
After this I loaded in these new filters.
The serial numbers in Fil's and OLD and NEW columns are flip flopped in the main aLOG, LHO:85922. Here's the corrected version with the serial number's columns flipped to reflect reality. Suspension Old New OSEM ETMY MO S1100088 S1100098 F1F2F3SD ETMY MO/RO S1100083 S1100079 RTLF/RTLF ETMY RO S1000281 S1100087 F1F2F3SD TMSY S1100148 S1100172 F1F2F3LF TMSY S1100172 S1100107 RTSD MC1 S1100118 S1100128 T1T2T3LF MC1/MC3 S1000287 S1000292 RTSD/T1T2 MC3 S1100119 S1000297 T3LFRTSD
Here's the characterization data and fit results for S1100098 , assigned to ETMY M0's F1F2F3SD OSEMs (Fil refers to this as ETMY MO F1F2F3SD above). The data was taken per methods described in T080062-v3. The data was processed and fit using ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ plotresponse_S1100098_ETMY_M0_F1F2F3SD_20250717.m Explicitly, the fit to the whitening stage zero and pole, the transimpedance feedback resistor, and foton design string are Optic Stage Serial_Number Channel_Number OSEM_Name Zero_Pole_Hz R_TIA_kOhm Foton_Design ETMY M0 S1100098 CH1 F1 0.0971:5.31 120 zpk([5.31],[0.0971],1,"n") CH2 F2 0.0965:5.27 120 zpk([5.27],[0.0965],1,"n") CH3 F3 0.0955:5.22 120 zpk([5.22],[0.0955],1,"n") CH4 SD 0.0946:5.17 120 zpk([5.17],[0.0946],1,"n") The attached plot and machine readable .txt file version of the above table are also found in ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ As LHO:85626 and the above LHO:86028 discusses, R_TIA_kOhm is the default 120 kOhm, as it's not used in the compensation filter -- but also because the magnitude of the measurements didn't need me to adjust them; I was able to get a good phase and magnitude fit by just adjusting the zero frequency.
Here's the characterization data and fit results for S1100079 , assigned to ETMY M0/R0's LFRT/LFRT OSEMs (Fil refers to this as ETMY MO/RO RTLF/RTLF above -- note his typo in channel order). The data was taken per methods described in T080062-v3. The data was processed and fit using ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ plotresponse_S1100079_ETMY_M0R0_LFRTLFRT_20250717.m Explicitly, the fit to the whitening stage zero and pole, the transimpedance feedback resistor, and foton design string are Optic Stage Serial_Number Channel_Number OSEM_Name Zero_Pole_Hz R_TIA_kOhm Foton_Design ETMY M0 S1100079 CH1 LF 0.0951:5.20 120 zpk([5.20],[0.0951],1,"n") M0 CH2 RT 0.0965:5.28 120 zpk([5.28],[0.0965],1,"n") R0 CH3 LF 0.0967:5.29 120 zpk([5.29],[0.0967],1,"n") R0 CH4 RT 0.0962:5.26 120 zpk([5.26],[0.0962],1,"n") The attached plot and machine readable .txt file version of the above table are also found in ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ As LHO:85626 and the above LHO:86028 discusses, R_TIA_kOhm is the default 120 kOhm, as it's not used in the compensation filter -- but also because the magnitude of the measurements didn't need me to adjust them; I was able to get a good phase and magnitude fit by just adjusting the zero frequency.
Here's the characterization data and fit results for S1100087 , assigned to ETMY R0's F1F2F3SD OSEMs (Fil refers to this as ETMY RO F1F2F3SD above). The data was taken per methods described in T080062-v3. The data was processed and fit using ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ plotresponse_S1100087_ETMY_R0_F1F2F3SD_20250717.m Explicitly, the fit to the whitening stage zero and pole, the transimpedance feedback resistor, and foton design string are Optic Stage Serial_Number Channel_Number OSEM_Name Zero_Pole_Hz R_TIA_kOhm Foton_Design ETMY R0 S1100087 CH1 F1 0.0951:5.20 120 zpk([5.20],[0.0951],1,"n") CH2 F2 0.0951:5.20 120 zpk([5.20],[0.0951],1,"n") CH3 F3 0.0959:5.25 120 zpk([5.25],[0.0959],1,"n") CH4 SD 0.0980:5.35 120 zpk([5.35],[0.0980],1,"n") The attached plot and machine readable .txt file version of the above table are also found in ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ As LHO:85626 and the above LHO:86028 discusses, R_TIA_kOhm is the default 120 kOhm, as it's not used in the compensation filter -- but also because the magnitude of the measurements didn't need me to adjust them; I was able to get a good phase and magnitude fit by just adjusting the zero frequency.
Here's the characterization data and fit results for S1100172 , assigned to TMSY M1's F1F2F3LF OSEMs (Fil refers to this as TMSY F1F2F3LF above). The data was taken per methods described in T080062-v3. The data was processed and fit using ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ plotresponse_S1100172_TMSY_M1_F1F2F3LF_20250717.m Explicitly, the fit to the whitening stage zero and pole, the transimpedance feedback resistor, and foton design string are Optic Stage Serial_Number Channel_Number OSEM_Name Zero_Pole_Hz R_TIA_kOhm Foton_Design TMSY M1 S1100172 CH1 F1 0.0969:5.30 120 zpk([5.30],[0.0969],1,"n") CH2 F2 0.0964:5.28 120 zpk([5.28],[0.0964],1,"n") CH3 F3 0.0950:5.20 120 zpk([5.20],[0.0950],1,"n") CH4 LF 0.0960:5.26 120 zpk([5.26],[0.0960],1,"n") The attached plot and machine readable .txt file version of the above table are also found in ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ As LHO:85626 and the above LHO:86028 discusses, R_TIA_kOhm is the default 120 kOhm.
Here's the characterization data and fit results for S1100107 , assigned to TMSY M1's RTSDxxxx OSEMs (Fil refers to this as TMSY RTSD above). The data was taken per methods described in T080062-v3. The data was processed and fit using ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ plotresponse_S1100107_TMSY_M1_RTSDxxxx_20250717.m Explicitly, the fit to the whitening stage zero and pole, the transimpedance feedback resistor, and foton design string are Optic Stage Serial_Number Channel_Number OSEM_Name Zero_Pole_Hz R_TIA_kOhm Foton_Design TMSY M1 S1100107 CH1 RT 0.0945:5.17 120 zpk([5.17],[0.0945],1,"n") CH2 SD 0.0961:5.26 120 zpk([5.26],[0.0961],1,"n") CH3 xx 0.0956:5.23 120 zpk([5.23],[0.0956],1,"n") CH4 xx 0.0957:5.24 120 zpk([5.24],[0.0957],1,"n") The attached plot and machine readable .txt file version of the above table are also found in ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ As LHO:85626 and the above LHO:86028 discusses, R_TIA_kOhm is the default 120 kOhm.
Here's the characterization data and fit results for S1100128 , assigned to MC1 M1's T1T2T3LF OSEMs (Fil refers to this as MC1 T1T2T3LF above). The data was taken per methods described in T080062-v3. The data was processed and fit using ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ plotresponse_S1100128_MC1_M1_T1T2T3LF_20250717.m Explicitly, the fit to the whitening stage zero and pole, the transimpedance feedback resistor, and foton design string are Optic Stage Serial_Number Channel_Number OSEM_Name Zero_Pole_Hz R_TIA_kOhm Foton_Design MC1 M1 S1100128 CH1 T1 0.0962:5.26 120 zpk([5.26],[0.0962],1,"n") CH2 T2 0.0947:5.18 120 zpk([5.18],[0.0947],1,"n") CH3 T3 0.0972:5.32 120 zpk([5.32],[0.0972],1,"n") CH4 LF 0.0938:5.12 120 zpk([5.12],[0.0938],1,"n") The attached plot and machine readable .txt file version of the above table are also found in ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ As LHO:85626 and the above LHO:86028 discusses, R_TIA_kOhm is the default 120 kOhm.
Here's the characterization data and fit results for S1000292 , assigned to MC1/MC3 M1's RTSD/T1T2 OSEMs (Fil refers to this as MC1/MC3 RTSD/T1T2 above). The data was taken per methods described in T080062-v3. The data was processed and fit using ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ plotresponse_S1000292_MC1MC3_M1_RTSDT1T2_20250717.m Explicitly, the fit to the whitening stage zero and pole, the transimpedance feedback resistor, and foton design string are MC1 M1 S1000292 CH1 RT 0.0937:5.13 120 zpk([5.13],[0.0937],1,"n") MC1 M1 CH2 SD 0.0960:5.25 120 zpk([5.25],[0.0960],1,"n") MC3 M1 CH3 T1 0.0970:5.31 120 zpk([5.31],[0.0970],1,"n") MC3 M1 CH4 T2 0.0958:5.24 120 zpk([5.24],[0.0958],1,"n") The attached plot and machine readable .txt file version of the above table are also found in ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ As LHO:85626 and the above LHO:86028 discusses, R_TIA_kOhm is the default 120 kOhm.
Here's the characterization data and fit results for S1000297 , assigned to MC3 M1's T3LFRTSD OSEMs (Fil refers to this as MC3 T3LFRTSD above). The data was taken per methods described in T080062-v3. The data was processed and fit using ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ plotresponse_S1000297_MC3_M1_T3LFRTSD_20250721.m Explicitly, the fit to the whitening stage zero and pole, the transimpedance feedback resistor, and foton design string are MC3 M1 S1000297 CH1 T3 0.0972:5.32 120 zpk([5.32],[0.0972],1,"n") CH2 LF 0.0949:5.19 120 zpk([5.19],[0.0949],1,"n") CH3 RT 0.0979:5.35 120 zpk([5.35],[0.0979],1,"n") CH4 SD 0.0949:5.19 120 zpk([5.19],[0.0949],1,"n") The attached plot and machine readable .txt file version of the above table are also found in ${SusSVN}/trunk/electronicstesting/lho_electronics_testing/satamp/ECR_E2400330/Scripts/ As LHO:85626 and the above LHO:86028 discusses, R_TIA_kOhm is the default 120 kOhm.
[Matt, Jenne, Elenna]
Matt and I tried running a new jitter training on CALIB STRAIN CLEAN, and noticed that we could likely subtract a bit more jitter noise from CLEAN, and also probably reinject less noise, especially around the power lines. We then reran a training on NOLINES to prepare to apply the new cleaning today.
Jenne then walked me through how to generate the script which would update the cleaning parameters. I copied over the old observe.snap file, in case I made a mistake and need to revert to the old coefficients.
Once we were in observing, I ran Jenne's template which checks how the cleaning is performing. It definitely looks like it is doing a good job. I accepted the new parameters. Once we are locked for a little longer, I will generate some comparison plots to the old cleaning parameters.
Here is a ratio comparison plot, showing the ratio of CLEAN / NOLINES for an observing time last night and today. We're still thermalizing, so this may change slightly. Matt and I adjusted the plot colors and alpha so the old cleaning is on the bottom and you can see where we are no longer injecting extra noise, and also where the cleaning has improved slightly, especially for the peaks at a few hundreds of 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.