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

[Guillem Pratx]

Hi Simon,

Yes, the source is moving and therefore it is good to have >100 slices for smooth motion. Most time slices should have 0 decay events, but somehow GATE (or GEANT4) is systematically overestimating the number of slices that should be getting positron decays. Since the expected number of positron decays in a time slice is equal to activity * time slice duration, there must be a round-off error at that level, since the error goes away if activity or time slice duration is large.

A quick workaround would be to randomly remove events from the Coincidence file to correct the number of decays (on average). I think I’ll do that until a better fix can be found. 

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 9:45 AM, Simon Stute <gate.stute at gmail.com> wrote:

> 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/91c42357/attachment.html>