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
Best,
Bail
Hi @Bail ,
would you mind providing us with your configuration files? It would make it easier for us to look into this.
Thanks
Paul
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,
Main.conf
[Allpix]
log_level = "WARNING"
log_format = "DEFAULT"
detectors_file = "Setup.conf"
number_of_events = 50000
[GeometryBuilderGeant4]
world_material = "vacuum"
[DepositionGeant4]
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
[ElectricFieldReader]
model = "linear"
bias_voltage = -300V
depletion_voltage = -60V
[GenericPropagation]
temperature = 293.15K
charge_per_step = 100
[PulseTransfer]
max_depth_distance = 5um
[DefaultDigitizer]
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
[ROOTObjectWriter]
file_name = "data.root"
include = PixelHit, MCParticle
and
Setup.conf
[Detector]
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.
Yours,
Andy
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 ?
Cheers,
Simon
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.
Yours,
Andy
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.
Yours,
Andreas
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:
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!
Cheers,
Simon
Hi @simonspa ,
It’s nice to see that the problem is understood now 
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).
Yours,
Andreas
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.
/Simon