search

eic / EICrecon

EIC Reconstruction - JANA based
https://eic.github.io/EICrecon
GNU Lesser General Public License v3.0
6 stars 29 forks source link

Total four-momentum of a calorimeter #1496

Closed sebouh137 closed 3 months ago

sebouh137 commented 4 months ago

Is your feature request related to a problem? Please describe. Need an algorithm that produces the total four momentum of all of the clusters in a calorimeter (for instance the HCal Insert, or the ZDC)

Describe the solution you'd like New algorithm that adds up the four momenta of all clusters in the calorimeter, assuming they are from particles originating from the origin

Describe alternatives you've considered N/A

Additional context N/A

ruse-traveler commented 4 months ago

Hi Sebouh, I may have missed this since I left the LFHCal meeting early, but could you elaborate this request? For example, what type of output would such an algorithm produce? Would it be ReconstructedParticles?

sebouh137 commented 4 months ago

This is a good question, and I plan to fulfill this feature myself. I would like to output a single object representing the four momentum of the events, but if PODIO does not support outputing a four vector object I will create a ReconstructedParticle object instead.

ruse-traveler commented 4 months ago

Hmmm... So there are 4-vectors in the data model: e.g. see edm4hep::Vector4f here, but these aren't meant to be saved to a collection...

And ReconstructedParticle is a pretty heavy type for just a 4-vector, so my next question is what's it for? Is it for things like the neutron candidates in the ZDC?

sebouh137 commented 4 months ago

The detector I have in mind for this is the forward HCAL insert, since a large amount of the transverse momentum and energy goes to that detector. @ruse-traveler , let me know which data type you think is most appropriate for this.

ruse-traveler commented 3 months ago

It makes sense that a lot of pT ends up in the insert, but what are you going to do with the total 4-momentum? For example, is it going to be used to determine the kinematics of a particular set of particles? Or is it going to be used to tag a particular final state?

Or is this a performance metric for the insert? In which case, I think this calculation would be better served as a detector benchmark...

I ask because I'm a bit confused about why this calculation needs a separate algorithm and to be persisted in a datatype... Could this be handled in analysis code downstream?

sebouh137 commented 3 months ago

Hi Derek, Thanks for the suggestion; we could use this algorithm in a detector benchmark.

ruse-traveler commented 3 months ago

Gotcha! Sounds good!