Range diff over last 24 hours

I compared the sensitivity from two segments over the last 24 hours where our range was about 157 Mpc and 162 Mpc each (60 second averages). Looks like a broad improvement from about 30-300 Hz when using the range comparison script.. The 350 Hz SQZ blrms are 0.25 dB better in the higher range time. It's hard to see a large change in the 38-60, 60-100 or 100-450 Hz range blrms. Whether you use a shorter or longer average, the difference between two times is 5 Mpc.

PSL 10-Day Trends

FAMIS 31100

ISS diffracted power has generally been trending down over the past week, but at least it's starting to settle back at the desired setpoint of 4%. No other major events of note.

Tue CP1 Fill

Tue Aug 26 10:07:19 2025 INFO: Fill completed in 7min 15secs

 

Whitening chassis for ASC-AS_C and OMC-REFL_A changed

This continues work from alog 86442. A new cable, D2500252, was made to replace the old ISC_455 (D2200327) and ISC_39 (standard 25-pin d-sub cable).

The DC offset have been adjusted but not accepte din SDF.

The second anti-whitening filter of OMC-REFL_A is now a normal anti-whitening filter, zpk([10],[1],1,"n"), and not the antiLP, zpk([49.63],[497.5],-0.9995,"n"). However, the filter files are not updated yet.

H1 SUS SR3 M1 Pitch and Yaw Estimator: Was missing L to P Sus. Point Input -- now Installed

J. Kissel, E. Bonilla, I. Zhong, B. Lantz, O. Patane

Per LHO:86563, Edgard found/noticed that the H1SUSSR3 M1 Pitch Estimator system wasn't using the Sus Point L to M1 P contribution that had been a part of the design intent. I used 
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/
        make_SR3_pitch_model.m      rev 12618
to install the extra filters into FM1 and FM2 of the H1:SUS-SR3_M1_EST_P_FUSION_MODL_SUSP_L_2GAP filter bank.
The script uses 
    /ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/FilterDesign/Estimator/
        Clean_fits_H1SR3_P_2025-08-05.mat      rev 12594

Steps to install:
(0) From the sitemap, open up the SR3 overview screen, and find the pitch estimator overview screen as well as the Sus Point to M1 filter bank collection.
(1) Open matlab, navigate to the above directory and open the script.
(2) TURN THE ESTIMATOR OFF, by using the the fader switch: H1:SUS-SR3_M1_EST_P_SWITCH_NEXT_CHAN goes from 3.0 to 2.0 (but you can do this with the "Use OSEM" button on the estimator overview screen)
(3) Run the matlab script -- this uses autoquack (LIGO's home brewed matlab-to-foton filter install function) to push the matlab filter to SR3's foton file.
(4) Open up the SR3 GDS_TP screen, where there should now be a "Modified Filter File" message shown on the channel H1:FEC-44_MSG2. Use the !DIFF button -- which pops up a screen showing the diff between what's installed and what you're about to install -- to validate at least that "the only filter bank that's been touched or modified is the new L to P filter" (since it's tough to validate Second Order Sections by eye).
(5) THE ESTIMATOR IS OFF, RIGHT? OK, then hit the "COEFF LOAD" button. The filter names listed below should appear in FM1 and FM2 of the EST_P_FUSION_MODL_SUSP_L_2GAP bank.
(6) THE ESTIMATOR IS OFF, RIGHT? OK, then use the MEDM interface on the EST_P_FUSION_MODL_SUSP_L_2GAP screen to turn on the input, output, FM1 and FM2, and set the gain to 1.0
(7) While the impulse response of the filter settles, set the H1:SUS-SR3_M1_EST_P_FUSION_MODL_SUSP_L_2GAP_STATE_GOOD filter module state checker bit word to match the current state's word H1:SUS-SR3_M1_EST_P_FUSION_MODL_SUSP_L_2GAP_STATE_NOW. Should need a change from 0x2000000 to 0x6000f4.
(8) Turn the estimator back ON. And at least look at the estimator overview screen to confirm that sensor signals are not going bonkers. In fact, they really shouldn't look that different at all.
(9) If you like what you see, go back to the GDS_TP screen and accept the new EPICs settings with this new filter ON in both the safe and observe snap files:
    /opt/rtcds/userapps/release/sus/h1/burtfiles/
        h1sussr3_safe.snap
        h1sussr3_observe.snap
commit these to the userapps svn with the appropriate message when you're done.
(10) Commit the updated foton file to the userapps svn with a similar message
    /opt/rtcds/userapps/release/sus/h1/filterfiles/
        H1SUSSR3.txt
(11) Profit! Start looking at the performance!

Here's the design explicitly:
SR3_M1_EST_P_FUSION_MODL_SUSP_L_2GAP
FM1        "ISI_fit_L"      Fit to (M1 Response / Sus. Point L Excitation) TF, plus calibration from nm to um.
    sos(0.0001142264006754552, 
        [-2.0000000000000009; 1.0000000000000011; 
         -1.999975478282779; 0.99997585128576594; 
         -1.999816005993748; 0.99982977526725314; 
         -1.999982188592295; 0.99998283118601283; 
         -1.999884963247067; 0.9998851520162283; 
         -1.999988292191436; 0.99998835461999513; 
         -2.0001080651245839; 1.0001082464362681; 
         -1.999989760987597; 0.99998984142840619; 
         -2.000082349605993; 1.0000836590827351; 
         -1.9999909890250209; 0.99999272379034698])
FM1        "to_um/nm"       Vestigial Organ; calibration is folded in to FM1's filter these days.
     zpk([],[],1.000000000000000,"n")

Changing TCS-SIM values for surface defocus effects

M. Todd, C. Compton, S. Dwyer

---

We changed the gain settings in TCS-SIM that convert the powers of each actuator (including self-heating) to surface defocus for calculating the overall radius of curvature of each test mass at a given thermal state.

The motivation for this was that the simulation seems to be largely overestimating the Higher Order Mode spacing. Hopefully, with these new predictions, we will observe better agreement between the simulation and HOM measurements.

We also changed the absorption values using values taken from alog 80714 for the ITMs, and using galaxy for the values for the ETMs.

 

Tuesday Ops Maintenance Day

TITLE: 08/26 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 15mph Gusts, 9mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:
H1 has been locked for 10+ hours.

Today At 14:21 UTC it appears the Magnetic Injections started.
At 14:40 UTC Back to Observing.
Down to Commissioning again at 14:45 UTC



Expected Tuesday Maintenance Work:
VAC - MX and MY pump install work continuing (booster pumps will be connected)
VAC - BSC1 AIP troubleshooting. Needs LASER SAFE condition.  Postponed
VAC - LN2 delivery: MX (CP5) and MY (CP3)
VAC - FC guage work (pumping)
Randy - North Bay - cleaning of top of eMod
Randy - East Bay - remove C3 cleanroom sock cover over HAM5 & 6
FAC - rock delivery at Staging building
CDS -Daniel - Change the whitening chassis that is currently used for the ASC-AS_C QPD
Fil - HAM5&6 racks - install of BHD stuff
LN2 - MY & MX
Charge meas't ?

 

 

Workstations updated

Workstations updated and rebooted.  This was an OS packages update.  Conda packages were not updated.

Committed Fits and Bandpasses for the PR3 OSEM estimator

Edgard, Ivey, Brian. [This a summary logpost. More detailed information on the fits and blends is now available, together with better plots]

post on PR3 OSEM estimator fits: [LHO: 86574].
post on PR3 OSEM estimator blends:[LHO: 86588].

We committed the fits, blend designs, and scripts needed to commission the H1 PR3 OSEM estimator. to the 'sus/trunk/HLTS/Common/FilterDesign/Estimator' folder.
Hopefully this will be sufficient for some commissioning soon

The files committed are:

on revision 12616:
fits_H1PR3_P-2025-08-19.mat    [fits for H1PR3 with pitch damping gain set to -0.2]
fits_H1PR3_Y_2025-08-19.mat    [fits for H1PR3 with yaw damping gain set to -0.2]
make_PR3_pitch_model.m          [script to load the fitted PR3 pitch transfer functions into the foton file. It should modify 3 filter banks]
make_PR3_yaw_model.m            [script to load the fitted PR3 yaw transfer functions into the foton file. It should modify 2 filter banks]

make_SR3_pitch_model.m          [script to load the fitted PR3 pitch transfer functions into the foton file. It should modify 3 filter banks | there was a typo in this script]

on revision 12617:
blend_PR3_pitchv2.m                                                                  [creates tuned bandpasses for the PR3 P estimator]
Estimator_blend_skinnynotch_PR3yaw_20250825.m            [creates tuned bandpasses for the PR3 Y estimator]
make_PR3_blends.m                                                                   [loads the PR3 Pitch and Yaw bandpasses. It should modify 4 filter banks]

The fits are shown in the pdf attached. We will post a detail of the blends, as well as the zpk designs tomorrow.

 

OPS Eve Shift Summary

TITLE: 08/26 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 158Mpc
INCOMING OPERATOR: TJ
SHIFT SUMMARY:

IFO is in NLN and OBSERVING as of 04:05 UTC.

Very quiet shift in which we had one ETMX Caused Lockloss (alog 86559). Lock reacquisition was fully automatic but did require an initial alignment following DRMI lock issues and one DRMI LL.

 

 

Lockloss 02:29 UTC

Lockloss due to ETM Glitch.

Ops Day Shift End

TITLE: 08/25 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY: Observing and have been Locked for over 14 hours now. This has been a very quiet shift. We had some commissioning earlier, and then had an earthquake coming in that was in the middle of the green earthquake zone so we decided to use the Hi ASC Gain button (first tested 86364). It turned out that the earthquake was so small that we didn't even need to go into Earthquake mode, but it was a good second test of this mode, and I found an import error in the script that was easy to fix but might  have been bad if it had been found by someone facing an actual lockloss-causing earthquake.
LOG:

14:30 UTC Observing and have been Locked for over 4.5 hours
15:30 Out of Observing for Commissioning
18:36 Back into Observing
19:34 Hanford site monthly emergency testing phone call
22:42 Out of Observing due to earthquake coming in - we decided to test out the Hi ASC Gains script
22:53 Reverted back to NLN with the ASC Low Noise script
22:54 Back into Observing 

Correction/Update: SR3 Estimator Impact on ASC (plus new OMC and ASC-AS plots)

Jeff, Oli

On Thursday (86507) I alogged the differences we were seeing in the ASC with the SR3 estimator on. The time that I was taking as our 'reference time' for the estimator off, however, doesn't seem like it was a good time showing the lowest the ASC noise could be. You could say this caused us to over estimat(or) the differences.
So I plotted some more times with the estimator off, then with the estimator on, and I found that maybe the SR3 noise is limiting the ASC noise less than shown in 86507. However, I also found that below 0.2 Hz, where we thought that the estimators were elevating the noise, that also seems to have been not related to the estimator, so that is something we might not have to worry about. 
Of course the peaks at 0.6 and 0.7 Hz are elevated in the estimator plots below due to not damping them in the inital blend filter (mentioned in 86507), and this is something that we partially fixed this morning (86544), and will be working on further damping at the next available commissioning time.

There are still times where the estimator on makes the noise better at some frequencies, but there are also other times where the estimator is on, but something else is limiting the noise, so it looks like SR3 isn't limiting the noise very much at all. It will still be interesting to see if adding estimators onto the rest of the SRC give us different results.

In the plots below, I am showing the variation in noise with the estimators off and the estimators on,
The 'bad' time for the estimators OFF is: 2025-08-17 09:00 UTC (green)
The 'good' time for the estimators OFF is: 2025-08-20 18:29 UTC (blue)
For the estimators ON times, they're both 'good' and 'bad' at different frequencies, so I'll just list their times:
2025-08-21 16:35 UTC (red)
2025-08-24 18:18 UTC (gold)

	Pitch			Yaw
ASC-DHARD	Error
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
	Control
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
ASC-MICH	Error
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
	Control
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
ASC-SRC1	Error
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
	Control
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
ASC-SRC2	Error
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
	Control
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
ASC-AS_A_DC	Control
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
ASC-AS_B_DC	Control
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
ASC-OMC_A	Control
	Est OFF	Est ON	Both	Est OFF	Est ON	Both
ASC-OMC_B	Control
	Est OFF	Est ON	Both	Est OFF	Est ON	Both

OMC-DCPD_SUM_OUT	Est Off	Est ON	Both
OMC-REFL_A_LF_OUT	Est Off	Est ON	Both

 

new version of noise budget code: WIP

I've made a fresh start on the noise budget code, using much of the work and many of the functions from aligoNB, but in a code that should be overall simpler for us to work with.  This exists in a repo here: simplenb.

Noises estimated using the excess power method can be read in either using gps times or from a dtt template. .xml files are tracked using git lfs and read in by dttxml. If a list of gps times is provided then the code will download the data using gwpy and save asds as a .pkl file, so that the data doesn't need to be downloaded each time the budget is run. Deleteing the pkl file from the local copy will cause it to redownload the data if the user wants to change times or resolution.  The excess power projection is done using the frequency resolution of the dtt file, or right now it is hard coded to an fft length of 3 seconds for those made using a list of gps times.  The noises are rebinned to a frequency vector specified for the budget after the projections are made. 

Thermal noises are imported from gwinc.  Quantum noises are also calculated using gwinc, which is why this code needs to be run in an environment that uses Kevin's superQK branch of gwinc.  I've added a function save_quantum_params to my quantum noise modeling repo that takes a template of a yaml file including all the parameters you think are important for modeling quantum noise, and a ifo struct, which saves a yaml file with the current parameters.  This function is also available in the quantum_utils.py function in this repo, so that people can use it with any method they like of generating a gwinc model of quantum noise to incorporate into this noise budget. I think it is best to leave the quantum noise budgeting separate from this repo for now, because the code for that is still evolving.  For now I've used the quantum parameters where all the missing squeezing is explained by frequency dependent loss from 85942, the next step is to add mode mismatches to that model.

Running the budget.py script will generate noise budget plots, you can choose how many layers deep to go in plotting sub-budgets by setting that parameter in the make_all_plots function call in the final lines.  The plots attached were made using the injections that Camilla made this morning (86550), and a reference time of 20:00 UTC.

Still to do:

• Add missing noises:
  • residual gas
  • DAC noise
  • PD dark noise
  • Newtonian Noise
  • remainder of ASC noises
• Correct some noise terms:
  • intensity noise has double counting around 1kHz (also an issue in old noise budget)
  • frequency noise loop correction (it is measured with only one sensor in loop, in full lock we use 2 sensors)
• Would be nice:
  • specifiy the ftt length for excess power noises using gps times for each noise
  • get Craig's interactive svg working, which isn't working in either model yet
  • add some useful information to plot, like gps time of reference, maybe some quantum model parameters

OPS Eve Shift Start

TITLE: 08/25 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 152Mpc
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 13mph Gusts, 10mph 3min avg
    Primary useism: 0.11 μm/s
    Secondary useism: 0.09 μm/s
QUICK SUMMARY:

IFO is in NLN and OBSERVING as of 17:20 UTC (13.5 hrs!) (with some drops out of observing for various reasons).

Oli just finished testing Jim and Elenna's Earthquake robust ASC state during an earthquake, though we probably would have survived since it was a small EQ. I will turn this back on to continue testing if a sufficiently large EQ rolls in.

Otherwise, IFO is behaving excellently.

Elenna's new SRCL FF Fit turned on

In 86481, Elenna proposed using a new FF fit as the bruco showed SRCL coherence, this has improved the low frequency SRCL noise, but moved the bump at 200Hz to 100Hz, overal a small improvement, see plot attached. Saved in ISC_LOCK and safe and observe sdfs.

first look at sqz dataset, limit on IFO to OMC mode mismatch

I've taken a first look at the data that Camilla and Matt took in https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=85813. 

In the past, I've started modeling these data sets by assuming a fixed arm power, and finding IFO readout losses that are needed to fit the measured shot noise without squeezing at 2kHz.  This time, inspired in part by a comment from Begum, I instead used only the known IFO readout losses and attributing the rest to mode mismatch between the IFO and OMC, this allows us to make an upper limit on the mode mismatch from the IFO to the OMC.

From the google sheet , I will include SRC losses as a known readout loss (although the are listed as sqz injection losses, I think for the IFO they are readout losses), 0.99(SRC)*0.995(OFI)*0.9993(OM1)*0.985(OM3)*0.9904(QPD)*0.956(OMC)*0.98(QE) = 10% known readout losses.  The known injection losses (not including SRC losses) are then 0.985(OPO)*0.99^3 (3 SFI passes)0.99 (FC QPDs)*0.99(other HAM7 loss) *0.99 (OFI)= 7.2%

Fitting the level of squeezing and anti-squeezing at 2kHz suggests an NLG of 13.2 (fairly close to Camilla's measurement of 13.4), and a total efficiency of 0.752 using the Aoki equations (treating mismatches as losses).  Looking at the interactive sqz gui, the IFO to OMC mismatch reduces the measured sqz anf anti squeezing at 2kHz, but the mismatch phase only has an impact below about 400Hz. 

Using only the known readout (10%) and injection losses (7.2%), perfect sqz to OMC mode matching, we can get some limit on the amount of OMC to IFO mode mismatch that can be compatible with our 2kHz squeezing.  5.1% mismatch (which would imply 355kW in the arm cavity) seems too high to be compatible with our squeezing, while a mode mismatch of 3.7% with 350kW in the arm does seem compatible if the sqz to OMC mode matching is perfect. So, we can take 3.7% as an upper limit on the IFO to OMC mode matching that is compatible with known squeezing losses.  The data could be compatible with mode mismatches as low as 2.3% (345kW in arms) without introducing any extra losses.   Any unknown squeezer losses, like excess crystal losses, will reduce this amount.  The arm power of upper limit that we'd infer from this is 350kW, but this depends sensitvely on what we assume the non quantum noise is at 2kHz.  I will try to redo this estimate soon using the cross correlation data that Elenna is working on to have more confident limits on the arm power.

These first two plots show that this model isn't well tuned at a few hundred Hz, I haven't tried to set either the SRCL offset or homodyne angle yet, or the OMC to IFO mismatch phase.  At first glance it does not seem like I will be able to make this match well by adjusting the mismatch phase. 

The last two plots show the squeezing level in dB, just so that we have a plot we can look at.  The script to make these plots are committed here