Incorrect treatment of documentation lines in Geant4InputHandling

[gaede]

We observed a sever bug in events with charged lepton pairs - in particular w/ taus.
In many of these events one of the two taus is actually simulated twice - once with the correct pre-assigned decay and once w/ a decay chosen from Geant4. This is indirectly related to #383, however the actual geant4 crash is an independent bug in geant4 tau decays. These decays should never happen in generator samples w/ pre-assigned decays.
I strongly suspect this fix: 23bd42f committed to fix #307.
The problem occurs in events, of the form

tau+, tau- > 94 object
94 -> tau+, tau-
tau - -> tau-, gamma

here only the last tau+, tau-, gamma should have been given to geant4, but we include also the previous tau parents ( that have zero lifetime in the input file). This also causes the tau lifetime to be applied n-times by geant4, as geant4 treats this as a decay chain.
@andresailer any idea how to revert your fix and still get the correct treatment for real decay chains w/ very short lived particles ?
I guess it would need a more correct check for float value 0 ...
Issue can be reproduced by running: /afs/desy.de/user/g/gaede/public/4f_ZZ_semileptonic_G4crash.slcio through any detector w/ DDG4/ddsim.
In the output file one of the taus will have daughters added in simulation not present in the input file.

[andresailer]

The particles you refer to have generator status 2, right? That is not documentation.

DD4hep/DDG4/include/DDG4/Geant4Particle.h

Lines 69 to 74 in 37a4d07

	// Generator status for a given particles: bit 0...4, agreed by many formats (HepMC, LCIO, ....):
	G4PARTICLE_GEN_EMPTY = 1<<0, // Empty line
	G4PARTICLE_GEN_STABLE = 1<<1, // undecayed particle, stable in the generator
	G4PARTICLE_GEN_DECAYED = 1<<2, // particle decayed in the generator
	G4PARTICLE_GEN_DOCUMENTATION = 1<<3, // documentation line
	G4PARTICLE_GEN_BEAM = 1<<4, // beam particle

Basically you want to reject taus (and maybe other things we discover later on) with 0 lifetime but keep other particles with 0 life time?

Have you tried taking the changes out and seeing what happens?

[gaede]

I guess the problem is that Pythia (and other generators?) are not using genstat==2 for decays only but also for 'documentation' where they then assign a lifetime of 0.
So the correct logic - for this problem - would be to take out the taus ((charged) leptons in general) with lifetime=0 - but not those with lifetime!=0.
However I am a bit uncertain about the correct check for lifetime==0. This has to be done in a way that takes the double precision result of differences into account - as was done in the old version:

    double proper_time_Precision =  pow(10.,-DBL_DIG)*me*fmax(fabs(p->time),fabs(dp->time));
    bool isProperTimeZero = ( proper_time <= proper_time_Precision ) ;
    // -- remove original --- if (proper_time != 0) {
    if ( !isProperTimeZero ) {

Do the short lived hadrons (eta_prime) that you used in testing your fix have 'exactly 0' lifetime or only such a small lifetime that they where falsely identified as having 0 lifetime ?
Depending on this, we'd either have to change the logic to sth. like:

   // -- remove original --- if the pdgID is not known (generator "strings") or the particle has zero lifetime and is quark, gluon, Z, W,  electron, muon, tau, etc.
+    const std::set<int> rejectPDGs{1, 2, 3, 4, 5, 6, 21, 23, 24, 11, 13 , 15 };  // note added leptons
+    if ( (p.definition() && rejectPDGs.count(abs(p->pdgID)) == 0) ) ||
( ! isProperTimeZero && rejectPDGs.count(abs(p->pdgID)) == 1) ) {

or put in the old code and fix the check for zero lifetime...

PS: We did verify that in our testproduction w/ v01-19-05, ie before your patch, the samples w/ lepton pairs where correct.

[andresailer]

Do the short lived hadrons (eta_prime) that you used in testing your fix have 'exactly 0' lifetime or only such a small lifetime that they where falsely identified as having 0 lifetime ?

I don't know

[gaede]

Seems like this is fixed with: 16de447
We'll run a larger test with this as soon as we have a new iLCSoft pre-release