[gate-users] small bug about coincidence sorter

[yuxuan.zhang at di.mdacc.tmc.edu]

hi,

Recently I've written another coincidence sorting program from the ASCII 
output
of the singles.dat file because I need
get some other information that GATE coincidence sorter can not provide. 
After I finished the program, I compared the results from my program and 
the
results from GATE, then I noticed thare were some differences between 
them.
Especially under the high activity condition (large amount of random 
coincidence).
For example, with one model, using GATE output of the coincidences are:

 Total  True   Random   Scatter   NECR
 21761  4014    15056      2691    740

the output from my program:

 Total  Ture    Random   Scatter  NECR
 22600  4011     15833      2756   712

Though the differences of the NECR is only 3%~4%, but still I wanted to 
find out the causes.

After I compared each event that was different in these two outputs and 
checked the original
singles data file, I found out in which condition this will happen.

Usually there are two kinds of situation:

example 1, there are some enevts in the single events list:

ID_of_enevt     Time_Stamp 
8243            4.42524487908583266e-05
8249            4.42824325537103663e-05
8250            4.42823796782774862e-05
8257            4.43126886297442500e-05

in this case, if we set the timewindow as 10 ns, event 8249 and 8250 
should be a coincidence,
but from the GATE output, there's no this coincidence.

example 2, for these events:

10593           5.66959683503792577e-05 
10595           5.66958859230306874e-05 
10595           5.66959047255570771e-05 
10610           5.67960969563888841e-05 

there are three events 10593, 10595 and 10595  in the timewindow, 
according the sorting criterion,
if there are more 2 events within the timewindow, all these events should 
be rejected. However, 
GATE program give a coincidence for 10595 and 10595.

So we can see that in both cases, the sequence of the events appears in 
the singles data file is not
exactly according to the time that the events was detected (time_stamp). 
Sometimes, a single event with
a larger time_stamp (later one) can be in front of another event with a 
smaller time_stamp
(early one). It seems that when this happans, the GATE sorting program 
just ignores the first
events. 

Hope this bug can be fixed in the next generation of GATE. And then GATE 
will provide more accurate results.



Yuxuan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20050721/b57c59bd/attachment.htm>