Charge propagation problem

Dear allpix2 developers,

When I choose fixed MIP as source particle, hitting the sensor at different position vertically, the plots in the GenericPropagtion which shows the charge carriers moving path and the final transfered charge to the strip are not matched. See plots below,


This is when MIP hit to the strip center, holes are collected by the implant. Theoretically the charge should be mostly collected by single strip, but when I check the output, charge are equally distributed to two strips:

=== 1 ===
--- mydetector ---

--- Printing MCParticle information (0x22160c0) -------------------------
Particle type (PDG ID):      -1
Local start point:               10  mm |    10.062  mm |     -0.15 mm  
Global start point:              10  mm |   -37.938  mm |     -0.15 mm  
Local end point:                 10  mm |    10.062  mm |      0.15 mm  
Global end point:                10  mm |   -37.938  mm |      0.15 mm  
Linked parent:           <nullptr>
Linked track:            <nullptr>
-------------------------------------------------------------------------

--- mydetector ---
--- Pixel charge information
Pixel: (0, 80)
Charge: 8945 e
Local Position: (0, 10, -0.15) mm
Global Position: (0, -38, -0.15) mm

--- Pixel charge information
Pixel: (0, 81)
Charge: 8325 e
Local Position: (0, 10.125, -0.15) mm
Global Position: (0, -37.875, -0.15) mm

As a comparison, where is when MIP hitting at the strip edge, charge carriers(holes) are moving to two adjescent strips,


while in the output file, charges are mostly collected by single strip:

=== 1 ===
--- mydetector ---

--- Printing MCParticle information (0x36ae190) -------------------------
Particle type (PDG ID):      -1
Local start point:               10  mm |        10  mm |     -0.15 mm  
Global start point:              10  mm |       -38  mm |     -0.15 mm  
Local end point:                 10  mm |        10  mm |      0.15 mm  
Global end point:                10  mm |       -38  mm |      0.15 mm  
Linked parent:           <nullptr>
Linked track:            <nullptr>
-------------------------------------------------------------------------

--- mydetector ---
--- Pixel charge information
Pixel: (0, 79)
Charge: 140 e
Local Position: (0, 9.875, -0.15) mm
Global Position: (0, -38.125, -0.15) mm

--- Pixel charge information
Pixel: (0, 80)
Charge: 19740 e
Local Position: (0, 10, -0.15) mm
Global Position: (0, -38, -0.15) mm

--- Pixel charge information
Pixel: (0, 81)
Charge: 180 e
Local Position: (0, 10.125, -0.15) mm
Global Position: (0, -37.875, -0.15) mm

The non-linear electric fields used in this job are generated by TCAD software:

The charge transfering behaviors really make me confused.

Hi @wangsh

Wow, this looks really odd - esoecially since one should just be a graphical representation of the other…
Where exactly do you shoot into the sensor? Does this rather correspond to the line graph or the output?

Cheers,
Simon

Dear @simonspa

In the first scenario, I defined the shoot position is position = 10mm 10062um 0um, it can be conformed in the text output. And for the line graph, since the sensor’s pitch is 125um, the coordinate y= 10062um is agree with the pixel 81.5.
So the 2nd scenario is the same.

Cheers,
Shen

Dear @simonspa ,

Have you figure out the problem I post above? Now I meet a new problem, when I try to simulate the energy loss performance in the silicon sesnor, the results are not what I expected. The sensor is P-in-N type and the beam particle is 100GeV muon. See plot below,
image
It’s a beautiful landau, but the MPV is about 16500e-. Much less than 22500e-. Then I change the TCAD efield direction to simulate N-in-P sensor, it looks alright,
image
The modules I used are GenericPropagation and SimpleTransfer.
Dose this because holes mobility is about 3 times less then electrons, so less holes will drift to electrode? Or did I forget something?

Cheers,
Shen

Hi @wangsh,

in a 300 um thick sensor, it might well be that not all holes are collected within the integration_time of the GenericPropagation, which defaults to 25 ns. You can verify this by increasing the integration time and check whether you collect the expected 22 ke.

Cheers
Paul

Dear @pschutze ,

Thanks for your reply, it solved my problem!

Shen

Hi @wangsh,

I’m glad to hear that!

Cheers
Paul

Hi @wangsh

coming back to your initial problem with the offset seen in the line graphs. I looked at this again in detail I have now found a very old off-by-one error when using pixel units as you seem to be doing.

A fix is underway here:

Could you maybe test this and see if this solved your issue?

Thanks!
Simon