How to convert Geant4TrackID into MCParticle Parent ID

[QuantumSlack]

Good morning Andre,

Currently I am trying to find the lineage of the photons which are detected in the photo-detector. For that I want the track ID for the parent of that photon. So first I created two dictionaries. One is for relating the track-id with the pdg of the particle which was in the track and another one where I relate track-id with parents array which is stored in MCParticles. From that, I can now relate the track-id with both PDG and parents. Now, I added some fields in my SD Action to add the parent ID in my HitScin and HitCer (which store the cerenkov and scintillation photons which arrived). However, the parent ID stored in that array is different from the ones that I got from parents in MCParticles. Is there any way to relate Geant-4 ID and DD4hep MCParticle id?

I am attaching my code for creating the dictionary and log files for parents in MCParticles, dictionary created from those parents, and then finally parentID in the HitScin field which I stored by modifying the SD-Action file.

mc_parent_list.log

dicts_MCParticles.log

DRFNoSegment_HitScin_parentID.log

neutron_parent.py

Note:- in the log files, ignore the last two lists which are being printed

[andresailer]

I cannot follow through your log files, or what logic writes which list, and how you expect the lists to actually look like, or what the issue with the different lists is.

What probably happens is that the MCParticle history provided by DD4hep is collapsed to "important" particles, but I cannot tell for sure, since I don't know what command with what options you run.

If you really want some help, you need to say exactly what you run, and where in your code you extract which information. Use the capability of github to link to individual lines of code for example.

Thank you for your understanding and good luck!

[QuantumSlack]

Sorry for the ambiguous question. So here's my reasoning:-

Goal:- Extract the number of photons which hit the detector and also originated from a charged particle produced by a neutron decay.

Logic:- My idea was that I need to store the parent and their PDG ID for each particle which was produced. Then using that data, I can perform a recursion to trace out which photons have that parentage.

Code:- I store that information in my Hit Class definition by defining a struct for the arrived photons which stores those parameters given in https://github.com/QuantumSlack/DualTestBeam/blob/8211ba017a9270695ef8e435089a62c38bb203b7/include/DualCrysCalorimeterHit.h#L71-L78

After that I extract those values in the SDAction code referenced in https://github.com/QuantumSlack/DualTestBeam/blob/8211ba017a9270695ef8e435089a62c38bb203b7/src/DualCrysCalorimeterSDAction.cpp#L283

Additionally, the DRFNoSegment branch in addition to MCParticles and EdgeDetSegment was also storing the truth value of the contribution which is referenced in https://github.com/QuantumSlack/DualTestBeam/blob/8211ba017a9270695ef8e435089a62c38bb203b7/src/DualCrysCalorimeterSDAction.cpp#L418

Up until here, I am not sure of two things:-

1. In MCParticles, there two fields:- "g4Parent" and "parents". What's the difference between? Upon inspecting the histogram for these fields, the values of g4Parent is higher than parents. So do they correspond to the same particle but just different way of storing it? For analysis, which one will refer to the actual process which happened in the detector?

2. In MCParticles, there is a field called "id" and in truth values there is a field "trackID". What's the difference between these two fields? I presume that trackID is the ID number for the corresponding particle and "id" is a unique label for a particle. If "id" is unique for each particle, then the values of "id" should be very high because there are many particles which are being produced, however in my ROOT file, the maximum values for "id" is around 1400.

Maybe this will clarify some of the confusion I have for the log files.

[andresailer]

produced by a neutron decay.

Do you mean a neutron decay -- after 10 minutes of lifetime -- or something else?

Regardless, if you are looking for particles that come after a certain decay, there is the "saveProcesses" option for the particle handler.

What probably happens is that the MCParticle history provided by DD4hep is collapsed to "important" particles, but I cannot tell for sure, since I don't know what command with what options you run.

[QuantumSlack]

Hi Andre, I am running the ddsim command as follows:-

ddsim --compactFile=/Users/shiva/DD4hep/examples/DualTestBeam/compact/DRFSCEPonly.xml --runType=batch -G --steeringFile=/Users/shiva/DD4hep/examples/DualTestBeam/compact/SCEPCALsteering.py --outputFile=/Users/shiva/DD4hep/examples/DualTestBeam/compact/output/FSCEPonly/out_FSCEPonly_10GeV_pi-.root --part.userParticleHandler= -G --gun.position="0. 0.*mm -80*cm" --gun.direction "0. 0.05 0.99875" --gun.energy "10*GeV" --gun.particle="pi-" -N 10 >& /Users/shiva/DD4hep/examples/DualTestBeam/compact/output/FSCEPonly/sce_pi_FSCEPonly_10.log

which produced the ROOT and log files which is what I am using for my data analysis.

Whenever there is a neutron, it can decay into an electron and anti-neutrino and then those charged electrons can produce photons. So, out of all the photons that are detected in photodetector, I want to know how many of these photons actually reach the detector. For that, I was saving the id, pdgID for the parent and then trying to form a map to trace out which photons were produced by these processes.

[andresailer]

Assuming this is your steering file
https://github.com/QuantumSlack/DualTestBeam/blob/8211ba017a9270695ef8e435089a62c38bb203b7/compact/SCEPCALsteering.py#L418

You can just turn on keepAllParticles and I think the two IDs are going to be the same?

[QuantumSlack]

Hi Andre, I tried that and they are still not the same. In any case, what's the difference between "id" and "pdgID"? And why they are different from each other?

[andresailer]

pdg ID is a numerical code to identify the particle (11 electron, 22 gamma, etc.)

id is the id of the specific track, like a running counter. Maybe I was confusing things in my head. I meant the id and the OriginalG4ID should be the same if keepAllParticles is true

DD4hep/DDG4/include/DDG4/Geant4Particle.h

Lines 108 to 110 in e369490

	int id { 0 };
	int originalG4ID { 0 }; //! not persistent
	int g4Parent { 0 };

[QuantumSlack]

Hi Andre,

So, is id unique for each particle? Or for a given track, the particles produced in that track will have the same id? Also, how is trackID different from id?

[andresailer]

Which trackID? Can you please link to the relevant source code

[QuantumSlack]

This variable comes from saving the contribution truth value in the ROOT file. https://github.com/QuantumSlack/DualTestBeam/blob/8211ba017a9270695ef8e435089a62c38bb203b7/src/DualCrysCalorimeterSDAction.cpp#L418

[andresailer]

Where is this in the source code of DD4hep?

[andresailer]

trackID for the hit is filled here

DD4hep/DDG4/src/Geant4Output2ROOT.cpp

Line 232 in e369490

t.trackID = m_truth->particleID(trackID);

which calls particleID, which gives the equivalent trackID.

DD4hep/DDG4/src/Geant4Particle.cpp

Lines 537 to 543 in e369490

	int Geant4ParticleMap::particleID(int g4_id, bool) const {
	TrackEquivalents::const_iterator iequiv = equivalentTracks.find(g4_id);
	if ( iequiv != equivalentTracks.end() ) return (*iequiv).second;
	printout(ERROR,"Geant4ParticleMap","+++ No Equivalent particle for track:%d."
	" Monte Carlo truth record looks broken!",g4_id);
	dump();
	return -1;

There is no difference between id and trackID