<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Simon,<div><br></div><div>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.</div><div><br></div><div>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. </div><div><br><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Guillem Pratx, PhD<br>_______________________________________________<br><br> Assistant Professor<span class="Apple-tab-span" style="white-space: pre;"> </span>Office A247<br> Radiation Oncology<span class="Apple-tab-span" style="white-space: pre;"> </span>1050 Arastradero Rd<br> Stanford University<span class="Apple-tab-span" style="white-space: pre;"> </span> Palo Alto, CA 94304<br> <a href="http://pratxlab.stanford.edu">http://pratxlab.stanford.edu</a> (650) 724-9829<br>_______________________________________________</div></div>
</div>
<br><div><div>On Mar 12, 2014, at 9:45 AM, Simon Stute <<a href="mailto:gate.stute@gmail.com">gate.stute@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Obviously, you just move the source... Sorry !<br>Simon<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 12, 2014 at 5:43 PM, Simon Stute <span dir="ltr"><<a href="mailto:gate.stute@gmail.com" target="_blank">gate.stute@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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="HOEnZb"><div class="h5"><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><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>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><blockquote type="cite">
<div><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 class="gmail_extra"><br><br><div class="gmail_quote"><div>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><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>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 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><span><time_slice_bug.png></span></div></div><div><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>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></body></html>