As I was testing TrackSrim, I noticed some strange behaviors.
The number of electrons created in the track varies wildly for the same type of particle with the same kinetic energy. I produced this behavior by calling NewTrack multiple times and print out the number of electrons produced (another method would be to just call NewTrack once in the program but run the program multiple times). Here are the values that I saw: 6, 56, 7955, 41, 81, 6, 4, 54, 11044, 19.
When the randomEngine.Seed(n) function is used, Garfield++ would print to the screen the seed n that the user had chosen. However, ever since I updated Garfield++ a couple of days ago, I noticed that the seed value (the one printed to the terminal) is stuck at 624 no matter what I change in the program.
The second problem is not so much a TrackSrim problem as I saw that other provided examples (like DriftTube) behave the same way.
I have attached my program to this post. Please let me know if I had done something wrong in my program. Thank you. TrackSrimTest.txt (7.1 KB)
The ā624ā seed value is a TRandom3::GetSeed incompatibility introduced in ROOT 6.24/00.
You can get the backward compatible behavior when you use, e.g.: gRandom->TRandom::GetSeed()
Here is the SRIM file. It is supposed to be for a 10MeV proton traversing isobutane. The default density is a magnitude higher than what I use, so I changed the density inside the code using SetDensity(). Hydrogen in Iso-Butane (ICRU-493) (gas).txt (7.3 KB)
Hi,
Iāve attached a slightly modified version of your program, using a parallel plate geometry without any wires. With that I get more reasonable values for the number of electrons produced along the track.
Iām wondering if the issue could be that the track sometimes hits one of the wires, in which case it will stop. Could you, as a check, switch off straggling? track.EnableTransverseStraggling(false);) test.cpp (2.2 KB)
With transverse straggling turned off, the number of electron pairs is now all in the same order of magnitude, so I think your hypothesis is correct. Can you give me some more details on what the straggling option is? I noticed that with it turned off, the track is now just a straight line. Naively, I would think that this is not realistic? But I am not sure.
Hi,
the table in the SRIM output file includes a column āLateral Stragglingā (see the tutorial āRange statisticsā on the SRIM website for details).
At every step, TrackSrim draws two Gaussian-distributed random numbers (with a Ļ given by the straggling parameter scaled to the step length) and smears the two cluster coordinates transverse to the direction of the track accordingly. If the coordinates happen to be outside of the active area (e. g. inside a wire), then the track is considered stopped.
If the straggling option is switched off, no smearing will be applied and the track will indeed be just a straight line.
Youāre right that neglecting straggling completely is probably not the best approach. On the other hand, with the straggling option switched on (the way itās implemented) we might overestimate the probability that the ion is intercepted by wire. Not sureā¦ If you have a good idea, let me knowā¦