Is your feature request related to a problem? Please describe.
TS clustering applies a hit time cut to avoid including late hits. The deduction of what is "late" is based on the time of flight between the TS pad at hand and the target (since we set t=0in our events when the beam electron is expected to hit the target). This makes this (configurable) variable depend on the detector geometry, and every time you use a non-standard geometry the "pad time" needs to be manually set.
Describe the solution you'd like
TS clustering should be able to know which geometry we are using.
- One way is to pass it upon instantiation, and then on the python side of things we take care of updating the pad time accordingly.
- Another solution is to have some TS geometry object that we can ask about these things in clustering explicitly (or in hit reconstruction, and just mark hits as late there).
- This would add the possibility of deducing bar
x and y coordinates directly from the geometry, instead of translating using a function that maps bar to spatial coordinate, as is done now.
- This in turn would mean that TS tracking can retrieve x and y from its hit/cluster constituents.
Describe alternatives you've considered
No that would be all, thanks.
Is your feature request related to a problem? Please describe.
TS clustering applies a hit time cut to avoid including late hits. The deduction of what is "late" is based on the time of flight between the TS pad at hand and the target (since we set
t=0in our events when the beam electron is expected to hit the target). This makes this (configurable) variable depend on the detector geometry, and every time you use a non-standard geometry the "pad time" needs to be manually set.Describe the solution you'd like
TS clustering should be able to know which geometry we are using.
xandycoordinates directly from the geometry, instead of translating using a function that maps bar to spatial coordinate, as is done now.Describe alternatives you've considered
No that would be all, thanks.