jeffrey.kissel@LIGO.ORG - posted 16:56, Wednesday 12 October 2022 - last comment - 11:02, Monday 31 October 2022(65317)
TAKE 2: HSTS P and Y Motion Below 2.5 Hz Modeled to Be Dominated by 18-bit DAC Noise Through the TOP Mass (M1) Stage
J. Kissel Conor Mow-Lowry and Jesse von Dongen we working through my 2014-era noise budgeting code for the beam splitter (BSFM) damping loops to create HoQI inspired bigger beam splitter (BBSS) damping loops, and discovered a math flaw that I've been carrying around in all my 2014-era code that calculates actuator noise for angular DOFs for every suspension type. GULP. In short, the error results in an over estimation of the actuator noise for the rotational DOFs -- perhaps most interestingly, P and Y -- by a factor of 1/sqrt(lever arm). For the HSTS -- which I recently budgeted in LHO:65247 and claimed the actuator noise was huge -- the over-estimation is a factor ranging from ~3 to 6 depending on the stage and the degree of freedom. I have now fixed the error, and recomputed all the various configurations of HSTS that were used in LHO:65247 and I remake my assessment here. (The L plot is identical, since there's no lever arm error, but I include it here again such that the complete L P Y set is here.) Surprisingly, in the current situation -- as demonstrated by the "H1SR2" plot collection -- the 18-bit DAC noise through the TOP (M1) stage is still dominating the lower-end of the P and Y budgets. It's just now by less, and the cross-over between BOSEM sensor noise and the M1 stage actuator noise (dominated by 18-DAC noise) is at 2.5 Hz rather than 3.0 Hz. If we improve the TOP (M1) DAC to a 20-bit DAC (an assume it performs as well as shown in E1800243), then the P M1 actuator noise becomes comparable to the Seismic and BOSEM sensor noises, but the Y M1 actuator noise still remains dominant below 1.5 Hz. So -- even though, in LHO:65247, I had the actuator noise over estimated by a factor 3x-6x -- after updating the budgets in this aLOG, my conclusion still stands: we should still upgrade the top masses of the HSTS to 20-bit DACs, and consider changing the frequency response of the TOP mass driver. Statements made in LHO:65247 about the current awesomeness of the HAM-ISI w.r.t. to other noises in terms of M3 optic displacement still hold. Even in the "ideal" case, with H1FC1 (where "ideal" means using the current best possible existing coil driver designs and 20-bit DACs, and with current best damping loop rejection of BOSEM sensor noise), the ISI is still an order of magnitude or more below the P and Y dofs, and only just barely sneaks above BOSEM and M3 actuator noise in L right at ~10-11 Hz. Explanation of the error in more detail in the comments.
Non-image files attached to this report
Comments related to this report
Here's how we traditionally estimate torque noise from actuators from a given stage (I'll use the four-OSEM, M2, stage of the HSTS as the example):
Fundamentally, we assume that the DAC (and coil driver self) noise are incoherent torque noises from the 4 actuator channels:
Torque noise = sqrt( (Force Noise_{UL}/lever_{UL})^2
+ (Force Noise_{LL}/lever_{LL})^2
+ (Force Noise_{UR}/lever_{UR})^2
+ (Force Noise_{LR}/lever_{LR})^2 )
where I've enforced the incoherence of the four noise channels by adding the noises together in quadrature.
We can (and typically do) reduce the complexity if we *model* the force noise and the lever arms from each actuator to be the same:
Force Noise_{UL} = Force Noise_{LL} = Force Noise_{UR} = Force Noise_{LR} = Force Noise
lever_{UL} = lever_{LL} = lever_{UR} = lever_{LR} = lever
>>
Torque noise = sqrt( (Force Noise * lever)^2
+ (Force Noise * lever)^2
+ (Force Noise * lever)^2
+ (Force Noise * lever)^2 )
= sqrt(4 * (Force Noise * lever)^2 )
Torque noise = sqrt(4) * Force Noise * lever
where the units work out nicely to be the units of Force Noise -- N/sqrt(Hz) -- multiplied by the lever arm units -- m -- to get Torque noise units, (N.m)/sqrt(Hz).
Generically, since stages can have 2, 3 or 4 actuators, this becomes
Torque noise = sqrt(nActuators) * Force Noise * lever
The logical flaw in my old code was that I dropped the *square* of the noise terms within the square root, and skipped directly to the answer equation:
(Torque noise)_BAD = sqrt(4 * Force Noise^2 * lever)
(Torque noise)_BAD = sqrt(4 * lever) * Force Noise
thus because the lever arms are less than 1 [m], then (Torque noise)_BAD is *over* estimating the noise contribution by a factor of 1/sqrt(lever), because
right Torque noise sqrt(nActuators) * Force Noise * lever sqrt(lever)
----- = ------------------ = -------------------------------------------- = ----------
wrong (Torque noise)_BAD sqrt(nActuators) * Force Noise * sqrt(lever) 1
Super dumb.
The code in which this problem lies for the HSTSs is
${SusSVN}/trunk/HSTS/Common/FilterDesign/Scripts/plothstsactuatornoise.m
which has now been fixed as of rev 11354.
I'll slowly but surely work my way through the rest of my actuator noise functions for other SUS types, and update the actuator noise curves for the noise budgets of those other SUS types too. Eventually.
The attached plots show the individual and full 6x6 regression coherences between the PR3/SR3 and HAM2/5 GS13 signals. The loss of coherence around few Hz supports (at least does not rule out) the damping actuator/sensor noise contribution to PR3/SR3 damping signals noise. The regression was done in the frequency domain.
Images attached to this comment
You can find .mat files of the above noise budgets in the SusSVN under
/ligo/svncommon/SusSVN/sus/trunk/HSTS/Common/FilterDesign/MatFiles/
dampingfilters_HSTS_H1SR2_NoSQRTLever4ActNoise_2022-10-11_model.mat (HAM5 ISI Input, M2 and M3 stages with 10x gain modified TACQ drivers)
dampingfilters_HSTS_H1SRM_NoSQRTLever4ActNoise_2022-10-11_model.mat (HAM5 ISI Input, Only M2 stage with 10x gain modified TACQ drivers)
dampingfilters_HSTS_H1FC1_NoSQRTLever4ActNoise_2022-10-11_model.mat (HAM7 ISI Input, all TACQ drivers as originally designed)
The struct that contains the noise budget is opticDisp. It's a 1x6 struct, where the 6 elements are the 6 DOFs, in L=1, T=2, V=3, R=4, P=5, Y=6 order. So, to plot the FC1 pitch plot from above,
>> fc1 = load('dampingfilters_HSTS_H1FC1_NoSQRTLever4ActNoise_2022-10-11_model.mat');
>> loglog(fc1.freq(:),[fc1.opticDisp(5).seismNoise,...
fc1.opticDisp(5).senseNoise,...
fc1.opticDisp(5).stage(1).acttrNoise,...
fc1.opticDisp(5).stage(2).acttrNoise,...
fc1.opticDisp(5).stage(3).acttrNoise,...
fc1.opticDisp(5).total(:)]);
where hopefully the struct's field names are self-explanatory enough that you can immediately understand which trace is which.
Everything else relevant is also saved within the mat file as well, so if you're interested in how to use that content head to the design scripts as usual,
design_damping_HSTS_20221011_H1SR2_NoSQRTLever4ActNoise.m
design_damping_HSTS_20221011_H1SRM_NoSQRTLever4ActNoise.m
design_damping_HSTS_20221011_H1FC1_NoSQRTLever4ActNoise.m
Though you'll likely not be able to run them since they call from 5 or so svn repositories in disparate locations. That's why I save the finished workspace to a matfile!
Attached are the entire collection of plots for all DOFs that are typically included in the design.
Non-image files attached to this comment