DD
W/Z Muon Selection
For Winter Conferences
Tom DiehlFNAL
@ 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
Drift Detectors
Scintillation Counters
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 R(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
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
W/Z to Muons
Tightergates
Efficiency Calculation
isolationTrackTriggerTightLooseefficiency ****
Efficiency For W’s
22
22
*
**]2[*
isolationTrack
TriggerTightTightTwoLooseefficiency Efficiency For Z’s
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_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 dEtaSMT (100/pt)+10 0.5 0.4 Global same same sameCFT 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 Changes II continued
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
DD
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
First Try:
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.