Project

General

Profile

Bug #3062

PrimaryGeneratorAction crashes on ions

Added by Andrei Gaponenko almost 7 years ago. Updated almost 7 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Start date:
10/20/2012
Due date:
% Done:

0%

Estimated time:
Duration:

Description

Geant may produce ions and handle them. However if an ion is fed to Geant from a generator via GenParticle, the Mu2eG4 code will crash. (Try nitrogen,pdgId=1000070140, for example) The crash happens in this line

https://cdcvs.fnal.gov/redmine/projects/mu2eofflinesoftwaremu2eoffline/repository/revisions/56673d98db9d854b7dcce2de6514e3647a722a35/entry/Mu2eG4/src/PrimaryGeneratorAction.cc#L162

and is caused by g4id from the previous line being NULL.

This causes problems for multi-stage jobs, when particles from one stage are written to disk, then passed to the next G4 job by reading them via a mu2e generator.

Andrei

History

#1 Updated by Rob Kutschke almost 7 years ago

  • Status changed from New to Feedback

Hi Andrei

There are several issues here and there is one that I don't know for sure how to deal with - I will forward it to the G4 people.

Let's get the easy issue dealt with first: did you check that inside our PrimaryGeneratorAction::fromEvent method the pdgcode in the generated particle had the expected value (can you point me to the code that made the gen particle - I presume you had to cast the unknown Id into the right type?).

Here is the real problem. When the job starts, the G4 particle table contains no isotopes ( not counting, p, n, d, and maybe T as isotopes). The physics classes that produce nuclei as daughters all make the particle data table entries for the isotopes on demand. So if you start a fresh G4 job and immediately encounter an isotope as a genparticle, then that isotope is not in the table.

You can look at the c'tor for the G4PrimaryParticle at:

/grid/fermiapp/products/mu2e/artexternals/geant4/v4_9_4_p02/source/geant4.9.4.p02/source/particles/management/src/G4PrimaryParticle.cc

It simply sets its own internal pointer and never does a validity check; the first time the bug is encountered is in our code at the place you pointed out.

I will ask the G4 people how to add isotopes on demand. Supposing we do not get an answer soon, is it OK if we just check for g4id==0 and continue? Or check earlier in the chain for:

pdgid > PDGCODE;;G4Threshold

and continue?

#2 Updated by Andrei Gaponenko almost 7 years ago

Hi Rob,

I worked around this for now by substituting, inside my generator code, ions with protons of the same kinetic energy.

We need to fix this properly. When PrimaryGeneratorAction gets NULL g4id there should be a way to add that ion to the table. Let's see what G4 people suggest.

Andrei

#3 Updated by Rob Kutschke almost 7 years ago

Email sent to the G4 people at fnal: Daniel, Soon, Julia and Krzysztof

Hi All,

I have a question about G4 that requires a bit of a preamble ...
In Mu2e we frequently run chains of G4 jobs.  We run G4 and look for particles entering any of a set of interesting
volumes - when a particle enters one of these volumes we record the properties of the particle at that point and then kill
the particle. In a second G4, job we read in the properties of the saved particles and, in our UserPrimaryGenerator action, we
recreate these particles as primary particles and start G4 again. We aggregate the output of the two G4 jobs into a single
event-data file and we have a bookkeeping tool that lets us follow the parent-child history spanning the two jobs.
We typically do this when the yield in the first job is small - say one event out for 1000 events generated.  This allows us
to rerun G4 from the saved point without having to rerun the first step. We sometimes run chains of 3 jobs this way.
From time to time one of the saved particles will be an isotope or ion ( one of the particles with a G4 particle ID > 
1000000000 ). The problem is that, at the start a G4 job, these particles are not present in the particle table; the particle
defintions are created as needed by those physics processes that create them! So it can happen that we read in an isotope before
its particle definition is created in the G4ParticleTable.
When this happens there is prompt crash because the particle definition is not present in the table.
So here is the question: in our user primary generator action how can we tell the G4ParticleTable to find the information for
isotope in question and load it? An alternative, since we are not tight for memory might be to tell the particle table, at job
start, to load all of the isotopes and ions that it knows about.
Rob

#4 Updated by Rob Kutschke almost 7 years ago

Rob Kutschke wrote:
Hi Andrei

There are several issues here and there is one that I don't know for sure how to deal with - I will forward it to the G4 people.
Let's get the easy issue dealt with first: did you check that inside our PrimaryGeneratorAction::fromEvent method the pdgcode
in the generated particle had the expected value (can you point me to the code that made the gen particle - I presume you had to
cast the unknown Id into the right type?).
Here is the real problem. When the job starts, the G4 particle table contains no isotopes ( not counting, p, n, d, and maybe T
as isotopes). The physics classes that produce nuclei as daughters all make the particle data table entries for the isotopes on
demand. So if you start a fresh G4 job and immediately encounter an isotope as a genparticle, then that isotope is not in the
table.

You can look at the c'tor for the G4PrimaryParticle at:

/grid/fermiapp/products/mu2e/artexternals/geant4/v4_9_4_p02/source/geant4.9.4.p02/source/particles/management/src/G4PrimaryParticle.cc

It simply sets its own internal pointer and never does a validity check; the first time the bug is encountered is in our code at the place you pointed out.

I will ask the G4 people how to add isotopes on demand. Supposing we do not get an answer soon, is it OK if we just check for g4id==0 and continue? Or check earlier in the chain for:

pdgid > PDGCODE;;G4Threshold

and continue?



Also available in: Atom PDF