sPHENIX discussion of software

[Edouard Kistenev <kistenev AT bnl.gov>]

Nils. I have one comment. In this calorimeter knowing X,Y,Z does not help much. The same X/Y will be in two different towers of the same section and many other interesting possibilities. If I was wring pattern recognition for this detector today then the whole philosophy would be different from one based on detector image projected into LEGO plot.  For a number of times I was trying to say that in this calorimeter the only sensible coordinate system for pattern recognition is polar so the tower needs to carry its vector in polar coordinates and all comparison operators must be built using vector algebra. I am not an expert in  modern coding tools but  to me that means that my towers instead of carrying vectors in cartesian coordinates should inherit from vectors in polar coordinates and use every technique available for managing those.

Edward 

On Jul 29, 2015, at 6:20 PM, Nils Feege <nils.feege AT stonybrook.edu> wrote:

Dear all,

Chris, Jin and I had some discussion about common calorimeter tower objects in the software for all calorimeters, i.e. sPhenix barrel HCAL, Spacal, and the forward calorimeters for fsPhenix / EIC.

We'll have two slides and an opportunity for plenary discussion tomorrow 10 am at the sPhenix workfest:

https://indico.bnl.gov/conferenceDisplay.py?confId=1237

Here's what we came up with so far: Each sub-detector would keep its own implementation up to the tower builder code. The output of these individual tower builders will be generic tower objects (CaloTower, see below). This would allow downstream code (clustering etc) to run on towers independent from the calorimeter they came from. In other words, these tower nodes are junctions where the independent simulation / reconstruction for all calorimeters can converge.

We plan to test this with the forward calorimeters first (and SPACAL and HCAL later if it works smoothly). Here's a list of the classes we plan to implement:

- CaloTower: A new base tower class which will represent a tower and have parameters like TowerID, Energy, Time(?) and respective Get functions (it will replace the RawTower class).

- CaloTowerv1: Inherits from CaloTowerv1. This is how tower information will be stored on the node tree. The idea is to keep this tower information general so it would have the same information and functionality for Simulation and Data.

- CaloSimTowerv1: Inherits from CaloTowerv1 and adds additional information that would only be available for simulated events.

- CaloTowerContainer and CaloTowerContainerv1: Store multiple CaloTower and retrieve them by TowerID or iterator.

- CaloGeometry: Provides center position x,y,z and size for each TowerID. Will be created on the fly (either from mapping files or later from TGeo object) and is therefore NOT stored in the output file.

I'll work on implementing and testing this in the next couple of days.

Best,

Nils

--

Dr. Nils Feege

Research Associate

SUNY at Stony Brook

Department of Physics & Astronomy

Stony Brook, NY 11794-3800

e-mail nils.feege AT stonybrook.edu

skype nils1920

phone +1-631-632-8112

www.linkedin.com/in/nilsfeege

_______________________________________________
Sphenix-software-l mailing list
Sphenix-software-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-software-l