I am traying to get neutron scattering data using examples/extended/hadronic/hadr03 , but i am not able to get secondary energy deposits like gammas produced in process. I was trying to get TotalEnergyDeposited in Stepping action but it isn’t working and parentID keep coming 0.How should i get energy deposit secondaries?
There are different ways to answer your question depending on what you mean by “secondary” here. Do you want only the particles that are the children/secondaries of the initial primary neutron? There is a very east way to do that.
In PostUserTrackingAction grab the particle ID
If it is 0, then it is the primary.
Grab all the secondaries there
Histogram the kinetic energies of this list by particle type as you have done in the stepping action.
This check only has to occur exactly once when the primary neutron activates an AtRest process, is captured, or leaves the world volume. You could further kill all of these secondaries (i.e. fstop and kill) and effectively stop the simulation after the primary neutron has generated all direct secondaries. It should be a very fast simulation to run.
If your case is not this you will probably wind up defining some UserInformation to pass down to further removed secondaries since Geant4 particle’s do not have “memory” of their lineage past their parent by default.
Edit - I mostly mention this method since it avoids a lot of the weird edge cases with doing this in the steps when they will be aggregated anyway for the UserTrackingAction.
Example Hadr03 is designed to identify and print the nuclear reaction which can happen at end of the first step of primary particle.
It is not recommended to continue the event. If you allow secondary particles to travel and to interact, the above algorithm will be lost, may crash or give wrong informations.
Also, please remember that neutral particles (photons, neutrons) do not deposit energy along their trajectory; only their charged daughters can do.
May I suggest you to start from examples Hadr06 of Hadr07
Just a side note, Michel (and Justin). Under rare circumstances, a neutron track may be assigned an “EnergyDeposit” value, as a consequence of tracking ProductionCut settings (we have seen this in the CDMS simulations) :
If the hadronic (“proton”) production cut is set long, then a neutron elastic scatter will not produce a secondary; the recoil energy will be attributed to the incident neutron.
If the gamma production cuts are set long, then a neutron elastic scatter, which would normally produce de-excitation gammas, may instead have some or all of the de-excitation energy attributed to the incident neutron.
I will note that our observations of this (and subsequent adjustment of production cuts to avoid it!) was with Geant4 10.07.p04. It might be that this is handled differently in G4 11.
The UserSteppingAction is different from the UserTrackingAction. The first is called every step while the second is called only twice. Once for the PreUserTrackingAction (when the particle is “born”) and in the PostUserTrackingAction (when the particle “dies”). The idea is that if you want to record just the initial kinetic energy of the direct secondaries when they are born by accessing the secondaries of the primary track.
If you want the deposited energy than you have to identify what level of secondary do you “mean”. Gammas and neutrons are not detected directly but instead through cascades of ionized electrons and/or recoil protons. You simply will not be the “gamma” or neutron” directly deposit any energy since deposited energy is fundamentally tied to electromagnetic interactions that do not exist for uncharged particles.
There are ways to sneak around this but again I ask what level of secondaries are you targeting here?
That is interesting and I suppose that gives a possible second route to do this which is just to set the production cuts of electrons and protons to kilometers. Might be a little bit slower than just checking the secondaries of the primary but I could definitely think of some useful cases for this where certain G4Regions could be “tuned” for this behavior such as in shielding, PCB stackups, etc. where you might not care as much about what the energy is but where it is going.
Thank you jrellin , Yes it was suppose to be UserTrackingAction sorry.
What I want is energy transfer in detector by the gamma which are create due to neutron flux as incident beam, I’ll not call it deposit as you have suggested it is from cascade not from gamma. I think if I able to get kinetic energy of those gamma just before leaving detector volume, then I’ll get energy transfer to detector.
There are multiple complication that will arise with this. This includes gammas being fully absorbed within your detector and the case where you have multiple “gammas” leaving your volume from a single incident neutron. This can happen due to x-ray excitations or due to positron annihilation 511 keV gammas (indirectly downstream of neutron induced nuclear reactions).
Do you want to know the energy of the gammas at all or just the energy they deposit? The example you are using is intended to get cross sections which would be interested in the gamma spectrum of the initially generated gammas. And I think you want the latter?
Yes I want energy they are depositing. To see nucleus recoil deposit spectra I want to subtract that gamma spectrum, so gamma deposit spectrum instead all the gamma which created in reaction would be good.
If you want nuclear recoil from the incident neutrons. Does this do what you might want?
void MyTrackingAction::PreUserTrackingAction(const G4Track* track) {
// ParentID 1 means it was created by the primary neutron
if (track->GetParentID() == 1) {
G4ParticleDefinition* pD = track->GetDefinition();
if (pD->GetAtomicNumber() > 0) { // ion check, one way to do it
G4Ions* ion = static_cast<G4Ions*>(pD);
G4double excitation_en = ion->GetExcitationEnergy();
G4double kin_en = track->GetKineticEnergy();
// Creator process if you want it
const G4VProcess* creator = track->GetCreatorProcess();
// Add additional code if you want only specific processes
// Add your code to histogram the energy or energies you want
}
}
}
}
excitation_en and kin_en give you both the excitation energy and the kinetic energy and because this is done in the PreUserTrackingAction these are both the “initial”. You would not need to track or account for gammas at all.
Still unclear what it is you are trying to measure. But with this you at least remove the “initial” neutron energy transfer part. What part of that you want to measure afterward is up to you.
My idea was that by getting energy deposit of gamma (i mean by photoelectric or Compton effect ) with detector volume I can get gamma spectra. The gamma are produced from reaction of incident neutron and nucleus of detector volume. I am able to get each gamma energies as you can see in code from reaction, but point is that not all of that gamma are depositing energy, so in order to get actual detector signal or similar, I think I need deposited gamma energies, not all gamma energies from reaction. I hope now you may understand what I am saying.
The SteppingAction as you originally shared does not record any deposited energy. You populate histograms based on the identity of the particle and its energy. My guess is the reason that you were not seeing these histograms as output if that is the issue is because you defined the histograms elsewhere as being off by default and needed to enable them in your macro file since it looks like this code was copy-pasted from other examples that do exactly that.
The problem will be that your histograms will multiply count scatters i.e. neutron scatters or compton scatteres among others as you noted. The unambiguous way to record the deposited energy is to define and use a sensitive detector which is a very core and often used feature of Geant4 i.e. you need list mode data if you want fine control and accumulators otherwise.