Dear Allpix2 devs,
I have been doing some comparative studies of strip detector simulations with and without the charge induction effect implemented in the TransientPropagation and InducedTransfer modules. I am mostly interested in distributions of collected charge on individual strips and in these I see differences which I have trouble understanding.
I’m using Allpix2 version v1.5.0+410^gbe33ac51. I fired 1000 5.8GeV electrons (1 particle per event) perpendicularly into the sensor. With the TransientPropagation and InducedTransfer modules in use I see 13% less overall charge in the PixelCharge output than with the GenericPropagation and SimpleTransfer combination. Since both simulation runs used the same random_seed, the total deposited charge should in both cases be the same and the 13% must have disappeared either during the propagation or the transfer step. However I don’t understand why this is happening.
I’m not sure the other major difference is an indication of a problem, nevertheless I would like to check if this makes sense to you. There is a very significant increase in the amount of low-charge entries (<4000e) in the distribution when the TransientPropagation and InducedTransfer modules are used. I guess this is because the Shockley-Ramo effect induces a lot of small charges on strips which are further away from the propagating charge carrier? But with the induction_matrix being by default set to 3, I am surprised by how big this increase is.
Some additional info about the fields, the electric one was created for a single-strip cell (75.5 um wide). The weighting field was made for a two-strip cell with the principal strip at the edge, I mirrored it to make it symmetrical around the principal strip, so it now spans four strips (302 um wide). I attached both the field init files to this post (I just changed the extension from .init to .conf to be able to upload it).
Thanks for any help or advice you can offer,
Radek.
main.conf (1018 Bytes)
geometry.conf (60 Bytes)
atlas17.conf (225 Bytes)
fieldW.conf (1.7 MB) fieldE.conf (288.9 KB)
Hi @rprivara
thanks a lot for the very comprehensive description of your question as well as the configuration files - this made it very easy for me to re-run your simulation and to recreate the issue.
Before coming to your actual question, let me dive into one nice feature we have in the framework: the possibility to name messages at in- and output of each module. With this feature you can run the two simulations you were comparing in parallel as shown below (omitting other parameters and modules):
# Without Shockley-Ramo
[GenericPropagation]
output = noramo
[SimpleTransfer]
input = noramo
output = noramo
[DefaultDigitizer]
input = noramo
# For Shockley-Ramo
[TransientPropagation]
output = ramo
[PulseTransfer]
input = ramo
output = ramo
[DefaultDigitizer]
input = ramo
This will create two different trees in your output file, names dut_ramo and dut_noramo with the two simulation chains.
One more thing I noticed is your use of the InducedTransfer module, which is probably fine for what you are looking at currently - but it is a simplification more meant for being used together with GenericPropagation. It Just counts charge carriers at the electrodes and then calculates additionally induced currents from charge carriers still “in flight”. Since you are using TransientPropagation I would recommend using PulseTransfer to really generate the proper currents in the front-end channels.
Now to your question: I would think that the effect you see is actually physical. you might have noticed that you have about 3x the statistics in the version with Ramo-Shockley - which is consistent with additional strips with very small charge being present owing to the induction via the weighting potential.
When zooming in and overlaying the two distributions I see a peak of similar height at your expected MIP energy, in addition, the Ramo-Shockley version (here in black) has an additional, more pronounced peak for double-strip clusters (shared) and many more very tiny contributions.
I guess to fully conclusively understand the matter, you should perform clustering and then compare the two simulations based on the cluster charge, e.g. by placing the [DetectorHistogrammer] module at the end of your simulation chain (unfortunately currently doesn’t work with the I/O trick mentioned above).
Let me know if this helps!
/Simon
Hi Simon,
thanks a lot for your analysis of the issue. Also thanks for letting me know about the input/output feature, that will be very handy in any future comparative simulations.
I will make sure to use the PulseTransfer module in the future, as you suggested. I reran the simulations with it, just to be sure, but there was no difference to the results I was looking at.
Looking at the cluster_charge histograms in DetectorHistogrammer output, I see a very similar plot to what you posted (again Ramo in black) and I agree with your conclusions about why the central part looks like it does. What confuses me is the peak on the very left in the Ramo version, which suggests a fairly high amount of events (~12%) where a cluster with small charge was created and I can’t figure out how this came to be.
My reasoning could be wrong here, but as I see it the Shockley-Ramo will always induce charges “continuously” around the central strip, it shouldn’t be able to induce charge in a strip isolated from the primary cluster (except I guess for a very weird weighting field). For induction_matrix set to 3,3 any induced charge should be either in the primary strip or in an adjacent one and that should only affect the cluster size, not the number of clusters in that event. And I do see about 120 more entries in the Shockley-Ramo cluster_charge histogram, which corresponds to the 12% of events with a small-charge cluster. Am I missing something important here?
Thanks a lot,
Radek
Hi @rprivara
sorry for the late response, I have looked at this again, trying to find out if we’re looking at physics or a bug. 
I can reproduce exactly what you posted above, after clustering I get a distribution with some low-charge clusters:
I have checked some things like that using an induction_matrix = 3, 3 does not have an effect when having only one “pixel” in x (no effect) and a few related things. What I noticed is the rather odd residual distribution in y, being compatible with the central strips going undetected:
I fear we will have to look at this event-by-event to find out if something is going wrong. If you found anything, please let me know!
Cheers,
Simon
