CMS Software Architecture

1
CMS Software Architecture
Software framework, services and persistency in
high level trigger, reconstruction and analysis

• Vincenzo Innocente
• CERN/EP/CMC

2
CMS (offline) Software
Quasi-online Reconstruction
Environmental data
Slow Control
Online Monitoring
store
Request part of event
Store rec-Obj
Request part of event
Event Filter Objectivity Formatter
Request part of event
store
Persistent Object Store Manager Object Database
Management System
Store rec-Obj and calibrations
store
Request part of event
Data Quality Calibrations Group Analysis
Simulation G3 and or G4
User Analysis on demand
3
Requirements (from the CTP)

• Multiple Environments
• Various software modules must be able to run in a
  variety of environments from level 3 triggering,
  to individual analysis
• Migration between environments
• Physics modules should move easily from one
  environment to another (from individual analysis
  to level 3 triggering)
• Migration to new technologies
• Should not affect physics software module

4
Requirements (from the CTP)

• Dispersed code development
• The software will be developed by
  organizationally and geographically dispersed
  groups of part-time non-professional programmers
• Flexibility
• Not all software requirements will be fully known
  in advance
• Not only performance
• Also modularity, flexibility, maintainability,
  quality assurance and documentation.

5
CMS Software Architecture RD

• 95-96 RD41 --- OO Detector Reconstruction
• Detector model, Local hit cache, Pattern
  recognition
• 95-97 RD45 --- OO Event Model (persistent)
• Event structure, Raw data, Reconstructed objects
• 95-97 RD45 --- Calibration Database
• Time dependent data, Versioning, Experience with
  Objy
• 96-98 Implicit Invocation
• Event dispatching, Reconstruction on demand
• 97-98 Test-Beam (H2, X5)
• OO Daq, Online filtering, ODB population

6
Use Cases

• L1 Trigger Simulation
• Track Reconstruction
• Physics Reconstruction

7
L1 Trigger Simulation
detectors
Front-end trigger logic
Local trigger
Global trigger
Final trigger decision
8
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

9
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
10
Physics reconstruction

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

11
Reconstruction Sources
12
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 obtained
• Use these objects to perform physics
  reconstruction and analysis of the Event

13
Components

• Reconstruction Algorithms
• Event Objects
• Other services (detector objects, environmental
  data, parameters, etc)
• Legacy not-OO data (GEANT3)
• The instances of these components require to be
  properly orchestrated to produce the results as
  specified by the user

14
CARFCMS Analysis Reconstruction Framework
Application Framework
Physics modules
Reconstruction Algorithms
Event Filter
Data Monitoring
Physics Analysis
Calibration Objects
Event Objects
Visualization Objects
Utility Toolkit
15
Architecture structure

• An application framework CARF (CMS Analysis
  Reconstruction Framework), customisable for each
  of the computing environments
• Physics software modules with clearly defined
  interfaces that can be plugged into the framework
• A service and utility Toolkit that can be used
  by any of the physics modules
• Nothing terribly new, but...
• Traditional architecture can not cope with
• LHC-collaboration complexity

16
Framework Basic Dynamics

• Implicit Invocation Architecture
• 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

17
Event Driven Notification
Dispatcher
Obs1
Obs2
Obs3
Obs4
Observers
18
Active and Lazy Observers
Dispatcher
Lazy Obs2
Lazy Obs2 obsolete
Lazy Obs2 uptodate
Obs
Lazy Obs1
Lazy Obs1 obsolete
Lazy Obs1 uptodate
19
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
20
Action on Demand
Rec Hits
Detector Element
Rec Hits
Rec Hits
Hits
Event
Rec T1
T1
T2
Rec T2
Analysis
21
Detector 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
• User entry point is a Detector Set-up Object

22
Event Object Identification

• A RecObj collection is identified by
• object type (or super-type)
• name of the Reconstructor (same as RecUnit)
• event it belongs to
• Implicitly belong to the current detector
  set-up
• Does not require the RecUnit to be in place or
  operational
• User entry point is the Event Object

23
Framework Main Services

• Define the events to be dispatched and link them
  to the their actual source
• Allow the selection among available resources
  (user plug-ins)
• Integration with the DBMS
• Manage the not yet removed sequential
  components (coming from legacy code data)

24
Framework Persistency Services

• transactions
• metadata and event collections
• define the logical persistent object structure
• physical clustering
• access to persistent event structure
• effectively shield physics modules from the
  underlying technology

25
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

26
Framework middle layer

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

27
CARF layered Structure
Core mechanisms and data structures
Generic Application
G3
TestBeam
H2
T9/X5
Raw Data
Raw Data
Raw Data
Generic Clients
28
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
29
RecObj Object Model
30
Results of RD

• Traditional software architectures
  (mainsubroutines, pipesfilters) have been found
  not to be adequate to CMS (long time-scale, large
  dispersed collaboration)
• An implicit invocation architecture is a
  flexible software solution which can scale with
  the complexity of the CMS project.
• ODBMS, integrated into the framework, provides a
  coherent management of persistent objects
• The framework can effectively shield physics
  modules from the underlying technology

31
Summary

• CMS has developed an AnalysisReconstruction
  framework based on a implicit invocation
  architecture. The present prototype
• supports both detector- and event-centric
  reconstruction
• provides a fully integrated persistency services
  based on a commercial ODBMS (Objectivity/DB)
• is being validated by several applications
  ranging from test-beam (Daq and analysis) to high
  level trigger simulation (digitization,
  reconstruction, event selection)

32
CMS - Software Components