New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect treatment of documentation lines in Geant4InputHandling #387

Closed
gaede opened this Issue May 17, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@gaede
Contributor

gaede commented May 17, 2018

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.

@gaede gaede added the bug label May 17, 2018

@andresailer

This comment has been minimized.

Member

andresailer commented May 17, 2018

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

// 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

This comment has been minimized.

Contributor

gaede commented May 17, 2018

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

This comment has been minimized.

Member

andresailer commented May 17, 2018

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

This comment has been minimized.

Contributor

gaede commented May 17, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment