Hello!
I have a question regarding the simulation of radioactive sources. When I used Co-60 as a source for my simulation, I got a strange detector signal. So i wanted to get to the bottom of it step by step, starting with the energy of emitted particles from my source. Via MCTrack → getKineticEnergyInitial() I got the initial energy of the particles, which I filtered for electrons (pdgID=11). The resulting histogram looks like this:
Sorry that the labeling is in german. I know that the energies of secondary electrons (very low energies) are also displayed, as these have a new track. However, I didn’t know any other way to get the initial energy of only the primaries. Maybe someone can help me with this too.
The spectrum of the main beta decay has a maximum energy of 317 keV. Here it is about 180 keV. The energy spectrum of the gammas, on the other hand, looks very good with the two typical gamma lines at 1.17 MeV and 1.33 MeV.
I have the same problem with the beta spectrum in the simulation of Sr90. Does anyone have an idea what might be the root cause of this problem?
Here is a part from my config file (can’t upload the file). I didn’t know exactly what to set for the cutoff_time in DepositonGeant4. So I left the value at the default of 221s. Maybe this is the problem.
[GeometryBuilderGeant4]
world_material = “vacuum”
[DepositionGeant4]
physics_list = QGSP_BIC
particle_type = “Co60”
source_energy = 0MeV
source_position = 0 0 -15cm
source_type = “point”
cutoff_time = 221s
max_step_length = 1um
number_of_particles = 1
[ElectricFieldReader]
model=“linear”
bias_voltage = -100V
depletion_voltage = -50V
[GenericPropagation]
type= “diode_new”
temperature = 293.15K
charge_per_step = 100
integration_time= 25ns
[SimpleTransfer]
max_depth_distance = 300um
Best,
Mathis
Hi @mathisbrae ,
thanks for posting your question here!
- You can filter the
MCTrack objects by their creation process, either via getCreationProcessName() or getCreationProcessType(), see the [code referencehttps://allpix-squared.docs.cern.ch/reference/classes/classallpix_1_1mctrack/). I don’t remember from the top of my head what the name you’d be looking for, but you the process names are human readable, so if you print a few of them or look in the TBrowser (MCTrack → origin_g4_process_name → data) you should be able to figure it out.
- Your configuration looks ok to me, so for now I do not know where the difference would be coming from. Depending on what you’re about to study, it could be worth to switch on
record_all_tracks = true in the DepositionGeant4 module, such that also tracks are recorded and stored that do not leave a signal in the detector. This would increase statistics for your plot and maybe remove a bias.
Cheers
Paul
Hi @mathisbrae ,
I looked into the simulation a bit.
- The additional electrons indeed look odd. There’s an additional decay channel, but I’m not sure why this would lead to more electrons being produced. Interestingly, it seems like there’s never 2 or 3 electrons being produced per event, but >3 is possible. What I also see from the printout is that this happens instead of one photon being released in the de-excitation steps. However, this is a pure Geant4 issue, I’m afraid there’s not much we can do.
- I cannot reproduce the energy spectrum you’re showing. My beta spectrum, determined as the initial kinetic energies of electrons with creation process name “Radioactivation” looks as shown below, ending at around the expected 317 keV.
Would you mind uploading or pasting your analysis file? Maybe there’s an issue there.
Cheers
Paul
Hi @pschutze,
of course I can upload it. I use python to do the anaylsis. Unfortunately, as a new member, I cannot upload any files apart from pictures. Then I could have sent my root file as well.
I think the main problem was the non-logarithmic y-axis. But it still looks different in width and height. These are also 100000 events.
Do you have any ideas on how to speed up this evaluation? This was a 5GB root file and took about 30 minutes. I have already waited 3 hours for larger root files. That seems pretty long to me.
Cheers
Mathis
This is the result of the script
Even when reproducing your analysis script (to most extents), I get the spectrum we would expect and the same I posted above. See below. It also seems like it’s not a problem of scaling per se, because the two higher bins around 1.2-1.3 MeV are similar for your and my plot.
Hence, I believe that the issue is in the simulation. I don’t have much time to test whether it has an effect, but what I recommend is to switch on the record_all_tracks parameter for the DepositionGeant4 at least for testing purposes and see whether this makes a difference.
Concerning the time: I think that exactly the file size is the issue why the analysis takes so long. When you store data in ROOT files, you can select which objects should be written via the include or exclude parameter. Try to switch things off that you do not need for the analysis. E.g. in this case, for just looking at the MCTracks I only stored MCTracks (actually I ran the allpix squared simulation only until DepositionGeant4) and thus I can analyse 100kEvents quite quickly (< 1 minute). But down the line, if you have to store all objects for the rest of the post-processing, I suggest moving to C(++), which is just way more performant.
Cheers
Paul
1 Like
I have now run another simulation (100.000 Events) with the following parameters. I think that only the parameters of DepositionGeant4 should play a role here, or am I wrong?
[DepositionGeant4]
physics_list = QGSP_BIC
particle_type = “Co60”
source_energy = 0MeV
source_position = 0 0 -15cm
source_type = “point”
max_step_length = 1um
number_of_particles = 1
record_all_tracks = true
Unfortunately, the spectrum still looks like the one i post above.
Maybe you could share your config, then I can compare it.
By the way, i use the Allpix version v3.1.0, which i source via /cvmfs/clicdp.cern.ch/software/allpix-squared/latest/x86_64-el9-gcc12-opt/setup.sh.
Cheers
Mathis
