CMSSW Documentation

The DQM (Data Quality Monitoring) Framework provides the infrastructure for detector-specific code to interact with DQM services like the DQM GUI, Tier0 processing, and Online DQM. It is designed to be data-agnostic and subsystem-agnostic, providing core services like the DQMStore and MonitorElement abstractions.

Key components include:

• Plugins: DQM code runs as CMSSW plugins, primarily categorized as Analyzers (for filling histograms in RECO jobs) or Harvesters (for manipulating histograms during transitions in harvesting jobs).
• DQMStore: A singleton edm::Service that manages the lifecycle and storage of DQM data.
• MonitorElement (ME): The primary abstraction for DQM data (mostly histograms).

The FWCore/SharedMemory package provides tools for two-process communication via shared memory. The typical architecture involves a Controller process (running within cmsRun via a module) and one or more Worker processes that perform tasks on behalf of the Controller.

Key characteristics:

• Uses boost::interprocess for shared memory management.
• Supports a 1-to-N relationship where one Controller module can manage multiple Workers (e.g., one Worker per Stream).
• All classes reside in the edm::shared_memory namespace.

TruthInfo is an experimental prototype providing a single, navigable, physics-oriented MC-truth graph for CMS. It abstracts the complex generator and simulation truth history (HepMC, GenParticles, SimTracks, SimVertices, etc.) into a unified model.

Warning: This is a prototype under heavy development. It targets Phase-2 (Run 4) only and its APIs/configurations change frequently. It is not intended for production use or external contributions at this stage.

NanoAODTools is a Python-based toolkit designed for post-processing NanoAOD files. It enables users to:

• Skim events based on selection criteria.
• Add new variables to the NanoAOD trees.
• Produce plots.
• Perform simple analyses.

It can be used within a CMSSW environment or as a standalone package. Note that while it is flexible, its sequential design model may result in lower performance for complex analyses compared to highly parallelized frameworks.

The Global Track Trigger (GTT) is a CMS subsystem located downstream of Level-1 Track Finding. Its primary purpose is to perform Level-1 vertex-finding for the L1 Correlator Layer 1 (used for PF Candidate / PUPPI reconstruction) and to globally construct track-only objects. These objects are then sent to the Global Trigger.

Key objects produced by the GTT include:

• Jets
• HT (Scalar sum of transverse momentum)
• MET (Missing Transverse Energy)
• Mesons (specifically $\phi$ and $\rho$)
• $W \to 3\pi$ candidates

The XrdAdaptor is the CMSSW implementation of the CMS AAA infrastructure for XRootD. It provides features on top of the standard XRootD client library, specifically:

• Error Recovery: Automatic retries for certain errors.
• Multi-source Support: The ability to use multiple XRootD sources for a single Physical File Name (PFN).

Key components include:

• XrdFile: Implements edm::storage::Storage and acts as the glue between the edm::storage::Storage API and the RequestManager for a single PFN.
• RequestManager: Manages retries and the multi-source algorithm. It contains one or more Source objects.
• Source: Represents a connection to a specific storage server.
• XrdStatisticsService: A default service enabled in cmsRun that centrally reports XRootD-related statistics.
• XrdStorageMaker: A plugin in the StorageMaker hierarchy used to create XrdFile objects.