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: Christof Roland <christof.roland AT cern.ch>
  • To: Anthony Frawley <afrawley AT fsu.edu>
  • Cc: "sphenix-tracking-l AT lists.bnl.gov" <sphenix-tracking-l AT lists.bnl.gov>
  • Subject: Re: [Sphenix-tracking-l] TPC clusters
  • Date: Tue, 11 May 2021 09:47:48 +0200

Hi Tony, 

if I recall correctly Hugo observed an r dependence of the cluster centroid shift already
before I took apart the cluster finder to speed it up. Also the 754 microns were determined
a long long time ago. There were a number of other changes that happened in between, 
maybe even the electron drift etc. Do you recall when was the last time you tuned this 
parameter?

When rearranging the clusterfinder I changed a few things that can affect the edges 
of the clusterts. The change to integer values made a change visible in the jenkins plots.
This also entrailed a different effective threshold after pedestal subtraction. There is a cut 
on the ADC value of about 1 now due to the rounding etc. before the clusterfinder happily 
accepted negative values and there were some.

Cheers

    Christof 

On 10. May 2021, at 23:39, Anthony Frawley <afrawley AT fsu.edu> wrote:

Hi Hugo,

I can reproduce the effect.

I see an average centroid shift of +/- 135 microns in the first 16 layers, +/- 120 microns in the middle 16 layers, and +/-50 microns in the last 16 layers. 

The correction that is in the TpcClusterizer code now has a magnitude of  0.0754 cm, i.e. 754 microns. 

I will play around and see if I can understand better what changed. 

Tony


From: Hugo Pereira Da Costa <hugo.pereira-da-costa AT cea.fr>
Sent: Monday, May 10, 2021 2:07 PM
To: Anthony Frawley <afrawley AT fsu.edu>; sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>
Subject: Re: [Sphenix-tracking-l] TPC clusters
 

On 5/10/21 12:00 PM, Anthony Frawley wrote:
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 have no explanation for this either.

I will poke at it a bit this afternoon.
Thanks ! I guess the first thing would be to try to reproduce my plots :) (a bug in my evaluators is not completely excluded). I must stress however that the same evaluation code is used in the before/after plots I have attached in the previous email. Some even with a bug, "something" has changed ...


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
_______________________________________________
sPHENIX-tracking-l mailing list
sPHENIX-tracking-l AT lists.bnl.gov
https://lists.bnl.gov/mailman/listinfo/sphenix-tracking-l




Archive powered by MHonArc 2.6.24.

Top of Page