Tiny number of electrons produce by TrackSrim

Hi,

As I was testing TrackSrim, I noticed some strange behaviors.

  1. 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.

  2. 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()

1 Like

Thanks a lot!

Hi,
can you send/attach the SRIM file that youā€™ve used for the test?

Hi,

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)

Hi,

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ā€¦

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.