[Gate-users] Scatter dependent on range cut – bug?

Wed May 18 13:28:36 CEST 2022

Hi David,

interesting indeed ... I would suggest, maybe, to use a second phase-space
actor attached to the crystal and see if you can observe similar behavior.

You mentioned "range cut", but did you really used "ranged cut" (
https://opengate.readthedocs.io/en/latest/cut_and_variance_reduction_technics.html#special-cuts)
or the default "production cut" (
https://opengate.readthedocs.io/en/latest/cut_and_variance_reduction_technics.html#id2)
?

I don't really get why the # of incident gammas is lower with lower cut ;
maybe try to look at the energy spectra ? Also, there are differences
between crystalHits and phase-space. For example: crystalHits do not store
hits when edep=0 while phasespace does. Phase space actor has many options
(storeAllStep for example, see
https://github.com/OpenGATE/Gate/blob/develop/source/digits_hits/src/GatePhaseSpaceActorMessenger.cc)
you can play with to try understand what happens. Be sure to define (in
particular): storeSecondaries (should be false), storeOutgoingParticles
(should be false) and storeAllStep (should be false).

Sincerely,
David

On Tue, May 17, 2022 at 11:34 PM David Leibold <D.Leibold at tudelft.nl> wrote:

> Dear Gaters,
>
> I am simulating a cone beam CT setup where I output the Hits / Singles
> registered in the detector, which I then split into primary and scatter
> contribution based on the nPhantomCompton, nPhantomRayleigh and parentID
> parameters. These indicate the number of Compton or Rayleigh scatter events
> in the phantom and whether a particle was created by the source or via
> creation of secondary particles.
> We noticed that the scatter-to-primary ratio in our simulation was far
> below the values reported in literature (more than a factor 10). I was able
> to show that for certain range cuts not every scattered photon exhibited a
> nPhantomCompton or nPhantomRayleigh value that would have indicated that
> it was indeed scattered. In the following I will try to explain what I mean
> by that and which behaviour of the simulation I can’t explain.
>
> In the following figure you will see on the left the simulation setup:
>
>    - A monoenergetic source emitting a pencil beam of 120 keV photons,
>    - A water cube serving as a phantom,
>    - A phase space actor in front of a realistic (two-dimensional)
>    detector,
>    - And a CTdetector of a realistic material (CsI), to which a crystalSD
>    detector is attached.
>
>
> With the output of the crystalSD detector (Hits/Singles) and the phase
> space actor, one can simply plot the coordinates of the intersection point
> of the incident photons with the detector plane. Any photon that does not
> go through the centre axis must then either have been scattered in the
> water phantom or be a secondary. (*)
> Additionally, the crystalSD detector outputs the nPhantomCompton,
> nPhantomRayleigh and parentID parameters, which I used initially to
> separate primaries from scatter.
>
> (*) Note: In the Hits dataset, I only evaluate the first entry for a given
> eventID, so scatter inside the detector does not influence this evaluation
> (I guess?). In the data of the phase space actor, only photons flying in
> the direction of the detector are evaluated.
>
>
> In the following the range cut* inside the detector* is now varied. I
> then evaluated:
>
>    - How many photons end up in the detector, which is evaluated by
>    counting the number of unique eventIDs in the Hits dataset (label “incident
>    photons”),
>    - How many photons are flagged by Gate as scatter or as secondary
>    particle, based on the nPhantomCompton, nPhantomRayleigh and parentID parameters
>    (label “Gate: scatter&secondaries”),
>    - How many photons are outside the centre axis, based on the their
>    intersection with the phase space actor (label “off-centre in
>    phase-space”),
>    - and how many photons are outside the centre axis, based on their
>    intersection with the realistic detector (i.e., using their coordinates as
>    registered in the Hits output, label “hits off-centre").
>
> The following plot shows the results:
>
> As one can see, below a certain range cut the number of events flagged by
> Gate as scatter or secondaries (via the  nPhantomCompton, nPhantomRayleigh
>  and parentID parameters) drops considerably and deviates from the
> evaluation based on the number of photons that are off-centre. I have no
> explanation for this phenomenon.
>
> Now let’s zoom into the the number of incident photons:
>
> Interestingly, the number of photons incident on the detector varies with
> the range cut, which to me is unexpected. Sure, the number of interactions
> inside the detector increases with decreasing range cut, but this should
> have no effect on the number of incident photons.
>
> Here is a zoom into the number of off-axis photons:
> I don’t have an explanation why the phase space actor and the crystalSD
> have a slightly different number of off-axis photons, but this is at the
> moment not my main concern. Again, one can see that their number changes
> with decreasing range cut.
>
>
> Last but not least, I kept the range cut in the detector at the default
> value and instead changed the range cut inside the phantom. Here is the
> result:
> In this case, the three different ways to extract the number of scatter
> and primaries agree more or less. Again, one can clearly see a change in
> the number of total incident photons with smaller range cuts.
>
>
> So far, I am unable to explain the behaviour shown above, and I am not
> sure whether I did something wrong in my Gate simulation or whether this is
> a bug. Please find attached the Gate macros that I used to create this
> minimum example, and also the Python script I used to evaluate the
> resulting data. FYI, I use Gate version 9.1, and I also observe this
> behaviour with Gate version 9.0.
> Any help or suggestions would be greatly appreciated. If you think that
> this is a bug, then I am happy to submit a bug report on GitHub.
>
> Thanks a lot for your time in advance!
>
> Kind regards,
> David Leibold
>
>
>
> _______________________________________________
> Gate-users mailing list
> Gate-users at lists.opengatecollaboration.org
> http://lists.opengatecollaboration.org/mailman/listinfo/gate-users

-- 
David Sarrut, Phd
Directeur de recherche CNRS
CREATIS, UMR CNRS 5220, Inserm U1294
Centre de lutte contre le cancer Léon Bérard
28 rue Laënnec, 69373 Lyon cedex 08
Tel : 04 78 78 51 51 / 06 74 72 05 42
http://dsarrut.github.io
_________________________________
 "2 + 2 = 5,  for extremely large values of 2"
_________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20220518/578f0d28/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.png
Type: image/png
Size: 88393 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20220518/578f0d28/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stp_d.png
Type: image/png
Size: 102928 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20220518/578f0d28/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stp_d_ni.png
Type: image/png
Size: 86794 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20220518/578f0d28/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stp_d_oa.png
Type: image/png
Size: 98274 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20220518/578f0d28/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stp_p.png
Type: image/png
Size: 96827 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/pipermail/gate-users/attachments/20220518/578f0d28/attachment-0009.png>