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.
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 ?
SNEWS Test @ 16:59 UTC
Vaccum Mid X Pressure alarm Low 17:53 UTC.
12 Hours ago there was an increase in CER Temps
Expected Tuesday Maintenance Work:
Done - VAC - MX and MY pump install work continuing (booster pumps will be connected)
Postponed ------ VAC - BSC1 AIP troubleshooting. Needs LASER SAFE condition.
Done - VAC - LN2 delivery: MX (CP5) and MY (CP3)
"Done ....For Now...." ~ Gerardo - VAC - FC guage work (pumping)
Done North Bay - cleaning of top of eMod
Done East Bay - remove C3 cleanroom sock cover over HAM5 & 6
Done - FAC - rock delivery at Staging building
Done - CDS -Daniel - Change the whitening chassis that is currently used for the ASC-AS_C QPD
Done - Fil - HAM5&6 racks - install of BHD stuff
Done - LN2 - MY & MX
Done - SUS Charge meas't ?
Done - Beaver Bark gravel dumps
Done - Dust Mon Pump Swap
CER temps are now dropping
Elenna noticed that we dropped from Observing 8 times last night, for around 2 minutes each time, plot. This was mainly due to the OPO loosing lock, reporting "2025-08-26_08:04:01.503798Z SQZ_OPO_LR [LOCKED_CLF_DUAL.run] USERMSG 0: OPO not really locked or maybe locked in a wrong mode" and taking itself to DOWN. I don't see a clear reason why, plot attached.
The OPO PZT was around 100V but we can operate up to 110V and the OPO ISS AOM was at it's central value of 5V.
There is some OPO TRANS glitches where the power drops by more than 20% but the OPO stays locked, plot attached.
Tagging OpsInfo, please check for drops in Observing overnight using the verbal alarms computer and tag the relevant team in your alog it it's obvious what caused the observing drop. For SQZ, there is a ndscope under sitemap > SQZ > SQZ Overview > ! SQZ Scopes > SQZ Guardians that compares the H1:GRD-IFO_OK channels to all SQZ Guardian to see if they were the reason for the observing drop.
Workstations updated and rebooted. This was an OS packages update. Conda packages were not updated.
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.
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 due to ETM Glitch.
Back to NLN at 04:05 UTC
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
Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
---|---|---|---|---|---|---|
15:01 | FAC | Nelly | MY | n | Tech clean | 15:44 |
15:04 | FAC | Kim | MX | n | Tech clean | 16:10 |
16:44 | FAC | Eric | EX | n | Checking out part that needs to be replaced | 17:03 |
20:39 | Camilla | OpticsLab | n | Sorting parts | 21:17 |
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 |
Jeff, Oli, this is good to know!
I also noticed that the SUSpoint L to M1 P block of the estimator does not have the corresponding filter fit. For the Pitch degree of freedom, we expect the ISI longitudinal contribution to be relevant enough that it should be modeled. Maybe this explains some of the inconsistent behavior around the length/pitch modes.
I modified 'make_SR3_pitch_model.m' inside sus/trunk/HLTS/Common/FilterDesign/Estimator to ensure that we get the correct fits into this filter bank. This update is current as of SVN revision 12616
In total, autoquack should populate 3 filter banks for the pitch estimator:
Wow. Thanks for all the data. One quick clarification. Above it says "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"
To be clear, the first version of the pitch estimator was designed to damp these peaks. But - recall that "estimator" is the blend of the model and the measurements. In the first version, nearly all of the damping signal in the estimator was from the MODEL, whereas the 2 higher frequency peaks (and all 3 yaw peaks) use the MEASUREMENT path from estimator. In version 1, the model path for the estimator wasn't working well. This seems to mean that the model is not correctly predicting the gap motion. We suspect that this is because of an unmodeled drive, which we think is DAC noise.
So we were applying damping with the estimator, but it was not working as expected. Version 2 has updated blend filters which use the osem signals around all 4 peak frequencies, and hopefully this will improve the estimator performance.
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:
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.
J. Kissel, O. Patane, B. Lantz Continuing to refine my understanding of the metrics for the GS13 FF Estimator, I update the plots from LHO:86503. Also, I barely explained the plots there, so I'll try to do a better job here. First Point: Concepts and Clarification I've had a conceptual misunderstanding about what the estimator is at its core. Discussions with Brian have cleared this key point up for me: I had been calling the estimator a "GS13 Feed Forward Estimator," but that neglects a key innovation of the estimator. Not only does it use the HAM5 ISI GS13's to predict the susp-point motion input -- that's the feed-forward part -- but it also takes the total top mass *requested* drive from the suspension's M1 stage as well, and (with a 1 clock cycle delay) feeds that back as another input to the estimator. That's the composition of the estimator super sensor: the sum of the estimated input motion from the ISI as well as the total requested drive "including the estimator controls, what's left of the classic, broadband OSEM control, and any ISC drive". In the case of SR3, there is no AC ISC drive, just alignment offsets, so for the purposes of us looking at the ASDs as performance metrics it's irrelevant. So, saying that description of the total requested drive sentence again for SR3: "including the estimator controls [from GS13s and filtered estimated total drive] and what's left of the broadband OSEM control." Remember, for SR3, the original total EPICs gain on the OSEM-only damping loops was -0.5. So, "what's left of the OSEM-only damping loops" is -0.1 of the OSEM-only damping loops and whatever percentage of OSEMs is allowed to pass through the OSEM / Estimator Super-sensor blend on resonance. So -- what *are* the relevant local metrics? On the sensor side -- it's interesting (and necessary) to compare (a) the OSEM signal (b) the total Estimator Super Sensor, which is comprised of (c) the Estimated M1 motion caused by Suspension Point Motion, predicted by the HAM5 GS13s (d) the Estimated M1 motion caused by M1 drive, predicted by the internally *requested* M1 drive On the output drive side -- it's interesting (and necessary) to compare - the total internally requested drive; in the case of SR3 only from (1) the small, but broadband fraction of control from the OSEMs (2) when OFF, the larger broadband fraction of control from the OSEMs (3) when ON, the estimator control from . estimated M1 motion via GS13, . M1 drive, and . larger fraction of blend-filtered OSEM control The first two "TRACEKEY" attachments show these 4-trace "sensor" and 3-trace "drive" plots for pitch, with the estimator overview screen handy so you can relate the traces with where they are in the control system topology. Second Point: Pitch Sensors Alright, so let's look at the pitch plots. Open the "Pitch Sensor Metrics when P and Y Estimators are both ON" alone plot first. (i) As we already knew, the raw OSEM signal can't see anything. It's dominated by its sensor noise for the vast majority of the 0.05 to 50 Hz frequency band, with *some* real on-resonance motion peaking up above the noise at 0.64 Hz, 0.75 Hz, and 2.1 Hz. The 3.4 Hz mode isn't resolved at all. (ii) The estimator super sensor, however, does an awesome job at predicting the M1 motion at these resonances above the first 0.64 and 0.75 Hz pair; it's dramatically less that the OSEM sensor noise. The fits to the GS13 Sus. Point to M1 motion and M1 Drive to M1 motion are quite fruitful. In this f > 0.75 Hz region, you get an interesting mix of GS13 and M1 stage drive, alternating which is better. I'm a little surprised to see a 1.59 Hz mode estimated by the GS13s that isn't otherwise controlled at all, because it doesn't show up in the total M1 drive trace. (iii) Below 0.75 Hz -- the estimator seems to show that the M1 motion is completely dominated by suspension point motion. Is that real, or is that GS13 noise? Not so clear with these local metrics. The fact that ASC sees worse noise from 0.1 top 0.3 Hz with the estimator on (see LHO:86507 e.g. SRC2 Pitch Control signals), implies to me that it *is* GS13 noise, and we should still high-pass at least the pitch damping loop controller. OK. Now that you're used to the noise budget, turn on the comparison of these traces between P & Y estimators ON vs. OFF. (i) For the OSEMs, all the can see is the following: the estimators have made the on-resonance motion *worse* between 0.64 and 0.75, and at 2.1 Hz. But -- the OSEMs are still in-loop sensors, so some factors of 1 / (1+G) - like factors may be in play, confusing us as to whether this an artifact of their being less on-resonance loop suppression ... or something. We've gotta math that out still. (Again, the out-of-loop ASC error/control signals shown in LHO:86507 seem to indicate that there is more real on resonance motion, and the OSEMs are faithfully telling us the *change*. The on-resonance story, especially for pitch is going to continue to be "complicated" for a while. (ii) Comparison between the bright red vs. bright blue estimated super sensor really shows where we win pitch noise improvement with the P and Y estimators: between resonances in the frequency band between 0.75 and 8 Hz. Since we're using a factor of 5 less OSEMs (aside from on-resonance), the total M1 stage drive motion from the broadband OSEM damping loop drops by factors of 10x. (iii) Interestingly, the GS13s still predict suspension point motion to dominate below 0.75 Hz regardless of whether the estimators are on, but the M1 drive signal (unfortunately very subdominant) drops by a factor of 2x ish between 0.1 and 0.3 Hz at the microseism -- and it's by the same ratio of raw-OSEM noise to estimator super sensor / GS13 suspension point prediction. *That* says to me that we *are* doing better with the estimators ON at the useism, vs. what the ASC sensors are saying... Third Point: Pitch Drive Now let's switch to the M1 stage drive breakdown for pitch. Here, the comparison is a bit tough to grok immediately, because - With the estimators OFF, you're damping the SUS with -0.5 worth of OSEM broadband damping, but it's split through two paths -- the "classic" broadband path with 0.1 gain, and a "fader" broadband path with gain of -0.4, and summed (thanks linear algebra!). - With the estimators ON, the -0.1 gain "classic" path remains, for the other path the OSEMs are now blended to only have -0.4 gain on resonance. That explains the drive comparison plot then: (i) The off-resonance, total requested, M1 drive -- with the estimators ON -- drops as shown in the sensor plot, but does not drop entirely to the noise floor of the GS13 sus. point estimate because -- above 0.75 Hz and off-resonance the stage 1 motion is still limited by the -0.1 gain broadband OSEM path (which doesn't change from ON vs. OFF). (ii) The on-resonance story especially at and in-between the 0.64 and 0.75 Hz resonances, remains "interesting" / confusing. There's *more* drive from -0.1 gain OSEM path on resonance with the estimators on vs. off, but difference between the -0.4 OSEM path and full-estimator path drive is better focused on the two resoances, dropping the total-total drive in-between. This is confirming that something in the OSEM sensor path incorrectly sensing the motion in between 0.64 and 0.75 Hz and the -v2 pitch blend filters -- which restore the use of the drive / GS13 FF super sensor for this tiny, in-between frequency band -- is doing the right thing. Fourth Point: Yaw Sensors Ok -- now on to yaw sensors. I attach both the P&Y Estimators ON alone as well as ON vs. OFF, but you're good enough at looking at these now and yaw is apparently a much more simple story, so let's just open the ON vs. OFF comparison. (i) The GS13 estimate of the suspension point motion is *much* less than in pitch. The OSEM's don't see anything at all. (ii) Above 0.5 Hz, you see off-resonance improvement in the super-sensor estimation of M1 motion by the factors of 4x-5x improvement you would expect from dropping from -0.5 gain (total) usage of the OSEMs to -0.1. (iii) This actually advocates for making the blend filter notches in yaw *even skinnier* than the improvement discussed in LHO:86265. (iv) I'm not sure this would help, but seeing the estimated suspension point motion peak back above the control noise at 30-40 Hz says to me that (if we can) we should improve the ST0/HEPI feed-forward to ST1 motion for HAM5. The hump is present even in the Estimator OFF drive trace, so it tells me that the physical motion of the M1 stage is smaller than M1 cage motion. So, we also should consider -- if we can't improve the 30-40 Hz ISI motion (likely), then we roll-off the yaw damping loop controller (definitely easier, we should have plenty of phase margin). Fifth Point: Yaw Drive Finally -- the yaw drive. I'm not sure there's too much to discuss here, since the story is more simple and the same as what's seen in the sensors. With the estimator ON, you get the 4x-5x reduction in drive when you're not using the OSEM portion of the estimator. Summary Plot Once you're done thinking through it all, it's good to zoom back out and stare so I provide all the plots together -- see 2025-08-25_H1SUSSR3_M1_GS13FFEstimator_LocalPerformance_Summary_QuadPlot.png.
Over the past couple of weeks, I took transfer functions for SR3 and PR3 with different configurations of P or Y damping gain for the estimator, so here are the results for those plus a comparison of their peak locations.
SR3
DAMP P gain at -0.1 (nominally -0.5), other dof gains at their nominal -0.5
Measurements: 86203
Results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Results/2025-08-05_1800_H1SUSSR3_M1_ALL_TFs.pdf r12611
DAMP Y gain at -0.1 (nominally -0.5), other dof gains at their nominal -0.5
Measurements: 86202
Results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Results/2025-08-05_1700_H1SUSSR3_M1_ALL_TFs.pdf r12612
PR3
DAMP P gain at -0.2 (nominally -1.0), other dof gains at their nominal -0.2
Measurements: 86459
Results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Results/2025-08-19_1815_H1SUSPR3_M1_ALL_TFs.pdf r12613
DAMP Y gain at -0.2 (nominally -1.0), other dof gains at their nominal -0.2
Measurements: 86459
Results: /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Results/2025-08-19_1715_H1SUSPR3_M1_ALL_TFs.pdf r12614
Comparison between SR3 and PR3
Results:
/ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/Data/allhltss_2025-08-25_SR3vsPR3Comparison_DampPat20percent_ALL_TFs.pdf r12615
/ligo/svncommon/SusSVN/sus/trunk/HLTS/Common/Data/allhltss_2025-08-25_SR3vsPR3Comparison_DampYat20percent_ALL_TFs.pdf r12614
Sheila, Camilla
Followed instructions in 74681, I did not go to NLN_CAL_MEAS but that would have given clearer signals. Last done in June 85250, . Saved in /ligo/gitcommon/NoiseBudget/simplenb/dtt_files/ but not yet pushed to git: https://git.ligo.org/NoiseBudget/simplenb. Note different folder location and git directory used.
FYI -- for the record, these noise budget excitations were taken *after* the SR3 pitch estimator's blend filters were updated to -v2 this morning (LHO:85544). (I sincerely doubt they'll play a role, but just stating for the record.)
It has been a while since we ran our A2l decoupling script, so I ran it this morning. I also took before and after tranfer funstion measurements for the HARD loops to DARM, the script did improve things overall. The templates used for these measuerments are in userapps/asc/h1/templates/CHARD and DHARD. I've loaded these changes into ISC lock. I had planned to check if it is possible to do better than the script by adjusting ITMs in common and differential by hand, but based on these measurements that doesn't seem worth doing, as the only one close to DARM around 20 Hz is CAHRD P where the decoupling looks quite good at 20 Hz
Optic | DOF | Initial | Final | Diff |
---|---|---|---|---|
ETMX | P | 3.18 | 3.07 | -0.11 |
ETMX | Y | 4.89 | 4.79 | -0.1 |
ETMY | P | 5.53 | 5.54 | 0.01 |
ETMY | Y | 1.33 | 1.42 | 0.09 |
ITMX | P | -0.53 | -0.45 | 0.08 |
ITMX | Y | 3.25 | 3.16 | -0.09 |
ITMY | P | 0.08 | 0.19 | 0.11 |
ITMY | Y | -2.82 | -2.75 | 0.07 |
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.
I doubled the amplitude of the injection from 0.04 to 0.08, ran the template and saved as /lsc/h1/scripts/feedforward/SRCL_excitation.xml while FM5 was on, so that in the future we can try to fit a separate >100Hz filter as Elenna suggests in 86481. I didn't measure the pre-shaping as expect we recently have that.
In preparation to create a high frequency SRCL FF based on this data, I copied the SRCLFF1 FM10 highpass into FM10 of SRCLFF2 (not to be confused with a different, older "highpass" in FM1 of SRCLFF2).
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
Posting this comment which has been saved in my drafts, which I thought I'd posted a while ago:
I've taken a second quick look at this data, constructing a model in the same way that I've done in the past without any mode mismatches. This works OK, and suggests that for 347kW arm power we'd have 2.5% unknown readout losses and
This data can be fit reasonably well without frequency independent losses, no mode mismatch and an SRC detuning, simliar to previous data sets. This doesn't mean that there's not a mode mismatch, but there's not new evidence for mode mismatch here. Kevin did mention that I should look at scenarios where we have both SQZ to OMC mismatches and IFO to OMC mismatch. Indeed, when I do that the mismatch phase is important for the sqz and anti-sqz level at 2kHz.