Skip to Content.
Sympa Menu

sphenix-tracking-l - Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code

sphenix-tracking-l AT lists.bnl.gov

Subject: sPHENIX tracking discussion

List archive

Chronological Thread  
  • From: "Pereira Da Costa, Hugo Denis Antonio" <hugo.pereira-da-costa AT lanl.gov>
  • To: "Pereira Da Costa, Hugo Denis Antonio" <hugo.pereira-da-costa AT lanl.gov>, Anthony Frawley <afrawley AT fsu.edu>, "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 20:24:00 +0000

Quick follow-up: updating get_phi inside the SiliconTpc matching only marginally improve things. But in the meanwhile I figured that the seed parameters published by KFProp

(e.g. m_slope for instance, used to calculate eta) also do not account for distortion corrections (while KFProp does, internally). This is because of the way the seed parameters are calculated inside PHSimpleKFProp::publishSeeds, (line 1200 or so), using _cluster_map, rather than the distortion corrected global positions …

 

I’ll look into this in more details

 

Hugo

 

From: sPHENIX-tracking-l <sphenix-tracking-l-bounces AT lists.bnl.gov> On Behalf Of Pereira Da Costa, Hugo Denis Antonio via sPHENIX-tracking-l
Sent: Thursday, March 14, 2024 12:08 PM
To: Anthony Frawley <afrawley AT fsu.edu>; sphenix-tracking-l AT lists.bnl.gov; Joe Osborn <osbornjd91 AT gmail.com>
Subject: [EXTERNAL] Re: [Sphenix-tracking-l] Problem with distortion+correction in matching code

 

Yes, I’ll check with local implementation that this fixes the issue I see.

I agree that things get complicated in the pp case.

 

 

From: Anthony Frawley <afrawley AT fsu.edu>
Sent: Thursday, March 14, 2024 12:01 PM
To: Pereira Da Costa, Hugo Denis Antonio <hugo.pereira-da-costa AT lanl.gov>; sphenix-tracking-l AT lists.bnl.gov; Joe Osborn <osbornjd91 AT gmail.com>
Subject: [EXTERNAL] Re: Problem with distortion+correction in matching code

 

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

 

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





Archive powered by MHonArc 2.6.24.

Top of Page