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

How were these data selected?

There are three categories of triggers in the MuMonitor dataset, which strongly overlaps with the Mu and MuOnia datasets, including formal overlaps of the trigger selection. These categories are also heavily overlapping with each other. The dataset provides some additional acceptance for low pt and/or lower quality muons:

~70% inclusive single muon triggers with varying trigger pt threshold 0,3,5,7 GeV plus several with loosened quality cuts.

~50% inclusive dimuon triggers with no explicit trigger pt threshold or loosened requirements on 2nd muon.

~5% one J/psi trigger with no pt threshold.

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
The possible HLT trigger paths in this dataset are:
HLT_L1DoubleMuOpen
HLT_L1Mu
HLT_L1Mu7
HLT_L1MuOpen
HLT_L1MuOpen_DT
HLT_L2Mu0
HLT_L2Mu3
HLT_L2Mu30
HLT_L2Mu5
HLT_L2Mu7
HLT_Mu0
HLT_Mu0_L1MuOpen
HLT_Mu0_L2Mu0
HLT_Mu0_Track0_Jpsi
HLT_Mu3
HLT_Mu3_L1MuOpen
HLT_Mu5_L1MuOpen

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