Skip to Content.
Sympa Menu

sphenix-tracking-l - Re: [Sphenix-tracking-l] TPC clusters

sphenix-tracking-l AT lists.bnl.gov

Subject: sPHENIX tracking discussion

List archive

Chronological Thread  
  • From: Anthony Frawley <afrawley AT fsu.edu>
  • To: Hugo Pereira Da Costa <hugo.pereira-da-costa AT cea.fr>, "sphenix-tracking-l AT lists.bnl.gov" <sphenix-tracking-l AT lists.bnl.gov>
  • Subject: Re: [Sphenix-tracking-l] TPC clusters
  • Date: Mon, 10 May 2021 18:00:02 +0000

Hi Hugo,

That is strange. I assume that it is opposite for Z < 0 (?)

Whether or not it is due to storing the hit energy as a short int can be checked easily, by increasing the scale-up factor for the TPC. I doubt that is the problem, but I will check this.

I find it a bit surprising that the Z offset is such a strong function of layer/radius. The offset in the code corrects for the asymmetric shaping time of the SAMPA, which (in the simulation) is the same for all layers. 

I will poke at it a bit this afternoon.

Tony

From: sPHENIX-tracking-l <sphenix-tracking-l-bounces AT lists.bnl.gov> on behalf of Hugo Pereira Da Costa <hugo.pereira-da-costa AT cea.fr>
Sent: Monday, May 10, 2021 12:39 PM
To: sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>
Subject: [Sphenix-tracking-l] TPC clusters
 

Hi all,

it seems something else broke with the recent TPC cluster changes. If you remember from the slides at https://indico.bnl.gov/event/10904/

(in particular slide 8, or slide 20), there was some <100um systematic offset in the TPC z residuals (tracks - truth), with opposite sign between positive and negative z. But overal (integrated over layers) the offset was essentially consistent with zero.

With recent changes, things has gotten worse.

For positive z, the offsets are now 150-200 um for the TPC inner layers, and ~0 for the outer layers. Same thing with opposite sign for neg. z.

This is illustrated in the plots attached.

I have tracked down the change to come from PR1106 (https://github.com/sPHENIX-Collaboration/coresoftware/pull/1106).

This is not easy because the code at that time does not compile any more against recent ACTS, so you have to do quite some ACTS related changes in the trackreco to get this to compile. Anyway:

I don't think it is related to the change of the cluster map formats themselves, or the multithreading. Could this be due to using short ints for the hit charges ? 

Maybe it is enough to adjust the zz_shaping_correction parameter ...

I can probably track this down further (this directly impacts space charge distortion reconstructions), but would like to be done with new micromegas geometry implementation first.

Does anyone have some cycles to have a look ? To see this it should be enough to look at cluster - truth residuals in the TPC vs layer number for either positive or negative z.

Hugo




Archive powered by MHonArc 2.6.24.

Top of Page