GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

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 Go to previous messageGo to previous message
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
first-grade participant

From: *
Hi all,
I think I found out something. I have to thank Isabella who suggested me to look into PndStack for the trackID! Grazie! Smile

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:
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).

Read Message
Read Message
Read Message
Previous Topic: Problems with TPC and genfit
Next Topic: Memory leaks in digitization (TPC!)
Goto Forum:

Current Time: Mon Nov 29 16:12:57 CET 2021

Total time taken to generate the page: 0.02195 seconds