sphenix-tracking-l AT lists.bnl.gov
Subject: sPHENIX tracking discussion
List archive
[Sphenix-tracking-l] Question regarding proceeding
- From: David Stewart <0ds.johnny AT gmail.com>
- To: sphenix-tracking-l AT lists.bnl.gov
- Subject: [Sphenix-tracking-l] Question regarding proceeding
- Date: Tue, 21 Mar 2023 14:59:30 -0400
When collecting Mvtx TrkrHit's for the PHG4 truth tracks, I am now aware that the hits don't go through the MvtxHitPruner. Basically, the phg4 clusters use all the TrkrHits (associated with phg4 hits for each phg4 track), whereas the Svtx tracks use clusters that have been digitized and then collapsed strobe 0 only. For example, as the end of the end of the PHG4MvtxHitReco container, the listing of the hits looks like this for a given event. (The last number is the TrkrHit->energy())
```
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(0) 240 layer 0 stave 0 chip 7 strobe 0 13180
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(1) 241 layer 0 stave 0 chip 7 strobe 1 13180
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(2) 720 layer 0 stave 1 chip 6 strobe 0 10060
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(3) 721 layer 0 stave 1 chip 6 strobe 1 10060
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(4) 1200 layer 0 stave 2 chip 5 strobe 0 5960
...
 FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(87) 139473 layer 2 stave 16 chip 6 strobe 1 64580
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(88) 139504 layer 2 stave 16 chip 7 strobe 0 5160
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(89) 139505 layer 2 stave 16 chip 7 strobe 1 5160
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(90) 139984 layer 2 stave 17 chip 6 strobe 0 25828
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(91) 139985 layer 2 stave 17 chip 6 strobe 1 25828
```
but by the time it is clustered in the MvtxClusterizer module it looks like the following (note that the energy has been scaled in the MvtxDigitizer module by this point):
```
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(0) 240 layer 0 stave 0 chip 7 strobe 0 596
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(1) 720 layer 0 stave 1 chip 6 strobe 0 436
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(2) 1200 layer 0 stave 2 chip 5 strobe 0 256
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(3) 1744 layer 0 stave 3 chip 6 strobe 0 204
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(4) 2256 layer 0 stave 4 chip 6 strobe 0 168
...
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(41) 138512 layer 2 stave 14 chip 8 strobe 0 2056
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(42) 138960 layer 2 stave 15 chip 6 strobe 0 256
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(43) 139472 layer 2 stave 16 chip 6 strobe 0 2552
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(44) 139504 layer 2 stave 16 chip 7 strobe 0 248
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(45) 139984 layer 2 stave 17 chip 6 strobe 0 1232
```
So, @hpereira, @frawley, @jdosbo, et al., when making truth tracks I don't need to have a lower threshhold energy cutoff, but otherwise, should either emulate the functionality of the PHG4MvtxDigitizer and MvtxHitPruner prior to making truth clusters or just put a PHG4 hitsetcontainer on the node tree that is run through both these modules and eventually results in the truth clusters?
As I pull more and more code into the TruthMvtxClusterBuilder object (which currently is used within the PHG4MvtxHitReco object, and just collects PHG4Hits for each PHG4Track and clusters them on the fly), the more it seems likely that it would be best to use one set of code and put the TrkrHit's for each truth track separately and process with the actual regular digitiser and pruner code. The best way to do this would probably be to slightly modify the PHG4MvtxDigitizer and MvtxHitPruner modules so that they can be called to run over variable TrkrHitSetContainers and called at will. Or, I could just purservear with the current process and suck in all the additional functionality with increasing amounts of duplicated code.
```
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(0) 240 layer 0 stave 0 chip 7 strobe 0 13180
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(1) 241 layer 0 stave 0 chip 7 strobe 1 13180
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(2) 720 layer 0 stave 1 chip 6 strobe 0 10060
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(3) 721 layer 0 stave 1 chip 6 strobe 1 10060
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(4) 1200 layer 0 stave 2 chip 5 strobe 0 5960
...
 FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(87) 139473 layer 2 stave 16 chip 6 strobe 1 64580
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(88) 139504 layer 2 stave 16 chip 7 strobe 0 5160
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(89) 139505 layer 2 stave 16 chip 7 strobe 1 5160
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(90) 139984 layer 2 stave 17 chip 6 strobe 0 25828
FIXME TRKR_HITSET hits at end of PHG4MvtxHitReco hit(91) 139985 layer 2 stave 17 chip 6 strobe 1 25828
```
but by the time it is clustered in the MvtxClusterizer module it looks like the following (note that the energy has been scaled in the MvtxDigitizer module by this point):
```
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(0) 240 layer 0 stave 0 chip 7 strobe 0 596
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(1) 720 layer 0 stave 1 chip 6 strobe 0 436
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(2) 1200 layer 0 stave 2 chip 5 strobe 0 256
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(3) 1744 layer 0 stave 3 chip 6 strobe 0 204
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(4) 2256 layer 0 stave 4 chip 6 strobe 0 168
...
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(41) 138512 layer 2 stave 14 chip 8 strobe 0 2056
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(42) 138960 layer 2 stave 15 chip 6 strobe 0 256
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(43) 139472 layer 2 stave 16 chip 6 strobe 0 2552
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(44) 139504 layer 2 stave 16 chip 7 strobe 0 248
FIXME TRKR_HITSET hits at start of MVtxClusterizer hit(45) 139984 layer 2 stave 17 chip 6 strobe 0 1232
```
So, @hpereira, @frawley, @jdosbo, et al., when making truth tracks I don't need to have a lower threshhold energy cutoff, but otherwise, should either emulate the functionality of the PHG4MvtxDigitizer and MvtxHitPruner prior to making truth clusters or just put a PHG4 hitsetcontainer on the node tree that is run through both these modules and eventually results in the truth clusters?
As I pull more and more code into the TruthMvtxClusterBuilder object (which currently is used within the PHG4MvtxHitReco object, and just collects PHG4Hits for each PHG4Track and clusters them on the fly), the more it seems likely that it would be best to use one set of code and put the TrkrHit's for each truth track separately and process with the actual regular digitiser and pruner code. The best way to do this would probably be to slightly modify the PHG4MvtxDigitizer and MvtxHitPruner modules so that they can be called to run over variable TrkrHitSetContainers and called at will. Or, I could just purservear with the current process and suck in all the additional functionality with increasing amounts of duplicated code.
Happy to Zoom and talk this out if that work better for anyone,
Dave
-- David Stewart
Postdoctoral Fellow | Department of Physics, Wayne State University
-
[Sphenix-tracking-l] Question regarding proceeding,
David Stewart, 03/21/2023
-
Re: [Sphenix-tracking-l] Question regarding proceeding,
David Stewart, 03/21/2023
- Re: [Sphenix-tracking-l] Question regarding proceeding, Anthony Frawley, 03/21/2023
-
Re: [Sphenix-tracking-l] Question regarding proceeding,
David Stewart, 03/21/2023
Archive powered by MHonArc 2.6.24.