CMS Software Architecture - PowerPoint PPT Presentation

Loading...

PPT – CMS Software Architecture PowerPoint presentation | free to download - id: 21a050-NDg2N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

CMS Software Architecture

Description:

Define the events to be dispatched and link them to the their actual source ... A CARF Application is characterized by the events it dispatches ... – PowerPoint PPT presentation

Number of Views:37
Avg rating:3.0/5.0
Slides: 31
Provided by: ygap
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
CARF CMS 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
About PowerShow.com