Skip to Content.
Sympa Menu

sphenix-tracking-l - [Sphenix-tracking-l] Cluster matching

sphenix-tracking-l AT lists.bnl.gov

Subject: sPHENIX tracking discussion

List archive

Chronological Thread  
  • From: David Stewart <0ds.johnny AT gmail.com>
  • To: Christof Roland <christof.roland AT cern.ch>, Anthony Frawley <afrawley AT fsu.edu>, sphenix-tracking-l AT lists.bnl.gov, "Osborn, Joe" <osbornjd AT ornl.gov>, "Pereira Da Costa, Hugo Denis Antonio" <hugo.pereira-da-costa AT lanl.gov>
  • Subject: [Sphenix-tracking-l] Cluster matching
  • Date: Sat, 27 May 2023 08:29:14 -0400

Hugo, Christof, all,

I have a question regarding some clusters. I am looking at why my cluster matching is failing to match some clusters in the same TrkrDefs::hitsetkey surface, when I know that the PHG4 and Svtx clusters are from the same track. In this instance, the track looks like this png, where the gray and black points are the matched cluster locations for the tracks, and the red and magenta are unmatched cluster locations, even through most of the time there are some in the same layer/TrkrDefs::hitsetkey location.

image.png

To match clusters, the algorithm I put in looks at the phi and Z (/time) cluster locations and widths (given in units of number of bins, because that is a smaller memory footprint than a float). It then compares the difference in phi and Z locations to (tolerance) x max(g4_nbins_wide,sv_nbins_wide) x bin_widths_for_layer. 

I have added a ClusHitsVerbose object to optimally collect the bin information for g4 and sv tracks. Printing them out for one of the un-matched cluster pairs in the same surface, I get this:

 --- Layer 29 un-matched G4+Sv clusters
 G4:Sv:rel-delta data:: PHI size(  0.0159:  0.0159) loc(  0.2971:  0.2477) rel delta(3.108)
 G4:Sv:rel-delta data:: Z   size(265.0000:265.0000) loc(12590.6660:12593.1367) rel delta(0.009)
G4: phi n( 4) i-adc<  578:1129,  579:9580,  580:7796,  581: 761>
      z n( 5) i-adc<  234: 222,  235:2818,  236:7847,  237:7474,  238: 905>
cut phi n( 4) i-adc<  577:   2,  578:  52,  579:   7,  580: 147,  581: 240>
cut   z n( 7) i-adc<  233:  10,  234: 177,  235:  94,  236:   1,  237:   1,  238: 156,  239:   9>

Sv: phi n( 4) i-adc<  578:  10,  579: 133,  580: 176,  581:  40>

      z n( 5) i-adc<  235:  50,  236: 141,  237: 147,  238:  20,  239:   1>

Explanation:

G4: phi n( 4) i-adc<  578:1129,  579:9580,  580:7796,  581: 761 <- these are the three phi bins in the PHG4 cluster, in bins indexed 578, 579, 580, and 581, with adc values of 1129, 9580, . . .

PHI size(  0.0159:  0.0159) <- these are the phi cluster sizes from the phg4 and svtx track, from 3 (?!) bins x 0.0053, set from the call `const double pitch = PHG4TpcCylinderGeomContainer->get_phistep`

loc(  0.2971:  0.2477) <- these are the locations of the clusters from TrkrCluster->getPosition(0)

rel delta(3.108) <- this is fabs(0.2971-0.2477)/max(0.0159,0.0159)

cut phi n( 4)… <- these are the low-adc bin hits that were cut for being < 1% of the total adc hits in this clusters in the PHG4 track.

Sv: phi n( 4) i-adc<  578:  10,  579: 133,  580: 176,  581:  40> <- these are the Svtx cluster bins, the exact same bins as the phg4 track – and therefore the same bin size. 


A few notes:
1. The svtx cluster data is saved directly from the TpcClusterizer.cc code. I don't think there is an TrkrCluster modification in subsequent processing.
2. It appears that the cluster size should be 4, not 3.
3. The cluster location is assigned in the code to the weighted phi location, so it is ok that they are not identical, even with the same number of phi bins.

Biggest takeaway, is the get_phistep() just the wrong function to use/getting the wrong value? If the clusters have the same number of bins, then the centers cannot fall outside of the bin width range, even with the apparent miscalculation of the number of bins at 75% of the real value. 

Thanks much. I've gotta run, but will check back later,

Best,
Dave
--
David Stewart
Postdoctoral Fellow | Department of Physics, Wayne State University


  • [Sphenix-tracking-l] Cluster matching, David Stewart, 05/27/2023

Archive powered by MHonArc 2.6.24.

Top of Page