Commissioning primary dataset in AOD format from RunB of 2010 (/Commissioning/Run2010B-Apr21ReReco-v1/AOD)

How were these data selected?

Data taking / HLT
The collision data were assigned to different RAW datasets using the following HLT configuration.

Data processing / RECO
This primary AOD dataset was processed from the RAW dataset by the following step:
Step: RECO
Release: CMSSW_4_2_1_patch1
Global tag: FT_R_42_V10A::All
The configuration file for RECO step can be generated with the cmsDriver command line script in the corresponding CMSSW release area:
cmsDriver.py reco -s RAW2DIGI,L1Reco,RECO --data --conditions FT_R_42_V10A::All --eventcontent AOD --no_exec --python reco_cmsdriver2010.py

HLT trigger paths

There are four categories of triggers in the Commissioning dataset:

~30% "almost" Minimum-bias-like trigger (some tagger requirements):
HLT_L1_BptxXOR_BscMinBiasOR

~10% multi-vertex triggers with or without energy threshold (biased):
HLT_MultiVertex6_v2
HLT_MultiVertex6
HLT_MultiVertex8_L1ETT60_v2
HLT_MultiVertex8_L1ETT60

~30% isolated track triggers with some L1 jet (e.g. for taus):
HLT_IsoTrackHB_v2
HLT_IsoTrackHB
HLT_IsoTrackHE_v3
HLT_IsoTrackHE_v2
HLT_IsoTrackHE

~20% technical "muon" (DT or CSC based) triggers:
HLT_Activity_CSC
HLT_Activity_DT
HLT_Activity_DT_Tuned

All possible HLT trigger paths in this dataset are:
HLT_Activity_CSC
HLT_Activity_DT
HLT_Activity_DT_Tuned
HLT_Activity_Ecal
HLT_Activity_EcalREM
HLT_Activity_L1A
HLT_Activity_PixelClusters
HLT_IsoTrackHB
HLT_IsoTrackHE
HLT_L1_BptxXOR_BscMinBiasOR
HLT_MultiVertex6
HLT_MultiVertex8_L1ETT60
HLT_MultiVertex6_v2
HLT_MultiVertex8_L1ETT60_v2
HLT_IsoTrackHB_v2
HLT_IsoTrackHE_v3
HLT_IsoTrackHE_v2
HLT_IsoTrackHE_v2

How were these data validated?

During data taking all the runs recorded by CMS are certified as good for physics analysis if all subdetectors, trigger, lumi and physics objects (tracking, electron, muon, photon, jet and MET) show the expected performance. Certification is based first on the offline shifters evaluation and later on the feedback provided by detector and Physics Object Group experts. Based on the above information, which is stored in a specific database called Run Registry, the Data Quality Monitoring group verifies the consistency of the certification and prepares a json file of certified runs to be used for physics analysis. For each reprocessing of the raw data, the above mentioned steps are repeated. For more information see:

CMS data quality monitoring: Systems and experiences

The CMS Data Quality Monitoring software experience and future improvements

The CMS data quality monitoring software: experience and future prospects

How can you use these data?

You can access these data through the CMS Virtual Machine. See the instructions for setting up the Virtual Machine and getting started in

How to install the CMS Virtual Machine

Getting started with CMS open data

Files and indexes