Software

The main EMC offline reconstruction chain consists of:

StEmcAdcToEMaker - This maker gets ADC values for all EMC sub detectors and applies the calibration to get the proper energy value.
StPreEclMaker - This maker does clustering in all EMC sub detectors.
StEpcMaker - This maker matches the clusters in EMC sub detectors to get the final EMC point.

To have this chain working properly, some others programs are necessary. The full offline reconstruction chain is shown in the schema below:

Aside from Drupal, one can also find some very old BEMC documentation at http://rhic.physics.wayne.edu/emc/

Clustering

Second most important step in EMC data reduction is to find clusters from EMC data.

Main code performing EMC clustering is located in StRoot/StPreEclMaker and StRoot/StEpcMaker

The main idea behind the BEMC cluster finder is to allow multiple clustering algorithms. With that in mind, any user can develop his/her own finder and plug it in the main cluster finder.

In order to develop a new finder the user should follow the guidelines described in this page.

Display Macro

A Small cluster finder viewer was written for the BEMC detector. In order to run it, use the macro:

$CVSROOT/StRoot/StPreEclMaker/macros/clusterDisplay.C

This macro loops over events in the muDST files, runs the BEMC cluster finder and creates an event by event display of the hits and clusters in the detector. This is an important tool for cluster QA because you can test the cluster parameters and check the results online. It also has a method to do statistical cluster QA over many events.

The commands available are:

setHitThreshold(Int_t det, Float_t th)

This method defines the energy threshold for displaying a detector HIT in the display. The default value in the code is 0.2 GeV. Values should de entered in GeV. The parameters are:

Int_t det = detector name. (BTOW = 1, BPRS = 2, BSMDE = 3 and BSMDP = 4)
Int_t th = hit energy threshold in GeV.

next()

This method displays the next event in the queue.

qa(Int_t nevents)

This method loops over many events in order to fill some clusters QA histograms. The user needs to open a TBrowser n order to access the histograms. The parameters are:

Int_t nevents = number of events to be processed in QA

help()

Displays a small help in the screen.

How to write a new Cluster Finder

To create a new algorithm it is important to understand how the cluster finder works.

EmcClusterAlgorithm.h

This file defines a simple enumerator for the many possible cluster algorithms. In order to add a new algorithm the user should add a new position in this enumerator

StPreEclMaker.h and .cxx

The cluster finder itself (StPreEclMaker) is a very simple maker. This maker is responsible only for creating the finder (in the Init() method) and call some basic functions in the Make() method.

StPreEclMaker::Init()

This method just instantiates the finder. In the very beginning of Init() method, the code checks which algorithm is being requested and creates the proper finder.

StPreEclMaker::Make()

The Make() method grabs the event (StEvent only) and exits if no event is found. If the event is found it calls 4 methods in the finder. These methods are:

mFinder->clear(); // to clear the previous event local cluster
mFinder->clear(StEvent*); // to clean any old cluster or pointer in StEvent
mFinder->findClusters(StEvent*); // to find the clusters in this event
mFinder->fillStEvent(StEvent*); // to fill StEvent with the new clusters
mFinder->fillHistograms(StEvent*); // to fill QA histograms

The modifications the user should do in StPreEclMaker.cxx are only to add the possibility of instantiating his/her finder in the StPreEclMaker::Init() method.

Creating a new cluster algorithm

Before creating a new cluster algorithm it is important to know the basic idea behind the code. The basic classes are

StEmcPreCluster

There is an internal data format for the clusters in the code. The clusters are StEmcPreCluster which are derived from plain ROOT TObject. StEmcPreCluster is more complete than the regular StEvent cluster object (StEmcCluster) because it has methods to add and remove hits, split and merge clusters and well set matching id between different detectors.

StEmcPreClusterCollection

This is a placeholder for the StEmcPreCluster objects that are created. This object derives from the regular ROOT TList object. It has methods to create, add, remove and delete StEmcPreClusters. StEmcPreCluster objects that are created or added to the collections are owned by the collection so be careful.

StEmcVirtualFinder

This is the basic finder class. Any cluster algorithm should inherit from this class. It already create the necessary collections for the clusters in each detector.

To create a new finder algorithm you should define a finder class that inherits from the StEmcVirtualFinder and overwrite the method findClusters(StEvent*). Lets suppose you want to create a StEmcMyFinder algorithm. You should create a class with, at least, the following:
StEmcMyFinder.h

