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 : gsiftp://cms-gridftp.rcac.purdue.edu/store/user/kjung (for use with the new 'gfal' tools)
MIT : gsiftp://se01.cmsaf.mit.edu:2811//cms/store/user/

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://cmseos.fnal.gov//store/user/

Opening files from T2 : root://cmsxrootd.fnal.gov///

srm paths to various T2 sites

Purdue: srm://srm.rcac.purdue.edu:8443/srm/v2/server?SFN=/mnt/hadoop/store/user/kjung (soon to be decommissioned)
MIT: srm://se01.cmsaf.mit.edu:8443/srm/v2/server?SFN=/mnt/hadoop/cms/store/user/
LLR: srm://polgrid4.in2p3.fr:8446/srm/managerv2?SFN=/dpm/in2p3.fr/home/cms/trivcat/store/user/
CERN EOS: srm://srm-eoscms.cern.ch:8443/srm/v2/server?SFN=/eos/cms/store

tdr_diff instructions

https://twiki.cern.ch/twiki/bin/view/Main/TdrDiffInstr

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 (?)

Herwig

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

Herwig++

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.