Particle incidence direction

Dear Developers,

I have set the particle to be incident vertically on the detector at coordinates 8950.I exported the particle information and found hits in other locations as well, as shown here

Is this normal? Is it necessary to artificially ignore such particles?


Hi @Bail ,

would you mind providing us with your configuration files? It would make it easier for us to look into this.


Hi @pschutze @Bail ,

I have been aware of this issue as well (although it never affected my work). If you wish to recreate it, a simple config file like,

log_level = "WARNING"
log_format = "DEFAULT"
detectors_file = "Setup.conf"
number_of_events = 50000

world_material = "vacuum"

physics_list = FTFP_BERT_LIV
particle_type = "proton"
source_energy = 120GeV
source_position = 0 0 -2mm
source_type = "beam"
beam_size = 1mm
beam_direction = 0 0 1
number_of_particles = 1
max_step_length = 1um

model = "linear"
bias_voltage = -300V
depletion_voltage = -60V

temperature = 293.15K
charge_per_step = 100

max_depth_distance = 5um

electronics_noise = 0e
gain = 1
gain_smearing = 0
qdc_resolution = 20
qdc_smearing = 0
qdc_slope = 1
qdc_offset = 0
allow_zero_qdc = 1
threshold = 1000e
threshold_smearing = 0e

file_name = "data.root"	
include = PixelHit, MCParticle


type = "cmsp1"
position = 0 0 0
orientation_mode = xyz
orientation = 0deg 0deg +0deg

should be able to replicate the issue. By checking with a quick script, I got a lot of events like the ones @Bail posted. For example,

Particle ID: 2212
Local Start Position: (5.13,3.23679,-0.1425) mm
Local End Position: (5.13,3.23679,0.1425) mm
Particle ID: 2112
Local Start Position: (5.41949,4.61172,0.1425) mm
Local End Position: (5.52986,5.13589,-0.1425) mm
Particle ID: 2112
Local Start Position: (5.61519,3.19681,0.1425) mm
Local End Position: (5.80016,3.18157,-0.1425) mm

where the “*” characters separate a single event in the data.root default output ROOT file.



Hi @Andrew @Bail

thanks for the report and the sample config - I tried to reproduce the issue, for simplicity with the TextWriter module, but cannot find similar events to what you are reporting. From time to time I do see multiple particles, but these are of different type than the initial proton and are compatible with delta electrons produced in the sensor:

=== 56 ===
--- Printing MCParticle information (0x7f4558529b20) --------------------
Particle type (PDG ID):    2212
Local start point:          3.54106  mm |   3.84251  mm |   -0.1425 mm  
Local end point:            3.54106  mm |   3.84251  mm |    0.1425 mm  
Linked parent:           <nullptr>

--- Printing MCParticle information (0x7f4558529c08) --------------------
Particle type (PDG ID):      11
Local start point:          3.54106  mm |   3.84251  mm |-0.0646016 mm  
Local end point:            3.54304  mm |   3.83963  mm |-0.0561327 mm  
Linked parent:           0x7f4558529b20

However, seeing multiple primary particles is not something that has happened to me. Would you mind sharing the script you used to pull out the information from the ROOT tree, @Andrew ?


1 Like

Hi @simonspa

I am on it right now, give me a little time and I will share the git repository I used to recreate the issue.



1 Like

Hi @simonspa ,

The link for the git repository is: Andreas Mastronikolis / Debug · GitLab. The setup is for CVMFS but you can change the rootlogon.C and _OBJECTS_PATH_ preprocessor variable in debugger.cpp appropriately, in case you are working from a local installation. I also forgot to say, that I am working with version 2.0.3. Let me know if you have any issues.



PS: Ignore the really bad/unrealistic parameters in [DefaultDigitizer] module. They do not affect the issue, since we are looking into the vector that contains MCParticle* (independent of PixelHit* ones) objects.

Hi @Andrew

thanks for the code to debug this, with a tiny extension we were able to track down what this is:

diff --git a/debugger.cpp b/debugger.cpp
index e106226..7ac398f 100644
--- a/debugger.cpp
+++ b/debugger.cpp
@@ -52,13 +56,13 @@ int debugger()
                                int count = 0;
                                for (auto &mcparticle : MCParticles)
-                                       if (mcparticle->getParticleID() == 2112) {count++;}
+                                       if (mcparticle->getParticleID() == 2212) {count++;}
                                if (count >= 2)
                                        std::cout << "*****************************************" << std::endl;
-                                       std::cout << "Protons Found: " << count << std::endl;
+                                       std::cout << "Protons Found: " << count << " evt " << evt+1 << std::endl;
                                        for (auto& mcparticle : MCParticles)

This gives us the event ID of a given event where the issue appears, e.g.:

Protons Found: 2 evt 9028

Particle ID: 2212
Local Start Position: (4.88646,4.12467,-0.1425) mm
Local End Position: (4.88647,4.12467,0.1425) mm
Self: 0x55f343bcdd30
Parent: 0

Particle ID: 2212
Local Start Position: (5.87754,4.04292,0.1425) mm
Local End Position: (6.05043,4.03337,-0.1425) mm
Self: 0x55f343ef8840
Parent: 0x55f343bcdd30

Now, knowing the initial random seed as well as the event ID, we can single out that one event and just run exactly that:

allpix -c Main.conf -o random_seed=8156334119563125231 -o skip_events=9027 -o number_of_events=1

Here, we configure the fixed starting seed, skip all events until the one in question, and then just run one. Now adding VisualizationGeant4 as a module, we can have a look at the event:

Or, in side view, with primary proton incident from the left:

So the situation is as follows:

  • Initial proton incident from the left, crosses sensor and interacts with silicon
  • After crossing, it undergoes a nuclear interaction with the PCB material behind the sensor, with lots of secondaries backscattering
  • Some of these secondaries hit the sensor again, crossing from topside-to-backside (initial positive z axis, exiting at negative z, creating the other particles (protons) which are linked to the initial one.

While the physics here is sane, the linking between the particles (i.e. the cseondary being linked to the initial proton) is somewhat unexpected because we should treat every particle that has been created outside the sensor as a primary - which we clearly fail to do here.

We’ll have a look at how to solve this properly… Thanks a lot!


1 Like

Hi @simonspa ,

It’s nice to see that the problem is understood now :slight_smile: and thanks for the nice explanation (also, the allpix -c Main.conf -o random_seed=... is a really nice debugging tool). Bear also in mind that this also happens without support as well, i.e. with a model called test as

type = "hybrid"

number_of_pixels = 800 200
pixel_size = 25um 100um

sensor_thickness = 150um
sensor_excess_direction = 0.0mm 0.0mm 0.6um 0.6um 
bump_sphere_radius = 9.0um
bump_cylinder_radius = 7.0um
bump_height = 20.0um
bump_offset = 0.0um 0.0um
chip_thickness = 400um

we still have interesting events like the ones shown above; I guess there is also backscattering there, but it happens elsewhere (I should check where).



Hi @Andrew

very likely in the readout ASIC or the bump bonds. You can cross-check this by switching to a monolithic model and setting the chip_thickness = 0. You will still have secondaries, but then only the ones that should actually have a link because they were created in the sensor.


Hi @pschutze ,

Thank you for the great answers! I had the same problem as @Andrew showed, but when I counted the amount of charge collected per pixel it had an effect on the results because the pixel at an unexpected location split the charge.


Suggested fix: Fix #228: force parent ID to zero if particle was not created in current sensor volume (!695) · Merge requests · Allpix Squared / Allpix Squared

1 Like