I'm working on the development of several new EEMC libraries which I will be using for the EEMC pi0 analysis.  Hopefully they will also be useful to others doing EEMC analyses.  The idea is to organize the code carefully such that all analyses and further modifications/maintenance can be done as easily and quickly as possible, i.e. get the software aspects resolved (but still maliable) so that we can focus on physics.   One can also consider the following framework as a possible suggestion for making an FGT analysis framework.  The libraries are:

1. StEEmcResponseTreeMaker
2. StEEmcHitMaker
3. StEEmcAnalysisTreeMaker
4. StEEmcViewer

The code is 90% written and is currently being debugged.  The code can be viewed in the CVS respository.

--------------------------------------------------------------------------------------------------------------------

1) StEEmcResponseTreeMaker

This library includes several key components.

1. The basic class to hold the data (StEEmcReponse_t).  The data is the calibrated response of the endcap.
2. The class to fill the data from the A2EMaker (StEEmcReponseMaker_t)
3. The class to write the data to a TTree in a TFile (StEEmcResponseTreeMaker_t)
4. The class to read the data from a TTree in a TFile (StEEmcResponseTreeReader_t)

The motivation for the class is that reading from MuDsts and the StarDB is slow, both due to access time and due to the number of events that do not produce a meaningful response in the endcap.  Thus, when one is adjusting later methods, it saves time to not have go all the way back to MuDSTs and the DB.  Also, it provides a standard interface for the data, which can then be used for either processing or for making histograms.

--------------------------------------------------------------------------------------------------------------------

2) StEEmcHitMaker

Hit making involves determining how many particles hit the EEMC, and for each particle, determining the position and energy.  This is generally broken down into clustring the towers and SMD strips, finding points, and determining the energy.  See the image in this previous blog.   (Note: I'm still deciding what to do about 'discrimintator' classes)

This library was designed so that one can have full control over what methods to use for each sub-task, and to facilitate the testing of current methods and teh development of new codes.  There is a distinction between the "finder" classes, which impliment a  specific method for a specific task, and the structural (coordinator) classes, which keep track of which tasks need to be done and which class will do them.

--------------------------------------------------------------------------------------------------------------------

3) StEEmcAnalysisTreeMaker

The motiviation is that many analysis all depend on interpreting the EEmc response in terms of hits, i.e. what particles hit it where with how much energy.  Thus tasks common to several analysis should be seperated from those that are not common.  Note, though, each analysis could run the common part with different options tailored to that particular analysis.  Also, it is useful for a given analysis to have a single starting point, regardless of the options used in Hit Finding.  I.e., one can then run the same analysis code for different methods, or even compare event by event the difference between different methods. The tree maker effectively saves the results of the hit maker, as includes options for saving the event and spin information and the EEmcResponse.  At a tree reader will also be included in the future.

--------------------------------------------------------------------------------------------------------------------

4)  StEEmcViewer

 The making of histograms/canvases, for either the EEmc Reponse or for the point maker, is seperated from the classes actually doing the processing.  This allows the most flexibility, and so that the same histograms can be made for various options for the other classes, without having to recopy the code to make the histograms.  There is a base class for all histogram makers (called viewers), and conceptually the histogram makers are seperated  into event level and run level histograms.  The current plan is for the histograms to be saved in a TFile, with the TFile having seperate directories for run- and event- level plots.  Each of these subdirectories then includes subdirectories for either each run or for each event (unless the run or event produced no plots).

One can then open the TFile created by this viewer without having to have all the StRoot dictionary files, i.e. on ones personal computer rather than requiring the STAR framework.