parent daughter relations in DDG4 #307
Comments
|
@MarkusFrankATcernch any chance that you can have a look at this ? If confirmed, this would be a show stopper for our MC production ... |
|
Please give example/instruction to reproduce and maybe a dump of the MCParticles table to better illustrate. |
|
Heavy mesons are added to the particle list "late" ie. way after the original particle list is added. This is done inside Geant4, when the heavy mesons are decayed. Does anyone knows where and how this is actually done? |
|
@MarkusFrankATcernch we use pre-assigned decays for heavy mesons, i.e. the decay particles are already in the generator input file. Geant4 might only update the kinematics according to field stepping, energy loss etc but not change the particles and their parent daughter relationships. |
|
The problem can be reproduced for example with: This lists all particles with generator status ==1 and more than one parent, which should never happen. You can also use dumpevent and scroll down the MCParticle collection to look for particle with more than one parent. |
|
The problem is most likely in the "rebaseSimulatedTracks function in the Geant4ParticleHandler The number after the |
|
Are we really sure the input record is properly entered? should NOT be daughters of 48049, but rather of 48094 and 48095. |
|
The input generator file is correct, i.e. it does not have any particles with more than one parent (except for some 92 string objects but never for 'real' particles). With this we get sth like: corresponding lines from dumpevent: So here a D+s (172) decays to an eta' ( 244 ) + sth, and the eta'(244) decays to a photon (292) and a rho. The photon (292) lists its correct parent the eta' but also its grandmother the D+s (172) as parents. PS: The 48111 in the above example is a pi0 ( here 292) with gen stat==2 and thus not listed in my script - but of course has the same problem .... |
|
We should think of defining a couple of consistency checks to verify the MC truth records on demand. The issue is non trivial and may be - depending on the situation - error prone. Hence, such checks are quite vital. |
|
Every issue that has a tag |
|
I think #310 only fixed the symptom, but not the underlying issue. Look at the Vertex and Endpoint of the Particles from @gaede comment above: Focus on the X positions:
Notice how the Start of 244 does not correspond to the end of 172, and the end of 244 does not correspond to the beginning of 292. However, the beginning of 292 does correspond to the end of 172. This is caused by the check for non-zero lifetime: DD4hep/DDG4/src/Geant4InputHandling.cpp Lines 383 to 385 in 8ce1a00 That means 244 is never actually passed on to geant to be simulated (and then immediately decayed), instead all the daughters of 244 are assigned to 172. Because 244 is not passed to geant its vertex and endpoint are not changed to the actual positions from the simulation. This can be seen when dumping the pre-assigned decays from the geant4 vertex Following some hacks to replace the isProperTimeZero to just ignore quarks, gluons and "strings" I can pass all particles to geant4 Then I also get the correct positions for vertex and endpoints of particles and the correct parent daughter relationships, even without the changes from #310. |
The parent daughter relationships for MCParticles are broken after running DDG4 with DDSim.
When simulating for example ttbar events, we find many MCParticles with genStat==1 that have two parents. This seems to happen in particular with heavy meson decays, B->D->pi,K,.. where the grand-daughters are also falsely added to the grand-mother (the B).
@MarkusFrankATcernch any idea where and why this happens ?
If needed, I can provide example scripts to run for reproducing this problem.
The text was updated successfully, but these errors were encountered: