Home » PANDA » PandaRoot » Bugs, Fixes, Releases » FairMCPoint trackID vs FairLink trackID.
| Re: FairMCPoint trackID vs FairLink trackID. [message #11121 is a reply to message #11110] |
Mon, 25 October 2010 18:43   |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi all,
I think I found out something. I have to thank Isabella who suggested me to look into PndStack for the trackID! Grazie! 
In PndStack there is the function FillTrackArray(), which fills the array of MCTracks that will be stored.
It calls the function SelectTracks().
This applies some cuts to decide whether to store a track or not (e.g. if it has a kinetic energy below a threshold it is not stored) and creates a map containing the track indices and a flag whether to store it or not.
Then, the MCTracks are created in the usual way and they fill a TClonesArray.
This means, for example, that if you have 6 tracks (0, 1, 2, 3, 4, 5) and you decide you want to store the first four tracks and the last one, but not the track number 4, you will have a TClonesArray with 5 entries and so you have a "misalignment" between the original trackIDs and the positions of the MCTracks in the TClonesArray:
gMC
TRACK -> STORE? -> TCA POSITION
ID
-----------------------------------
0 Yes 0
1 Yes 1
2 Yes 2
3 Yes 3
4 No -
5 Yes 4
To care about these cases and to store in the various mcpoints, saved for each detector, the correct track index (i.e. the track index corresponding to the position of the MCTrack inside its TClonesArray) there is a function called UpdateTrackIndex(TRefArray* detList). It runs over all the mcpoints of all the detectors and updates the trackIDs.
In the example I made here, before the UpdateTrackIndex() function is applied, the mcpoints have trackIDs: 0, 1, 2, 3, 5, but after it the numbers become 0, 1, 2, 3, 4: the trackID of the mcpoints belonging to the last track have been correctly changed from 5 to 4, since in the MCTrack TClonesArray there is no track number 5 and the last track has position 4.
In conclusion, the trackID taken from STTPoint.fTrackID correctly gives the track index of the MCTrack inside its TClonesArray, while the trackID taken from STTPoint.fLinks.fIndex has the wrong value, because the trackID has not be updated. If all I said before is correct (please someone correct me if I am wrong) I think it should be update as well in the PndStack::UpdateTrackIndex(TRefArray* detList).
Cheers,
Lia.
|
|
|
|
Current Time: Mon Dec 09 10:15:11 CET 2024
Total time taken to generate the page: 0.00628 seconds
|
GSI Forum
Search
Help
Members
Login
Home
