1 / 14

Validation and RTT in the new xAOD Framework

Validation and RTT in the new xAOD Framework. Bruce Schumm, UC Santa Cruz For the ID Val/RTT Task Force Tim Adye, Max Baugh, Nick Edwards, Goetz Gaycken, Heather Gray, Simone Pagan Griso, Qi Li, Soeren Prell, Shaun Roe, Basil Schnieder, Bruce Schumm, Nick Styles July 8 2015.

abbott
Download Presentation

Validation and RTT in the new xAOD Framework

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. Validation and RTT in the new xAOD Framework Bruce Schumm, UC Santa Cruz For the ID Val/RTT Task Force Tim Adye, Max Baugh, Nick Edwards, Goetz Gaycken, Heather Gray, Simone Pagan Griso, Qi Li, Soeren Prell, Shaun Roe, Basil Schnieder, Bruce Schumm, Nick Styles July 8 2015

  2. Motivation and Outline • Of course, need to move into new xAOD framework • Opportunity to rethink / further codify approach to validation and monitoring • Real-Time Testing (RTT): “Nightly” (daily) snapshot of tracking CP on a number of physics samples (single particle, Zμμ, ttbar, minimum-bias) • Validation: More detailed review of tracking CP and MC simulation for fixed releases • This will be a status report, with some points of current discussion highlighted

  3. Overview • New package, InDetPhysValMonitoring, developed from scratch (Shaun Roe) to replace prior InDetPerformanceRTT package. • Uses “decorated” xAOD; decorator algorithm runs a number of tools developed by Shaun that restore detailed information to tracks nominally missing from the xAOD collections (e.g. hit info) • Skeleton and basic functionality in place • One exception is hit residuals; should be available soon • Fine details (fiducial region, track quality) still under discussion • Survey relative to prior (InDetPerformanceRTT) functionality for RTT and Validation (missing plots, plotting format) completed; missing areas being addressed • Hope to have rudimentary system implemented in nightlies (RTT) soon, with DCube comparison between monitored and reference • But finalization of underlying package will continue for some time

  4. RTT Functionality: DCube Plots • Resolutions, pulls and biases for the five track parameters, as functions of both PT and  • Tracking efficiency vs.  • Many categories of hit content of tracks: No. of Blayer, pixel, SCT, TRT hits, holes, shared, etc. • Hit efficiencies by system • Hit residuals in pixel, SCT, TRT • Tracking efficiency and fakes within jets “Validation” task has substantially more plots; won’t list functionality here (still parsing the list in fact)

  5. RTT Interface for Shifters

  6. ttbar sample • Can be added: • Fake (low matching probability) and duplicate (two tracks to same MC particle) rates for general tracking • Tracking efficiency vs. PT

  7. Fiducial Region • We have typically had three categories of tracking that we monitor: • General tracking • Outside-in tracking; i.e. BackTracking (TRT standalone tracking?) • Tracking for Minimum Bias events • For the calculation of tracking efficiency, the following have been identified as criteria to be considered in defining “trackable” particles • 1) Charged • 2) Stable • 3) Not a strange baryon • 4) Include/exclude descendants of KS or , or e+- from a conversion • 5) Within specified eta range • 6) Above specified Pt cut • 7) Originates within specified radial extent • 8) Track provenance (inside-out, backtracking, TRT standalone) • 1) and 2) are always applicable; 3) comes from the MinBi analysis and would probably be fine for all types. 4) must be included for outside-in tracking. 5), 6) are probably the same for all; 7) must be relaxed for outside-in; for 8), MinBias requests only inside-out tracks

  8. Fiducial Region II Propose three fiducial-region configurations (please comment) *But makes use of special low-PT tracking for reconstruction • Implemented via new TrackTruthSelectionTool (Nick Edwards) in InDetPhysValMonitoring package • Configures via a string; more configurations can be implemented • Determines “denominator” of tracking efficiency calculation

  9. Track Quality Cuts • Following are the loose cuts for inside-out tracks, from InDetTrackingPerformanceGuidelinesTwiki, which claims that they are applied during reconstruction and thus do not need to be applied again to the collection • pT > 400 MeV: Note that we consider the pT cut to be a physics cut and, as such, is likely to be application specific. Therefore we list the cut that is used in track reconstruction here, but it does not form part of the official recommendations. • |η| < 2.5 • NSi ≥ 7 • Nshmod ≤ 1 • NholeSi ≤ 2 • NholePix ≤ 1 • Addition cuts define loose-primary • Either (NSi ≥ 7 and NshSi = 0) OR NSi ≥ 10 • and tight • NSi ≥ 9 (if |η| ≤ 1.65) • NSi ≥ 11 (if |η| > 1.65) • NIBL + NB-layer > 0 • NholePix = 0 Additionally, for the numerator of the tracking efficiency calculation, we can apply a truth-matching probability (0.50?)

  10. Track Quality Cuts II • Some questions regarding track quality cuts… • Do we want to apply tighter cuts? • Same cuts for MinBi as for other analyses? (“Yes” for current RTT/Validation) • Separate treatment for muons and electrons? (“No” for current RTT/Validation) • What about outside-in tracking? • Another question for outside-in tracking: Just BackTracking or also TRT-standalone?

  11. This and That… • Diamond Beam Monitor (see next slide): do we include in ID RTT/Validation? Under discussion (thoughts?). • Need to incorporate package into RTT “nightlies” system (Goetz is working with Brinnick; nearly done, but just ttbar sample for now). • Post processing: Validation makes use of large samples divided between numerous files  “post-processing” step must be included to combine files before performance assessment (Soeren Prell)

  12. Diamond Beam Monitor (DBM)

  13. Projected Timelines A little hard to say… but some guesses: InDetPhysValMonitoring package should be in the RTT stream (ttbar sample at least) within a week(?), but code in package will still need work before output is useful for nightly monitoring. Hoping that InDetPhysValMonitoring package will mature over the next few weeks to month. This will include outside-in tracking (BackTracking and perhaps also TRT Standalone Tracking) DCube will also require some configuring (which plots for which samples), but may happen in parallel with the final stages of code development Validation will require additional post-processing step, and the implementation of many more plots. Probably will be a few weeks longer before that rolls out. I could be totally wrong about any of this, in either direction!

  14. BACKUP

More Related