I’m trying to track photons emitted by atomic deexcitation by electron ionisation.
For me, it is necessary to know the volume of origin and the element of interaction (without comparing the energy to fluorescene line energies).
So far, I know that it is not possible to use the GetCurrentElement method, since electron ionisation is not defined in the G4VEmProcess. But is there any other possibilty to get the element, maybe by accessing the G4AtomicTransitionManager or something?
Also, it seems that OriginTouchable is also not defined for the delta rays, and I couldn’t find any other way to access the volume of origin (I always get the ‘Adress not mapped to object’ error when I try to access any information of the track of the delta ray).
Any tips on how to access the informations on the generated delta rays?
That “should” be possible. Ionisation is a subclass of G4VEnergyLossProcess which does have its own GetCurrentElement() function.
Do you have electron production cuts set low enough that you actually get a trackable delta ray, or is it just being rolled into the EnergyDeposit of the parent track? If the delta ray isn’t a track, you won’t be able to get the touchable. You might need to set the electron production cut to zero.
Sadly, it does not work. I still get a segmentation violation (adress not mapped to object).
My production cuts are set to 10um, and the secondaries are being generated, I can access them with GetSecondaryInCurrentStep
Interestingly, the same error also happens with delta rays produced by compton scattering (and the following relaxation) → ProcessSubType defined by the step is compton scattering, the creatorProcess of the produced gamma-secondary is also compton scattering but GetCurrentElement of the process still ends in the segmentation violation.
Another thing I discovered: Sometimes, the process I get via GetProcessDefinedStep is different than the creatorProcess of one of the secondary produced in the same step (always a delta ray produced by electron ionisation relaxation; PIXE is on). Is there some option to access the other process?
Edit: Of course I am talking about gamma rays, not delta rays…, sorry for the confusion!
Your “segmentation fault” errors are almost certainly due to getting a null pointer back from a function, and then trying to dereference that (non-existent) pointer.
The general statement is that “any time” you call a function that returns a pointer, you should test whether the pointer is null before using it.
In Geant4, there are lots of places where the pointer is “guaranteed” to be defined, and you can just use it. For example, aStep->GetPreStepPoint()->GetTouchable()->GetVolume() (the step always has both pre- and post-step points, which always have a touchable, and the touchable always refers to an actual volume).
But there are other places where a null pointer may be returned and you need to test it.
Be careful. Something we have observed in our simulations is that GetSecondaryInCurrentStep() does not seem to always do what the name implies. We’ve seen cases where it returns nothing, or cases where it returns all the secondaries along the track, even from past steps. We haven’t dug deep enough to understand fully the conditions, so we’ve moved away from trying to use that function for analysis.
Right. GetProcessDefinedStep() tells you which process had an interaction length which was the shortest, so that’s the process which the function returns. But on any step, multiple processes may be called into action to do things – along step processes, forced processes, etc. It’s possible that one of those other processes might create secondaries.
I tried it with testing, but even then, it results in a crash. For example, when I try to get the Volume of the origin touchable:
this works just fine: track->GetOriginTouchable()
but when I try to get the volume of that touchable: track->GetOriginTouchable()->GetVolume()
it results in a crash, even if it is just in an if statement or try block.
This only happens with processes generated by the PIXE option (I don’t get the problem when I turn PIXE off), e- through ionisation, gamme through ionisation / compton scattering.
Am I missing something, or are the processes generated by PIXE different in their definition? Why shouldn’t be the Volume of the OriginTouchable be defined?
Thank you for the warning!
To clarify, I thought that secondaries can only be generated by discrete steps (or at least their respective discrete part of their process, like with bremsstrahlung). So it is possible for several discrete steps to occur within the same step (or at least part discrete like ContinuousDiscreteProcess)?
So, is there any way to access the other processes of the step?