GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » Bugs, Fixes, Releases » FairMCPoint trackID vs FairLink trackID.
FairMCPoint trackID vs FairLink trackID. [message #11110] Wed, 20 October 2010 19:17 Go to next message
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. Confused

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 Go to previous messageGo to next message
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! 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:
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.
Re: FairMCPoint trackID vs FairLink trackID. [message #11122 is a reply to message #11121] Mon, 25 October 2010 21:57 Go to previous message
Mohammad Al-Turany is currently offline  Mohammad Al-Turany
Messages: 518
Registered: April 2004
Location: GSI, Germany
first-grade participant
From: 109.107.225*
Hallo Lia,

You are absolutely right! the links array have to get the same update as the MC points.

regards

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


Current Time: Wed Dec 04 17:29:01 CET 2024

Total time taken to generate the page: 0.00795 seconds