We are getting a fatal exception from lambda decays in the recent ALICE production, run with Geant4 10.4.p02: -------- EEEE ------- G4Exception-START -------- EEEE ------- *** G4Exception : DECAY003 issued by : G4Decay::DoIt Can not determine decay channel for lambda mass of dynamic particle: 1.0182 (GEV) dacay table has 2 entries 0: BR 0.639, IsOK? 0, --> proton + pi- 1: BR 0.358, IsOK? 0, --> neutron + pi0 *** Fatal Exception *** core dump *** G4Track (0x2ac004a50620) - track ID = 1588, parent ID = 0 Particle type : lambda - creator process : not available Kinetic energy : 1.70335 TeV - Momentum direction : (0.00010466,-0.000248765,1) Step length : 1.7217 m - total energy deposit : 0 eV Pre-step point : (5.4114,-7.28681,44050) - Physical volume : ZDCA (ZDC_VOID) - defined by : Transportation - step status : 1 Post-step point : (5.59159,-7.71511,45771.7) - Physical volume : ZDCA (ZDC_VOID) - defined by : Decay - step status : 4 *** Note: Step information might not be properly updated. -------- EEEE -------- G4Exception-END --------- EEEE ------- As the exception is fatal, it blocks the Geant4 production.
A production with the same same generator ran successfully 2.5 years ago with Geant4 10.1.p02.
This exception occurred because the mass of Lambda is too small (1018.2 MeV) to decay. The mass should be larger than 1073.5 MeV to decay into n + pi0 mode. The PDG mass of Lambda is 1115.683 MeV. In this case, the hadronic model set the value of dynamical mass to 1073.5 MeV and it causes the problem.
It seems a problem due to the hadronic model responsible of the creation of the lambda - likely FTFP given the high-energy of the particle. It would be helpful if you could find out which is the parent particle which has created the lambda, which energy it has, and which is the target nucleus in which the hadronic interaction (that has created the lambda) occurred. Which this information, we can try to reproduce the problem and hopefully understand what went wrong.
I have checked that in the third patch of the 10.4 series, i.e. 10.4.p03, there was a bug fix that might be relevant for this problem: " hadronic/management: o G4HadronicProcess: added check if secondary particle is on the mass shell; if its mass differ from the PDG mass more for 1.5 MeV then mass is forced to the mass shell, energy conserved, but momentum is changed. " Therefore, I would suggest to move to G4 10.4.p03 (or more recent versions of Geant4). If this migration requires too much validation effort, a possibility would be to simply take the file geant4/source/processes/hadronic/management/src/G4HadronicProcess.cc from 10.4.p03 and use it in your 10.4.p02 installation.
Hi all, I have re-checked, that the fix in 10.4p03 was not working, because additionally to the protection in G4HadronicProcess the fix was required in G4DynamicParticle. The last was done only for 10.6. I do not see a simple way to back-port both fixes from 10.6 to 10.4, it will require very accurate validation. So, my proposal would be to keep 10.4p02 unchanged, some probability of crash will remain. If ALICE will migrate to 10.6p01 this type of problem will disappear. Vladimir
Thank you for your investigation. We found out the older reports of the same problem in ALICE bug tracker system, where the problem was further tracked, and found that these lambdas come from the primary event generator. This also confirms the "creator process : not available" in the exception.
Hi Ivana, thank you for the information. There is likely a probability, that in generators lambda may be be produced far from mass shell (likely ion-ion generators). In HepMC/Geant4 this should be taken into account for particles with status=1 (no predefined decay, not an exotics). I will do a protection for CMS using an algorithm from G4HadronicProcess.cc Vladimir
It turn out, that the protection was in CMS since long time: if (toBeAdded) { G4PrimaryParticle *g4prim = new G4PrimaryParticle(pdg, px*GeV, py*GeV, pz*GeV); if (g4prim->GetG4code() != nullptr) { g4prim->SetMass(g4prim->GetG4code()->GetPDGMass()); … } }
