I have been trying validation process. Of NaITl 1" crystal and one 6x6 SiPM. However, I keep having “destorted” data at SiPM readout. I am tracking optical phontons from scintillation process and record all photons which can get via glass from scintillator to the SiPM and then kill them (so any king of backscattering is ruled out). Counting is ended at the end of event, and event consists of one decay of Cs-137. And I am getting somtehing like this: Photopeak is clearly visible, but, where compton edge is, something weird arises. I have been triing to simulate crystal behaviour withou SiPM and recorder all absorbed photon and nothing like this was visible.
I would check the raw energy deposit spectrum in the scintillator independent of the optical photons to rule out whether the problem occurs somewhere else. In addition, one thing to also check is whether what you are seeing is actually the photopeak and not the Compton edge with the photopeak missing. If you are using a steppingAction you can get the creation process using the code below and then print or store to file. The output should be “compt” for a Compton scatter and “phot” for the photoelectric effect being triggered when the 662 keV interacts with the NaI(Tl) crystal.
Pure deposit from gamma particles and scintillation spectra out of it is completely ok. I forgot to mention it in initial quote. The code you have written will not tell wheather photon which comes to SiPM is from “compt” or “phot”. Result of this will be always “Transportation”. Even if you call for GetCreatorProcess() method, result will always be “Scintilation”. To find out, if the scintilation photon is from “comp” or “phot” energy deposit, one has to write specific class for it, I think. I am looking for a little bit less time consuming solution. Funny part is, behaviour like this can be seen only when SiPM is there. RIndexes seem all to be set ok, reflectivity atc. is fine. Sundenly when I add SiPM to the question , this peak arises. I have tought about some backscaterring at first, but it is resolved with killing the track of the particle. Then I tought about angles, but statistically it gives no sense. Any more clues?
Sorry I was not clear with the creator process, that is for checking the incoming gamma photon not the optical photons. It is code that I have used in my scintillation codes for checking processes with and the implementation can be found here.
In terms of other clues, in your material definition for NaI have you played around with the RESOLUTIONSCALE parameter which will alter the number of optical photons generated and smear your result.
To help determine whether there is an issue at the generation of the number of optical photons (which would be related to the physics list etc.) You will need to count how many optical photons are generated per event and cross-check this with the energy deposited per event. An example of how to count them can be found in both the LXe example and OpNovice example stacking actions. If this produces the expected spectra, then you should focus on how the photons are being collected and how you are tallying them. In case you are not killing the photons correctly etc. and leading to multiple counts for lower energy events.
I hope this helps and provides some direction on how to solve.
