-
Notifications
You must be signed in to change notification settings - Fork 266
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
Possible misbehaviour in GatePositronAnnihilation class #518
Comments
Hello, does this benchmark: https://github.com/OpenGATE/GateBenchmarks/tree/master/t19_acollinearity replies to this issue ? You can see discussion here : OpenGATE/GateBenchmarks#50 |
I'm afraid I don't understand if there has been any change in the GATE code or it's only code to validate GATE. It seems the latter to me, but I'm not that familiar with the code, so I may be wrong. |
The example shows a macro with the back2back source that (if I understand correclty) should depicts these (slightly) non-collinear gammas. Can you try it to see if it fits your need ? https://github.com/OpenGATE/GateBenchmarks/blob/master/t19_acollinearity/mac/acoBTB.mac |
The GateBackToBack |
The code provided in https://github.com/OpenGATE/GateBenchmarks/blob/master/t19_acollinearity/mac/acoF18.mac is, from my understanding, the "right" way to simulate positron range and gamma non collinearity in GATE. Note that I say "right" since I cannot vouch on the "positron range" part: I remember vaguely some emails in the GATE mailing list talking about incorrect positron range values in some context. However, I am pretty sure that the acoF18.mac file will simulate positron range. At least, I believe I had validated that before (maybe 2-4 years ago). Note that it is kinda easy to validate: simulate a point source inside a sphere of water/whatever (~5 mm radius or more) and check the spatial distribution of the coincidences origin. Without positron range, the coincidences origin should be exactly in the point source. |
Ok, I'll give it a try, thanks! However, I'm not saying that the positron range is not simulated at all, but that it is simulated incorrectly, since the positron always annihilates at rest, and not in flight, if I understand the code correctly. Therefore, it's not enough to check that the origin of the coincidences is not the point source. |
It seems I have misinterpreted your intent. What you want, is to ascertain the validity of positron simulation in GATE and/or GEANT4. To do this, it should be, to my knowledge, equivalent to ascertain that positron range and positron annihilation are done correctly. The easy way should be looking at the code, but I fail to understand the code sometimes, so I often analyze the result of a simulation to validate my understanding. With simulation, you can do the first part (for GATE) with the origin of the coincidences. If positron range is simulated correctly in GATE, the (expected/theoretical) positron range distribution in a given medium should be similar to the histogram of the origin of the coincidences obtained with a simulation. True, it does not give information about their remaining energy prior to their annihilation, but you would at least know if the range of the positrons make sense. For the second part... that is a really tricky part simulation-wise (Well, it is/was for me)! So, just to make sure I understand: what does it means for you to "correctly" simulate positron annihilation emission? Is it the simple acolinearity of 0.5/0.59 deg or do you mean the complete branching of the positronium states? If it is the second, I believe that it is not simulated in GATE since I remember that the people of the J-PET project had to modify the code to simulate the different positronium branching (three gammas, two gammas with acolinearity, etc.) |
I checked the second part, and I do find an acollinearity of ~0.54 degrees FWHM using the same code as in GATE (with a few modifications I had to do to make my custom-made process actually happen instead of the Geant4 annihilation process, described in my first message). I also checked the final momenta of the positrons and they are always zero, that's why I suspect that something is being done wrong with the positron range. Note that I'm not using GATE itself, simply because I never did and I already have my geometry implemented in my own Geant4 application, but I reproduced the code of the |
Hi!
I’m trying to reproduce the expected behaviour of e+e- annihilation into two non-collinear gammas, with a deviation of 180 degrees following a distribution with sigma 0.5 degrees in my Geant4-based code (as it has been measured, for instance, in this work). I contacted with the Geant4 developers and they confirmed to me that this behaviour is not included in Geant4 so far.
However, I found that GATE does implement it, as I could read in the documentation, in particular I read that this is achieved using the command
/gate/physics/addProcess PositronAnnihilation e+
. I reproduced the sameGatePositronAnnihilation
class as a new physics process in my code and I observe the following behaviour:G4EmStandardPhysics_option4
, when I run a simulation, the Geant4 process is called, not mine. I noticed that theGatePositronAnnihilation
class inherits from theG4eplusAnnihilation
class, therefore it shares the same name “annihil”. How is this dealt with in the GATE code?G4eplusAnnihilation
toG4VEmProcess
), then I find the expected behaviour. However, e+ always annihilates at rest (the class has only aAtRestDoIt()
method), therefore I deduce that the range of the positron is not simulated correctly, is that right? If that's the case, it could affect PET simulations, where the positron range in tissue is relevant, correct? Also, energy is not conserved, of course.My understanding is that this behaviour should happen using GATE, as well, since I reproduced exactly the same class, but I haven't had the chance to run it, since I've never used GATE. I would say that it is not the expected behaviour, but I may be missing something about how GATE works here.
Thanks!
Laptop:
The text was updated successfully, but these errors were encountered: