sPHENIX tracking discussion

["Pereira Da Costa, Hugo Denis Antonio" <hugo.pereira-da-costa AT lanl.gov>]

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