1 / 53

D0 Level 3 filters

D0 Level 3 filters. Dan Claes Moacyr Souza U. of Nebraska Fermilab / Lafex - Rio de Janeiro. Dzero Collaboration Meeting November 9th, 2001. status of ScriptRunner status of Filters/Tools status of L3 Monitoring. Digest the coor commands and

vbeard
Download Presentation

D0 Level 3 filters

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. D0 Level 3 filters Dan Claes Moacyr Souza U. of Nebraska Fermilab / Lafex - Rio de Janeiro Dzero Collaboration Meeting November 9th, 2001

  2. status of ScriptRunner • status of Filters/Tools • status of L3 Monitoring

  3. Digest the coor commands and • act according • status: working properly after some • re-arrangements with L3 Frame • Build/append/delete pieces of the execution tree, on • demand. • status: working properly • Do the Filter Dispatching • -Execution tree implemented as a linked list pattern • -Intended behavior : never hear about it! • 1) No logic involved • 2) There is only one way to go : otherwise -> crash • This is how robustness was insured • status: No complaints! (never heard about!) • Gather status & statistics and send Monitoring data • to servers : I will be taking about at the end

  4. L3TJet Tool • seeks 95% rejection of L2-accepts, relying on • the high precision calorimeter readout available • in L3 and the improved energy and position • resolution this makes possible • identify (and reject) low-ET events passing L2 trigger • sharpen the turn-on curve • may need to introduce additional kinematic cuts • dijet mass, jet-lepton angular separations • Resolutionsobtained by comparing L3 jets to MC jets • 1/ E dependence • with best fit constant term of • 0.87 (central calorimeter) 1.16 (forward calorimeter)

  5. L3TJet Tool leading jet pT for JT_HI failed and passed events JT_HI CJT(1,10) JET_15(MinEt=15) 18.5 JT_LO CJT(1,5) JET_10(MinEt=10) 8.77 Rejection:

  6. For development studies Electron Tool currently implemented by filtering on highly electromagnetic jets • applies cut on emfrac • calculated within thecalorimeter cluster tool • EM_LOW: CEM(1,5) PT>7 GeV emfrac>0.9 • EM_HIGH: CEM(1,10) PT>11 GeV emfrac>0.9 • final runs (132947-133014) before shutdown375K events • included a substantial subset of Mark & Pass’ed events offline studies by Ia Iashvili (UC-Riverside)

  7. from 32117 Mark&Passed events CEM(1,10) PT>11 GeV emfrac>0.9 Rejection = 5.5 sharpens the turn-on (emfracalone = 3.6) efficiency as a function of PT recalculated w.r.t. Z=0 PT EM (GeV)

  8. from 32117 Mark&Passed events CEM(1,10) PT>11 GeV emfrac>0.9 with the added OFFLINE Good EM Requirements: EM fraction > 0.9 Isolation<0.2 HM41<200 ||<0.8 efficiency as a function of PT recalculated w.r.t. Z=0 PT EM (GeV)

  9. No bias observed between filtered and M&P data All events Passed events ISO Emf HM9 HM41

  10. from 525 Mark&Passed events CEM(1,5) PT>7 GeV emfrac>0.9 Rejection = 15 (emfracalone = 2.7) efficiency as a function of PT recalculated w.r.t. Z=0 PT EM (GeV)

  11. L3 EMCertification Ulla Blumenschein (Mainz) Single electron efficiency in CC fiducial region vs electron pT L3 EM objectwith EMFR>0.9with track matchwith CPS match

  12. proposed L3TEleElectron Tool Plan to come up running a fully functionaltool with the following available functionality: • applying a cut only on emfrac • should duplicate the conditions we ran under at shutdown • possibly more rejection available with • isolation cut • offline (and parallel Mark&Pass filters) will study • harder shower shape cuts • preshower calls will be implemented when CPS available

  13. L3TCPS Central PreShower Clustering Tool authors: Andre Turcot (BNL),Chunhui Han(MICH) • Combine contiguous stripsabove threshold • intosingle-layer- clusters (SLCs) • for each layer and hemisphere. • Apply a SLC energy threshold cut • Search for geometrically allowed combinations • (of one SLC from each layer) • matched within position errors • and with a reasonable energy correlation Implements L3Region and localized clustering. (with either f or h-f from electron or photon tool) Once CPS readout is commissioned ~2 weeks to implement into L3Ele

  14. L3TCPS Tool PERFORMANCE • Efficiency defined as • clusters matched within 20 mm divided by • number of pT>5 GeV ewithin CPS fiducial • Z0e+e- with 6 Min Bias events • Efficiency=293/296 = 99% • t t events with 7 Min Bias • Efficiency = 76/93 = 82% • J/ (low PT) study (for events passing L1/L2) • Efficiency = 76/93 = 86% • QCD20 sample passing L1/L2 • Rejection=17 (track/CPS/cal match) Timing Regional clustering =2ms Unpacking = 5 ms

  15. l3fCalMEt Missing Et Tool author: Lee Sawyer(Louisiana Tech) • calorimeter cell-based tool • L3TCalUnpToolprovides unpacked cell information • assumed to include ICD/MG sampling corrections • CAL energy stored (assuming nominal (0,0,0) vertex) • Missing Et calculated through intermediate hring sums • L3TPrVtxToolreturns the most probable primary vertex • recalculate ring sums using primary vertex • currently uses the nominal (0,0) • calculates Missing ET,, fMET, scalar ET, and • Missing ET significance • no muon correction included yet • Ready to run pending certification studies

  16. SMT Unpacking & Clustering Scales with the number of clusters avg time avg #clusters

  17. CFT Unpacking & Clustering Scales with the number of clusters avg time avg #clusters spread here due to sorting fibres into order

  18. CFT Tracking Algorithm - L3TCFTTracker Principal author: Ray Beuselink(IMPERIAL) Daniela Bauer, Robert Illingworth • Initialization x,y,f positions of every fiber calculated • stored in arrays for fast lookup • Track-finding in selected L3Regions or across entire detector • Adjacent hits merged into clusters • and average x,y,f position stored • Single track may physically cross no more • than 3 adjacent fibers in any doublet layer. • Clusters longer than 3 not used. • Tracking proceeds in 2 stages:axial followed by stereo. • Separation permits axial tracking alone. • A fast circle fit (axial layers) • identifies candidates as arcs thru the origin. • A straight line fit in the Sz-plane • determines the track helix parameters • S is the arc length traversed in the xy-plane y 0 Sxy x d0 R  a0 (xc,yc)

  19. CFT Tracking Algorithm - L3TCFTTracker • “Link-and-tree” Algorithm - developed for TASSO, used by ALEPH • Links join clustered hits from different layers • radius calculated of the circle thru both clusters and the origin • must exceed radius corresponding to selected PT cut • even a 0.5 GeV/c cut reduces combinatorics dramatically • Links across a missing layer allowed (up to two total missing layers) • Starting from a link in the outer layer, candidate track paths built by • adding links from adjacent layers to extend path length • if curvature consistent with preceding link • continues recursively. • The longest extended path found starting from the initial link • is kept as a track candidate

  20. L3TCFTTracker Example Resolution plots for Z->μμ See DØ note 3779 for performance studies.

  21. Example Resolution plots for Z->μμ

  22. L3TCFTTracker Status • Some final coding to complete and test • followed by • Certification • L3TVertexFinder • First version of a Primary Vertex tool in test release • designed to run from CFT tracks, but • being expanded to include the global tracker • (requires minor mods) • Certification Ready for online testing~January, 2002

  23. L3TSMTTracker - Silicon Microstrip Tracker author: Daniel Whiteson(BERKELEY) • modified “link-and-tree” method - segments connect neighboring hits • between points within Df=0.4 (tunable parameter) • segment paths are linked if z-slope within 0.2and Dfwithin 0.015 • (both tunable parameters) of previous segment • without seed info, begin with outermost SMT layer, • Look for longest paths toward center • Longest paths fitted to a helix. • Path with smallestc2selected - its hits marked as in use. • Paths are to have 4 hits, and not > 2 consecutive missed layers. • SMT divided into 24 15Osections. Track segments may cross • boundaries, but not skip sections. • Hits on disks ignored.

  24. L3TSMTTracker - Efficiency & Purity Studies Event sample Efficiency Purity Hits per track msec/evt correct/incorrect Single 5-GeV m .788 1.0 4.55/ .005 7.44 (1000 events) Z m m .784 0.929 4.45/ .111 51.3 (100 events) Z t t .740 0.930 4.51/ .131 50.2 (100 events) Efficiency:c2<1.0 and Pt >1.0 GeV cuts applied to all tracks “missed” tracks lack full 3D info - z position placed at strip center

  25. Level 3 Global Track Finding author: Daniel Whiteson(BERKELEY) • preliminary results on a global (SMT plus CFT) stiff track finder • Find axial CFT tracks • Track “stubs” - CFT axial hit pairs in outer two layers (X7 and X8) • having df/dr < maximum value determined by Pt_min • Linear extrapolation of each stub predicts crossing at next CFT layer • hits within df/dr added if do not increase c2 by more than 35.0 • Axial tracks required to have 7 hits. • Match stereo clusters • For a given axial track stereo clusters reconstructing z within CFT • hit pairs on outer layers U4 and V4 linearly extrapolated • sequential least-squares estimate updated w/hits at each radius • CFT track requires at least 7 axial hits matched with stereo hits • Extend into SMT • A fully fit CFT track can be propogated into SMT • (see preceding description of SMT Track Extension)

  26. Level 3 Global Track Finding author: Daniel Whiteson(BERKELEY) • Uses raw data from CFT • Uses 1-dimensional raw data from SMT to avoid cluster ghosts • Combines CFT and SMT information in a globally • rather than simply extending tracks from CFT • SMT information helps improve resolution and reject fakes • Employs an adaptive histogramming technique for stereo tracking • Time depends on PTmin threshold & number of tracks in event

  27. Efficiency Studies Event sample Pt cut Efficiency Purity Hits per track correct/incorrect Single 5-GeV m 0.0 GeV 1.001.00 10.8/ 0.03 Z m m +0 minbias 2.0 GeV 0.971.00 9.95/ 0.34 3.0 GeV 0.961.00 10.4/ 0.24 5.0 GeV 0.991.00 10.6/ 0.17 10. GeV 1.001.00 10.6/ 0.17 Z m m +2 minbias 2.0 GeV 0.94 0.99 9.92/ 0.43 3.0 GeV 0.97 0.99 10.2/ 0.38 5.0 GeV 0.97 0.99 10.7/ 0.39 10. GeV 0.98 1.00 10.5/ 0.31 Z t t +0 minbias 2.0 GeV 0.96 1.00 9.93/ 0.43 5.0 GeV 0.97 1.00 10.3/ 0.38 10. GeV 0.97 1.00 10.3/ 0.43 Z t t +2 minbias 2.0 GeV 0.90 1.00 9.44/ 0.72 5.0 GeV 0.96 1.00 9.75/ 0.74 10. GeV 0.98 1.00 9.69/ 0.77

  28. Proposed Level 3 SMT-only Tracker author: Daniel Whiteson(BERKELEY) single track (SMT-only) filter now under study using data to provide additional rejection to current muon, jet filters

  29. Runs 132167-8:SMT (4 hits)tracks 13000 evts(magnet on) #tracks vs trk at DCA DCA(cm) vs  sine wave also seen offline (vertex not centered) straight bands show noise DCA (sine wave subtracted out) tracks within Gaussian are highly pure

  30. Runs 132167-8:SMT (5 hits)tracks 13000 evts(magnet on) #tracks vs trk at DCA DCA(cm) vs  sine wave also seen offline (vertex not centered) straight bands show noise DCA (sine wave subtracted out) tracks within Gaussian are highly pure

  31. Filtering data with a simple SMT track Vertexer SMT tracks examined for 2 or more with close z-positions at DCA Z MC QCD (PT>20) Data Maximal Z-distance between tracks in a given vertex

  32. vertex filtered SMT-only efficiencies Min pT (GeV) Z-distance (cm) QCD, pt>20, 2.5mb Zmm, 2.5 mb data runs 130167-8

  33. L3 Primary Vertex Algorithm author: Guilherme Lima(UERJ/Brazil) D0Note # 3592 - J. Zhou, J. Hauptman, and M. Narain • Sort SMT barrel hits in f • Define f-slices up to 50 hits or f = 0.2 maximum • discard slices with < 10 hits • De-ghost by defining roads using 2o stereo hits and then • use 90o hits only when within the road • Pair hits with Df<0.05 rad and Dr > 1 cm • Histogram z-axis projections (with 1 cm bin width) of all • hit pairs in each slice • Threshold selects vertex candidate peaks for each f-slice • Sum slices counting number of slices contributing to, • and total # of entries in, each candidate peak. • Discard candidates with <3 contributing f-slices • Assign probabilities of (#entries) x (#slices) • Merge candidates with separation < 0.5 cm

  34. L3TPrVtxTool Efficiency Studies Dependent on event topology t-tbar 5000 events X to b-bbar 250 events B to yKs, y to m+m- 1000 events B to yKs, y to m+m- 1000 events Prompt y to e+e- 1000 events W to mn1000 events W to en1000 events Z to mm1000 events Z to ee 1000 events Z to tt1000 events g + jet 1000 events Generated hits Reconstructed hits Eff(%) Resol(mm) Eff(%) Resol(mm) t-tbar 93 620 79 2000 B yK 94 510 43 1100 QCD 95 500 66 1500 Has yet to be tested on REAL DATA

  35. L3TMuon author: Paul Balm(NIKHEF) Martin Wegner, Martin Grunewald (Aachen) L3TMuoUnpack (unpacking tool) run successfully in ONLINE tests but not yet independent of rapidly changing configuration files fix provided by Scott Snyder to be implemented & checked • L3TMuon, skeleton version of full global muon tool calls: • L3TMCT, the calorimeter confirmation tool • L3TMuoCentralMatch (callsa central track tool) • Provides Tracker with region to look for tracks. • Tracks matched at muon A layer using a  2 based on  and  • extensively studied w/1000-event 5GeVpT single muon sample • but not yet with real data • Performance studies and certification of these features underway

  36. interimL3TMuonfunctionality collect Mark & Pass data filtering on local muon track reconstruction only: • L3TMuoLocal (RunI-style segment finder) • Fast reconstruction of the local muon track • reconstructs track segments using the space points (hits) within • a single module • links segments before and after toroid to make full track • narrowing down h,f and PT • adapts OFFLINE segment and local track algorithms, • introduces FAST segment finder • pending the • unpacker’s independence of configuration files and • confirmation of a memory leak fix

  37. Continue development and testing to • stage additional Muon Tool functionality • January, 2002? • L3TMuoCentralMatch • callingL3TCFTfast central track tool when track readout available • studies completed with single muon andBJ/ KsMC samples, • but performance tests and certification w/real data still to be completed • L3TScint author: Victor Koreshev(IHEP,Russia) • constraining track parameters with narrow scintillator time window • L3TMTC • verifying MIP trace thru the calorimeter

  38. timing Paul Balm(NIKHEF) L3TMuon 1000 BJ/ Ks MC sample L3MuoUnpacker/calibration 3 msec/event (unpacking of SMT+CFT+Muon 21 msec/event) GlobalTracker 7 msec/event SMTTracker 10 msec/event CFTTracker >133 msec/event (~15 overflows) L3Tmuon tracking 66 msec/event L3TMuoCentralMatch 4 msec/event ~70ms/evt forlocal muons only ~95 ms/evt withGlobalTracker match 1 GHz Clued0

  39. L3FTauHadronic Level3 TauTool author: Gustaaf Brooijmans (FNAL) t • pursuing two approaches • Calorimeter-driven search: • Starts with • L3TCalCluster pT>1GeVproviding cluster widths and profiles • ET>3GeV width<0.3 profile>0.25 • L3TCFTTracker provides pT>1GeV tracks, collect those: •  <0.25  <0.4 • Track-based search: • Starts from • L3TCFTTracker providing pT>1GeVCFT • (cluster tracks w/R<0.3), order in , match with • L3TCalClusterclusters Certifying code, plan to get non-optimized filter into triggerlist, gather information online for tuning under online conditions

  40. Some Timing Estimates Tool Timing Estimate CalUnp 10 msec/event CalCluster <1 msec L3jet <1 msec CPS unpack <1 msec CPS clustering <1 msec SMTunpack 10 ms(~1/2 spent clustering) SMT Tracking 10 msec Global Tracking10 msec CFTunpacking 2 msec(~1/3 spent clustering) PrimVtx(SMT) 2 msec MuoUnp 3 msec MuoSegment <1 msec MuoTrackFitting 66 msec (J/ study) on typical (QCD) events to cluster calorimeter cells and get a primary vertex ~40msec. muon events ~70msec with Global trackmatch ~90msec.

  41. Last Run: medium luminosity (6E30) -no software vertexing was run 120-150 msec avg, but with LONG tails (most often due to muon) FILTERING time broke down as At 145 Hz into Level 2, the nominal budget was <Tnom> = Nnodes/ Hz In = 45/145 = .31 sec = 310 msec. Queuing theory warns of deadtime within 0.7 to 0.8 of this number. This was the "wall" hit at around a 220-250 msec processing rate. mu 55 % jet 16 electron 13 Missing ET11 Mu confirmation 2 Sum ET 2

  42. L3Monitoring SR duties (other than make the filters dispatching) • Fill the L3Chunk • For each filter, record • - status : passed/failed (and called) • - Unbiased : L3Unbiased • L2Unbiased • “forced_unbiased” • - L3prescaled • - others • Fill the Debug Chunk (on demand) • - can vary • Fill the Event_Header • For each event, record : • - L1 active && fired bit mask • - L2 active && fired bit mask • - L3 active && fired bit mask • - Streaming information • - run #, event #, Luminosity Block, data_size, ...

  43. L3Monitoring • Send monitoring information at a given heart beat • For each filter, record • - Rates : # called , # passed • - Special events : # L3Unbiased • # prescaled • - Others : Histogram of the overall filtering time/per event • … • and time to time, send the Tools’ monitoring data (l3fstatmanager): • per Tool : # of candidates • Timing • Correlations, others … • Send monitoring informationper Luminosity block • For each L2 bit: • - # events received • - corresponding L2 bit number • - L3 bit names (l3scripts) • - L3 prescale factors • - # events passed, per filter • - # events failed, per filter • - # events L3Unbiased

  44. All this is already implemented in the SR side • All monitoring information are grouped in the • L3MonChunk • and SR currently gathers all this information and • inserts it into (L3MonChunk) • There is only one heart beat: • whenever the luminosity block index changes • Any other persistent data can be added!

  45. For the L3 Monitoring Server : • In the SR / l3fchunk side: L3MonChunk methods • (together they allow the implementation of the monitoring server) • L3MonChunk operator + (L3Monchunk &c1, L3MonChunk &c2) • implement the sum of all elements belonging to the • L3MonChunk private members. This is, of course, crucial to the • monitoring server implementation. • Void makeMonString( std::string &) : information for the Daq_Monitor server • This method produces a string with all the monitoring information • in a format readable by the L3 monitor server. • void makeString( std::stringt &) : information for the Luminosity server • This method produces a string with all the monitoring information • per luminosity block and all other information, in a format • readable by the luminosity monitor server.

  46. L3 Monitor Server : • Main ingredients: • Register nodes at start of run time • Receive data from the Linux nodes and store them on node’s ( or process ) boxes • Set up an alarm to time out nodes that overflow the time slice allotted • Sum up information from all active nodes ( processes ) when either all nodes are • done or if the alarm fires • Produce (string) messages with all the information assembled according, to be sent to • - Daq_Monitor_Display server • - Luminosity server • At the end of run time ( for all or for some nodes ) • send information to the Run Summary server AND • clear all boxes for those nodes ( processes ) that • ended.

  47. L3Monitoring L3 Nodes L3 Nodes L3 Nodes L3 Nodes Information (L3MonChunk as a d0omStream object) is sent, as ITC messages, each time that the luminosity index changes Here the information from all actives (not timed out) nodes are summed up L3 Monitor Server Alarm Statistics, rates,…, for this luminosity index value DAQ Monitor Display Luminosity Server Rates, timing, ... so far To be implemented Run Summary Server

  48. The L3 Monitoring Server • Progress/Problems in the last (NT) run • Progress: • During the past beam run with NT nodes, we were able to run the Monitor Server and send information to the Daq Monitor. Also we were able to receive the luminosity monitoring information. • Normally, 4 to 8 NT nodes were active. • Problems: • We had several problems, mostly related to ITC messages framework. • One major problem was that: • A certain number of nodes (2 to 4) always timed out - different ones, though. • That made the monitoring display hard to understand for people not aware of this. • That also made the luminosity information more or less useless, because time outs must be very • exceptional for this (and any other) scheme to make sense. • Hard to debug code in the SR side, because of other higher priorities during beam time

  49. The L3 Monitoring Server: Progress/Problems with Linux nodes We had, so far, none of the problems seen with NT nodes : - no time outs - no corrupted data We have implemented the feature that the server can deal with several processes per node. So far, we had no problems. But we have not yet tested the system at full load, with : - Lots of nodes >> 10 (expected ~100 nodes, 2 processes per node) - Lot of information travelling

  50. L3 Monitor Server L3 Monitor Server L3 Monitor Server Master L3 Monitor Server DAQ Monitor Display Luminosity Server Run Summary Server Taking advantage of the modular design, we may consider the possibilty of : L3 Nodes L3 Nodes L3 Nodes L3 Nodes L3 Nodes L3 Nodes

More Related