I have been using the Heed to simulate 1,000 tracks and find the initial information for Delta electrons. Whenever I run my code, I realized that the first couple Tracks generated by NewTrack() never seem to act correctly. The information gotten from track->GetElectron() is always 0.000. After that then it seems to run perfectly normal. I was wondering if anyone has encountered a problem similar to this and if so, how to fix it.
Thank you!
Here is the main loop of my code
Hi,
the counter in the for loop over the electrons should start at 0. In other words, you need to replace
for (int iclus = 1; iclus <= nclus; iclus++) {
by
for (int iclus = 0; iclus < nclus; iclus++) {
That worked perfectly.
I am now comparing my results to an article over Electron-Ion Pairs production in a gas. This is the table and a definition of what np and nt are:
In my simulation, I am using a 70/30 Ar/CO2 mix, meaning:
Np = (0.7 * 23) + (0.3 * 35.5) = 26.75 primary electrons per cm
Nt = (0.7 * 94) + (0.3 * 91) = 93.1 initialized electrons per cm
I am using a single gem sensor that is .2cm in the z-direction. I am simulating a -mu particle going straight down through the sensor with DisableDeltaElectronTransport turned on. I should be aiming for:
5.35 primary electrons
18.62 initialized electrons
When I simulated 1,000 tracks I got an Average of
5.822 primary electrons per track
22.97 gain per primary electron
139 total electrons avalanched per track
I was wondering if these values seemed a little bit high or not? Whenever I call track->GetClusterDensity() for this simulation. It returns 28.18 clusters/cm (and some clusters have 2 primary electrons) which is higher than the 26.75 that the table calls for. In addition I was also wondering if there was a similar function as Track->GetCusterDensity for the Avalanche?
Hi,
sorry, I’m a bit lost. How do you calculate the equivalent of nt in your simulation?
Also I’m not sure what’s the definition of nt used in the table. I guess it’s the most probable value of the distribution of electron-ion pairs produced along the track? The mean of this distribution is not very well defined because of the long tail towards large energy losses.
I am so sorry, I thought that snippet had the definition of nt include. Ill attach it here:
In this simulation I have DisableDeltaElectronTransport() included. With that now being said, would nt represent the number of gain for each primary electron avalached, or would it represent the number of primary/secondary electrons produced by a track when DisableDeltaElectronTransport() is excluded?
Whenever I have DisableDeltaElectronTransport() excluded, it returns around 12 primary/secondary electrons produced per track, which is a lot lower than the 18.62 expected if its that way.
To my understanding, nt is the total number of electron-ion pairs produced by a charged-particle (including the secondary electrons produced by delta electrons and Auger electrons). So it should correspond to what you get from Heed when you enable delta electron transport. This number will fluctuate from track to track though, following a Landau-like distribution. I assume (although it doesn’t seem to be stated explicitly) that the number in your table corresponds to the most probable value of this distribution.
It’s also worth mentioning that this distribution will depend to some extent on your geometry. If your detector is small, there will be a significant chance that the higher energetic delta electrons will leave the active area before having lost all of their energy.
Ok that makes since. The table said it was for the minimum ionizing particles. I tested sending a particle through the detector with different momentums. I attached a graph that shows the number of primary and secondary electrons produced. I think I was just confused with the term “minimum ionizing particles” could this be inferred by were the least primary and secondary particles are produced, or do I need to look at the energy loss per cluster and sum them up for the track?
Also here is the article. The graph is on the 3rd page and the information about it is right above it on the second.
Wikipedia → minimum ionizing particle (MIP, mip, m.i.p.)
Uncle Google → minimum ionizing particle
So, shoot some moderately relativistic charged particle (other than an electron) with 3 <= beta * gamma <= 4 (e.g., beta * gamma = 3.5, so the momentum = 0.37 GeV for muon, 0.49 GeV for charged pion, 3.3 GeV for proton).
Note that the assumption is that the total energy loss in your detector is small enough that the particle can still be considered a MIP (e.g., beta * gamma >= 3, so the momentum >= 0.31 GeV for muon, 0.41 GeV for charged pion, 2.8 GeV for proton).
@hschindl I set the momentum to 0.37 GeV and shot through a muon down through a triple gem detector (.7cm total z height) 1000 times. It produced 19.4 primary electrons when DisableDeltaElectronTranspot() was turned on, and 41.44 primary and secondary electrons when DisableDeltaElectronTranspot() was turned off.
In my simulation, I am using a 70/30 Ar/CO2 mix and GetClusterDensity() returns 28.18 clusters/cm.
I realized that when I avalanched the electrons produced by tracks, the total number of electrons avalanched per track didn’t seem to change when DisableDeltaElectronTranspot() was turned off or on.
So does DisableDeltaElectronTransport() not really change the final results of an avalanche, it just gets rid of the secondary electrons when getcluster() is called?
Sorry, I saw your message only just now.
I assume you are using AvalancheMicroscopic to simulate the electron avalanches?
For a given starting point, the average number of electrons produced in the avalanche will only depend on the energy of the initial/seed electron. If you activate delta electron transport, TrackHeed will return low-energy “conduction” electrons. When you disable delta electron transport, TrackHeed returns the “primary” electrons knocked out by the primary charged particle and the subsequent Auger electrons (if any). These have a tail towards high energies.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
