d0 level 3 filters dan claes moacyr souza u. of nebraska fermilab / lafex - rio de janeiro dzero...
TRANSCRIPT
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
• 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
• Digest the coor commands and act according status: working properly after some re-arrangements with L3 Frame
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
Resolutions obtained by comparing L3 jets to MC jets 1/ E dependence
with best fit constant term of 0.87 (central calorimeter) 1.16 (forward calorimeter)
Title:C:\WINNT\Profiles\claes\Level3\FilterReports\L3JetHiPt.psCreator:GSview from C:\WINNT\Profiles\claes\Level3\FilterReports\L3JetHiPt.psPreview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
L3TJet Toolleading jet pT for JT_HI failed and passed events
JT_HI CJT(1,10) JET_15(MinEt=15) 18.5JT_LO CJT(1,5) JET_10(MinEt=10) 8.77
Rejection:
For development studiesElectron Tool currently implementedby filtering on highly electromagnetic jets
•applies cut on emfrac calculated within the calorimeter cluster tool
EM_LOW: CEM(1,5) PT>7 GeV emfrac>0.9EM_HIGH: CEM(1,10) PT>11 GeV emfrac>0.9
final runs (132947-133014) before shutdown 375K events included a substantial subset of Mark & Pass’ed events
offline studies by Ia Iashvili (UC-Riverside)
efficiency as a function of PT recalculated w.r.t. Z=0
PT EM (GeV)
CEM(1,10) PT>11 GeVemfrac>0.9
Title:C:\WINNT\Profiles\claes\Level3\FilterReports\EMhighPt1.psCreator:GSview from C:\WINNT\Profiles\claes\Level3\FilterReports\EMhighPt1.psPreview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
Rejection = 5.5sharpens the turn-on(emfrac alone = 3.6)
from 32117 Mark&Passed
events
efficiency as a function of PT recalculated w.r.t. Z=0
PT EM (GeV)
from 32117 Mark&Passed
events
CEM(1,10) PT>11 GeVemfrac>0.9with the added
OFFLINE
Good EM Requirements:EM fraction > 0.9
Isolation<0.2HM41<200
| |<0.8
Title:C:\WINNT\Profiles\claes\Level3\FilterReports\EMhighPt2.psCreator:GSview from C:\WINNT\Profiles\claes\Level3\FilterReports\EMhighPt2.psPreview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
Title:C:\WINNT\Profiles\claes\Level3\FilterReports\EMhighVar1.psCreator:GSview from C:\WINNT\Profiles\claes\Level3\FilterReports\EMhighVar1.psPreview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
Title:C:\WINNT\Profiles\claes\Level3\FilterReports\EMhighVar2.psCreator:GSview from C:\WINNT\Profiles\claes\Level3\FilterReports\EMhighVar2.psPreview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
ISO
HM9 HM41
Emf
All events Passed events
No bias observed between filtered and M&P data
efficiency as a function of PT recalculated w.r.t. Z=0
PT EM (GeV)
from 525 Mark&Passed
events
CEM(1,5) PT>7 GeVemfrac>0.9
Title:C:\WINNT\Profiles\claes\Level3\FilterReports\EMlowPt1.psCreator:GSview from C:\WINNT\Profiles\claes\Level3\FilterReports\EMlowPt1.psPreview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
Rejection = 15(emfrac alone = 2.7)
Title:
Creator:ROOT Version3.01/06Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
L3 EM Certification Ulla Blumenschein (Mainz)
Single electron efficiency in CC fiducial region vs electron pT
L3 EM object with EMFR>0.9 with track match with CPS match
proposed L3TEle Electron Tool
•applying a cut only on emfracshould 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
Plan to come up running a fully functional tool
with the following available functionality:
L3TCPS Central PreShower Clustering Toolauthors: Andre Turcot (BNL) ,Chunhui Han (MICH)
•Combine contiguous strips above threshold into single-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 or from electron or photon tool)
Once CPS readout is commissioned ~2 weeks to implement into L3Ele
L3TCPS Tool PERFORMANCE
Efficiency defined as•clusters matched within 20 mm divided by•number of pT>5 GeV e within CPS fiducial
Z0e+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)
TimingRegional clustering =2ms
Unpacking = 5 ms
l3fCalMEt Missing Et Toolauthor: Lee Sawyer (Louisiana Tech)
calorimeter cell-based tool •L3TCalUnpTool provides unpacked cell information assumed to include ICD/MG sampling corrections •CAL energy stored (assuming nominal (0,0,0) vertex)
•Missing Et calculated through intermediate ring sums •L3TPrVtxTool returns the most probable primary vertex
•recalculate ring sums using primary vertex •currently uses the nominal (0,0)
•calculates Missing ET,, , scalar ET, and Missing ET significance • no muon correction included yet
Ready to run pending certification studies
Title:
Creator:ROOT Version2.26/00Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
SMT Unpacking & Clustering Scales with the number of clusters
avg time
avg #clusters
Title:
Creator:ROOT Version2.26/00Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
CFT Unpacking & Clustering Scales with the number of clusters
avg time
avg #clusters
spread heredue to
sorting fibres into order
CFT Tracking Algorithm - L3TCFTTracker
•Initialization x,y, 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, 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
Principal author: Ray Beuselink (IMPERIAL)Daniela Bauer, Robert Illingworth
0(xc,yc)
Sxy
R
x
y
0
d0
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
See DØ note 3779 for performance studies.
L3TCFTTracker Example Resolution plots for Z->μμ
Example Resolution plots for Z->μμ
L3TCFTTracker Status
Some final coding to complete and test followed by
Certification
L3TVertexFinderFirst 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
L3TSMTTracker - Silicon Microstrip Tracker author: Daniel Whiteson (BERKELEY)
modified “link-and-tree” method - segments connect neighboring hits•between points within =0.4 (tunable parameter)•segment paths are linked if z-slope within 0.2 and within 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 smallest2 selected - its hits marked as in use.
•Paths are to have 4 hits, and not > 2 consecutive missed layers.•SMT divided into 24 15O sections. Track segments may cross boundaries, but not skip sections.•Hits on disks ignored.
Event sample Efficiency Purity Hits per track msec/evt correct/incorrect
Single 5-GeV .788 1.0 4.55/ .005 7.44 (1000 events)
Z .784 0.929 4.45/ .111 51.3 (100 events)
Z .740 0.930 4.51/ .131 50.2 (100 events)
Efficiency: 2<1.0 and Pt >1.0 GeV cuts applied to all tracks“missed” tracks lack full 3D info - z position placed at strip center
L3TSMTTracker - Efficiency & Purity Studies
Level 3 Global Track Findingauthor: 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 d/dr < maximum value determined by Pt_min•Linear extrapolation of each stub predicts crossing at next CFT layer
•hits within d/dr added if do not increase 2 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)
Level 3 Global Track Findingauthor: 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
Efficiency Studies
Event sample Pt cut Efficiency Purity Hits per track correct/incorrect
Single 5-GeV 0.0 GeV 1.00 1.00 10.8/ 0.03
Z +0 minbias 2.0 GeV 0.97 1.00 9.95/ 0.34 3.0 GeV 0.96 1.00 10.4/ 0.24 5.0 GeV 0.99 1.00 10.6/ 0.17 10. GeV 1.00 1.00 10.6/ 0.17
Z +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 +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 +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
Proposed Level 3 SMT-only Trackerauthor: Daniel Whiteson (BERKELEY)
single track (SMT-only) filternow under study
using data to provide additional rejection to
current muon, jet filters
Title:smtonly.4hits.magnet.ps (Portrait A 4)Creator:HIGZ Version 1.26/04Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
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 Gaussianare highly pure
Title:smtonly.5hits.magnet.ps (Portrait A 4)Creator:HIGZ Version 1.26/04Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
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 Gaussianare highly pure
Title:smtonly.vtxz.ps (Portrait A 4)Creator:HIGZ Version 1.26/04Preview:This EPS picture was not savedwith a preview included in it.Comment:This EPS picture will print to aPostScript printer, but not toother types of printers.
Filtering data with a simple SMT track Vertexer
SMT tracks examinedfor 2 or more
with close z-positionsat DCA
Maximal Z-distancebetween tracks in
a given vertex
Z MCQCD (PT>20)Data
vertex filtered SMT-only efficiencies
1.0 0.5 0.2 0.15.0 0.22
0.204e-3
0.100.192e-3
0.040.177e-4
0.0150.162e-4
10.0 0.070.151e-3
0.040.147e-4
0.010.133e-4
0.0050.121.5e-4
20.0 0.0150.073e-4
0.0090.071.5e-4
0.00250.067.5e-5
.00050.06~0
QCD, pt>20, 2.5mbZ2.5 mbdata runs 130167-8
Z-distance (cm)Min pT (GeV)
L3 Primary Vertex Algorithmauthor: Guilherme Lima (UERJ/Brazil)D0Note # 3592 - J. Zhou, J. Hauptman, and M. Narain
•Sort SMT barrel hits in •Define -slices up to 50 hits or = 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 <0.05 rad and r > 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 -slice•Sum slices counting number of slices contributing to, and total # of entries in, each candidate peak.•Discard candidates with <3 contributing -slices•Assign probabilities of (#entries) x (#slices)•Merge candidates with separation < 0.5 cm
Efficiency Studies
t-tbar 5000 events X to b-bbar 250 eventsB toKs, to1000 events B toKs, to1000 eventsPrompt to e+e- 1000 events W to 1000 eventsW to e 1000 events Z to 1000 eventsZ to ee 1000 events Z to 1000 events+ jet 1000 events
Generated hits Reconstructed hits Eff(%) Resol(m) Eff(%) Resol(m)t-tbar 93 620 79 2000B K 94 510 43 1100QCD 95 500 66 1500
L3TPrVtxToolDependent on event topology
Has yet to be tested on REAL DATA
L3TMuon, skeleton version of full global muon tool calls: •L3TMCT, the calorimeter confirmation tool•L3TMuoCentralMatch (calls a 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 5GeV pT single muon sample
but not yet with real data Performance studies and certification of these features underway
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 filesfix provided by Scott Snyder to be implemented & checked
interim L3TMuon functionalitycollect 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 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
Continue development and testing tostage additional Muon Tool functionality
January, 2002?
L3TMuoCentralMatch •calling L3TCFT fast central track tool when track readout available•studies completed with single muon and BJ/ Ks MC 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
timing Paul Balm (NIKHEF)L3TMuon
1000 BJ/ 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/eventL3TMuoCentralMatch 4 msec/event
~70 ms/evt for local muons only ~95 ms/evt with GlobalTracker match
1 GHzClued0
L3FTauHadronic Level3 TauToolauthor: Gustaaf Brooijmans (FNAL)
pursuing two approaches•Calorimeter-driven search: Starts with
L3TCalCluster pT>1GeV providing 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>1GeV CFT (cluster tracks w/R<0.3), order in , match with L3TCalCluster clusters
Certifying code, plan to get non-optimized filter into triggerlist, gather information online for tuning under online conditions
Some Timing EstimatesTool Timing Estimate
CalUnp 10 msec/event CalCluster <1 msecL3jet <1 msec
CPS unpack <1 msec CPS clustering <1 msec
SMTunpack 10 ms (~1/2 spent clustering) SMT Tracking 10 msecGlobal Tracking 10 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) eventsto cluster calorimeter cells and get a primary vertex
~40msec.
muon events
~70msecwith Global trackmatch
~90msec.
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 16electron 13Missing ET 11Mu confirmation 2Sum ET 2
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, ...
L3 Monitoring
• 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 information per 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
L3 Monitoring
• 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!
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.
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.
L3 Monitor Server
L3 Nodes L3 Nodes L3 NodesL3 Nodes
Run Summary Server
DAQ Monitor Display
LuminosityServer
Information (L3MonChunkas a d0omStream object)is sent, as ITC messages,each time that the luminosity index changes
Here the information fromall actives (not timed out)nodes are summed up
L3 Monitoring
Rates, timing, ... so far
Statistics, rates,…,for this luminosity index value
To be implemented
Alarm
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
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
L3 Nodes L3 Nodes L3 Nodes
Master L3 Monitor Server
Run Summary Server
DAQ Monitor Display
LuminosityServer
L3 Nodes L3 Nodes L3 Nodes
L3 Monitor Server
L3 Monitor Server
L3 Monitor Server
Taking advantage of the modular design, we may consider the possibilty of :
private area: map<int l2bit , map< string l3name, Stat> > _map; // L3ChunkStatMap vector<int > _time; // Time Histogram map<int run#, ClientData *> _clientData // holds all client information per run #: //L1<->L2 map. L2 active bits mask // and L3 #<->name) map<int l2bit, string name > _l2map; // L2 #<->name map (all) map<string name, l3ToolStats *> _tool; // ToolStatMap map[<string name , l3FilterStats *>_filter; //FilterStatMap
map<int l2bit, map<string l3name, LumStat> > _lum_old; // L3LumStatMap map<int l2bit, map<string l3name, LumStat> > _lum_old_save; // L3LumStatMap
L3MonChunk:
diem_cal
L3FJet(Jet10)
L3TEle(Ele_Loose)
L3TJet(Jet_10)
L3FMEt(calmet_)
Ele1
el_jet_met
Execution tree
L2 bitsL3 scripts L3 filters
Tools
L3FEle(ele2)
L3FInvMass (inv_1)
.
..
.
..
.
..
(ele1)
L3FEle(ele1)
Conclusion
Tools ready post-shutdownLTJetLTEle w/emfrac & isolation cuts available w/shower shape being tuned
L3TMuoLocal pending certificationMET pending certificationSMT-only Tracker pending certification
Additional tools ready by New Year
L3TMuon w/ trackmatch, SCINT, MTCCPS available with hardwareGlobalTracker forL3TCFTTracker online testing