240 likes | 334 Views
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?
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.