This Example Is Not Currently Working out of the Box
Setting Up CMSSW
Installation
The first step to running CMSSW is to set up scramv1 for the version of CMSSW you are using. We will be using CMSSW_1_2_0 for this set of tutorials.
source /code/osgcode/cmssoft/cmsset_default.sh CMSSW_1_2_2
You may want to put this in your .bash_profile (or other setup file) so that you don't have to do it every time you log in.
So my full procedure for initial installation looks something like this:
source /code/osgcode/cmssoft/cmsset_default.sh CMSSW_1_2_2
scramv1 project CMSSW CMSSW_1_2_2
The second line above will create a directory called CMSSW_1_2_2 in your current working directory. It will have a set of subdirectories.
Every time you login, you must set up your runtime environment. NOTE: The quotes around the scramv1 command are back quotes and are found on the same key as the ~. They are not single quotes.
cd CMSSW_1_2_2/src
eval `scramv1 runtime -sh`
Running CMSSW
Quick Example: From Simulation to Analysis
Since we all have accounts on uaf-1 at UCSD, we will do the tutorials here for now.
This example will be a streamlined run through of
Oliver's tutorial and then we will work with the constituent files to learn what they are and how they interact.
Let's start by setting up our project area and environment.
In your home directory, or where ever you want your CMSSW_1_2_2 directory set up:
source /code/osgcode/cmssoft/cmsset_default.sh CMSSW_1_2_2
scramv1 project CMSSW CMSSW_1_2_2
Now you will see a CMSSW_1_2_2 directory,
cd CMSSW_1_2_2/src
eval `scramv1 runtime -sh`
Your environment is now set up to run CMSSW_1_2_2.
Next, let's check out the package
Configuration
from the CMSSW CVS repository. First you must set up your CVSROOT environment variable.
source $CMS_PATH/utils/cmscvsroot.sh CMSSW
cvs login
The anonymous login password is: 98passwd
cvs co Configuration
Now you have the package
Configuration
in your work area.
The configuration file we use for the tutorial is part of the Configuration module:
Configuration/ReleaseValidation/data/h_zz_4mu_allReco.cfg
Take a look at this file and change the max events up to 10 or 20 so we might get some events in our histograms. We will look carefully at these files later, but for now we are just going to go through the motions. Now we are ready to use
cmsRun
which is the only executable you will ever run while using CMSSW.
cmsRun Configuration/ReleaseValidation/data/h_zz_4mu_allReco.cfg
This will produce a .root file of the specified number of events. We can take a look:
root
TBrowser b
To exit root
.q
Now we will run a bit of analysis code to reconstruct the Z and Higgs particles we simulated.
cp ~edusinberre/CMSSW_1_2_0/src/analyze_HZZ_head.C .
cp ~edusinberre/CMSSW_1_2_0/src/analyze_HZZ.C .
root
.x analyze_HZZ_head.C
.x analyze_HZZ.C
This produces a .root file called
HZZ.root
. We can use the mouse to navigate through the histogram as before, or we can load the file and plot the histograms from the command line.
root
TFile("HZZ.root")
mmumu->Draw();
mzz->Draw();
A More Complete Look at CMSSW
Now let's a closer look at the configuration files. The offical documentation on the CMSSW Configuration files can be found
here.
The configuration file is what tells the executable
cmsRun
what it should run, in which order, and with which parameters.
We are going to modify the file
Configuration/ReleaseValidation/data/h_zz_4mu_allReco.cfg
to also simulate H->gamgam decays. This is fairly simple, all we need to do is modify a couple of the parameters in the long parameter set.
You may also want to change the name of the .cfg and output files. Try this and then rerun. Note that nothing needs to be recompiled. (You will also note that this takes a long time to run. A file containing 200 H->gamgam events can be found at
~ssimon/CMSSW_1_2_0/src/h_gamgam.root
We now need to create an analysis that will reconstruct the invariant mass of the photons from the decayed Higgs. We will start with the code used to reconstruct the muons, so copy
analyze_HZZ.C
and
analyze_HZZ_head.C
to new file names. First change the
*_head.C
to open your new file with the Higgs decay events in it.
Next we want to add a photon Collection to the analysis. In the analyze_*.C file, first change the histogram filename to whatever you like. You then want to declare any new histograms you want to output for the photon information. For example, you may want to output the energy, eta and phi coordinates, and the mass of the reconstructed diphoton masses.
TH1F* h_scenergy = new TH1F("scenergy","Super Cluster Energy",100,0.,100.);
TH1F* h_sceta = new TH1F("sceta","SuperCluster Eta",50,-3.0,3.0);
TH1F* h_scphi = new TH1F("scphi","SuperCluster Phi",100,-6.28,6.28);
TH1F* h_mgg = new TH1F("mgg","DiPhoton Mass",100,0,200.0);
Since the code already has Track reconstruction, you can simply copy the declarations for tracks and modify them accordingly for photon reconstruction. Add the line
std::vector<reco::Photon> photonCollection;
Then declare the new photon branch
TBranch *pbranch = tree->GetBranch("recoPhotons_correctedPhotons__Test.obj");
pbranch->SetAddress(&photonCollection);
Inside the tree entries loop you will need to get the branch entries
pbranch->GetEntry(index);
Still inside the entries loop (I suggest just inside the end of the event loop), you will add a loop which runs over photons, calculates (or simply gets) quantities of interest (energy,eta,phi, diphoton mass, etc). An example of what you could add is provided below.
if (photonCollection.size()>1)
{
for ( unsigned int bindex = 0; bindex < photonCollection.size()-1; ++bindex )
{
reco::Photon* sc1 = (reco::Photon*)photonCollection[bindex];
for ( unsigned int cindex = bindex+1; cindex < photonCollection.size(); ++cindex )
{
reco::Photon* sc2 = (reco::Photon*)photonCollection[cindex];
double e1 = sc1->energy();
double e2 = sc2->energy();
double eta1 = sc1->eta();
double eta2 = sc2->eta();
double phi1 = sc1->phi();
double phi2 = sc2->phi();
TLorentzVector htest(0,0,0,0);
std::cout << "Photon 'mass' = " << sc1->mass() << std::endl;
Double_t px1 = sc1->px();
Double_t py1 = sc1->py();
Double_t pz1 = sc1->pz();
Double_t px2 = sc2->px();
Double_t py2 = sc2->py();
Double_t pz2 = sc2->pz();
Double_t DiPhotonMass = sqrt((e1+e2)*(e1+e2) - ((px1+px2)*(px1+px2) + (py1+py2)*(py1+py2) + (pz1+pz2)*(pz1+pz2)));
h_scenergy->Fill(e1);
h_scenergy->Fill(e2);
h_sceta->Fill(eta1);
h_sceta->Fill(eta2);
h_scphi->Fill(phi1);
h_scphi->Fill(phi2);
h_mgg->Fill(DiPhotonMass);
}
}
}
The full file format looks something like this (where "..." represents actual information omitted for the sake of brevity):
process Test =
{
source = PythiaSource
{
...
PSet PythiaParameters =
{
vstring parameterSets =
{
"pythiaHZZmumumumu"
}
vstring pythiaHZZmumumumu =
{
... (actual physics input?)
}
}
}
include ...
replace ...
service = RandomNumberGeneratorService
{
...
PSet moduleSeeds =
{
...
}
}
include ...
...
# Event output
include ...
module FEVT = PoolOutputModule
{
...
}
}
}
endpath outpath = {FEVT}
schedule = {p1,p2,p3,outpath}
}
The file is made out of a series of "loops" or "declarations" of objects. It appears to contain:
- One process loop that encompasses all the code. The process loop opens at the top of the configuration file, and closes at the end.
process Test =
{
...
}
- One source loop that contains the Parameter Sets (the actual physics information of the config file). This is the first thing in the process loop. The formal documentation claims that this defines where the input comes from.
source = PythiaSource
{
...
}
- A parameter-set loop, which contains within the vstrings with the physics parameters.
PSet PythiaParameters =
{
...
}
- Two vstrings, vectors of strings, that hold actual parameters.
vstring parameterSets =
{
"pythiaHZZmumumumu"
}
--
MatthewNorman - 05 Jan 2007
--
ElizabethDusinberre - 17 Jan 2007