#ifndef STAR_StEmcMyFinder
#define STAR_StEmcMyFinder
#include "StEmcVirtualFinder.h"
class StEvent;
class StEmcOldFinder : public StEmcVirtualFinder 
{
  private:
  protected:
  public: 
                      StEmcOldFinder();
      virtual        ~StEmcOldFinder();
      virtual Bool_t  findClusters(StEvent*);
  ClassDef(StEmcMyFinder,1) 
};

#endif

StEmcMyFinder.cxx

#include "StEmcMyFinder.h"
#include "StEvent.h"
#include "StEventTypes.h"
ClassImp(StEmcOldFinder)
StEmcMyFinder::StEmcMyFinder():StEmcVirtualFinder()
{
  // initialize your stuff in here
}
StEmcMyFinder::~StEmcMyFinder()
{
}
Bool_t StEmcMyFinder::findClusters(StEvent* event)
{
  // check if there is an emc collection
  StEmcCollection *emc = event->emcCollection();
  if(!emc) return kFALSE;
  // find your clusters

return kTRUE; }

The method findClusters(StEvent*) is the method that StPreEclMaker will call in order to find clusters in the event. All the StEmcVirtualFinder methods are available for the user.

The user has 4 pre cluster collections available. They are named

mColl[det-1]

where det =1, 2, 3 and 4 (btow, bprs, bsmde and bsmdp)

How to deal with clusters and collections

Lets suppose you identified a cluster in a given detector. How do I work with StEmcPreCluster objects and the collections? Please look at the code itself to be more familiar with the interface. The next lines will give basic instructions with the most common tools:

To create and add a cluster to the collection for the detector ´det´
StEmcPreCluster *cl = mColl[det-1]->newCluster();

This line creates a cluster in the collection and returns its pointer.

To remove and delete a cluster from a collection
mColl[det-1]->removeCluster(cl); // cl is the pointer to the cluster

mColl[det-1]->removeCluster(i); // i is the index of the cluster in the collection

This will remove AND delete the cluster.

To get the number of clusters in a collection
mColl[det-1]->getNClusters();

To add hits to a StEmcPreCluster (pointer to the cluster is called ´cl´)
cl->addHit(hit);

where hit is a pointer to a StEmcRawHit object.

To add the content of a pre cluster ´cl1´ to a cluster ´cl´
cl->addCluster(cl1);

The added cluster ´cl1´ is not deleted. This is very useful if you identified a spitted cluster and would like to merge them.

How to do matching in the cluster finder?
Depending on the cluster finder algorithm one can do clusters in one detector using the information in the other detector as seed. In this sense, it is important do have some kind of matching available in the cluster finder. In the original software scheme, StEpcMaker is the maker responsible for matching the clusters in the BEMC sub detectors. This maker is still in the chain.

Because of StEpcMaker, we CAN NOT create StEmcPoints in the cluster finder. This should be done *ONLY* by StEpcMaker. In order to have a solution for that, StEmcPreCluster object has a member that flags the cluster with matching information. This is done by setting a matching id in the cluster. Use the methods matchingId() and setMatchingId(Int_t).

The matching id is an integer number. If matching id = 0 (default value), no matching was done and the matching will be decided in StEpcMaker. If matching id is not equal to 0, StEpcMaker will create points with clusters with the same matching Id.

Using this procedure, we can develop advanced matching methods in the cluster finder algorithm.

How to plug your finder into the cluster finder

In order to plug your algorithm to the cluster finder you need to change two files in the main finder

EmcClusterAlgorithm.h
This file defines an enumerator with the cluster finders. To add your algorithm in this enumerator add an entry in the enumerator definition, for example:

enum EmcClusterAlgorithm { kEmcClNoFinder = 0, kEmcClDefault = 1, kEmcClOld = 2, kEmcMyFinder = 3}; StPreEclMaker.cxx You should change the Init() method in StPreEclMaker in order to instantiate your finder. To instantiate your StEmcMyFinder object, add, in the Init() method of StPreEclMaker: if(!mFinder) { if(mAlg == kEmcClOld) mFinder = new StEmcOldFinder(); if(mAlg == kEmcMyFinder) mFinder = new StEmcMyFinder(); }



  Original cluster algorithm (kEmcClOld)
   This page describes the original cluster finder algorithm. In order to use this algorithm you should set with the algorithm kEmcClOld.
