CARF

1
CARF
an AnalysisReconstructionFramework for CMS

• Vincenzo Innocente
• CERN/EP/CMC

2
CARF Development Philosophy

• Tailored to CMS analysis and reconstruction
• Serves present ORCA applications
• priorities driven development
• backward compatibility, legacy code and data!
• Bottom-up (concrete?abstract) development in
  synergy with other sub-systems
• It is also a prototype of 2005 software
• offers more than one solution to a single problem

3
CARF layered Structure
Core mechanisms and data structures
Generic Application
G3
TestBeam
H2
T9/X5
Raw Data
Raw Data
Raw Data
Generic Clients
4
Framework Basic Dynamics

• No central ordering of actions, no explicit
  control of data flow only implicit dependencies
• External dependencies managed through an Event
  Driven Notification to subscribers
• Internal dependencies through an Action on Demand
  mechanism

5
Framework Main Services

• Define the events to be dispatched and links them
  to the their actual source
• Allow the selection among available resources
  (user plug-ins)
• Manage the not yet removed sequential
  components

6
Framework Ancillary Services

• User Interface
• Error Report (Exception management)
• Logging facilities
• Timing facility (statistics gathering)
• Utility library
• Notably Objy utilities, wrappers and generic
  persistent capable classes

7
Framework middle layer

• A CARF Application is characterized by the events
  it dispatches
• Implementation of generic clients to specific
  services (events)
• simplified API
• uniform detailed design
• uniform use of ancillary services
• Requires synergy with detectors sub-systems

8
Use Cases

• L1 Trigger Simulation
• Track Reconstruction
• Physics reconstruction

9
L1 Trigger Simulation
detectors
Front-end trigger logic
Local trigger
Global trigger
Final trigger decision
10
L1 Trigger Simulation

• Accurate simulation of real electronics
• In the real experiment only final decision data
  are propagated forward
• Also required
• Monitoring of single trigger units
• Comparison of L1 trigger w.r.t. full
  reconstruction
• ability to simulate just a part of the system
• save computing intensive intermediate results

11
Track Reconstruction
For each detector element there are local
measurements of trajectory state-vector (just
position or more complex)
Local measurements are affected by the detector
element state (calibrations, alignments)
Pattern recognition navigates in the detector
to associate local measurements into a track
12
Physics reconstruction

• 4-vector-like objects are built out of
  trajectories and localized energy deposits
• A wide range of PID, jet, vertex etc algorithms
  can be applied to produce others 4-vector-like
  objects
• Access to the original detector data maybe
  required

13
Reconstruction Sources
14
Reconstruction Scenario

• Reproduce Detector Status at the moment of the
  interaction
• front-end electronics signals (digis)
• calibrations
• alignments
• Perform local reconstruction as a continuation of
  the front-end data reduction until objects
  detachable from the detectors are not obtained
• Use these objects to perform physics
  reconstruction and analysis

15
Components

• Reconstruction Algorithms
• Event Objects
• Other services (detector objects, parameters,
  etc)
• Legacy not-OO data (GEANT3)

16
CARF Fundamentals (inside the black box)

• Detector Components
• Event Driven Notification
• Action on Demand

17
Detector Components
Sim Hit Loader
Local Geometry
Load simulated hits from MC
Global Geometry
Generates Digis from SimHits (or loads them from
db)
Detector Element
Digitizer
Time Dependent Parameters
Reconstruct measured trajectory state-vector
from Digis
Reconstructor
18
Event Driven Notification
Dispatcher
Obs1
Obs2
Obs3
Obs4
Observers
19
Active and Lazy Observers
Dispatcher
Lazy Obs2
Lazy Obs2 obsolete
Lazy Obs2 uptodate
Obs
Lazy Obs1
Lazy Obs1 obsolete
Lazy Obs1 uptodate
20
Action on Demand
Rec Hits
Detector Element
Rec Hits
Rec Hits
Hits
Event
Rec T1
T1
T2
Rec T2
Analysis
21
Events currently dispatched
Start Xing
G3 Geom
Ready to build new G3 simulated event
SimPileUp
New pile-up event ready in Zebra memory
SetUp
SimTrigger
New trigger event ready in Zebra memory
SetUp Observers are Objects which depend on
geometry
G3Event
New event ready to be analyzed
22
RecObj Object Model
23
Object identification

• A Detector object collection is identified by
• object type (or super-type)
• detector element it belongs to
• implicitly belongs to the current crossing
• Required the detector to be in place and
  operational

24
Object identification

• A RecObj collection is identified by
• object type (or super-type)
• name of the Reconstructor (same as RecUnit)
• event it belongs to
• Does not require the RecUnit to be in place or
  operational