PileUp Framework Status

1
Pile-Up Framework Status
Paolo Calafiura, LBL

• Software Workshop
• Sep 18, 2001

2
Pile-up Framework tasks

• read events from multiple streams (physics, min
  bias...)
• organize them in time ordered structures (the
  bunch crossings) and link them to an overlaid
  event
• combine hit collections from the sub-events in
  the Xing, merging nearby hits according to
  detector-specific criteria

3
Overlaid Event Construction and Access

• Event Stores
• physics event store its iterator drives event
  loop
• min bias stores (and Muon bkg and LAr) random
  access iterator
• overlaid event store links to input events
• Overlaid Event
• time-ordered collection of sub-events
• Bunch crossing time offset identifies sub-events
• Event Loop Manager
• configure duration, contributing streams
  evts/stream, event offset distributions
  (Poisson, but also uniform and delta-function)

4
Event Object Diagram
Input Stores

• dataSvc

• Selectors
• nEvts
• timeDistr

XING
5
Setting up the Overlay Process

• ApplicationMgr.ExtSvc "PileUpEvtLoopMgr"
• PileUpEvtLoopMgr.PhysicsSelector
  "PhysicsSelector
• PileUpEvtLoopMgr.MinBiasSelectors
  "G3MBiasSelector"
• PileUpEvtLoopMgr.crossingFrequency 25 //ns
• //beam time history which mbias evts to use at
  which time
• PileUpEvtLoopMgr.makeCrossings -2, 1 //4
  x-ings, -50lttlt50ns
• PileUpEvtLoopMgr.collisions 23 //min bias
  per x-ing
• PileUpEvtLoopMgr.MinBiasDistribution "Poisson"
  // or "Fixed"

6
Overlaid EventInfo
collisions
xing

• EventInfo contains a collection of EventInfo
  pointers
• pointer is an extended SG DataLink that works
  across stores

7
Merging Hit Collections

• Hit (and digi) collections
• input collections time-stamped and copied to
  overlaid event
• hits in overlaid collection carry parent
  sub-event offset
• Hit (and digi) mergers
• detector specific, user-defined (sub-)algorithms
  
• sort hits by position and time
• merge nearby hits

8
Time-stamped Hit
9
Hit Merging
xing
10
The Merger Framework

• Merger is an algorithm holding a list of
  user-defined mergers (sub-algorithms)
• Merger provides the user digitizers with the hits
  they need and register the digi collection they
  generate
• Merger works with the concrete hit and digis
  types
• Need types to get the hits from the SG and to
  store the digis back
• No need for the user digitizer to see the store
• Safe, consistent (and efficient?) access via the
  Merger algo

11
User Merger

• class MyHitMerger
• public
• //export data object types
• typedef stdlistltMyHitgt in_cont
  //input (hits)
• typedef stdvectorltMyDigigt out_cont //output
  (digis)
• //this is the user method the framework invokes
  after it's done
• //preparing the inputs. The user merges the
  hits and digitize the result
• // takes the channel ID (to get geometry) and
  the hits iterator range
• StatusCode mergeChannel(AtlasID channelID,
• 
  in_contconst_iterator hbegin,
• 
  in_contconst_iterator hend)
• out_contiterator resultBegin()
• out_contiterator resultEnd()
• BTW this scheme could be used for the simulation
  digitizers (CDF)

12
Status

• Coding PileUpEvtLoopMgr
• Will commit soon, not much use to tag it
  officially before Merger
• Merger concept in place, but design not yet
  complete
• Need a factory for the user mergers (several
  ready to steal)
• Need a scheme to configure user mergers (use
  sub-algorithms?)
• Next month will need one or two early adopters to
  provide real(istic) mergers
• Goal is to release a prototype for end of October