<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Dear CASToR users and developers,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>I recently faced a problem while trying to convert the results of a GATE 9.0 simulation that used noise in the digitizer <!--StartFragment-->to <!--StartFragment-->CASToR <!--EndFragment--> LM format. </div><div>(<!--StartFragment-->link to the GATE documentation about noise : <a href="https://opengate.readthedocs.io/en/latest/digitizer_and_detector_modeling.html#noise" data-mce-href="https://opengate.readthedocs.io/en/latest/digitizer_and_detector_modeling.html#noise">https://opengate.readthedocs.io/en/latest/digitizer_and_detector_modeling.html#noise</a>)<!--EndFragment--> <br data-mce-bogus="1"></div><div>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 :</div><div><br data-mce-bogus="1"></div><div> -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<br><br data-mce-bogus="1"></div><div>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 <!--StartFragment-->CASToR <!--EndFragment--> LM no matter the restrictions. However, the number of events written in the <!--StartFragment--> CASToR <!--EndFragment--> LM header will not take into account the unknown events added (l. 2558 of <!--StartFragment-->castor-GATERootToCastor.cc) except when no restrictions are applied<!--EndFragment-->. When a restriction is applied, this will create a difference between the number of events considered as written in the <!--StartFragment-->CASToR <!--EndFragment--> LM header versus the number of events actually written in the <!--StartFragment-->CASToR <!--EndFragment--> 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.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>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.</div></div><div><br data-mce-bogus="1"></div><div> <!--StartFragment--><p class="xmsonormal" style="margin: 0px; background: white none repeat scroll 0% 0%;" data-mce-style="margin: 0px; background: white none repeat scroll 0% 0%;"><br data-mce-bogus="1"></p><!--EndFragment--> Thanking you in advance for your responses,<br>Sincerely, <br></div><div><br data-mce-bogus="1"></div><div data-marker="__SIG_PRE__">Timothée Zaragori, PhD Student<br>Nancyclotep Imaging Platform & IADI (INSERM U1254)<br>CHRU de Nancy Brabois, Rue du Morvan<br>54511 Vandoeuvre-Les-Nancy, France</div></div></body></html>