EMCAL Reconstruction

Introduction

This document presents the full chain of EMCAL data reconstruction code, from PRDF file to DST-like file. By data reconstruction we mean going from raw FEM packets (in PRDF file) to calibrated (both in energy and time) EMCAL towers and reconstructed clusters. We start by describing the high level interface (Fun4All-compliant) to the reconstruction, and then we gradually move to lower level pieces of code. We assume the reader is familiar with the Phenix CVS repository, the Fun4All framework, and C++, of course ;-)

The big picture

As any other Phenix subsystem, the EMCAL reconstruction is driven by a Fun4All's SubsysReco module, named EmcReco3. So if you'd like to quickly reconstruct EMCAL data, all you'd need to know is how to register this module to a typical Fun4All reconstruction macro :

Fun4AllServer* se = Fun4AllServer::instance(); 
se->registerSubsystem(new EmcReco3);

Note:

Real life example of Phenix reconstruction macros can be found in CVS under offline/crs-script/Run4, for instance.

The EmcReco3 class is not doing much by itself, it is a mere forwarder to the real worker, which is some implementation of the base class emcRecoModule. Which emcRecoModule class exactly is instanciated depends on the set of recoConsts flags used (mainly the run number and the SIMULATIONFLAG), and that decision is made in the emcRecoModuleFactory class.

All emcRecoModule classes are based on the same principle : they hold a list of PHModule that are called in sequence for each event. In the case of real data, that list can be as short as 2-3 modules (basically one calibrator and one clusterizer, see mEmcRecoModuleRealYear4 for instance), but for simulation the list can be little bit longer (see mEmcRecoModuleSimulationYear3 for instance).

In any case the EMCAL reconstruction is conceptually a two-step process :

• calibration phase : the raw PRDF packets are converted into calibrated towers,

• clustering phase : adjacent groups of calibrated towers are grouped together to form clusters.

Note:

You should realize that the first step is more "online-oriented" than the second, and so you should not be surprised that the corresponding code is a more low level one than the clustering code. For instance in the calibration code you have to know what FEM and FEM Channels are, whether in the clustering code you do not really care, as what you are dealing with are towers simply.

Both steps make use of various databases to retrieve information (for instance the values of the gains in the calibration phase, or the geometry for the clustering phase). All accesses to databases go through the emcDataManager (which internally uses pdbcal when needed), which provides a single and simple interface to read/write objects from/to some various data sources : Objy (now deprecated), PostgreSQL or plain ASCII files.

Below, we'll briefly describe the two reconstruction phases and the data manager philosophy.

Calibration

The calibration itself is a 3 stage process :

1. the raw packets are decoded to get out the 5 digital samples for each tower (low gain pre, low gain post, high gain pre, high gain post, tac)
2. a choice is made between low and high gain, pre minus post is computed and pedestal subtracted, to end up with one ADC and one TDC value per tower
3. ADC and TDC are finally converted to GeV and ns

Those stages are reflected in the top emcDataProcessor interface. In turn, each stage is handled through a specific implementation of the 3 interfaces emcPacketProcessor, emcRawDataProcessor and emcDCProcessor.

The emcDataProcessor interface is meant to be used directly by the online software. For offline purposes, it is encapsulated in a plain PHModule (see for instance mEmcCalibratorModulev2) to be useable from an emcRecoModule.

The output of this stage is a list of emcTowerContent (calibrated towers), accessible from their container, emcTowerContainer.

More...

Clusterization

Once the towers are calibrated, adjacent ones are grouped together to form clusters, using the mEmcClusterizerv0 module. Then a number of characteristics of the resulting clusters are computed, and are available through the emcClusterContent interface (all clusters for one event are available through the emcClusterContainer interface).

More...

Data Manager

The recommended way to access the various databases needed for the EMCAL reconstruction is through the emcDataManager (DM) API. Besides the data manager API, there is also a standalone command line based application, emcDB, which can be used to browse the databases and update them from ASCII files.

Note:

There is no way we can prevent users from bypassing it (using directly pdbcal, or worst using their own cooked routines), but please do not do it.

Note:

There's even a higher level access mode, the emcCalibrationDataHelper one which has methods to access the most commonly used calibration objects.

The DM is a singleton object and it has only two methods : Read() and Write(). You should realize that the DM is just a triage center : it will decide, based upon the actual type of the object to be read/written and the object's data source/destination, which one of its plugins is able to handle it, and will forward the read/write request to that plugin.

More...