Salient features of the method implemented in the program are,

Clustering have been performed for each sub detector separately.
Currently clusters are found for each module in the sub detectors. There are some specific reasons for adopting this approach especially for Shower Max Detectors (SMD's). For towers, we are still discussing how it should be implemented properly. We have tried to give some evaluation results for this cluster finder.
There are some parameters used in the code with their default values. These default values are obtained after preliminary evaluation, but for very specific study it might be necessary to change these parameters. 
The output is written in StEvent format.
    

Cluster algorithm



Performs clustering module by module
Loops over hits for each sub detector module
Looks for local maximums

Cluster parameters

mEnergySeed – minimum hit energy to start looking for a cluster
mEnergyAdd -- minimum hit energy to consider the hit part of a cluster
mSizeMax – maximum size of a cluster
mEnergyThresholdAll – minimum hit energy a cluster should have in order to be saved
    


Neighborhood criterion 

Because of the difference in dimension and of readout pattern in different sub detectors, we need to adopt different criterion for obtaining the members of the clusters. 

BEMC: Tower gets added to the existing cluster if it is adjacent to the seed. Maximum number of towers in a cluster is governed by the parameter mSizeMax. It should be noted that BEMC, which takes tower as unit is 2-dimensional detector and by adjacent tower, it includes the immediate neighbors in eta and in phi.
BSMD: As SMDs are basically one-dimensional detector, so the neighborhood criterion is given by the condition that for a strip to be a neighbor, it has to be adjacent to any of the existing members of the clusters. Here also maximum number of strips in a cluster is governed by mSizeMax parameter. 
    

 Cluster Object 
After obtaining the clusters, following properties are obtained for each cluster and they are used as the members of the cluster object. 

Cluster Energy (Total energy of the cluster member).
Eta cluster (Mean eta position of the cluster).
Phi cluster (Mean phi position of the cluster).
Sigma eta, Sigma phi (widths of the cluster in eta nd in phi).
Hits (Members of the cluster).

Some Plots
BSMDE clusters for single photon events
   

  Performance Evaluation
   Note:  This is a rather old study that I found on BEMC public AFS space and ported into Drupal.  I don't know who conducted it or when.  -- A. Kocoloski
On the subject of reconstruction made by cluster finder and matching, evaluation has been developed  to determine how good is the reconstruction, efficiency, purity, energy and position resolution of reconstructed particles originally generated by simulation data. 
Cluster finder is being evaluated at the moment using single particle events, which favors the evaluation of efficiency and purity. In this case, we can define efficiency and purity for single particle events as:

efficiency - ratio between the number of events with more than 1 cluster and the total number of events.
purity - ratio between the number of events with only 1 cluster and the number of events with at least one cluster.

There are other quantities that could be used for evaluation. They are:

energy ratio - ratio between the cluster energy and the geant energy.
position resolution - difference between cluster position and particle position.

All these quantities can be studied as a function of the cluster finder parameters,  mSizeMax, mEnergySeed and mEnergyThresholdAll. The results are summarized below.
BTOW Clusters
mEnergyThresholdAll evaluation
Nothing was done to evaluate this parameter.
mEnergySeed evaluation
The purity as a function of mEnergySeed gets better and the efficiency goes down as this parameter increases.  Some figures (the others parameters were kept as minimum as possible) are shown for for different values of mSizeMax for single photons in the middle of a tower with pt = 1,4,7 and 10 GeV/c.
The following plots were generated using energy seeds of 0.1 GeV (left), 0.5 GeV (middle), and 1.5 GeV (right).  Full-size plots are available by clicking on each image:
Eta dfference

       
Phi difference

              



Number of clusters  

               



Energy ratio

       
mSizeMax evaluation
Nothing was done to evaluate this parameter.
BSMD Clusters
mEnergyThresholdAll evaluation
Nothing was done to evaluate this parameter.
mEnergySeed evaluation
The purity as a function of mEnergySeed gets better and the efficiency goes down as this parameter increases.  Some figures (the others parameters were kept as minimum as possible) are shown for for different values of mSizeMax for single photons in the middle of a tower with pt = 1,4,7 and 10 GeV/c.
The following plots were generated using energy seeds of 0.05 GeV (left), 0.2 GeV (middle), and 0.8 GeV (right).  Full-size plots are available by clicking on each image:
Eta Difference (BSMDE only)

  


Eta difference RMS as a function of photon energy for different seed energies:





Phi Difference (BSMDP only)

  


Phi difference RMS as a function of photon energy for different seed energies:



Number of clusters for BMSDE

  

Number of clusters for BSMDP:

  
BSMDE efficiency and purity as a function of seed energy


BSMDP efficiency and purity as a function of photon energy for different seed energies



mMaxSize evaluation
The efficiency and purity as a function of mSizeMax get better as this parameter increases but for values greater than 4 there is no difference. Some figures (the others parameters were kept as minimum as possible) are shown for for different values of mSizeMax for single photons in the middle of a tower with pt = 5 GeV/c.
   

  Point Maker
   After obtaining the clusters for 4 subdetectors, we need to obtain the information about the incident shower by making the proper matching between clusters from different subdetectors.
It should be mentioned that, because of the better energy resolution and higher depth BEMC is to be used for obtaining the energy of the shower. SMDs on the other hand will be used for obtaining the position of the showers because of their better position resolution. 
Currently Preshower detector (PSD) has not been included in the scheme of matching, so we discuss here the details of the method adopted for matching other 3 sub detectors. 
Following steps are adopted to obtain proper matching:

The clusters obtained from different sub detectors are sorted to obtain the clusters in a single subsection of the SMD phi.

Each module of SMD phi consists of 10 subsections. 

Each subsection consists of 15 strips along eta, giving phi positions of the clusters for the eta-integrated region of 0.1. 


In SMD eta same subsection region consists of 15 strips along phi and the same region consists of 2 x 2 towers. 


In the present scheme of matching, we match the clusters obtained in 3 sub detectors in each of this SMD phi subsection.
There are two levels of matching:

SMD eta - SMD phi match

First matching aims to obtain the position of the shower particle in (eta, phi). Because of the integration of signals in SMD etas in the SMD phi subsection region, (i.e.. each SMD eta strip adds the signal in 0.1rad of phi and each SMD phi strip adds the signal in delta eta=0.1 region.) For this type of configuration of detectors, we have decided to get the position matching for each SMD phi subsection. Even though for cases like 1 cluster in SMD eta and 1 cluster in SMD phi in the subsection, we have mostly unique matching of (eta, phi), but for cases where SMD eta/SMD phi subsection consists of more than 1 cluster (see figure) then the possibility of matching does not remain unique. the task is handled from the following standpoint, The number of matched (eta, phi) pairs are taken as minimum of (number of clusters in SMD eta, number of clusters in SMD phi). The (eta, phi) assignment for the pairs are given considering the pair having minimum of (E1-E2)/(E1+E2), where E1, E2 are the cluster energy of SMD eta and SMD phi clusters.

            


Position - energy match

It should be mentioned that position/energy matching is done only when there exists a cluster in BEMC for the subsection under study. Because of the large dimension of towers, the clusters obtained in BEMC is made up of more than one incident particles. In case of AuAu data, where particle density is very large, the definition of clusters in towers become ambiguous, especially for low energy particles. In the present scheme, as we have discussed earlier, we have followed the method of peak search for finding clusters, where maximum cluster size is 4 towers. 4 towers make the region of one SMD phi subsection, so we have obtained the energy for the pairs obtained in (SMD eta, SMD phi) from the cluster energy of BEMC cluster in the same subsection. For the cases where we have 1 cluster in BEMC, 1 cluster in SMD eta, 1 cluster in SMD phi, we assign the BEMC cluster energy to (eta, phi) pairs. But for the cases when the number of matched pairs is more than one, then we need to split the BEMC cluster energy. Presently it is done according to the ratio of the strengths of (eta, phi) pair energies. This method of splitting has the drawback of using SMD energies, where energy resolution is worse compared to BEMC energy resolution.





Codes for the point maker are found in StRoot/StEpcMaker
   

  Usage
   The cluster finder can run in many different chains. The basic modes of running it are:

bfc chain: This is the usual STAR reconstruction chain for real data and simulation.
standard chain: this is the most common way of running the cluster finder. The cluster finder runs with real data and simulated data.
embedding chain
    

There are some rules a user needs to follow in order to run the cluster finder properly:

Include the file $STAR/StRoot/StPreEclMaker/EmcClusterAlgorithm.h in order to define the cluster algorithm enumerator
Need to load the shared libraries
StPreEclMaker should run *AFTER* the BEMC hits are created (StADCtoEMaker or StEmcSimulatorMaker)
The cluster algorithm should be defined *BEFORE* Init() method is called
Any change in the cluster parameters should be done *AFTER* Init() is called.
    

The following is an example on how to run the cluster finder in a standard chain:

// include the definitions of the algorithms
#include "StRoot/StPreEclMaker/EmcClusterAlgorithm.h"
class StChain;
StChain *chain=0;
void DoMicroDst(char* list = "./file.lis",
                int nFiles = 10, int nevents = 2000)
{ 
  gROOT->LoadMacro("$STAR/StRoot/StMuDSTMaker/COMMON/macros/loadSharedLibraries.C");
  loadSharedLibraries();
  gSystem->Load("StDbUtilities");
  gSystem->Load("StDbLib");
  gSystem->Load("StDbBroker");
  gSystem->Load("St_db_Maker");
  gSystem->Load("libgeometry_Tables");
  gSystem->Load("StDaqLib");
  gSystem->Load("StEmcRawMaker");
  gSystem->Load("StEmcADCtoEMaker");
  // create chain 
  chain = new StChain("StChain"); 
  // Now we add Makers to the chain...
  maker = new StMuDstMaker(0,0,"",list,"",nFiles);
  StMuDbReader* db = StMuDbReader::instance();
  StMuDst2StEventMaker *m = new StMuDst2StEventMaker();
  St_db_Maker *dbMk = new St_db_Maker("StarDb","MySQL:StarDb");
  StEmcADCtoEMaker *adc=new StEmcADCtoEMaker();
  adc->setPrint(kFALSE);
  StPreEclMaker *ecl=new StPreEclMaker(); // instantiate the maker
  ecl->setAlgorithm(kEmcClDefault); // set the algorithm
  ecl->setPrint(kFALSE); // disables printing
  chain->Init(); 
  StEmcOldFinder* finder = (StEmcOldFinder*)ecl->finder(); // gets pointer to the finder
  finder->setEnergySeed(1,0.8); // change some setting in the finder
  int n=0;
  int stat=0;
  int count = 1;
  TMemStat memory;
  while ( (stat==0 || stat==1) && n<nevents) 
  {
    chain->Clear();
    stat = chain->Make();
    n++;
  }
  chain->Finish();
}



  Data Format
   BEMC data is always available using standard StEvent collections.  This is true regardless of whether one is analyzing simulations or real data, or whether the actual input file is in a geant.root,  event.root, or mudst.root format.  The appropriate BEMC maker (StEmcADCtoEMaker for real data, StEmcSimulatorMaker for simulations) will create an StEvent in-memory if necessary and fill the BEMC collections wth the correct data.
Three different types of calorimeter objects are available:
StEmcRawHit -- a hit for a single detector element (tower, smd strip, or preshower channel)
StEmcCluster -- a cluster is formed from a collection of hits for a single BEMC subdetector (tower / smd-eta / smd-phi / preshower)
StEmcPoint -- a point combines StEmcClusters from the different subdetectors.  Typically the SMD clusters are used to determine the position of points, and in the case of e.g. pi0 decay photons they also determine the fraction of the tower cluster energy assigned to each photon.  The absolute energy scale is set by the tower cluster energy.  Current point-making algorithms do not use the preshower information.
For more information see the StEvent manual.
   

  Embedding
   Update:  New B/EEMC embedding framework from Wei-Ming Zhang currently in peer review

The present BEMC embedding works as an afterburner that must be done after the TPC embedding.  Wei-Ming Zhang is working on a version that work in parallel with the TPC embedding.  Here's the current workflow:

During TPC embedding
In this step, only real EMC data is processed with all of the TPC embedding.  In the end, there are two files:


.event.root - This file contains the TPC reconstructed tracks (real data + simulation) and BEMC reco information (real data only)
.geant.root - This files contains the simulated tracks (TPC + EMC simulated data)
Once again, no BEMC embedding is done at this level.  The chain that process the BEMC real data is the same as the one used for production (StEmcRawMaker, StPreEclMaker and StEpcMaker)


After TPC embedding
This is where the BEMC embedding happens.  The idea is to get the output from the TPC embedding (.geant.root and .event.root files) and mix the BEMC simulated data with the real BEMC data.  The mixing is performed by StEmcMixerMaker and the main idea is to add the simulated ADC values to the real event ADC values.  In order to do that we need to follow some simple rules:
We have to simulate the ADC values with the same calibration table used for the real data
We cannot add pedestals or noise to the simulated data.  The real data already include the pedestals and noise.  If we simulate them we will end up overestimating both quantities.
We should embed simulated hits only for the towers with status==1.
The macro that runs the embedding can be found at StRoot/StEmcMixerMaker/macros/doEmcEmbedEvent.C.  The basic chain that runs in this macro is 
StIOMaker - to read the .event.root and .geant.root files
St_db_Maker - to make the interface with the STAR database and get the BEMC tables
StEmcADCtoEMaker - reprocesses the real BEMC data and fills an StEvent object with the calibrated real data.
StEmcPreMixerMaker - this is a simple maker whose only function is to make sure the chain timestamp is set using the real data event time.  This is very important to make sure the tables are correctly retrieved from the database.
StMcEventMaker - builds an StMcEvent object in memory.  This is necessary because the simulator maker needs to get the BEMC simulated data in this format.
StEmcSimulatorMaker - this maker gets the StMcEvent in memory that contains the BEMC simulated hits and does a slow simulation of the detector, generating the ADC values with the correct calibration tables.  At this point we have two StEmcCollections in memory: the one with the real BEMC data from step 3, and the one with the simulated data from the simulator maker.
StEmcMixerMaker - this maker gets the two StEmcCollections and adds the simulated one to the real data.  This is a simple ADC_total = ADC1 + ADC2 for each channel in each detector.  Only simulated hits belonging to channels that were good in the real data are added.
StEmcADCtoEMaker - reconstructs the event once more.  This step gets the new ADC values and recalibrates them.
StPreEclMaker - reconstructs the clusters with the embedded hits.
StEpcMaker - reconstructs the points
StAssociationMaker - does the TPC association
StEmcAssociationMaker - does the BEMC association
Add your own analysis maker
The embedding flow is illustrated in the following diagram:



   
  StEmcAssociationMaker
   Introduction
To treat many-particle events (pp and AuAu), we need to know which particle generated which cluster/point before evaluating the reconstructed clusters and points.  StEmcAssociationMaker accomplishes this by matching the many clusters and points in a given event with the respective simulated particles.Association Matrix
In order to associate the clusters/points to the corresponding particles, the Association software creates matrices.  The matrix columns correspond to the reconstructed clusters/points and the lines correspond to the particles.  We have three kinds of matrices:
Simple Matrix - matrix elements are 0 or 1.
Particle Fraction Matrix - matrix elements are the fraction of the total particle energy in a cluster.
Cluster Fraction matrix - matrix elements are the fraction of energy of a cluster that comes from a given particle.

                Simple Matrix                      Particle Fraction Matrix                   Cluster Fraction Matrix

A simple example using association matrices is presented below.  In the case of double photon events, we plot the purity of the measured clusters in SMD eta as a function of the photon distance.  The purity is obtained from the "Cluster Fraction" Association Matrix.

How to Use
In order to follow the same scheme done in StAssociationMaker we save the association information in multimaps.  Multimaps make it very easy for the user to get the association information for a given StMcTrack, cluster or point.  Detailed documentation for StAssociationMaker is available <a href="http://www.star.bnl.gov/STAR/comp/pkg/dev/StRoot/StAssociationMaker/doc/">here</a>.  There are essentially four multimaps defined for the BEMC:
multiEmcTrackCluster - correlates the StMcTrack with StEmcClusters
multiEmcClusterTrack - corrrelates the StEmcCluster with StMcTracks
multiEmcTrackPoint - correlates the StMcTrack with StEmcPoints
multiEmcPointTrack - correlates the StEmcPoint with StMcTracksThe following sample code can be used to access one of these multimaps provided StEmcAssociationMaker is available in the chain:
StEmcAssociationMaker *emcAssoc = GetMaker("EmcAssoc");
if(!emcAssoc) return;
multiEmcTrackCluster *map = emcAssoc->getTrackClusterMap(1); 
if(!map) return;
for(multiEmcTrackClusterIter j=map->begin(); j!=map->end(); j++) 
{
  StMcTrack* track = (StMcTrack*)(*j).first;
  StEmcClusterAssociation* value = (StEmcClusterAssociation*)(*j).second;
  if(track && value)
  {
    StEmcCluster *c = (StEmcCluster*) value->getCluster();
    if(c) 
    {
      cout <<" McTrack = "<<track<<" GeantId = "<<track->geantId()
           <<" pt = "<<track->pt()<<" TReta = "<<track->pseudoRapidity()
           <<" Cl = "<<c<<" E = "<<c->energy()<<" eta = "<<c->eta()
           <<" phi = "<<c->phi()
           <<" FrTr = "<<value->getFractionTrack()
           <<" FrCl = "<<value->getFractionCluster()<<endl;
    }
  }
}     
For a detailed example of how to use the BEMC multimaps please have a look at the StEmcAssociationMaker::printMaps() method.

   


  Makers
   The BEMC makers available in STAR include:
StEmcADCtoEMaker - This maker converts plain ADC values in energy. It subtracts pedestals, applies calibrations and creates the StEmcRawHits in StEvent. This maker also checks for corrupted headers. The input data format for this maker can be ANY of the formats below:

DAQ format (from DAQ files)
StEmcRawData format (StEvent)
StEmcCollection (StEvent)
StMuEmcCollection (muDST)
    

A light version of this maker (StEmcRawMaker) runs during production. StEmcRawMaker uses only DAQ or StEmcRawData format as input. 

 

StPreEclMaker - This maker implements clustering of the BEMC detectors. 

 

StEpcMaker - This maker matches the clusters in the BEMC detectors making what we call an StEmcPoint. It also matches tracks with points, if the input format is StEvent.

 

StEmcTriggerMaker - This maker simulates the BEMC level 0 trigger response using the plain ADC information from the towers. It works both with real and simulated data and it applies exactly the same trigger algorithm as in the BEMC hardware.

 

StEmcSimulatorMaker - This is the slow BEMC simulator.  It takes an StMcEvent as input and fills the StEmcRawHit collections of StEvent with simulated ADC responses for all subdetectors.

 

StEmcCalibrationMaker - This is the maker used for BEMC calibration. It has methods to calculate pedestals for all the BEMC detectors as well as detector equalization, based on spectra shape and MIP analysis. This maker runs online as our online pedestal calculator.

 

StEmcMixerMaker - This maker is the basic BEMC embedding maker. It mixes hits from two StEvent objects in the memory. The hits from the second StEvent are mixed in the first one.  It can run in a standard BFC embedding chain or as an afterburner (afterburner mode requires an event.root file from non-BEMC embedding plus a geant.root file containing BEMC information for simulated particles to be embedded).
   
  StEmcTriggerMaker
   Documentation provided by Renee Fatemi



MOTIVATION:


    Apply online trigger algorithm to simulated data
    Apply "software trigger" to triggered data
    Ensure that the same code is used for case 1. and 2.



How the Code Works:

StEmcTriggerMaker is the class that provides the user access functions to the trigger decisions. The workhorse is the StBemcTrigger class.  StEmcTriggerMaker passes a StEvent pointer from either StEmcADCtoEMaker (real data) or StEmcSimulatorMaker (simulated data). The code accesses all offline status/ped/calibrations from StBemcTables, which are set in the macro used to run the code (ideal status/gain/ped can also be set). Code uses StEmcCollection to access ADC for all WEST BEMC channels which are not masked out with the status code and perform FPGA+L0 trigger on 12 bit ADC and 12 bit PED.



Access Function Examples:

    //  if event fulfills trigger return 1 else return 0  problems return -1
    int            is2005HT1() {return mIs2005HT1;}
    int            is2005JP1() {return mIs2005JP1;}
 
    // The ID of  the candidate HT (JP)
    int            get2005HT1_ID() {return HT1_ID_2005;}
    int            get2005JP1_ID() {return JP1_ID_2005;}
 
    // The DSM ADC of the candidate HT (JP)
    int            get2005HT1_ADC() {return HT1_DSM_2005;}
    int            get2005JP1_ADC() {return JP1_DSM_2005;}             
 
    //  The number of towers(patches) and the id’s which fulfill the trigger
    void           get2005HT1_TOWS(int, int*);//array of tow ids passing HT1_2005 trig
    int             get2005HT1_NTOWS() {return numHT1_2005;}//# tows passing HT1_2005 trig
    void           get2005JP1_PATCHES(int, int*);//array of patches passing JP1_2005
    int             get2005JP1_NPATCHES() {return numJP1_2005;}//# patches passing JP1_2005


These access functions exist for 2003 HT1, 2004 HT1+JP1, 2005 HT1+HT2+JP1+JP2



CODE EXAMPLE:

   //get trigger info
    trgMaker=(StEmcTriggerMaker*)GetMaker("StEmcTriggerMaker");
    HT1_2005_evt=-1;
    HT1_2005_id=-1;
    HT1_2005_dsm=-1;
    numHT1_2005=0;
    HT1_2005_evt=trgMaker->is2005HT1();
    HT1_2005_id=trgMaker->get2005HT1_ID();
    HT1_2005_dsm=trgMaker->get2005HT1_ADC();
    numHT1_2005=trgMaker->get2005HT1_NTOWS();
    for (int i=0;i<numHT1_2005;i++){
      int towerid=-1;
      trgMaker->get2005HT1_TOWS(i,&towerid);
      HT1_2005_array[i]=towerid;
    }
  

COMMENTs for DISCUSSION:

Conceptually this code was designed from a software/analysis user point of view.  Consequently I do not explicitly calculate and store all levels of DSM logic (it is unnecessary). From my understanding this is precisely what the StEmcTriggerDetector  class was written to do  -- return all DSM levels.  It propagates all of the trigger information to the MuDst. BUT the problem is that this class is not propagated to the simulation (as far as I can tell).  Even if it was propagated we probably wouldn’t want to take this option because it limits the usefulness of the simulation, whereas the StEmcTriggerMaker allows flexibility in applying the trigger algo to any simulation set. It is certainly possible code up the 2006 part of StEmcTriggerMaker to return all BEMC and EEMC trigger patch  information at all levels of DSM, but it doesn’t exist in the current code.   


  Utilities
   These are not Makers but codes that prove useful for BEMC analyses.  The headings indicate where the codes can be found in the STAR source code repository.
StRoot/StDaqLib
EMC/StEmcDecoder 
This utility converts the daq indexes for any BEMC detector (crate number, position in the crate, etc) in software ids (softId, module, eta, sub). 
It also converts the Level-0 BEMC trigger patches ids in the corresponding tower crate number and index in the crate. It is quite useful to determine the correspondent tower that fired the trigger

 

StRoot/StEmcUtil
geometry/StEmcGeom
This class is used to convert softId in real eta and phi position in the detector and vice-versa. Also converts softId in module, eta and sub indexes that are used in StEvent.
It has methods to get geometrical information of the BEMC, such as number of channels, radius, etc. This is a very important utility in the BEMC software.

 
projection/StEmcPosition
Utility to project tracks in the BEMC detector
database/StBemcTables
Utility to load the database tables and get any information from them. It works only in makers running in the chain and has methods to return pedestal, calibrations, gain and status values for all the BEMC detectors. To use it do, in your maker:
// in the constructor. Supposing you have a private
// member StBemcTables *mTables;
mTables = new StBemcTables();
// in the InitRun() or Make() method
// this method loads all the BEMC tables
// it is necessary to have St_db_Maker running
mTables-&gt;loadTables((StMaker*)this);
// Getting information
// for example, getting pedestal and RMS for the
// BTOW Detector softId = 100
float ped = mTables->pedestal(BTOW, 100);
float rms = mTables->pedestalRMS(BTOW, 100);

database/StBemcTablesWriter
This class inherits from StBemcTables and is useful for performing all kinds of more advanced BEMC DB operations, including uploading tables if you've got the privileges for it.
I'm not sure if anyone is actually using the rest of these, nor am I confident that they actually work in DEV.  Feel free to leave some feedback if you have some experience with them. -- Adam
hadBackground/StEmcEnergy
Utility to subtract hadronic energy from EMC towers. It uses StEmcHadDE to subtract the hadronic energy in the calorimeter in a event by event basis.

 
hadBackground/StEmcHadDE
Utility to calculate hadronic energy profile in the BEMC. It calculates the amount of energy deposited by a single hadron as a function of its momentum, position in the detector and distance to the center of the tower.

 
voltageCalib/VoltCalibrator
This utility calculates high voltages for the towers for a given absolute gain.

 
neuralNet/StEmcNeuralNet
Basic EMC neural network interface.
filters/StEmcFilter
Event filter for BEMC (StEvent and StMcEvent only)
This utility has a collection of tools to do event filtering in the BEMC. Some of the filters available are:

basic event filter: vertex, multiplicity, etc
tower filters: tower isolation filter, number of tracks in tower, energy cuts, tower energy and associated pt cuts, etc.