Preface to CMS Offline Software

Complete: 4

Introduction

The overall collection of software, referred to as CMSSW, is built around Framework, an Event Data Model, and Services needed by the simulation, calibration and alignment, and reconstruction modules that process event data so that physicists can perform analysis.

CMS software architecture

The high-level goals of the CMS software are to process and select events inside the High Level Trigger Farm, to deliver the processed results to experimenters within the CMS Collaboration, and to provide tools for them to analyze the processed information in order to produce physics results.

Many technical requirements should be considered such as the memory consumption and processing time per event necessary to meet financial constraints, and the physics performance requirements encompassing the ability to reproduce faithfully details of the underlying physics processes based on the detector data.

Requirements

CMS has identified the following underlying principles which motivate the overall design of the CMS software architecture.

Multiple Environments
Various software modules must be able to run in a variety of environments as different computing tasks are performed. Examples of these environments are High Level triggering, production reconstruction, program development, and individual analysis;
Migration between environments
a particular software module may start out being developed for one environment, then later used in other unforeseen environments as well;
Migration to new technologies
hardware and software technologies will change during the lifetime of the experiment: a migration to a new technology should require a finite effort localized in a small portion of the software system, ideally without involving changes to physics software modules;
Dispersed code development
the software will be developed by organizationally and geographically dispersed groups of experimenters;
Flexibility
not all software requirements will be fully known in advance, therefore the software systems must be adaptable without requiring total rewrites;
Ease of use
the software systems must be easily usable by collaboration physicists who are not computing experts and cannot devote large amounts of time to learning computing techniques.

These requirements imply that software should be developed keeping in mind not only performance but also modularity, flexibility, maintainability, quality assurance and documentation. CMS has adopted an object-oriented development methodology, based primarily on the C++ programming language.

Architecture design

The requirements described above on the software architecture result in the following overall structure for the CMS software:

  • an application framework customizable for each of the computing environments;
  • physics software modules with clearly defined interfaces that can be plugged into the framework;
  • services and utility toolkits that can be used by any of the physics modules.

The framework defines the top level abstractions, their behaviour and collaboration patterns. It comprises two components: a set of classes that capture CMS specific concepts like detector components and event features and a control policy that orchestrates the instances of those classes taking care of the flow of control, module scheduling, input/output, etc. This control policy is tailored to the task at hand and to the computing environment.

The physics and utility modules are written by detector groups. The modules can be plugged into the application framework at run time, independently of the computing environment. One can easily choose between different versions of various modules. The physics modules do not communicate with each other directly but only through the data access protocols that are part of the framework itself.

The service and utility toolkit consists of two major categories of services: physics type services (histogrammers, fitters, mathematical algorithms, geometry and physics calculation routines) and computer services (data access, inter module communication, user interface, etc.). This toolkit is based on LCG Application Area components. Both the application framework and the service and utility toolkit shield the physics software modules from the underlying technologies which will be used for the computer services. This will ensure a smooth transition to new technologies with changes localized in the framework and in specific components of the service toolkit.

Software domain decomposition

Several orthogonal domain decompositions have been identified. This document follows the decomposition between
  • Main areas including:
    • The Event Farm and High-Level triggering;
    • Simulation including event generation, pile-up and digitization;
    • Calibration and Alignment processing;
    • Physics tools and visualization;
    • Physics and Data Quality Monitoring,
  • Detector reconstruction objects (tracks, ECAL, HCAL and vertex reconstruction and muon reconstruction in muon systems)
  • Physics reconstruction objects (muon, electrons, photons, jets, b-tagging, taus, particle flow)
Furthermore, this guide contains a Developer's Guide and Common area for troubleshooting, code performamce issues etc.

Infomation sources

CMS Physics TDR: Volume I (PTDR1), Detector Performace and Software, CERN-LHCC-2006-001, 2 February 2006

Review status

Reviewer/Editor and Date (copy from screen) Comments
KatiLassilaPerini - 27 Apr 2007 created the page, contents from PTDR Vol1

Responsible: KatiLassilaPerini
Last reviewed by: Reviewer

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2007-11-22 - KatiLassilaPerini



 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback