sPHENIX discussion of software

[Nils Feege <nils.feege AT stonybrook.edu>]

Hi Edward,

thanks for your response. Yes, I see the advantages of the polar coordinates. Maybe we can just implement both options (getting positions as absolute x,y,z or as polar vector with respect to a given reference point, i.e. the event vertex). I'll put it on the slides for tomorrow.

Best,

Nils

On Wed, Jul 29, 2015 at 10:33 PM, Huang, Jin <jhuang AT bnl.gov> wrote:

Hi, Ed,

 

Thank you for the comment and fast reply.

 

In my understanding, it appears we are in good agreement here to use 2D distribution for calorimeter energy for pattern recognition. Examples including the FastJet jet clustering package, which work in the space of eta, phi and ET.

 

The choice of mapping tower to (X,Y,Z) in the initial step allows us to flexibly convert the calorimeter energy deposition into angular space for FastJet use. For example, we would like to calculate the angle of the tower based on the reconstructed vertex location. For |z| < 10 cm vertex, the true angle of the EMCal tower from vertex would be up to 100 mrad away from the one from (0,0,0). Also for the forward calorimeter walls in ePHENIX, the cluster is naturally found in the space of (X,Y), which is also a simple translation from (X,Y,Z) points.

 

Nevertheless, it is still a preliminary plan as Nils pointed out. And Nils will discuss that in the workfest tomorrow morning too.

 

Cheers,

 

Jin

 

 

 

 

______________________________

 

Jin HUANG

 

Brookhaven National Laboratory

Physics Department, Bldg 510 C

Upton, NY 11973-5000

 

Office: 631-344-5898

Cell:   757-604-9946

______________________________

 

From: phenix-ephenix-l-bounces AT lists.bnl.gov [mailto:phenix-ephenix-l-bounces AT lists.bnl.gov] On Behalf Of Edouard Kistenev
Sent: Wednesday, July 29, 2015 7:20 PM
To: Nils Feege <nils.feege AT stonybrook.edu>
Cc: PHENIX-EPHENIX-L <phenix-ephenix-l AT lists.bnl.gov>; phenix-nextfor-l <phenix-nextfor-l AT lists.bnl.gov>; sphenix-software-l AT lists.bnl.gov; EIC <eic AT stonybrook.edu>
Subject: Re: [Sphenix-software-l] Thoughts about new CaloTower object to store Calorimeter Tower Information

 

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

 

--

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