Notes from Noise Budget Planning Meeting, Feb 26 2013. Attendees: Chris Wipf Chris Mueller Zach Korth Kiwamu Izumi Anamaria Effler Peter Fritschel Lisa Barsotti Jeff Kissel Cameo: Matt Evans Table of Contents: SESSION ONE (Chris Wipf on eLIGO NoiseBudget) SESSION TWO (Chris Mueller on aLIGO IMC NoiseBudget) SESSION THREE (Long digression into "how should we wrap loops around the optickle model?") SESSION FOUR (Jeff Kissel on "Basic" SUS / Cavity NoiseBudgeting using Seismic Noise projected to Suspension Point) SESSION FIVE (Zach Korth on Common Mode Servo Modeling with LISO/Matlab) SUMMARY Conversation (Action Items) APPENDIX 1 SESSION 2013-02-26 (The Lame Organizational Stuff) SESSION ONE (Chris Wipf on eLIGO NoiseBudget) G1300138 Figure out how to get slow channels! - conlog? - get a time series and average? - stored in frames? - would like some easy script friendly way GOOD IDEAS: Look into Brian's asd2, tfe2, and coh2 for estimating amplitude spectral densities, transfer functions, and coherence include a link to the aLOG in the .mat of reference measurements Reference .mat files should share a similar format Obvious missing terms for DARM: SRCL ESD Driver Noise Newtonian Noise Residual Gas Noise Frequency Noise Update the Quantum Noise (Include Correlated Quantum Noise for GWINC as "ideal," but still have uncorrellated to account for junk light, and have it be a direct measurement of it, etc.) Magnetic Coupling SCOPE: - Noisebudget all length degrees of freedom, anglular? YES YES and YES - How to make more than one plot? - directory structure for different noises? - One directory structure so we can relate/intertwine coupled degrees of freedom? - Matlab for sure - Try to get away simulink (maybe not needed?) (See discussion below!) - Will be using LISO - Optickle? SESSION TWO (Chris Mueller on aLIGO IMC NoiseBudget) H1 doesn't work (did for a bit) save plots and enough data to reproduce the plot predicts the control signals (to see if we understand the noise) predicts the output frequency noise Goal was to make a model, compare against measured transfer functions, but then once they agree, through out the measurement in favor of the model Is this the right approach? - Modeled Noise and Modeled Transfer Functions? - Measured Noise and Modeled TFs - Modeled Noise and Measured TFs - Measured Noise and Measured TFs atom structure should be versatile enough to be able to include a spacer for both Cool Stuff: - Sub-budgets for each term! Awesome idea, but let's just build the structure that's drill-down able. We'll need to do sub-budgeting anyways for the auxiliary degrees of freedom, so let's just build in the capability - Function to measure Coherence between two curves? (Not really a noise budget issue, can be done with existing software, etc.) Pros and Cons - Liked having a full loop model - Simulink block diagram is sort of built in documentation - uses get_data to query for filter bank states SESSION THREE Long digression into "how should we wrap loops around the optickle model?" - Simulink - Pros: once you make the loop diagram you would already make, you're done; easy to add noise paths and spigots and such - Cons: linmod may poorly reproduce the response? Need to quantify further... - Lentickle - Pros: Already built infrastructure in the same vein of optickle - Cons: may be inflexible, may require require some rewriting to get it as versatile as we want - Connect and Append - Pros: Very simple, no-nonse stuff -- interfaces well with suspension models well - For large systems, it's difficult to keep track of the connection matrix (may be able to wrap around connect and append to make it more user friendly) - Jan Harms GUI interface to optickle? LUXOR What models do we need: DARM loops MICH SRCL Common Mode Loops (CARM, PRCL, IMC, FSS) ASC models (CommHard, CommSoft, DiffHard, DiffSoft, etc) A little more discussion of "how should we wrap loops?" but with M. Evans included. - Simulink might be OK. "linmod bad, LTI good" is based on (perhaps) an outdated impression of the capabilities of Simulink. Consider it "innocent until proven guilty," because they may have fixed it. BUT, take the approach of keeping it simple. - This closed loop model should be used merely for turn the closed loop measurement of the DOF's noise into open loop noise, and all other budget terms should be calculated or measured as has done before with "simple" calculations - Keep it in the modular structure, have separate models of MICH, IMC, Common Mode, etc, and treat those in the similar to the eLIGO structure as sort of independent noises that contribute to DARM - A cavity pole will work JUST FINE until detuned IFO. Other degrees of freedom could be cavity poles, but their frequency is too high up to care, so just consider it flat. MICH is flat. PRCL is flat. MICH and SRCL run pretty much independently, Common mode DOFs will have IMC and CARM intimately related, then feed to PRCL, but it should be doable. SESSION FOUR ("Basic" SUS / Cavity NoiseBudgeting using Seismic Noise projected to Suspension Point) Kissel talked about ISI projections -- just to advocate that we should do this in the noise budget projections matrices live in the userapps repository: /opt/rtcds/userapps/release/isc/common/projections/ You can find details in T1100617 infrastructure is in place, but inter-process communication is not yet turned on Kissel used the full projections to form a model of the single arm L, P, and Y, but it DOESN'T predict the cavity (or optic angular) motion In regions around 1 Hz (and maybe above in the future! were it not for the BSC pier motion) Online channels are limited by loop gain (sensor noise), so will get more and more suppressed if the loop gain is increased -- incorrectly displaying the motion as less that it is. So, they we should either Add the sensor noise ONLINE (constantly inject the GS13 noise floor) Or figure out a way to add it offline SESSION FIVE (Zach on Common Mode Servo Modeling with LISO/Matlab) Looks excellent. Looks like the right thing to do. Awesome. We spent most of the time discussing what discrepancies there were specific to the CM Board measurements. From his work, we should take advantage of his measurements as well as the model. SUMMARY Conversation (Action Items) We'll continue to use a similar infrastructure as was developed for the eLIGO noise budget, which has an "atom" script for each noise source. Where modeling is required (i.e. closed loop models), we will use simulink until it fails us. Decision was based on the following - GUI diagrammatic interface is excellent, self documenting - IMC model has already been built - interfaces well with suspension models - "Connect and Append" methods obfuscate what simulink does, probably similar action under the hood - It isn't easy to add new noise-injection ports to Lentickle infrastructure - No one really knows the status of LUXOR, would have to maintain it - Suspicions of "badness" may be outdated, recommended that we proceed until it fails, with efforts to keep the models as simple as possible - DARM loop model used by NoiseBudget Group and Calibration group should (and will be) the same. - Chris M and Chris W -- put together a "first article" template atomNoiseTerm.m using shot noise as the first example - Zach, Chris W (w/ Jeff K) -- Get started with LISO models of SUS coil drivers - Jeff K -- will put together a simulink model of DARM loop (for inverting closed loop DARM ASD to open loop DARM ASD) - Jeff K -- Figure out how to get slow channels! (Especially back in time, and Offsite) - conlog? - get a time series and average? - stored in frames? - would like some easy script friendly way - Peter F -- Figure out/compare pwelch vs. asd2 -Jeff K -- DAC Noise and ADC Noise reference measurements - Chris M -- Common Mode Servo Model - What're the ranges that we'll need in the actuators? Is the common mode servo suppressing the noise enough? - Look at the crossover between the additive offset an the mode cleaner length path? - The tons of excess noise needs to be taken out by the VCO - push up crossover from Common Mode Servo additive offset to IMC Common Mode Servo as high as we can get it to limited by the digital system (iLIGO was something like 100 Hz) APPENDIX 1 SESSION 2013-02-26 (The Lame Organizational Stuff) SVN directory structure: NB/ Common/ runMeas.m # Overarching function that runs the (or several sub-) noise budgets Utils/ addNoise.m # Adds noises in quarter plotBudget.m # plots a noise budget based on inputs CommHard/ CommSoft/ DARM/ Common/ runMeas_DARM.m # second-top-most function that runs the noise budget for that degree of freedom atomSeis.m # computes an individual noise source atomQuantum.m # computes an individual noise source atomMICH.m # computes an individual noise source ... DARMmodel.mdl # Simulink model of closed loop system (for that degree of freedom) H1/ Noise/ TFs/ Params/ params_DARM_H1.m # Defines measured basic parameters relevant to degree of freedom (Cavity Poles, Arm Lengths, Reflectivities), also defines which atoms are used, whether to use modeled or measured noises or transfer functions, what channels to get read, L1/ Noise/ TFs/ Params/ DiffHard/ DiffSoft/ CARM/ Common/ atomCARM_Frequency.m atomCARM_OscPhase.m atomCARM_SuspThermal.m IMC/ MICH/ PRCL/ SRCL/ Top-level Script Pseudo Code: params.m (at NB/Common/) IFO, DOFs = {'all'}; or {'DARM';'MICH';'DiffSoft';'DiffHard'}; or {'SRCL'}, measTime = gps('now') or 1046016546 or 'Oct 27 2014 15:30:00 UTC' freq = frequency vector over which to plot runMeas.m (at NB/Common/) % Call NB/Common/params.m params % Switch over the IFO degrees of freedom if strcmp(DOFs,'all') runMeas_DARM runMeas_MICH runMeas_CARM ... runMeas_CommHard else for iDOF = DOFS eval(['runMeas_' DOFS{iDOF}]) end runMeas_DARM.m atomMICH.m atomSRCL.m atomSeismic.m atomQuantum.m atomSuspTermal.m addNoises.m plotResults.m saveResults.m APPENDIX 2 SESSION (Using pwelch vs. FFT-the-whole-thing methods to estimate the ASD) - Both methods are viable - It's a competition between spectral leakage and reducing the variance. - Pwelch chunks up the time series, and takes averages of the periodograms (FFTs) of those smaller segments. - The method used in Brian's asd2 function, is "nearly identical mathematically" (but unnamed in Numerical Recipes), takes the FFT of the entire time series, with higher resolution than needed, and then averages adjacent frequency bins to form a (smaller varience) spectrum of lower resolution to reduce the variance. - Pwelch was invented to decrease computational cost - Both methods need windowing to avoid spectral leakage; in the pwelch method, a Hann (which is sometimes called the Hanning) window, who's average area / weight is 1/2, with 50% (i.e. 1/2) overlap of the chucks is what's typically used for a good balance between spectral leakage and reduced varience. In the FFT-of-the-whole-time-series method, where one would lose half the data by using a Hann window, it makes sense to use a Tukey-style window (which is a Hann window on the edges, with a flat region in the middle). - In our application, it will almost always be true that getting the time series from the frames will out way the difference in computational time between pwelch and FFT-the-whole-thing method - In the noise budget application, where we typically "hit go, and just wait patiently for the plot," it seems that it's natural to gather all the data, and use Brian's asd2 function which performs the FFT-the-whole-thing method. So for now, we'll start with the following parameters - Use asd2.m (which uses the FFT-the-whole-thing), - 50 avg - 0.1 Hz resoultion - (i.e. 500 seconds (8.3 minutes) of data) Consider ideas of using 0.5 Hz resolution for Full Span, then have other spans (low frequency high resolution, high frequency low resolution, etc). We don't want each atom to get 500 seconds of data consecutively. How to get around it? Have which atoms are used, the channels needed, and whether to use "live" measured data, reference data, or a model, defined in the interferometer's parameter file, i.e. ${40mSVN}/NB/aLIGO/DARM/L1/Params/paramsDARM_H1.m Then at the top of runMeas_DARM (or any DOF's runMeas), we get all the data at once, then pass it around through all the atoms. Some of the atoms won't use the data, that's fine. Is that too much data to pass around? Let's say a noise budget has at most 15 noise terms (atoms). 5 of those will be models, 5 are made of reference data. Of the 5 that left will get data, let's say they'll need 10 channels at worst (most may need one or three. Seismic and Newtonian Noise will need the most, but they're sampled at a lower rate anyways). On average, the channels will probably be stored at 2048 Hz as floats (32 bits/sec). So that's a data structure of time series that's 5 [live-data-atoms/NB] * 10 [channels/curve] * 500 [sec/channel] * 2048 [samples/sec] * 4 [bytes/sample] = 204 MB tossing around a 200 MB structure of data, doesn't seem impossible / impractical. Summary Summary: Near Term Things - Use LISO models of HSTS driver noise inside IMC noise budget model - Get measurements of ADC and DAC noise into reference measurements - Update IMC noise budget model to have the atom structure - For DRMI -- noise budget the MICH DOF - For HIFO -- may not be a point, but if we see lots of mystery in the frequency noise, then it's worth budgeting. Will consider further.