How to handle GATE noise events?

General Discussions
1

Dear CASToR users and developers,

I recently faced a problem while trying to convert the results of a GATE 9.0 simulation that used noise in the digitizer to CASToR LM format.
(link to the GATE documentation about noise : https://opengate.readthedocs.io/en/latest/digitizer_and_detector_modeling.html#noise)

Noise events will have special values assigned to some root keys such as event_ID that will be set to -2 or values related to Compton/Rayleigh interactions that will be set to -1. Here is an example of such a noise coincidence event :

-1 -2 -1 0.000e+00 0.000e+00 0.000e+00 1.96002948492605288954849e+00 4.799e-01 -3.543e+02 -1.694e+02 5.570e+01 0 1 17 0 2 0 -1 0 -1 0 0.000e+00 0.000e+00 0 16611 0 1.453e+00 -4.481e+01 2.934e+02 1.96002948537939247763973e+00 5.699e-01 3.744e+02 -8.549e+01 7.148e+01 0 8 17 9 3 0 0 0 0 0 0.000e+00 0.000e+00

During the conversion, this event will be classified as an unknown event by the function ComputeKindGATEEvent. With the block checking the restrictions of castor v3.1 (l.2186 of castor-GATERootToCastor.cc), the unknown events will be written to the CASToR LM no matter the restrictions. However, the number of events written in the CASToR LM header will not take into account the unknown events added (l. 2558 of castor-GATERootToCastor.cc) except when no restrictions are applied. When a restriction is applied, this will create a difference between the number of events considered as written in the CASToR LM header versus the number of events actually written in the CASToR LM file resulting in an error when using castor-recon that checks the consistency between the number of events in the header and the length of the LM file.

For my personal use, since I only use true coincidences, I simply added an if block to the block checking the restrictions in order to not write the event in the CASToR LM file if true_only_flag is true. However, I wanted to share with you this case and discuss how these events should be taken into account because I don’t think my solution is the right one.

Thanking you in advance for your responses,
Sincerely,

2

Dear Timothee,

Thank you for noticing this issue, it was definitely an overlook. The problem will arise from coincidence generated from two “noisy” singles. I believe these events should be considered as random events and treated accordingly in the ComputeKindGATEEvent() function. This will be addressed in a future patch.

Thanks again and best regards,
Thibaut