<div dir="ltr"><div><div><div><div>Hi again,<br><br></div>Thank you Guillem for having tested further and reporting the results.<br></div>We will dig on this to find the problem and hopefully a solution.<br><br></div><div>
And about your specific concern, why do you need to use so many time slices ?<br></div><div><br></div>Regards,<br></div>Simon<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 12, 2014 at 5:36 PM, Guillem Pratx <span dir="ltr"><<a href="mailto:pratx@stanford.edu" target="_blank">pratx@stanford.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Simon,<div><br></div><div>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. </div>
<div><br></div><div>I do apply standard 18F decay to my e+ source (see below):</div><div><blockquote type="cite"><div>/gate/source/addSource F18PointSource</div><div>/gate/source/F18PointSource/setActivity 1 becquerel</div>
<div>/gate/source/F18PointSource/gps/particle e+</div><div>/gate/source/F18PointSource/setForcedUnstableFlag true</div><div>/gate/source/F18PointSource/setForcedHalfLife 6586 s</div><div>/gate/source/F18PointSource/gps/energytype Fluor18</div>
<div>/gate/source/F18PointSource/gps/type Point</div><div>/gate/source/F18PointSource/gps/angtype iso</div><div>/gate/source/F18PointSource/gps/centre 0. 0. 0. cm</div><div>/gate/source/F18PointSource/attachTo movpoint</div>
<div>/gate/source/list</div></blockquote></div><div><br></div><div>And yes, I use a list of random seeds (simply 1, 2, 3, … etc.).</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks for your help,</div><div><br></div><div><div class=""><div>
<div style="text-indent:0px;letter-spacing:normal;text-align:start;text-transform:none;white-space:normal;word-wrap:break-word;word-spacing:0px"><div style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;text-transform:none;white-space:normal;font-family:Helvetica;word-wrap:break-word;word-spacing:0px">
Guillem Pratx, PhD<br>_______________________________________________<br><br> Assistant Professor<span style="white-space:pre-wrap"> </span>Office A247<br> Radiation Oncology<span style="white-space:pre-wrap"> </span>1050 Arastradero Rd<br>
Stanford University<span style="white-space:pre-wrap"> </span> Palo Alto, CA 94304<br> <a href="http://pratxlab.stanford.edu" target="_blank">http://pratxlab.stanford.edu</a> (650) 724-9829<br>_______________________________________________</div>
</div>
</div>
<br></div><div><div><div class="h5"><div>On Mar 12, 2014, at 3:13 AM, Simon Stute <<a href="mailto:gate.stute@gmail.com" target="_blank">gate.stute@gmail.com</a>> wrote:</div><br></div></div><blockquote type="cite">
<div><div class="h5"><div dir="ltr"><div><div><div><div><div>Hi Guillem,<br><br></div>I do not have the answer for that problem, but few suggestions.<br><br></div>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.<br>
<br>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) ...<br><br></div>Also, are you applying any decay to your source ?<br></div><div>What kind of source are you using (backtoback, e+ or ion) ?<br></div><div>Apologize for the silly question, but did you change the random seed from a replicate to another ?<br>
</div><div><br></div></div>Regards,<br>Simon<br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Tue, Mar 11, 2014 at 11:51 PM, Guillem Pratx <span dir="ltr"><<a href="mailto:pratx@stanford.edu" target="_blank">pratx@stanford.edu</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5">Dear GATE users and developers,<div><br></div><div>
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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div><div><br></div><div>Thank you for your help in solving this issue.</div>
<div><br></div></div></div><div><div><div class="h5"><div>
<div style="text-indent:0px;letter-spacing:normal;text-align:start;text-transform:none;white-space:normal;word-wrap:break-word;word-spacing:0px"><div style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;text-transform:none;white-space:normal;font-family:Helvetica;word-wrap:break-word;word-spacing:0px">
Guillem Pratx, PhD<br>_______________________________________________<br><br> Assistant Professor<span style="white-space:pre-wrap"> </span>Office A247<br> Radiation Oncology<span style="white-space:pre-wrap"> </span>1050 Arastradero Rd<br>
Stanford University<span style="white-space:pre-wrap"> </span> Palo Alto, CA 94304<br> <a href="http://pratxlab.stanford.edu/" target="_blank">http://pratxlab.stanford.edu</a> (650) 724-9829<br>_______________________________________________</div>
</div>
</div><div><br></div>
</div></div><span><time_slice_bug.png></span></div></div><div class=""><br>_______________________________________________<br>
Gate-users mailing list<br>
<a href="mailto:Gate-users@lists.opengatecollaboration.org" target="_blank">Gate-users@lists.opengatecollaboration.org</a><br>
<a href="http://lists.opengatecollaboration.org/mailman/listinfo/gate-users" target="_blank">http://lists.opengatecollaboration.org/mailman/listinfo/gate-users</a><br></div></blockquote></div><br></div>
</blockquote></div><br></div></div></blockquote></div><br></div>