1 / 20

STT simulations (Horst Wahl, 25 February 2000)

STT simulations (Horst Wahl, 25 February 2000). trigger simulation (Silvia Tentindo-Repond, Sailesh Chopra, John Hobbs, with help from Brian Connolly, Harrison Prosper, + Dave Toback) queueing studies (Stephan Linn). Outline:.

espen
Download Presentation

STT simulations (Horst Wahl, 25 February 2000)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. STT simulations(Horst Wahl, 25 February 2000) • trigger simulation • (Silvia Tentindo-Repond, Sailesh Chopra, John Hobbs, with help from Brian Connolly, Harrison Prosper, + Dave Toback) • queueing studies • (Stephan Linn) Outline:

  2. STT trigger simulation(Silvia Tentindo-Repond, Sailesh Chopra,…...) • STT trigger simulator: • integral component of D0 RunII Trigger Simulator; • tasks: • simulate all components of the STT: • hit clustering (STC) • CTT road information handling (FRC) • hit filtering (STC) • tracking (TFC) • provide tool for optimization of • trigger parameters and algorithms • monitoring parameters • provide tool for determination of efficiencies • L2STT Simulator code split into three packages: • tsim_l2stt (main package) • l2stt_util • l2stt_fitting (for detailed studies of track fitting algorithms)

  3. STT simulation status • presently available functionality • SMT hit clustering: • cluster algorithm: • so far, only one algorithm implemented: neighbor clustering without cap on clustersize, (same alg. as used in L3, but different from algorithm being studied for firmware implementation) • other algorithms foreseen • hit filter: • CTT roads now integrated into main package; • temporarily, use analytic expression for translation from CFT to SMT coordinates • first version of LUT (translation map) available (but based on nominal position -- will need possibility to use real positions) • tracking (with John Hobbs, Wendy Taylor): • l2stt_fitting contains all possible tracking algorithms (for testing); • main package will only have final choice of algorithm • still being debugged • test output: • create a text file that contains SMT hits in cable-format, to be used as an input for debugging and testing of VHDL code for clustering. (RCP switch) • CTT roads: to be done • most of the code committed to CVS t70

  4. Clusters from t tbar events • only from barrels

  5. Clusters from Zb bbar + 2 min.bias events • barrel only

  6. Clusters vs SMT layer from Zb bbar + 2 min.bias events

  7. Clusters from one t tbar event • Clusters from 100 t tbar events

  8. one t tbar event • road centers in SMT • SMT clusters in CTT roads

  9. CTT tracks from Zb bbar + 2 min.bias events • Clusters in roads • nb. of CTT tracks

  10. Queueing Studies(Stephan Linn) • Questions to be answered by queueing studies: • how much processing (e.g. track fitting) time can we afford before deadtime becomes unacceptably high? • where are the potential bottlenecks in the data flow through the trigger? • additional buffering needed? • Queueing simulation software • previously, used RESQ (IBM product) • not supported anymore, only runs on IBM platforms  look for alternative • Ptolemy: • simulation package developed by EE and comp.science dept. at UC-Berkeley • can simulate complex systems at different levels of detail and with different time scales • elements of system represented by “queue and serve galaxies” • specified by service time and queue depth • event defined by starting time and data value (event number)

  11. STT Model in Ptolemy • use available specifications(note by U.Heintz at http://physics.bu.edu/~heintz/STT_q.pdf) • parameterize (from MC data) • Nt = number of tracks per sextant • Nh = number of hits per detector • H = clusters per hit • T = clusters per track • transmission speeds • data sizes • model: • STT modeled as 6 independent sectors • random numbers Nt, (hyperexponential) Nh (double gaussian), track fitting time (double exponential, from JH+WT studies) • correlations between module delay times (depend on Nt, Nh) • PCI bus “arbitration” (priority to road transfer over filtered clusters) • STC filter waits for roads from FRC • (see draft of note by Stephan Linn at http://www-d0.fnal.gov/~linn/d0_private/queue.ps)

  12. STT Queueing model

  13. PCI bus model

  14. distributions used • cluster multiplicity • track multiplicity • track fitting time

  15. Queuing simulation results • latency • for one STT sextant: • latency for one sextant reproduces track fit delay • full system latency: worst-of-N convolution with five other sextants • total deadtime: < 1% (for nominal values) (not counting deadtime due to min. time between L1 accept) • 16 event buffer before track fitting takes care of 50s track fitting time -- never filled to capacity. • no additional buffer necessary

  16. Parameters in queueing simulation • Parameters used in simulation: • number of hits per detector Nh double gaussian with mean = 36, max. = 90 (corresponds to 8 overlapped jet-brew events, with L1 trigger pt > 7 GeV, plus 2% add’l occupancy for noise) • number of L1CTT tracks per sextant Nt hyper-exponential with mean= 2 , rms = 4, max = 32 (corresponds to 6 overlapped jet-brew events, with L1 trigger pt > 7 GeV) • number of hits per cluster H: gaussian with mean 3.6, rms 2.8 (from t tbar events) • timing for tracking: double exponential, with “old” values, i.e. 15s • notes: • changing Nt to 4.8 with rms 8, other parametes unchanged: deadtime < 2% • Z  b bbar + 2 MB events: • Nt = 1.5 (9 per event with rms 5), • Nh = 9, H = 3.9 • for 8 overlapped jet-brew events, Nt = 3.7, rms 6.0 • time for track fitting now much shorter than that used • for 396ns bunch spacing: • for L = 0.8 x 1032cm2 s-1 : mean nb. of int. = 2.3 prob. of 7 int. = 1% • for L = 2.0 x 1032cm2 s-1 : mean nb. of int. = 5.4 prob. of 7 int. = 12%, of 8 8%

  17. Probability of N(interactions)/crossing • For L = 0.8 x 1032cm2 s-1 N(int) 36 bunch 99 bunch 0 0.11219921 0.45137941 1 0.24543345 0.35904841 2 0.2684403 0.142802 3 0.19573587 0.03786381 4 0.10704204 0.00752966 5 0.04683045 0.00119789 6 0.01707344 0.00015881 7 0.0053354 1.8046E-05 8 0.00145888 1.7944E-06 1 or more 0.88780079 0.54862059 2 or more 0.64236734 0.18957218 4 or more 0.17819117 0.00890638 8 or more 0.00190983 1.9666E-06 <N> 2.18747933 0.79544703

  18. Probability of N(interactions)/crossing • For L = 2.0 x 1032cm2 s-1 N(int) 36 bunch 99 bunch 0 0.00421672 0.13688453 1 0.02305996 0.27221098 2 0.06305397 0.27066177 3 0.11494105 0.17941425 4 0.15714448 0.08919658 5 0.17187515 0.03547558 6 0.15665555 0.01175789 7 0.122386 0.00334028 8 0.08366151 0.00083032 1 or more 0.99578328 0.86311547 2 or more 0.97272333 0.5909045 4 or more 0.79472831 0.14082848 8 or more 0.18666714 0.00105815 <N> 5.46869832 1.98861757

  19. TFC timing • From “minimum bias jet-brew” with L1 pt > 7GeV, get mean number and standard deviation for CTT tracks; • parameterize Nt distribution by double exponential with  = 2 ; • integration of this function allows estimate of P(Nt <16) for given number of overlapping interactions • for L = 2.0 x 1032cm2 s-1 , and 396ns bunch crossing time, prob. of > 7 interactions is 18%; for 8 interactions, prob. of more than 16 tracks = 4%;  negligible effect on deadtime. Nint(Nt)(Nt) P(Nt < 16) 1 0.8 1.5  1 2 1.0 1.9  1 4 1.1 2.1 0.997 6 2.0 4.3 0.981 8 3.7 6.0 0.957

  20. Simulation summary • STT trigger simulation tools close to being ready and useful; • tracking part operational; • alternative clustering schemes to be implemented; • LUT for hitfilter to be done • work on providing test output in progress; • caveat: need to ensure that algorithms in trig. simulation correspond to firmware implemented in hardware. • queueing simulation package operational • have STT queueing model which is quite realistic • studies so far show no major bottleneck in design; even for high luminosities and occupancies; • can easily adapt to new specifications as design progresses; • more detailed TFC simulation in progress

More Related