add a variation on the ALICE pad position class for square pixels #16
Conversation
|
It is a breaking change for anyone who has files with raw digits or hits in them. TPC Clusters and downstream data products are not affected. |
|
To do: change the Pad Readout Functions (PRFs) to be all the CROC one, as that was designed for 6 mm x 6 mm square pads. |
|
And look at Leo's additions to the TPC Clustering algorithm which are pad-row aware. With a more isotropic detector, the algorithms may stay, but parameters adjusted so they treat the directions in a row and perpendicular to a row equally. One thing we might think about is not having a square grid of pixel pads but stagger them a bit so you don't get artificially straight segments which is the current problem when a track follows along a pad row. Such segments can be quite long even for gently curving tracks in the OOROC, which is why ALICE does a poor job of reconstructing those. I should check -- the geometry may be staggered anyway due to the fact that square pixels are arranged in a trapezoidal ROC. |
|
I can look into seeing if I can make the square pad class inherit from the ALICE one. That way the downstream use of it can be switched easily just by setting a pointer or reference. |
On Patrick's request, I made a new version of the AliTPCROC class, called AliTPCROCSquare, with adjusted parameters for square pads, 6 mm on a side. There are still IROC, OROC (just one kind of pad in the OROC now), and CROC. Enclosed are plots of the pad locations, and an event with raw digits over threshold and reconstructed tracks. There are now 508906 pads per side. The geometry is still double-sided with a cathode in the middle. This is easy enough to switch in the future, though the cathode-crossing track stitcher module should be taken out of the reco for that.
