Paths to forest files

Run Energy Type Location Path Production Env AOD files
Golden JSON 5.02 TeV Jet 100 trigger PbPb data (2015); jet pT > 70 GeV CERN EOS /mnt/hadoop/store/group/phys_heavyions/dhangal/HIHardProbes_Mar11/HIHardProbes/crab_HIHardProbes_Mar11/*/*/ github das link
  5.02 TeV PYTHIA6+HYDJET DijetMC (2015), pthat 50, 80, 100, 120, 170, 220; jet pT > 30 GeV Purdue /mnt/hadoop/store/user/jviinika/PbPb2015MCForest_5TeV_Pythia6Hydjet_v14/pthat* github das link
Golden JSON 5.02 TeV Jet 100 trigger PbPb data (2015); jet pT > 25 GeV; includes WTA axis too CERN EOS /mnt/hadoop/store/group/phys_heavyions/dhangal/PbPb2015dataForest_5TeV_Jet100trigger_ptmin25_Jun30/HIHardProbes/crab_PbPb2015dataForest_5TeV_Jet100trigger_ptmin25_Jun30/*/*/ github das link

gfal copy paths for various T2 sites

  • Purdue : gsi (for use with the new 'gfal' tools)
  • MIT : gsi
The gfal-* commands can be used with these paths as well as xrdcp, and the old-school lcg-cp commands via "lcg-cp -b -v -n 5 -D srmv2 "

Copying locally can be done by using "file:////" as a source or destination

Copying via xrdcp: xrdcp root://

Opening files from T2 : root://

srm paths to various T2 sites

  • Purdue: srm:// (soon to be decommissioned)
  • MIT: srm://
  • LLR: srm://
  • CERN EOS: srm://

tdr_diff instructions

Status codes for MC generators

Pythia 6

  • status 1: Stable final-state particle
  • status 2: Unstable particle
  • status 10902: Exactly the same as status 2 above
  • status 3: Documentary particle; Often a process generated outside pythia, then passed to it for showering

Pythia 8

  • Negative vs. Positive: A particle which decays is given a negative status; the final state only consists of positive-status particles
  • status 1: Final-state particle
  • status 11-19: Beam particles
  • status 21-29: Particles from the hardest subprocess
  • status 31-39: Particles from subsequent subprocesses in multiple interactions
  • status 41-49: Particles produced by initial-state showers (ISR, or generally particles not from the final state of the hard process)
  • status 51-59: Particles produced by final-state showers
  • status 61-69: Particles produced by beam-remnant treatment
  • status 71-79: Particles about to be hadronized (input partons to a hadron)
  • status 81-89: Primary output of hadronization process (first level of hadrons)
  • status 91-99: Particles produced in final decay process, or by Bose-Einstein effects (?)


Unhighlighted statuses from 153-165 may have somewhat different uses than those available

  • status 1: final state particle
  • status 2: parton before hadronization
  • status 3: documentation line
  • status 100: cone limiting jet evolution
  • status 101: `beam' (beam 1)
  • status 102: `target' (beam 2)
  • status 103: overall centre of mass
  • status 110: unprocessed hard process c.m.
  • status 111: unprocessed beam parton
  • status 112: unprocessed target parton
  • status 113: unproc. first outgoing parton
  • status 114: unproc. other outgoing parton
  • status 115: unprocessed spectator parton
  • status 120-25: as 110-15, after processing
  • status 130: lepton in jet (unboosted)
  • status 131-34: as 141-44, unboosted to c.m.
  • status 135: spacelike parton (beam, unboosted)
  • status 136: spacelike parton (target,unboosted)
  • status 137: spectator (beam, unboosted)
  • status 138: spectator (target, unboosted)
  • status 139: parton from branching (unboosted)
  • status 140: parton from gluon splitting (unboosted)
  • status 141-44: jet from parton type 111-14
  • status 145-50: as 135-40 boosted, unclustered
  • status 151: as 159, not yet clustered
  • status 152: as 160, not yet clustered
  • status 153: spectator from beam
  • status 154: spectator from target
  • status 155: unstable fundamental particle before decay
  • status 156: spectator before heavy decay
  • status 157: parton from QCD branching
  • status 158: parton from gluon splitting
  • status 159: parton from cluster splitting
  • status 160: spectator after heavy decay
  • status 161: beam spectator after gluon splitting
  • status 162: target spectator after gluon splitting
  • status 163: other cluster before soft process
  • status 164: beam cluster before soft process
  • status 165: target cluster before soft process
  • status 167: unhadronized beam cluster
  • status 168: unhadronized target cluster
  • status 170: soft process centre of mass
  • status 171: soft cluster (beam, unhadronized)
  • status 172: soft cluster (target, unhadronized)
  • status 173: soft cluster (other, unhadronized)
  • status 181: beam cluster (no soft process)
  • status 182: target cluster (no soft process)
  • status 183: hard process cluster (hadronized)
  • status 184: soft cluster (beam, hadronized)
  • status 185: soft cluster (target, hadronized)
  • status 186: soft cluster (other, hadronized)
  • status 190-93: as 195-98, before decays
  • status 195: direct unstable non-hadron
  • status 196: direct unstable hadron (1-body clus.)
  • status 197: direct unstable hadron (2-body clus.)
  • status 198: indirect unstable hadron or lepton
  • status 199: decayed heavy flavour hadron
  • status 200: neutral B meson, flavour at production


