Output data recently when I found a problem, I will I want to detect objects defined as SD, and then in CalorimeterSD: : ProcessHits by step extraction of the particle’s position information and energy deposition.
But when I look at my output file, I find that my output file will count different energy deposits at the same coordinate, such as this data.
Thank you for your reply, I am using a 26cm26cm26cm tank that emits I125 particles. I defined this tank as SD. i did not set a step limit. I’m just wondering if the data I’m extracting is reasonable, i.e., would using /run/beamOn 1 result in this situation of different energy deposits at the same location?
What energy, position, and momentum direction does the initial I-125 ion have? A low energy heavy nucleus in a dense medium won’t travel very far, so, depending on the units these numbers have (meters?), they may not actually be the same as the output looks truncated to 6 significant figures?).
/gps/ion 53 125
/gps/pos/centre 0 0 0
/gps/pos/rot1 1 0 0
#/gps/pos/rot2 0 1 0
/gps/pos/radius 2.0 mm
/gps/pos/inner_radius 1.5 mm
I’m not defines the initial energy of the I - 125, I define a physical process: RegisterPhysics (new G4RadioactiveDecayPhysics ()). And then through this physical process I-125 will produce overdecay, and I’m collecting the energy deposition in the tank from the particles generated during the decay process. This program is based on the B4c example, I do not know if B4c has defined truncation
Given what I’d guess is an at rest or extremely low energy nucleus, I don’t see any obvious issue with the numbers, though without knowing the exact particles these correspond to I can’t make a hard judgment.
I’d suggest running with more verbose tracking, e.g. in a macro or interactively use the command
to log to the terminal detailed information about the step, particle and processes. That’s best for exploratory runs, and you might want to set the number of threads to 1, or see: