1- Overview
We describe below the
modules and classes used in run 2 offline calorimetry.
A brief introduction
to the design and the event data model is given in section 2.
A description of the
calorimetry packages in the run 2software distribution in section 3
This is followed
by an overview of the calorimetry infrasturcture classes in section 4,
jets
in section 5, missing
Et in section 6, em clustering in section 7, shower maximum and
preshower clustering
in section 8. Examples of how to access data are given in Section
9.
*** If you want to jump to examples right away, go to section 9. ***
2- Event Data Model and Design.
The event
data model (EDM) allows us to directly add objects to the event record.
This means
we do not have to access and unpack a bank into a convenient data structure
(like a
fortran common block). Therefore, the output of offline calorimetry
software are container
classes
or "storable objects" e.g. we store calorimeter tower objects, jet objects
etc. The only
TRYBOS
banks used are the "D" banks coming on input from the online side.
More details on the
EDM and
the way calorimeter objects are stored are given in the appendix (available
soon).
The classes
in the calorimetry software can be divided into two categories: the first
category
deals with the building of towers from the online D banks. This task
is
performed
by the "CalorimetryModule" and the output is an object called "CalData"
which essentially
contains the information that used to be in the run 1 "TOWE"
bank.
The second category includes the infratructure to support em and
jet
clustering.
This part was designed so that a user can easily plug-in various
algorithms
into our clustering modules. The modularity of the clustering code
makes
it easy
to add algorithms and the choice of algorithm can be made at run time.
For example,
a user can select the data input source for jet clustering to be CalData
(i.e. real
data), HEPG (i.e. the particle list) or an arbitrary calorimeter grid.
The user
can also
select how the jet centroids are calculated from the towers using either
a
"Snowmass"
summer or a four-vector summer. This design allows us to export our
jet
algorithm
since the input data and the clustering algorithms are "factorized".
3- Calorimetry Packages in the Run 2 Distribution
The run2 software packages described below correspond to distribution versions
later
than 3.4.0.
Name
of package Contents
-CalorGeometry
Classes that access and build the calorimeter geometry (excluding
the shower maximum detectors) It also includes some utility classes
used in clustering algorithms.
-CalorObjects
Storable objects like the container of calorimeter towers (CalData), the
container for "physics towers" i.e. towers that have their transverse
energies calculated using a given vertex. Some parameter set classes
are also stored here. Also,
strip classes (central, plug, preradiator
strips) are kept here.
-Calor Algorithm classes used in em and jet clustering software.
-CalorMods
The module that builds CalData i.e. CalorimetryModule and an example
module that shows how to access CalData. It also contains
the CPR
(central preradiator strips) reconstruction module.
-JetObjects Jet object classes (like CdfJet and CdfJetColl)
-Jet
Some utility classes (like jet corrections)
and helper classes.
-JetMods
The default clustering algorithm (JetCluModule), the run 2 seedless cone
algorithm (SeedlessConeModule) and the Kt algorithm (KtClusModule).
It also contains an example module that shows how to access
jet information.
-MetObjects
The missing transverse energy object class (CdfMet, akin to run 1
METS bank).
-Met Met utility classes (like NaiveEtCalculator, CdfMetPuffer etc.).
-MetMods
The default missing transverse energy module (CdfMetModule) and
an example module that shows how to access CdfMet.
-Electron
The em object classes like EmCluster and CdfEmObject along with
some utility classes.
-ElectronMods
The em clustering module (EmClusterModule) and the CdfEmObject
module.
-ShowerMax
The shower maximum object classes like ShowerMaxCluster, PesCluster
and
CesCluster.
-ShowerMaxMods
The shower maximum clustering modules.
4- Calorimetry Infrastructure
The offline calorimeter
software contains many different kinds of classes or
objects, some of which are used
to store data while others are used as utility
classes. This part will concentrate
on information storage classes.
There are three main areas where information is stored in offline calorimetry:
4.1-
The first area contains geometry information. These classes can be found
in the CalorGeometry
directory. Both calorimeter simulation and reconstruction
get their geometrical
constants from this area.
4.2-
The second area contains information that is directly related to what was
measured
by the calorimeter, like energies or TDC times. We have labeled
the
container which has calorimeter data as "CalData". It is very similar
to
the
Run 1 TOWE bank. CalData contains calorimeter tower objects or
"CalTowers".
A CalTower will have the following information inside it:
- eta index
- phi index
- validation
code
- EM energy
- Hadronic
energy
- EM phi
center-of-gravity
- Hadronic
phi center-of-gravity
The CDF calorimeters
have 9 different types of towers and we therefore
need 9 different
data structures or classes to store their information. These
classes are called
TowerType0, TowerType1, ..., TowerType8. For example,
here are the
contents of the TowerType0 class (in the middle of the central
calorimeter):
chaTime
- TDC time for this tower
cemEnergy[0]
- CEM PMT 1 energy
cemEnergy[1]
- CEM PMT 2 energy
chaEnergy[0]
- CHA PMT 1 energy
chaEnergy[1]
- CHA PMT 2 energy
stripEnergy
- strip chamber energy
crackEnergy
- crack chamber energy
The TowerType
classes inherit from CalTower i.e. they have both their
specialized data
(like TDC time) and the more generalized data (like
eta index).
The access functions or methods will be given in a later
section along
with some examples on how to access the calorimeter data.
All the information
in CalData is currently persistent i.e. we store all
the integers
and floats sequentially to a file at the end of an event. We
are currently
in the process of compressing the contents CalData to make
its size comparable
to the Run1 Q bank (QTOW).
4.3-
The third area's information depends on the chosen vertex as well as the
some input data which can be real data (CalData) or a list of particles
(HEPG bank). Once a vertex is chosen, the transverse energy is calculated
for every eta segment of the calorimeter and an object called a PhysicsTower
is constructed. The reason we introduce the PhysicsTower at this
stage
is to enable our clustering algorithms to use these objects instead of
the CalTower mentioned above. This decouples the data input source
from the clustering code while still allowing the user to have access
to a CalTower (tower containing real data, not MC information), if needed.
The container of PhysicsTowers is called PhysicsTowerData. To make
PhysicsTowers, the user must specify a vertex (the default is 0), an
input source and a tower calculator algorithm i.e. you must specify
how the total Et in a tower is to be obtained. Currently the two options
are "Standard" (run1) and four-vector calculations.
5- Jet Clustering
There are currently 3 jet
clustering algorithms in the run2 code: JetCluModule
(the C++ version of the run
1 JETCLU) ,KtClusModule and SeedlessConeModule
(a run2 cone clustering algortithm).
These algorithms fill the CdfJet
object which
essentially contains
the information in the run1 JETS
bank. The collection of jets
is called CdfJetColl. The
parameters used in the making
of the collection e.g. the
algorithm, the cone size,
the seed threshold etc., are
stored in a separate object
and the collection has a
pointer to its parameter set
To see the CdfJet interface ,click here
6- Missing Et
The missing Et object is called
CdfMet and contains much of the information that
used to be in the run 1 METS
bank. The module that fills CdfMet is called CdfMetModule.
This module does a simple
vector sum of all towers above a certain threshold in the
calorimeter. Currently,
only the "raw" missing Et is available but optional corrections
will be available soon.
To see the CdfMet interface, click here
7- Em Clustering
...
8- ShowerMaximum and Preshower clustering
Here are some examples on
how to access data. Each example corresponds to a module
that can be used in an executable.
To get a complete list of accessible methods
for each class, please consult
our code browser.
A quick summary
on how to access some calorimetry objects (CalData, Met and Jets) from
the event can be found
here
-CalorExampleModule:
To run this module:
1- create a test release and add the CalorMods package
2- type: gmake CalorMods.tbin
3- type: bin/$BFARCH/CalorExample CalorMods/test/run_CalorExample.tcl
Here's part of the CalorExampleModule.cc
file in CalorMods/src
cout << "CalorExampleModule: event entry" << endl;
// make a handle to a CalData object.
CalData_ch data;
//
get CalData from the event.
CalData::Error
result = CalData::find(data);
if(result
!= CalData::OK){
cout << "could not find CalData in the event" << endl;
return(AppResult::ERROR) ;
}
//
this prints a summary of what is in CalData
data->printSummary();
//
with verbose = true, you'll get a printout for each tower
if
(_verbose.value()) data->print(cout);
//
this will be a list of calorimeters for this tower
DetList
caloList;
//
Here's a loop over towers in CalData
for(CalData::ConstIterator
tower= data->begin(); tower != data->end(); ++tower){
// some of the things you can ask a tower
// valcode_t code = tower->validCode();
// of validation code - not filled right now
float emCogPhi = tower->emCOGPhi(); // em center
of gravity
float hadCogPhi = tower->hadCOGPhi(); // had center of gravity
float e = tower->energy();
float emE = tower->emEnergy() ;
float hadE = tower->hadEnergy() ;
int ieta = tower->iEta() ;
// eta index of tower
int iphi = tower->iPhi() ;
// phi index of tower
int type = tower->myType() ;
// type of tower (0,8)
float emphi =tower->emPhi() ;
float hadphi = tower->hadPhi() ;
tower->detectors(caloList); // get detector list
// Loop over detectors (calorimeters) in the tower
for(DetList::iterator calIter = caloList.begin(); calIter != caloList.end();
++calIter){
// To access a particular Calorimeter in the tower, we build a key
CellKey key(ieta,iphi,*calIter);
// time is not filled in the simulation right now
// float time = -999.0;
// if(tower->hasTiming()) time = tower->time(key)
; // Only CHA has timing
// if the tower does not have a second pmt, the function will disregard
the
// pmt number (0 or 1).
// Note: simulation (GFLASH) splits the energy in two i.e. half for each
pmt.
// This will change
soon.
float pmtE0 = tower->pmtEnergy(key, 0);
float pmtE1 = tower->pmtEnergy(key, 1);
if((*calIter) == PEM){
if(pmtE0 !=0) cout << "PEM " << "pmt0 energy = "<<pmtE0<<
endl;;
}
if((*calIter) == CHA){
if(pmtE1 !=0) cout << "CHA " << "pmt1 energy = "<<pmtE1
<< endl;
}
if(tower->includesDetector(MIP)){
// No simulation of miniplug yet
// cout << "Miniplug tower (type 7
or 8)" << endl;
}
}
}
// now something
a bit more fancy using some STL
vector<const
CalTower* > towerList;
calorMakeView(data,towerList,HasCalorimeter(WHA));
cout << "there
are " << towerList.size() << " WHA towers with energy" <<
endl;
towerList.clear();
calorMakeView(data,towerList,EmEnergyGreater(3.0));
cout << "there
are " << towerList.size() << " Towers with EM energy above
3.0 GeV" << endl;
-JetExampleModule: 1- create a test release and add the JetMods package 2- type: gmake JetMods.tbin 3- type: bin/$BFARCH/JetExample JetMods/test/run_JetExample.tcl Here's part of the JetExampleModule.cc file in JetMods/src
//////////////////////////////////////////////////////////////////
//
// Get Jet collection from the event
//
//////////////////////////////////////////////////////////////////
// first make a handle (this is to be used as a pointer)
CdfJetColl_ch jetCollHandle;
// this will return the cone size in the tcl file (default is 0.7)
std::string description = "JetCluModule";
CdfJetColl::Error jetStatus = CdfJetColl::find(jetCollHandle,description);
if(jetStatus == CdfJetColl::ERROR){
cerr << "Error in JetExampleModule: could not find jet collection" << endl;
}
// print parameters and dump all information in the jet collection
jetCollHandle->jetParams().print();
jetCollHandle->print(cout);
const JetList& eventJets = jetCollHandle->contents();
// the "eventJets" belong to the event i.e. we can't modify them. For convenience,
// we'll make a local copy that can be manipulated at will.
JetList jets = eventJets;
size_t nJets = jets.size();
// sort them in descending Et (in principle they are already sorted in JetClu)
sort(jets.begin(), jets.end(), EtGreater());
// Make a list of high Et jets. There many ways of doing this.
// Here's one (not the most efficient... just want to show some
// STL algorithms). Will use new EDM views in a short while.
JetIter iter15GeV = find_if(jets.begin(),jets.end(),EtLessThan(15.0));
JetList highEtJets;
for(JetIter iter = jets.begin(); iter != iter15GeV; ++iter)
highEtJets.push_back(*iter);
// this is the number of high et jets without the electron
size_t nHighEtJets = highEtJets.size();
// loop over our list of high Et jets and print some contents
cout << "Size of jet collection: " << nJets << endl;
cout << "number of high Et jets: " << nHighEtJets << endl;
for(JetIter iter = highEtJets.begin(); iter!=highEtJets.end(); ++iter){
cout << endl;
cout << "Et of jet: " << iter->et() << endl;
cout << "eta of jet: " << iter->eta() << endl;
cout << "phi of jet: " << iter->phi() << endl;
// loop over the towers of a jet
PhysicsTowerView& jetTowers = iter->towers();
Towers::const_iterator firstTower = jetTowers.begin();
Towers::const_iterator lastTower = jetTowers.end();
for(Towers::const_iterator iter = firstTower; iter != lastTower; ++iter){
// print the contents of the towers
cout << *iter << endl;
}
} // end loop over jets -MetExampleModule: 1- create a test release and add the MetMods package 2- type: gmake MetMods.tbin 3- type: bin/$BFARCH/CdfMetExample MetMods/test/run_MetExample.tcl Here's part of the CdfMetExampleModule.cc file in MetMods/src /////////////////////////////////////////////////////////// // // Get the uncorrected missing Et // /////////////////////////////////////////////////////////// // first make a handle (this is to be used as a const pointer) CdfMet_ch metHandle; // this will return the first Met object it finds CdfMet::Error metStatus = CdfMet::find(metHandle); if(metStatus == CdfMet::ERROR) cerr << "Error in CdfMetExampleModule: could not find Met" << endl; float missingEt = metHandle->met(); cout << endl; cout << "Uncorrected missing Et = " << missingEt << endl; cout << "X component of missing Et = " << metHandle->exSum() << endl; cout << "Y component of missing Et = " << metHandle->eySum() << endl; cout << "Sum Et = " << metHandle->etSum() << endl; cout << "Em Y component of missing Et for tower type 0 = " << metHandle->etEmYType(0) << endl; cout << "Had X component of missing Et for tower type 1 = " << metHandle->etHadXType(1) << endl; cout << "Energy Sum for iEta 23= " << metHandle->eSumIeta(23) << endl; // The list of methods can be found in CdfMet.hh in the MetObjects/MetObjects area