Get the track ids from primary mcparticles

Hello,
I used the DepositionReader module to feed Geant4 energy depositions to Allpix2. I have provided the particle pdg_id, track_id and parent_id with create_mcparticles set to be true. Now I am analyzing the digitized output of Allpix. I want to know how I can get the track_id of the primary particles in the digitized output. I am trying to do something like this:

but I see that all the particleTracks are nullptrs in this case. I also don’t see any getter to access the particle track_id in the MCTrack class. How should I proceed?

Thank you very much,
Arka

Hi @asantra

the actual track_ids provided in the input ROOT tree are not stored. We only use them to figure out the relations between the individual MCParticle objects. They are then reflected by their getParent() relations.

The relevant code that does the sorting can be found here: src/modules/DepositionReader/DepositionReaderModule.cpp · master · Allpix Squared / Allpix Squared · GitLab

If you give me a bit of background why you are looking for these IDs maybe we can figure out a way to get your analysis running without that information.

/Simon

Hi @asantra

sorry, just saw the link to your analysis code now. Unfortunately right now the DepositionReader does not generate MCTrack objects - simply because a lot more information would be necessary in the trees to generate the relevant object.

You are basically looking for the energy of the MCParticle?

/Simon

Hi @simonspa ,
My goal is to feed the digitized data (clusters) from Allpix to the tracking algorithm. Then reconstruct the track energy from the tracking algorithm and compare that with the truth track energy. For this comparison, the unique track id will be really helpful in order to resolve ambiguity.

In the DepositionReader module, can I add something here in the MCParticle to store track_id? Then get back track_id from MCParticle in the digitized output? If this is done, then that is good to go for us for now.

Best,
Arka

Hi @asantra

yes, of course that would be possible. You could juts add another member to the MCParticle object and store the track_id in there. I’d suggest to add the track Id then to the MCParticle constructor and set a default value, i.e.

MCParticle::MCParticle( /* ... */, int track_id = -1) { /* ... */ }

such that you don’t have to change the code everywhere we generate MCParticles. Then you can use the additional information in the DepositionReader to set that info.

/Simon

Hi @simonspa ,
Thank you for the tip. I tried to implement this:

A. In MCParticle class:

  1. I have added the track_id_ variable to the MCParticle class.
  2. The constructor of MCParticle class now contains track_id. This is in the header file and this is in the cpp file.
  3. Added a getter for track_id in the MCParticle class.

B. In DepositionReader module:

  1. Opened a map to store mcparticle track id.
  2. Here mcparticle track_ids are stored.

The setup is compiling and running fine. But when I get the track id from MCParticle::getParticleTrackID, I see garbage values. For example, this is the input track ids:

Screen Shot 2021-11-25 at 17.52.17

and this is what I get from the processed output (x-axis is multiplied by 1e6):

I am not sure why this is happening. Is there any other place where I am supposed to add track_id? I did not change anything in DatabaseWriter module, but my understanding is that this is not needed because I am not writing to SQL database. Any heads up will be greatly appreciated.

Thanks once again!
Arka

Hi @asantra

your code looks fine. I would increment the ClassDefOverride(MCParticle, 9); to ClassDefOverride(MCParticle, 10); because you added a new member. This is ROOT-internal versioning of objects - so skipping the increment might load the object without the new member.

Apart from that I don’t see anything obvious you would need to change. The DatabaseWriter should be of no concern to you, as you stated correctly.

Do you see the log output from here with the IDs you are expecting?

/Simon

Hi @simonspa ,
Apparently changing ClassDefOverride(MCParticle, 9); to ClassDefOverride(MCParticle, 10); did the trick. I now get sensible MCParticle track ids in the output. This solves my problem!
Many thanks,
Arka

Perfect, then it really was ROOT getting confused about which members to expect in the class. :slight_smile: