I am trying to reconstruct my data for cylindrical PET system after creating scanner.geom and scanner.cdh files. However, I get an error that my crystal index is out of range as shown below:
iScannerPET::GetPositionsAndOrientations() → Crystal index 1 (-2090952667) out of range [0:5615]
Could you suggest me how do I overcome this issue?
If I am correct, this was a PET simulation and you used the castor-GATERootToCastor conversion program to convert your simulated data into a CASToR datafile ?
I am Sergio, new in Castor. I have exaclty the same problem than Kajal (crystal index out of range) and I would like to know how Kajal fixed the issue.
I might have a solution. However, I do not have time to test it: I stumbled upon this recently and I haven’t taken the time to reproduce correctly for Issue reporting.
In short, in the method ConvertIDcylindrical of gDataConversionUtilities.cc, change “uint8_t layer = 0;” to “uint32_t layer = 0;”. I think the problem arise from the line “layer = layerID;” where layerID is a uint32_t while layer is a uint8_t. I am not sure if it is an error in the code or the compiler, C type casting is kinda far in my memory…
With a little chance, this will resolve your problem! If not, well, good luck!
Hi,
If I remember correctly Kajal used GATE data and had an issue related to a geometry conversion error from mac files, which was solved in a later CASToR version.
However this error message is displayed when a crystal index read from the datafile has a value outside its range defined from the geometry file. It can occur in a variety of contexts, most likely if something went wrong during the CASToR datafile generation/conversion regardless of whether this datafile has been generated from GATE root data (with GateRootToCastor) or manually created.
A first step could be to use castor-datafileExplorer in order to read the content of each event and check what is wrong in the datafile and which fields are affected. Then try to identify where the error comes from depending on how the castor datafiles were generated.
(And thanks Maxime for the remark about the erroneous cast conversion).
I had a similar problem using a generic cylindricalPET, I was not using my pixels in the layer layer0 (apparently is mandatory for a correct index identification) but rather the crystal layer, so my solution was to attach my crystal pixels to the layer0 instead of crystal and adapt the geometry in acordance.