Potential Coincidence Sorter Bug

[MrTzschr]

Hi, I get very strange results from my PET simulation and I am not sure if this is a bug. The setup is quite simple: cylindricalPET with a point source and without any phantom, 4 ns time window of coincidences. My backtoback source is emitting 1 Bq activity over a time slice length of 1e8 s (very low activity to keep the number of randoms as low as possible).

Looking at the coincidences I can see:

1. a drop in the number of coincidences over time to approx. 1/2 of the previous magnitude, happening roughly at 3.6e7 s and
2. that after a point in time no coincidences are found at all, happening at approx. 7.2e7 s.

Especially point 2) indicates that no coincidences at all are generated from 7.2e7 to 1.e8 s. The drop is also visible if looking at "eventID1" and "eventID2" but I assume this is a consequence of the drop and not the reason.

Checking the singles shows that the simulation works as expected, so I get a homogeneous emission without any drops over the whole measurement time. Meaning the coincidence sorting seems broken. In a second attempt I halved the simulation time and doubled the activity: 5e7 s with 2 Bq. Here I do see the same drop after the same amount of time: 3.6e7 s.

I also checked what happens if I split the simulation into several runs but this does not help at all, as the time stamps are not resetted for each run, only the event id's.

Performing the same simulation using setTotalNumberOfPrimaries works fine, so no drop in the number of coincidences formed over time. But here all events are emitted in the time window from 0 to 1 s, which significantly increases the number of randoms generated.

The same behavior can be seen for the second coincidence sorter method: /gate/digitizer/Coincidences/allPulseOpenCoincGate true I attached an image showing the different time histograms for singles and coincidences in the 1 Bq and the 2 Bq case as well as my simulation macro. I would like to understand what's happening here as this makes longer simulations unreliable. Any help is appreciated.

A suggestion on the mailing list was to modify the presort buffer size, e.g. /gate/digitizer/Coincidences/setPresortBufferSize 32 but this does not change anything. And I assume that this should modify a few events but not something in the range of 2.8e7.

From the comparison of using the setTotalNumberOfPrimaries approach (which works fine) vs. the time slice approach (which seems broken) I assume that somewhere in the code something related to the time stamps does not work as it should.

Here is the macro I used for my simulations: main.txt

Maybe someone has an advice?

[dsarrut]

Hello, strange ... No time to investigate right now, but please could you try with PR #267 to see if it changes something? We will look at it asap

[MrTzschr]

hey @dsarrut, thanks for your suggestion. Sadly PR #267 does not resolve the issue, maybe some small changes but nothing obvious but this PR is quite complex.

[dsarrut]

bug confirmed ... Can you please test with slightly different parameters for the coinc sorter? It seems that I don't have the bug with : /gate/digitizer/Coincidences/setInputName Singles /gate/digitizer/Coincidences/setWindow 2.0115 ns /gate/digitizer/Coincidences/minSectorDifference 5 /gate/digitizer/Coincidences/MultiplesPolicy takeAllGoods /gate/digitizer/Coincidences/allPulseOpenCoincGate true (To be confirmed)

[MrTzschr]

I tested the suggested parameters @dsarrut: once with my 4 ns time window and also with your 2.0115 ns out of curiosity. The results look like this: Keep in mind that the simulation time was 10^8 s, so the maximum value of the x-axis of this histogram should be 100x10^6. So for the 4 ns case it is the same behavior as before with the drop after 3.6x10^7 s and a second drop to zero after 7.2x10^7 s. For the 2 ns case the drop appears at the same time of 3.6x10^7 s but drops directly to zero, so nothing happens afterwards at all. I also confirmed this by looking at the actual number of coincidences.

[dsarrut]

ok thanks! At least we know it is related to the window width ;)

Cannot look at it right now. It is probably somewhere related to https://github.com/OpenGATE/Gate/blob/develop/source/digits_hits/src/GateCoincidenceSorter.cc

Hopefully next week. If you find anything in the meantime let us know.

[dsarrut]

Hello, I investigated but cannot figure out what happens. I asked Jared (the author of the last version of the CoincSorter). It may be related to floating number precision issue. The simulation time is stored in ns, so the nb of ns since the beginning of the simulation is in the order of 1e16, close to the precision limit (~16 digits) and close to the time windows precision ... Not fully clear yet.

As a workaround, with increase activity 100Bq (and decrease time duration), it seems to work.

Cannot do more on that atm.