Current status code scheme seems to be temporary, will likely change in the future. Statuses 0, 3, and 12-200 are not currently in use; all particles not labelled 1, 2, or 4 are labelled 11.

  • status 0: an empty entry, with no meaningful information and therefore to be skipped unconditionally
  • status 1: a final-state particle, i.e. a particle that is not decayed further by the generator (may also include unstable particles that are to be decayed later, as part of the detector simulation). Such particles must always be labelled '1'.
  • status 2: a decayed Standard Model hadron or tau or mu lepton, excepting virtual intermediate states thereof (i.e. the particle must undergo a normal decay, not e.g. a shower branching). Such articles must always be labelled '2'. No other particles can be labelled '2'.
  • status 3: a documentation entry
  • status 4: an incoming beam particle
  • status 11-200: an intermediate (decayed/branched/...) particle that does not fulfill the criteria of status code 2, with a generator-dependent classification of its nature

CMS Computing Structure

CMS Data Hierarchy

1. RAW: full event information from the Tier-0 (i.e. from CERN), containing 'raw' detector information (detector element hits, etc)

2. RECO: the output from first-pass processing by the Tier-0. This layer contains reconstructed physics objects, but it's still very detailed

3. AOD("Analysis Object Data"): this is a "distilled" version of the RECO event information, and is expected to be used for most analyses

CMSSW and Event Data Model ( EDM)

The CMSSW event processing model consists of one executable, called cmsRun, and many plug-in modules which are managed by the Framework. All the code needed in the event processing (calibration, reconstruction algorithms, etc.) is contained in the modules. The same executable is used for both detector and Monte Carlo data.

The CMSSW executable, cmsRun, is configured at run time by the user's job-specific configuration file. This file tells cmsRun

  • which data to use
  • which modules to execute
  • which parameter settings to use for each module
  • what is the order or the executions of modules, called path
  • how the events are filtered within each path, and
  • how the paths are connected to the output files
The CMS Event Data Model (EDM) is centered around the concept of an Event. An Event is a C++ object container for all RAW and reconstructed data related to a particular collision. During processing, data are passed from one module to the next via the Event, and are accessed only through the Event. All objects in the Event may be individually or collectively stored in ROOT files, and are thus directly browsable in ROOT. This allows tests to be run on individual modules in isolation. Auxiliary information needed to process an Event is called Event Setup, and is accessed via the EventSetup.

The HLT system creates RAW data events containing:

  • the detector data,
  • the level 1 trigger result
  • the result of the HLT selections (HLT trigger bits)
  • and some of the higher-level objects created during HLT processing.
The CMS software framework uses a “software bus” model, where data is stored in the event which is passed to a series of modules. A single executable, cmsRun, is used, and the modules are loaded at runtime. A configuration file defines which modules are loaded, in which order they are run, and with which configurable parameters they are run.

Events from a software point of view: The Event Data Model ( EDM)

In software terms, an Event starts as a collection of the RAW data from a detector or MC event, stored as a single entity in memory, a C++ type-safe container called edm::Event. Any C++ class can be placed in an Event, there is no requirement on inheritance from a common base class. As the event data is processed, products (of producer modules) are stored in the Event as reconstructed (RECO) data objects. The Event thus holds all data that was taken during a triggered physics event as well as all data derived from the taken data. The Event also contains metadata describing the configuration of the software used for the reconstruction of each contained data object and the conditions and calibration data used for such reconstruction.

Products in an Event are stored in separate containers, organizational units within an Event used to collect particular types of data separately. There are particle containers (one per particle), hit containers (one per subdetector), and service containers for things like provenance tracking. The full event data (FEVT) in an Event is the RAW plus the RECO data. Analysis Object Data (AOD) is a subset of the RECO data in an event; AOD alone is sufficient for most kinds of physics analysis.