GSI Forum: Tracking » Problem with secondary tracks

Home » PANDA » PandaRoot » Tracking » Problem with secondary tracks

Show: Today's Messages :: Polls :: Message Navigator

Problem with secondary tracks [message #12375]

Thu, 28 July 2011 18:10

Felix Boehmer
Messages: 149
Registered: May 2007
Location: Munich

first-grade participant

From: *natpool.mwn.de

Dear pandarooters,

in the course of figuring out what is going wrong with the MC PID correlation, we came across some strange behavior concerning trackIDs of secondary particles.

What happens is that the trackID we extract in the processHits() method of the TPC Detector class from the MCStack is no longer a valid position in the MCTrack array after the simulation. This only happens for secondary tracks and explains why in some generator channels we get invalid PDG codes.

We have been trying to find out if/where these IDs are altered in the framework, but failed so far. Does anybody know what is happening?
Since time is short right now we would be very grateful for any help on that matter. We will be running simple example macros to find out what's going on.

Cheers

Felix

Report message to a moderator

Re: Problem with secondary tracks [message #12377 is a reply to message #12375]

Thu, 28 July 2011 18:29

Mohammad Al-Turany
Messages: 518
Registered: April 2004
Location: GSI, Germany

first-grade participant

From: 46.248.220*

Hi,

There is a filter on secondary particles, by default, this filter will skip secondary particles that:
1. do not hit any detector
and
2. do not have any daughter that hit any detector

such particles can never be detected and we simply delete the and reindex the whole mother-doughter relations in the TClonesArrays and the MCTrack
(all what goes to the Tree is consistence)

Now if you have classes that do not inherits from the MCpoint classes in framework or you do your own things (you save the particle Id your self in the simulation in some privet classes), then I can imagine that you get some discrepancies!

Anyway, this filter can be easily switched off in the g4/3Config.C macro:

/// create the Specific stack
   PndStack *stack = new PndStack(1000); 
   stack->StoreSecondaries(kTRUE);
   stack->SetMinPoints(1);

if you set the min points to zero, i.e:

/// create the Specific stack
   PndStack *stack = new PndStack(1000); 
   stack->StoreSecondaries(kTRUE);
   stack->SetMinPoints(0);

Then all particles will be saved to the output without any filtering. But this could increase the file sizes dramatically.

I hope this will help you.

regards from the sunny Jordan with 40 degrees in shadow.

Mohammad

Report message to a moderator

Re: Problem with secondary tracks [message #12379 is a reply to message #12377]

Thu, 28 July 2011 21:12

Felix Boehmer
Messages: 149
Registered: May 2007
Location: Munich

first-grade participant

From: *adsl.alicedsl.de

Hi Mohammad,

thanks for your answer.
We certainly don't want to use any information of tracks outside the detector... However, we want to store the sec. track ID in the TPC points during processHits of the detector class... How can we assure to have valid trackIDs also for secondaries after the framework did its cleanup?

Cheers

Felix

PS: 40 degrees is more or less 4 times what we have here...

Report message to a moderator

Re: Problem with secondary tracks [message #12381 is a reply to message #12379]

Thu, 28 July 2011 23:24

Mohammad Al-Turany
Messages: 518
Registered: April 2004
Location: GSI, Germany

first-grade participant

From: 46.248.220*

Hi,

If I understand your code in "PndTpcDetector::ProcessHits" you are miss-using the trackID variable, this member variable comes from the base class FairMCPoint and the whole filtering is based on this inheritance (The FairMCStack has no idea about detector or experiments code).
To explain this: The trackID is used normally as unique identifier of a track, i.e: it is the index of this track in the array, and when you get the mother ID of a track you get also the index of that mother in the array. In your code you are setting the trackID to the mother ID:

 Bool_t  PndTpcDetector::ProcessHits( FairVolume *v)
  ........
    TParticle* mother=gMC->GetStack()->GetCurrentTrack();
    if(mother->IsPrimary()) secID = 0;
    else while(!mother->IsPrimary()){
    trackID=mother->GetFirstMother();
    mother=dynamic_cast<PndStack*>(gMC->GetStack())->GetParticle(trackID);
    //std::cout<<"Fetching mother id="<<trackID<<std::endl;
  }

  // trackID is now ID of primary mother
  // if the mother is already primary, secID is 0
  // else secID is an (arbitrary) number !=0
.............

 //gotta love TClonesArray syntax!
  PndTpcPoint* p=AddHit(trackID, secID, volumeID, pos.Vect(), mom.Vect(),
			time, length, eLoss);

As you see, the PndTpcPoint has a variable trackID which does not correspond to the track index anymore, and this will miss up the whole filtering! So I would suggest you to define a new variable in your TpcPoint which hold the info you need without miss-using the trackID.

Hope this will help you, now I will enjoy the rest of my vacation!

Cheers,

Mohammad

Report message to a moderator

Re: Problem with secondary tracks [message #12396 is a reply to message #12375]

Fri, 29 July 2011 16:48

Johannes Rauch
Messages: 41
Registered: September 2010
Location: TUM

continuous participant

From: *natpool.mwn.de

Dear Mohammad,

when I just assign the trackID (and not trackIDs of mothers) everything works fine!

Thanks for your help and have a nice holiday!

Johannes

Report message to a moderator

Previous Topic:	bug in PidCorrelator
Next Topic:	Update on eta_c reconstruction with STT and TPC

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Fri Apr 19 10:50:42 CEST 2024

Total time taken to generate the page: 0.00856 seconds