[Gate-users] Potential bug with short time slice / low activity

[Simon Stute]

Obviously, you just move the source... Sorry !
Simon


On Wed, Mar 12, 2014 at 5:43 PM, Simon Stute <gate.stute at gmail.com> wrote:

> Hi again,
>
> Thank you Guillem for having tested further and reporting the results.
> We will dig on this to find the problem and hopefully a solution.
>
> And about your specific concern, why do you need to use so many time
> slices ?
>
> Regards,
> Simon
>
>
> On Wed, Mar 12, 2014 at 5:36 PM, Guillem Pratx <pratx at stanford.edu> wrote:
>
>> Hi Simon,
>>
>> I looked at the number of positron decays in root (total_nb_primaries)
>> and again the number of observed positrons far exceeds what one would
>> expect (~330 positrons observed for a 1Bq, 100s acquisition with 500 time
>> slices). This result is verified for different random seeds. With 10,000
>> time slices, I even get >1200 positron decays when one would only expect
>> only ~100.
>>
>> I do apply standard 18F decay to my e+ source (see below):
>>
>> /gate/source/addSource F18PointSource
>> /gate/source/F18PointSource/setActivity 1 becquerel
>> /gate/source/F18PointSource/gps/particle e+
>> /gate/source/F18PointSource/setForcedUnstableFlag true
>> /gate/source/F18PointSource/setForcedHalfLife 6586 s
>> /gate/source/F18PointSource/gps/energytype Fluor18
>> /gate/source/F18PointSource/gps/type Point
>> /gate/source/F18PointSource/gps/angtype iso
>> /gate/source/F18PointSource/gps/centre 0. 0. 0. cm
>> /gate/source/F18PointSource/attachTo movpoint
>> /gate/source/list
>>
>>
>> And yes, I use a list of random seeds (simply 1, 2, 3, ... etc.).
>>
>> I think this behavior should be easy to reproduce with any PET
>> simulation. This would at least show that it is not an isse specific to my
>> macro.
>>
>> Thanks for your help,
>>
>>  Guillem Pratx, PhD
>> _______________________________________________
>>
>>    Assistant Professor Office A247
>>    Radiation Oncology 1050 Arastradero Rd
>>    Stanford University  Palo Alto, CA 94304
>>    http://pratxlab.stanford.edu           (650) 724-9829
>> _______________________________________________
>>
>> On Mar 12, 2014, at 3:13 AM, Simon Stute <gate.stute at gmail.com> wrote:
>>
>> Hi Guillem,
>>
>> I do not have the answer for that problem, but few suggestions.
>>
>> Try to use the command "/gate/application/verbose 2". This will print out
>> the number of EMITTED particles from the source at the end of the
>> acquisition. If this is not the expected one, one has to dig in this
>> direction (in this case that may be a bug), otherwise the problem may be
>> related to the detection process.
>>
>> As the problem disappears at bigger activities or fewer number of runs, I
>> would suspect some kind of rounding error accumulations (if the problem
>> comes from the number of emitted particles) ...
>>
>> Also, are you applying any decay to your source ?
>> What kind of source are you using (backtoback, e+ or ion) ?
>> Apologize for the silly question, but did you change the random seed from
>> a replicate to another ?
>>
>> Regards,
>> Simon
>>
>>
>> On Tue, Mar 11, 2014 at 11:51 PM, Guillem Pratx <pratx at stanford.edu>wrote:
>>
>>> Dear GATE users and developers,
>>>
>>> I have noticed a strange behavior with PET simulations that use low
>>> counts and short time slices. In my set-up, I am simulating a point source
>>> inside the Inveon PET scanner. The activity of the point source is varied
>>> from 1 to 1000 Bq,the total run time is 100 sec, the the time slice is 0.2
>>> s (so 500 slices).
>>>
>>> For 1 Bq, one would expect ~ 7 counts on average but in fact I observed
>>> 23 (average over 250 realizations). For higher activity, the error is
>>> smaller but still statistically significant (see attached plot). The issue
>>> disappears around 1000 Bq or if the number of time slices is reduced to ~
>>> 10 (instead of 500). Note that if the activity of the source is 0 Bq, then
>>> no counts are observed, so this is not a background issue.
>>>
>>> So my question is is there an explanation for this behavior, or could
>>> this be a bug in how counts are generated within each time frame?
>>>
>>> Thank you for your help in solving this issue.
>>>
>>>  Guillem Pratx, PhD
>>> _______________________________________________
>>>
>>>    Assistant Professor Office A247
>>>    Radiation Oncology 1050 Arastradero Rd
>>>    Stanford University  Palo Alto, CA 94304
>>>    http://pratxlab.stanford.edu           (650) 724-9829
>>> _______________________________________________
>>>
>>> <time_slice_bug.png>
>>>
>>> _______________________________________________
>>> Gate-users mailing list
>>> Gate-users at lists.opengatecollaboration.org
>>> http://lists.opengatecollaboration.org/mailman/listinfo/gate-users
>>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20140312/b3ba09d1/attachment-0001.html>