# Presentation: 102784

## CARF

*Vincenzo Innocente*
*CERN/EP/CMC*

**an Analysis&Reconstruction****Framework for CMS**

## 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

- Vincenzo Innocente   CARF Fundamentals

**Notes:**
NOT a generic “one size fit all” application framework

## CARF layered Structure

**G3**

**TestBeam**

**H2**

**Raw**
**Data**

**Raw**
**Data**

**T9/X5**

**Raw**
**Data**

- Core mechanisms
- and “data structures”

- Generic
- Application

- Generic Clients

- Vincenzo Innocente   CARF Fundamentals

## 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

- Vincenzo Innocente   CARF Fundamentals

## 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-in’s)
- Manage the “not yet removed” sequential components

- Vincenzo Innocente   CARF Fundamentals

## 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

- Vincenzo Innocente   CARF Fundamentals

## 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

- Vincenzo Innocente   CARF Fundamentals

## Use Cases

- L1 Trigger Simulation
- Track Reconstruction
- “Physics” reconstruction

## L1 Trigger Simulation

- detectors

- Front-end
- trigger logic

- Local trigger

- Global trigger

- Final trigger decision

- Vincenzo Innocente   CARF Fundamentals

## 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

- Vincenzo Innocente   CARF Fundamentals

## 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

- Vincenzo Innocente   CARF Fundamentals

## “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

- Vincenzo Innocente   CARF Fundamentals

## Reconstruction Sources

- Vincenzo Innocente   CARF Fundamentals

## 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

- Vincenzo Innocente   CARF Fundamentals

## Components

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

- Vincenzo Innocente   CARF Fundamentals

## CARF Fundamentals       (inside the black box)

- Detector Components
- Event Driven Notification
- Action on Demand

**Notes:**

Web site:
htttp;//nicewww.cern.ch/~innocent/cmsoo/carf1298.ppt

## Detector Components

- Detector
- Element

- Sim Hit
- Loader

- Digitizer

- Reconstructor

- Local
- Geometry

- Global
- Geometry

- Time
- Dependent
- Parameters

- Load simulated
- hits from MC

- Generates Digis
- from SimHits
- (or loads them
- from db)

- Reconstruct
- measured trajectory
- state-vector from Digis

- Vincenzo Innocente   CARF Fundamentals

## Event Driven Notification

- Obs1

- Obs2

- Obs3

- Dispatcher

- Obs4

**Observers**

- Vincenzo Innocente   CARF Fundamentals

## Active and Lazy Observers

- Lazy
- Obs2

- Obs

- Dispatcher

- Lazy
- Obs1

- Lazy
- Obs1
- obsolete

- Lazy
- Obs2
- obsolete

- Lazy
- Obs1
- uptodate

- Lazy
- Obs2
- uptodate

- Vincenzo Innocente   CARF Fundamentals

**Notes:**
Obsis a user object or a reconstruction algorithm which uses
services of LazyObs1 (for instance a detector object) whose status
depend on the event itself.
In turn LazyObs1 depends on LazyObs2(for instance a calibration object)
whose status also depends on the event itself.
When a new event arrives LazyObs1 and 2 get notified and they change status to “obsolete” without taking any further action.
When Obs gets notified it starts computation and will ask LazyObjs1 for a service.
At This point LazyObs1 will find itself obsolete and will try to update its status. In doing so it will ask a service to LazyObjs2 which will in turn find itself obsolete and will perform the computation to update its status.
Once updated, LazyObj2 will serve LazyObj1 which will in turn update itself
and serve Obs
Any further service requested to LazyObj1 or 2 will find the object up-to-date and only the computation (if any) to fulfill the specific service will be performed with no further update of its status.

If there is no request for service for a given event the LazyObjs stay obsolete.  

## Action “on Demand”

- Event

- Rec T2

- Rec T1

- Rec Hits

- Analysis

- Hits

- T1

- T2

- Detector
- Element

- Rec Hits

- Rec Hits

- Vincenzo Innocente   CARF Fundamentals

**Notes:**
Analysis is a “user object” where tracks (T1 and T2) built by two different algorithms (RecT1 and RecT2) are compared.
Both T1s and T2s are reconstructed out of intermediate HITS built by a common RecHits algorithm.
For each new event Analysis is notified.
It instantiates an iterator over tracks T1 which will ask Event for the T1s.
Event will not find any T1 and will ask RecT1 to reconstruct them.
RecT1 will ask Hits to Event (instantiating an iterator).
Hits are not there and Event will ask RecHits to reconstruct them.
 RecHits return Hits to Event which hands over them to RecT1 which reconstructs T1s, gives them to Event which hands over them to Analysis.
Analysis will then ask Event about T2.
T2 are not there and event ask RecT2 to reconstruct them.
RecT2 ask Event for Hits, which are there, and are immediately returned to it.
T2 get reconstructed and given to Event will will hands over to analysis which will finally perform the comparison.

## “Events” currently dispatched

- SetUp

- Start Xing

- SimPileUp

- SimTrigger

- G3Event

- G3
- Geom

- SetUp Observers are Objects
- which depend on geometry

- Ready to build new
- G3 simulated event

- New pile-up event
- ready in Zebra memory

- New trigger event
- ready in Zebra memory

- New event “ready”
- to be analyzed

- Vincenzo Innocente   CARF Fundamentals

## “RecObj” Object Model

- Vincenzo Innocente   CARF Fundamentals

## 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”

- Vincenzo Innocente   CARF Fundamentals

## 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

- Vincenzo Innocente   CARF Fundamentals