sphenix-tracking-l AT lists.bnl.gov
Subject: sPHENIX tracking discussion
List archive
Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code
- From: Anthony Frawley <afrawley AT fsu.edu>
- To: "Pereira Da Costa, Hugo Denis Antonio" <hugo.pereira-da-costa AT lanl.gov>, "sphenix-tracking-l AT lists.bnl.gov" <sphenix-tracking-l AT lists.bnl.gov>, Joe Osborn <osbornjd91 AT gmail.com>
- Subject: Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code
- Date: Thu, 14 Mar 2024 18:00:35 +0000
Hi Hugo,
Good catch! I missed that completely. The solution is a bit complicated though. The z positions, and thus the distortion corrections, are unknown until we have the bunch crossing - which is determined by the track matching. So your solution would work only
for triggered event reconstruction, where we can assume that the bunch crossing is zero.
For pp running, the current track seed model does not work well. I think the best solution
will be to store the phi and eta of the tracklet in the track seed, rather than calculate it on the fly. That way, the preliminary distortion correction module, which runs before the track matching, can recalculate phi and eta with preliminary distortion corrections
included. Then the track matching process does not need to know about clusters at all, it relies only on the best available track seed parameters.
I have something else going on this afternoon, I will look at it tonight.
In the meantime, you could apply your fix locally, and see how it works for the triggered
case.
Thanks
Tony
From: Pereira Da Costa, Hugo Denis Antonio <hugo.pereira-da-costa AT lanl.gov>
Sent: Thursday, March 14, 2024 12:32 PM
To: sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>; Anthony Frawley <afrawley AT fsu.edu>; Joe Osborn <osbornjd91 AT gmail.com>
Subject: Problem with distortion+correction in matching code
Sent: Thursday, March 14, 2024 12:32 PM
To: sphenix-tracking-l AT lists.bnl.gov <sphenix-tracking-l AT lists.bnl.gov>; Anthony Frawley <afrawley AT fsu.edu>; Joe Osborn <osbornjd91 AT gmail.com>
Subject: Problem with distortion+correction in matching code
Hi all, in particular Tony, Joe
I might have found the reason why I got poor upsilon reconstruction efficiency and good single track reconstruction efficiency when including distortions and correction.
I think the issue comes from the TPC to silicon matching, that does not properly include the distortion corrections.
The code PHSiliconTpcTrackMatching line 343
uses _tracklet_tpc->get_phi(_cluster_map,_tGeometry); to calculate a given TPC seed phi, and match to silicon phi. This version of get_phi accesses the cluster map directly and does not account for distortion corrections. So the matching is poor.
Tony: does that sound like a plausible explanation ? Did you compare the number of MVTX hits in tracks with and without distortion+reconstruction ?
The fix is "easy" I think: the TpcTrackMatching code must first loop over the clusters, calculate global positions while including the distortion corrections (as done elsewhere) and pass that to the get_phi method, rather than relying on the internal implementation.
Does that make sense ? If yes, I can implement.
I would also check if there are other occurrences of this elsewhere in the code.
Hugo
I might have found the reason why I got poor upsilon reconstruction efficiency and good single track reconstruction efficiency when including distortions and correction.
I think the issue comes from the TPC to silicon matching, that does not properly include the distortion corrections.
The code PHSiliconTpcTrackMatching line 343
uses _tracklet_tpc->get_phi(_cluster_map,_tGeometry); to calculate a given TPC seed phi, and match to silicon phi. This version of get_phi accesses the cluster map directly and does not account for distortion corrections. So the matching is poor.
Tony: does that sound like a plausible explanation ? Did you compare the number of MVTX hits in tracks with and without distortion+reconstruction ?
The fix is "easy" I think: the TpcTrackMatching code must first loop over the clusters, calculate global positions while including the distortion corrections (as done elsewhere) and pass that to the get_phi method, rather than relying on the internal implementation.
Does that make sense ? If yes, I can implement.
I would also check if there are other occurrences of this elsewhere in the code.
Hugo
-
[Sphenix-tracking-l] Problem with distortion+correction in matching code,
Pereira Da Costa, Hugo Denis Antonio, 03/14/2024
-
Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code,
Anthony Frawley, 03/14/2024
-
Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code,
Pereira Da Costa, Hugo Denis Antonio, 03/14/2024
-
Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code,
Pereira Da Costa, Hugo Denis Antonio, 03/14/2024
-
Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code,
Pereira Da Costa, Hugo Denis Antonio, 03/14/2024
- Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code, Anthony Frawley, 03/14/2024
-
Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code,
Pereira Da Costa, Hugo Denis Antonio, 03/14/2024
-
Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code,
Pereira Da Costa, Hugo Denis Antonio, 03/14/2024
-
Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code,
Pereira Da Costa, Hugo Denis Antonio, 03/14/2024
-
Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code,
Anthony Frawley, 03/14/2024
Archive powered by MHonArc 2.6.24.