Home » PANDA » PandaRoot » Bugs, Fixes, Releases » FairMCPoint trackID vs FairLink trackID.
| FairMCPoint trackID vs FairLink trackID. [message #11110] |
Wed, 20 October 2010 19:17  |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi Tobias,
I have a question on FairLink.
I tried to get the trackID from the simulated STTPoints, both with the fTrackID variable of FairMCPoint and from the FairLink, by doing:
cbmsim.Scan("STTPoint.fLinks.fType:STTPoint.fLinks.fIndex:STTPoint.fTrackID ")
I expected to find STTPoint.fLinks.fIndex always equal to STTPoint.fTrackID but I see that sometimes they are are different.
How is it possible? In PndSttPoint there is:
PndSttPoint::PndSttPoint(Int_t trackID, Int_t detID, TVector3 pos,
TVector3 posInLocal, TVector3 posOutLocal,
TVector3 momIn, TVector3 momOut,
Double_t tof, Double_t length, Double_t eLoss,
Double_t mass)
: FairMCPoint(trackID, detID, pos, momIn, tof, length, eLoss)
{
...
SetLink(FairLink("MCTrack", trackID));
}
...so trackID is the same in FairMCPoint and in FairLink. 
I also printed the trackID during the simulation, in ProcessHits, to see whether it was equal to STTPoint.fLinks.fIndex or STTPoint.fTrackID and it is equal to STTPoint.fLinks.fIndex.
Another test I did: I tried the command line I wrote above (with the equivalent points) for MVD, GEM and MDT and I see differences between *Point.fLinks.fIndex and *Point.fTrackID there too.
The main question is: am I reading the link in the wrong way or is there some real problem? Do you have any suggestion?
Thank you in advance,
Lia.
|
|
|
|
| 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.
|
|
|
|
|
|
Goto Forum:
Current Time: Wed Nov 27 03:32:36 CET 2024
Total time taken to generate the page: 0.00600 seconds
|
GSI Forum
Search
Help
Members
Login
Home
