240 likes | 251 Views
Detailed specifications and strategies for "Tight," "Loose," and "Astubs" muon selection for the W/Z group, including criteria, muon quality definitions, and duplication issues. The text discusses the importance of inner tracker contributions, identification methods for different muon qualities, and problems with quality definitions. Additionally, ideas for muon isolation, W/Z to Muons selection, and potential improvements like scintillator timing adjustments and utilizing inner trackers are presented.
E N D
W/Z Muon Selection For Winter Conferences Tom Diehl FNAL @ Saclay 12/2001 “Tight” and “Loose” Muon selection for the WZ group
“Muon Quality” • Specification and Description of • “Tight” • “Loose” • “Astub” • What we have to do for these to be complete • What I know • What I don’t know? • W/Z -> muons selection criteria • Ideas I have or have heard that I liked
Muon Quality “Tight” • Specification for “Tight” • Identify all “typical” muons using muon-only information • All muons available in one chunk & All information about them available in that chunk or from pointers there. • Uses the pieces of the muon detector that are also used in the L1 trigger • It’s used now in • Reco for “Muon-Corrected MET” (Quality=4) • WZ_Reco for streaming from FARM • La Macchina for selecting • Muon_L3
Muon Quality “Tight” • Definition of “Tight” MuonID • Use MuonID chunk • NS!hits(A-layer)>0 (1 @ L1) • NWhits(A-layer)>1 (3-4 maximum) • NS!hits(BC-layer)>0 (1 @ L1) • NWhits(BC-layer)>2 (2*3-4 typical, 2-4 not unlikely [holes] ) • Chi^2>0 (fit converged) • I believe it satisfies non-technical part of the specifications • “Tight” definition is looser than in Run 1 - we can afford that • The inner tracker will be a major contributor to muon ID, not only making the pT determination but also providing remaining background rejection
Specification for “Loose” • Identify all muons that can be found with the muon detector • not intended to be a “muon-detector-unbiased” sample • keep in mind holes in the detector coverage and typical electronics failures • Efficiency of “Loose” should be reliable with MC calculation • “Loose” muons should provide a sample with which to measure the efficiency of each component of “Tight” • Same technical specifications as for “Tight” i.e.- one chuck - all parameters available there or via pointers (we are stuck with tuples through winter conferences)
Muon Quality “Loose” • Definition of “Tight” muon MuonID chunk • 1a) NS!hits(A-layer)>0 (1 @ L1) • 1b) NWhits(A-layer)>1 (3-4 maximum) • 3) NS!hits(BC-layer)>0 (1 @ L1) • 4) NWhits(BC-layer)>2 (2*3-4 typical, 2-4 not unlikely [holes] ) • 5) Chi^2>0 (fit converged) • A “Loose” muon can fail one of the above criteria except 1a) and 1b) count only as one possible failure* *Because A-layer scint. and drift chamber holes are coincident
Muon Quality “Astubs” Specification for Astubs • primary: Identify muons that don’t penetrate the toroid magnets • 1.1 < pT(GeV/c) < 3 or 4 in central • 1.1 < p (GeV/c) < 3 or 4 in forward • secondary: Identify muons that miss all of BC Definition (hardly even preliminary) • “Astub” is S!Hits&WHits(A-layer)>1 • For L3, it’s probably got overlap with “Loose” and “Tight” • Warning: There’s lots of these because of background
Problems with Quality Definitions • In p10.13.00 all “Tight” are available in MuonID bank as nseg = +3 or -3 (and some of the “Loose” are +-3 as well) but … Not ALL “Loose” are available in MuonID chunk. • “Loose” must include BC tracks with a pT calculated from the vertex (nseg=-2) as well as those that have a gtrk match (nseg=+2) • Muon Duplication • One real muon can occur in the MuonID bankchunk up to three (six*) times if it’s in a dense region of central tracks, in a jet, perhaps. • What else? That I know of 15/Dec/2001
Muon Isolation Definition • Most Physics Groups have agreed to use DR(mu-jets[0.5])>0.5 until someone demonstrates something better. • We haven’t taken time to reoptimize this since Run I • Note that central muon phi resolution is pretty bad (unless nseg is positive) • Note that forward muon phi resolution is pretty bad (unless pixels are used in segment)
W/Z to Muons Selection • W’s: “Tight Muon” plus trackmatch • Z’s: Probably “Tight” * “Tight” “Tight” * “Loose” and at least one trackmatch. • Plus sensible kinematic requirements
Some Good Ideas • “Tight” scintillator timing • L1 trigger gate is 24 ns wide in central A-Layer. Efficiency would remain 99%+ if this was tightened to 18ns in L1 or L3 and probably could be tightened more Offline given some careful studies • Similar comment for all the rest of the scintillator • Count Decks instead of Hits in performing ID (Dave) • PDT’s & MDT’s have 3 or 4 decks • This is obviously correct. • Use the Inner Trackers !!!!!!!!!
Some More Good Ideas • Locate the beam scraping source in the North Tunnel - “a hot topic” • More Shielding in A-Layer - part of upgrade for Run 2b • Muon unbiased muon • I can imagine how we might do this and it’s something to think about six months down the road • …
Summary • I’ve discussed “Tight” and “Loose” muon definitions and their specifications • W/Z group is applying a “Tight” muon definition and has a working definition for “Loose” • We plan to select postshutdown events based on these definitions with the addition of Inner Tracker and sensible kinematic information. • Good ideas that I have heard
Trailer • MY Talk Ends Prior to Here
W/Z to Muons • Single Muon Trigger Rates • L=4.7e30 • mu1cmsc_fz = 46 *(64/108) =>5.8 hz/10^30 (not including octants 5 & 6) • mu1pix_fz = 60 hz =>12.8 hz/10^30 • Readout Bandwidth seems to be 30 hz so single muons are getting prescaled heavily Tighter gates
Efficiency For W’s Efficiency For Z’s Efficiency Calculation • Partly from Monte Carlo. • Monte Carlo calculates acceptance & kinematic selection • Monte Carlo doesn’t model the detector performance • Partly from Data • Use Data whenever possible • See above in reverse for Data
Muon Changes I • Reported by Frederic last time for p10.11.00 • muo_trackreco • addition of quality word (quality = 4 corresponds to “tight”) • muon_id • addition of MuonQualityInfo • int Nhit = NWA+10*NWBC+1000*NSA+10000*NSBC • method muoTrackIndex returns the local track index for |nseg|=3 else -1 • method segIndex returns segment index for nseg=1&2 else -1 • method TightMuoTrack returns “T” if “tight” muon (used by METcalmu)
Muon Changes II • Migrating muon selection (e.g. “tight” & “loose”) to Muon_ID • Muon_ID • nseg = -3: criteria changed from NWA>2 & NWBC>3 & 0<Chi2<1000 NWA>0 & NWBC>1 & -inf<Chi2<inf to match nseg=+3 (note it takes 2 hits to make a segment) • Failed to make an nseg= -2 in muon_id because there’s no BC-only tracks in muo_trackreco (Frederic is working on this)
Muon Changes II continued • Muon_ID Track-Matching • nseg = 3: trackmatch in Central w/ PT(gtrak)>3.0 GeV/c (was 1.5 GeV/c) note it’s still 1.5 GeV/c in Forward note it’s 3.0 GeV for BC-only (nseg=2) note it’s 1.5 GeV/c for Astubs • Criteria dZ(A-L.cm) dPhi dEta SMT (100/pt)+10 0.5 0.4 Global same same same CFT none same none (all now RCP controlled) (was 4) • Still, because in Muon_ID we match on A & BC segments, it’s possible to have an A-stub or BC-seg with a trackmatch in common with an ABC muon? • Track-matching is done with a CH loop (Pt-ordered) priority-ordered by muo_trks, BC-segs, Astub-segs
Muon L3 Filter What criteria are we going to have available to identify muons in L3? • We separated “muon object” from “object relational” criteria and concentrate on the “muon object” to begin with. • In step with the offline selection. • Providing muons well-matched in selection criteria • Providing means to measure efficiency • Attempting to anticipate the requirements of triggers
First Try: Muon Selection Criteria • Muon_L3(key,Nmu,eta,Region, Quality,PtLocal,TrackMatch, PtTrackmatch,CalMatch) • “key” is a marker for relational tools • Nmu is the required count • eta cut (e.g. |eta(muon)|<eta) • Region (e.g. forward/central) • Quality (“Tight” ,“Loose”, & “Astub”) based on muon criteria more coming up • PtLocal (Pt of the muon local track) • Trackmatch criteria more coming up • PtTrackmatch (Pt of inner tracker) • CalMatch criteria not much yet
Track Match Criteria • Matching with Central Tracks is important for muons, especially since we anticipate (and see) relatively pure muon triggers. • Capability in hand includes global trackmatch via best spatial criteria. • Paul is expanding the tracking detector options and • is considering selecting the track with a Pt-ordered spatial criteria.