Something wrong in propagation progress, nothing could be got about gain

Nora · March 12, 2024, 7:07am

Hi, I find something strange in propagation progress. There is no gain information in the propagation progress. I guess maybe it is due to my electric filed. But I am not sure and do not know how to solve it. Could anyone give me any advice? Thank you!

Here are part of the messages (there is information about gain in example.conf compared to mine):

|15:03:06.822|   (DEBUG) (Event 1) [R:DepositionGeant4] Created deposit of 85 charges at (20.71um,-411.493um,19.5um) global / (20.71um,-411.493um,19.5um) local in dut after 3.40069ps global / 0.146768ps local
|15:03:06.822|   (DEBUG) (Event 1) [R:DepositionGeant4] Created deposit of 64 charges at (20.71um,-411.493um,20.5um) global / (20.71um,-411.493um,20.5um) local in dut after 3.40402ps global / 0.150104ps local
|15:03:06.822|   (DEBUG) (Event 1) [R:DepositionGeant4] Created deposit of 108 charges at (20.71um,-411.493um,21.5um) global / (20.71um,-411.493um,21.5um) local in dut after 3.40736ps global / 0.15344ps local
|15:03:06.822|   (DEBUG) (Event 1) [R:DepositionGeant4] Created deposit of 76 charges at (20.71um,-411.493um,22.5um) global / (20.71um,-411.493um,22.5um) local in dut after 3.4107ps global / 0.156775ps local
|15:03:06.822|   (DEBUG) (Event 1) [R:DepositionGeant4] Created deposit of 65 charges at (20.71um,-411.493um,23.5um) global / (20.71um,-411.493um,23.5um) local in dut after 3.41403ps global / 0.160111ps local
|15:03:06.822|   (DEBUG) (Event 1) [R:DepositionGeant4] Created deposit of 37 charges at (20.71um,-411.493um,24.5um) global / (20.71um,-411.493um,24.5um) local in dut after 3.41737ps global / 0.163447ps local
|15:03:06.822|    (INFO) (Event 1) [R:DepositionGeant4] Deposited 6720 charges in sensor of detector dut
|15:03:06.822|   (DEBUG) (Event 1) [R:DepositionGeant4] Clearing track and deposit vectors
|15:03:06.822|   (DEBUG) (Event 1) [R:TransientPropagation:dut] Set of charge carriers ("e") on (20.71um,-411.493um,-24.5um)
|15:03:06.854|   (DEBUG) (Event 1) [R:TransientPropagation:dut]  Propagated 100 (initial: 100) to (18.614um,-411.219um,25um) in 0.56ns time, induced 99e, final state: halted
|15:03:06.856|   (DEBUG) (Event 1) [R:TransientPropagation:dut]  Propagated 100 (initial: 100) to (20.241um,-409.654um,25um) in 0.58ns time, induced 99e, final state: halted
|15:03:06.858|   (DEBUG) (Event 1) [R:TransientPropagation:dut]  Propagated 100 (initial: 100) to (22.263um,-410.83um,25um) in 0.57ns time, induced 99e, final state: halted
|15:03:06.860|   (DEBUG) (Event 1) [R:TransientPropagation:dut]  Propagated 39 (initial: 39) to (17.498um,-412.992um,25um) in 0.57ns time, induced 39e, final state: halted
|15:03:06.860|   (DEBUG) (Event 1) [R:TransientPropagation:dut] Set of charge carriers ("h") on (20.71um,-411.493um,-24.5um)

The following is my setup:

[Allpix]
log_level = "DEBUG"
log_format = "DEFAULT"
detectors_file = "detector.conf"
number_of_events = 200

[GeometryBuilderGeant4]

[DepositionGeant4]
physics_list = FTFP_BERT_LIV
particle_type = "Pi+"
number_of_particles = 1
source_energy = 120GeV
source_position = 0 0 -1mm
source_type = "beam"
beam_size = 500um
beam_direction = 0 0 1
max_step_length = 1um
output_plots= 1



[WeightingPotentialReader]
model = "pad"
output_plots = 1

[ElectricFieldReader]
model = "linear"
field_mapping = PIXEL_FULL
bias_voltage = -190V
depletion_voltage = -180V
output_plots = 1


[TransientPropagation]
temperature = 293K
mutiplication_model = okuto
charge_per_step = 100
integration_time =10ns
output_plots = 1

[PulseTransfer]
output_plots = 1
output_pulsegraphs = 1
#max_depth_distance = 5um

#[DefaultDigitizer]
#threshold = 600e

[CSADigitizer]
model = "simple"
feedback_capacitance = 1e-15C/V
rise_time_constant = 300ps
feedbake_time_constant = 450ps
integration_time = 0.5e-6s
threshold = 10mV
output_plots = 1
output_pulsegraphs = 1
ignore_polarity = true
clock_bin_tot = 10ps
clock_bin_toa = 10ps

[DetectorHistogrammer]
name = "dut"

pschutze · March 12, 2024, 9:08am

Dear @Nora ,

thank you for your message!
With the goal of simulating impact ionisation, there are two issues in your configuration:

The electric field is most likely too low. Please have a look at the resulting plots of the ElectricFieldReader. If you do not see an absolute electric field larger than the multiplication_threshold (default: 100kV/cm), there will not be any charge multiplication.
There is a typo in your configuration file: in mutiplication_model = okuto, there is an “l” missing in the key. With that typo, there is no multiplication enabled. Once this typo is fixed, this will enable the possibility of impact ionisation, under the premise that the electric field is sufficiently high (see 1.)

For bullet no. 2, there is a nice feature to detect such issues: at the very end of an execution of Allpix Squared, there is an information on “unused configuration parameters”. Those are parameters that are present in your configuration file but have never been “read” during runtime. Reasons can be invalid combinations of existing parameters or typos. For the configuration posted by you, you should get the following printout:

|09:34:07.450| (WARNING) Unused configuration keys in section ElectricFieldReader:detector1:
                         field_mapping
|09:34:07.450| (WARNING) Unused configuration keys in section TransientPropagation:detector1:
                         mutiplication_model
|09:34:07.450| (WARNING) Unused configuration keys in section CSADigitizer:detector1:
                         feedbake_time_constant

In detail:

field_mapping: this is a parameter that is only picked up when importing an electric field from file via the model = mesh parameter. With a linear electric field, there’s no usage in the field_mapping parameter.
mutiplication_model: typo
feedbake_time_constant: typo (bake → back)

Please let me know if you need any further help and we’ll be happy to provide support.

Best regards
Paul

Nora · March 12, 2024, 10:30am

Dear @pschutze ,
Thanks a lot. How careless I am making such typo.
I have solve almost all the problem according to your advice. But I find a new question now. All the gain values in the process are 1. Do you know why?

pschutze · March 12, 2024, 12:01pm

Hi @Nora ,

this happens to all of us - and that’s one reason why we implemented this check

Concerning your question: would you be able to provide me with an updated configuration?

Best
Paul

Nora · March 13, 2024, 7:54am

Thank you, @pschutze ! Here is my new configuration!

[Allpix]
log_level = "DEBUG"
log_format = "DEFAULT"
detectors_file = "lgad_detector.conf"
number_of_events = 200

[GeometryBuilderGeant4]

[DepositionGeant4]
physics_list = FTFP_BERT_LIV
particle_type = "Pi+"
number_of_particles = 1
source_energy = 120GeV
source_position = 0 0 -1mm
source_type = "beam"
beam_size = 500um
beam_direction = 0 0 1
max_step_length = 1um
output_plots= 1





[WeightingPotentialReader]
model = "pad"
output_plots = 1

[ElectricFieldReader]
model = "linear"
bias_voltage = -500V
depletion_voltage = -180V
output_plots = 1

[TransientPropagation]
temperature = 293K
multiplication_model = okuto
charge_per_step = 100
integration_time =10ns
output_plots = 1

[PulseTransfer]
output_plots = 1
output_pulsegraphs = 1

[CSADigitizer]
model = "simple"
feedback_capacitance = 1e-15C/V
rise_time_constant = 300ps
feedback_time_constant = 450ps
integration_time = 0.5e-6s
threshold = 10mV
output_plots = 1
output_pulsegraphs = 1
ignore_polarity = true
clock_bin_tot = 10ps
clock_bin_toa = 10ps

[DetectorHistogrammer]
name = "dut"



# replace by [VisualizationGeant4] to run the visualization
[Ignore]
mode = "gui"

[VisualizationGeant4]
# Use the Qt gui
mode = "gui"
accumulate = false
# Set opacity of the detector models (in percent)
opacity = 0.4
# Set viewing style (alternative is 'wireframe')
view_style = "surface"

# Color trajectories by charge of the particle
trajectories_color_mode = "charge"
trajectories_color_positive = "blue"
trajectories_color_neutral = "green"
trajectories_color_negative = "red"


[ROOTObjectWriter]

pschutze · March 15, 2024, 9:11am

Dear @Nora ,

as mentioned before, the electric field is critical:

Please have a look at the resulting plots of the ElectricFieldReader. If you do not see an absolute electric field larger than the multiplication_threshold (default: 100kV/cm), there will not be any charge multiplication.

I do not know the thickness of your sensor, but -500V for a linear field approximation is still rather low. Be aware that this linear approximation does not yield LGAD-like fields with a high-field gain layer. If you e.g. define a sensor of 100 um thickness, the average field will be -500 V / 100 um = 50 kV/cm (there’s a slight dependency on the thickness, though), which is below the default multiplication threshold.

To be fair, for a simulation of the gain of an LGAD, the electric field is the critical parameter and for a precise simulation and a comparison to a physical sensor one requires a good understanding of the electric field in the sensor. This is why e.g. @andrea_visibile uses a field simulated via TCAD. If you do not have a TCAD simulation of the electric field, but an understanding of what the field looks like, you can also use the custom electric field model to provide a closed form approximation of the field. If you would like to test the impact ionisation functionality itself, you can also use a very simplified field. Here’s a snapshot of what I used for debugging purposes (it generates a high electric field only in a small region along z and a low field else):

[ElectricFieldReader]
model = "custom"
field_function = "((z < [0]) ? [3] : ((z > [1]) ? [3] : [2]))"
field_parameters = 23.5um, 24.5um, -320kV/cm, -5000V/cm

Cheers
Paul

Nora · March 17, 2024, 6:44am

Thank you, @pschutze . I have solved the problem about the gain according to your advice. Now I am working on simulating the electric field for it.

Nora · March 21, 2024, 3:05pm

Dear @pschutze ,

Sorry for interrupting you again. I got a TCAD simulation now and used it for electric field. However, something goes wrong. I found something strange in the propagation process.

|23:03:48.696|   (DEBUG) Loading detectors
|23:03:48.696|   (DEBUG) Detector dut:
|23:03:48.696|   (DEBUG) Position:    (0mm,0mm,0mm)
|23:03:48.696|   (DEBUG)  misaligned: (0mm,0mm,0mm)
|23:03:48.696|   (DEBUG) Orientation: (0deg,0deg,0deg)
|23:03:48.696|   (DEBUG)  misaligned: (0deg,0deg,0deg)
|23:03:48.696|   (DEBUG) Interpreting Euler angles as XYZ rotation
|23:03:48.696| (WARNING) Main ROOT file "/Users/zhanglinnuo/allpix-squared/output/modules.root" exists and will be overwritten.
|23:03:48.700|  (STATUS) Loading module GeometryBuilderGeant4
|23:03:48.700|   (DEBUG) Found library during global search in runtime paths at /Users/zhanglinnuo/allpix-squared/install/lib/libAllpixModuleGeometryBuilderGeant4.dylib
|23:03:48.700|   (DEBUG) Creating unique instantiation GeometryBuilderGeant4
|23:03:48.700|    (INFO) [C:GeometryBuilderGeant4] Detected Geant4 multithreading capabilities, enabling multithreading support
|23:03:48.701|  (STATUS) Loading module DepositionGeant4
|23:03:48.701|   (DEBUG) Found library during global search in runtime paths at /Users/zhanglinnuo/allpix-squared/install/lib/libAllpixModuleDepositionGeant4.dylib
|23:03:48.701|   (DEBUG) Creating unique instantiation DepositionGeant4
|23:03:48.701|  (STATUS) Loading module WeightingPotentialReader
|23:03:48.701|   (DEBUG) Found library during global search in runtime paths at /Users/zhanglinnuo/allpix-squared/install/lib/libAllpixModuleWeightingPotentialReader.dylib
|23:03:48.701|   (DEBUG) Creating instantions for detector module WeightingPotentialReader
|23:03:48.704|   (DEBUG) Number of [support] sections: 0
|23:03:48.704|   (DEBUG) Number of [support] sections: 0
|23:03:48.704| (WARNING) Unused configuration keys in global section of sensor geometry definition:
                         material_budget
                         pixel_pitch
                         time_resolution
|23:03:48.704|   (DEBUG) Creating detector instantiation WeightingPotentialReader:dut
|23:03:48.704|  (STATUS) Loading module ElectricFieldReader
|23:03:48.704|   (DEBUG) Found library during global search in runtime paths at /Users/zhanglinnuo/allpix-squared/install/lib/libAllpixModuleElectricFieldReader.dylib
|23:03:48.704|   (DEBUG) Creating instantions for detector module ElectricFieldReader
|23:03:48.704|   (DEBUG) Creating detector instantiation ElectricFieldReader:dut
|23:03:48.705|  (STATUS) Loading module TransientPropagation
|23:03:48.705|   (DEBUG) Found library during global search in runtime paths at /Users/zhanglinnuo/allpix-squared/install/lib/libAllpixModuleTransientPropagation.dylib
|23:03:48.705|   (DEBUG) Creating instantions for detector module TransientPropagation
|23:03:48.705|   (DEBUG) Creating detector instantiation TransientPropagation:dut
|23:03:48.705|  (STATUS) Loading module PulseTransfer
|23:03:48.705|   (DEBUG) Found library during global search in runtime paths at /Users/zhanglinnuo/allpix-squared/install/lib/libAllpixModulePulseTransfer.dylib
|23:03:48.705|   (DEBUG) Creating instantions for detector module PulseTransfer
|23:03:48.705|   (DEBUG) Creating detector instantiation PulseTransfer:dut
|23:03:48.705| (WARNING) [C:PulseTransfer:dut] Per-event pulse graphs requested, disabling parallel event processing
|23:03:48.705| (WARNING) Module instance PulseTransfer:dut prevents multithreading
|23:03:48.705|  (STATUS) Loading module CSADigitizer
|23:03:48.705|   (DEBUG) Found library during global search in runtime paths at /Users/zhanglinnuo/allpix-squared/install/lib/libAllpixModuleCSADigitizer.dylib
|23:03:48.705|   (DEBUG) Creating instantions for detector module CSADigitizer
|23:03:48.705|   (DEBUG) Creating detector instantiation CSADigitizer:dut
|23:03:48.718|   (DEBUG) [C:CSADigitizer:dut] Parameters: cf = 0.001fC/mV, rf = 450000V*s/C, tauF = 0.45ns, tauR = 0.3ns
|23:03:48.718| (WARNING) [C:CSADigitizer:dut] Per-event pulse graphs requested, disabling parallel event processing
|23:03:48.718| (WARNING) Module instance CSADigitizer:dut prevents multithreading
|23:03:48.718|  (STATUS) Loading module DetectorHistogrammer
|23:03:48.719|   (DEBUG) Found library during global search in runtime paths at /Users/zhanglinnuo/allpix-squared/install/lib/libAllpixModuleDetectorHistogrammer.dylib
|23:03:48.719|   (DEBUG) Creating instantions for detector module DetectorHistogrammer
|23:03:48.719|   (DEBUG) Creating detector instantiation DetectorHistogrammer:dut
|23:03:48.719|  (STATUS) Loading module VisualizationGeant4
|23:03:48.719|   (DEBUG) Found library during global search in runtime paths at /Users/zhanglinnuo/allpix-squared/install/lib/libAllpixModuleVisualizationGeant4.dylib
|23:03:48.719|   (DEBUG) Creating unique instantiation VisualizationGeant4
|23:03:48.719| (WARNING) Module instance VisualizationGeant4 prevents multithreading
|23:03:48.719|  (STATUS) Loading module ROOTObjectWriter
|23:03:48.719|   (DEBUG) Found library during global search in runtime paths at /Users/zhanglinnuo/allpix-squared/install/lib/libAllpixModuleROOTObjectWriter.dylib
|23:03:48.719|   (DEBUG) Creating unique instantiation ROOTObjectWriter
|23:03:48.720|  (STATUS) Loaded 10 modules
|23:03:48.720|   (ERROR) Multithreading disabled since the current module configuration does not support it
|23:03:48.720|  (STATUS) Initializing 10 module instantiations
|23:03:48.725|   (DEBUG) [I:GeometryBuilderGeant4] Checking Geant4 datasets
|23:03:48.726|   (DEBUG) [I:GeometryBuilderGeant4] Making a single-thread RunManager
|23:03:48.805|    (INFO) [I:GeometryBuilderGeant4] Using Geant4 modules without multithreading might reduce performance when using complex geometries, please check the documentation for details
|23:03:48.806|   (DEBUG) [I:GeometryBuilderGeant4] World size is (1.43mm,1.43mm,2.2mm)
|23:03:48.806|   (DEBUG) [I:GeometryBuilderGeant4] Creating Geant4 model for dut
|23:03:48.806|   (DEBUG) [I:GeometryBuilderGeant4]  Wrapper dimensions of model: (1.3mm,1.3mm,175um)
|23:03:48.806|   (DEBUG) [I:GeometryBuilderGeant4]  Global position and orientation of the detector:
|23:03:48.806|   (DEBUG) [I:GeometryBuilderGeant4]  - Position		:	(0mm,0mm,0mm)
|23:03:48.806|   (DEBUG) [I:GeometryBuilderGeant4]  Center of the geometry parts relative to the detector wrapper geometric center:
|23:03:48.806|   (DEBUG) [I:GeometryBuilderGeant4]  - Sensor material		:	silicon
|23:03:48.806|   (DEBUG) [I:GeometryBuilderGeant4]   - Sensor		:	(0mm,0mm,-62.5um)
|23:03:48.806|   (DEBUG) [I:GeometryBuilderGeant4]   - Chip		:	(0mm,0mm,25um)
|23:03:48.806|   (DEBUG) [I:GeometryBuilderGeant4] Storing total material budget of 0.00186845 x/X0 for detector dut
|23:03:48.806|    (INFO) [I:GeometryBuilderGeant4] No overlapping volumes detected.
|23:03:48.807|    (INFO) [I:DepositionGeant4] Using G4 physics list "FTFP_BERT_LIV"
|23:03:48.807|   (DEBUG) [I:DepositionGeant4] Registering Geant4 step limiter physics list
|23:03:48.807|   (DEBUG) [I:DepositionGeant4] Registering Geant4 radioactive decay physics list
|23:03:48.807|    (INFO) [I:DepositionGeant4] Setting G4 production cut to 10um, derived from properties of detector "dut"
|23:03:48.807|    (INFO) [I:DepositionGeant4] Setting minimum kinetic energy for tracks to 3.64eV, derived from material of detector "dut"
|23:03:48.807|   (DEBUG) [I:DepositionGeant4] Setting world volume user limits to constrain event time to 221s and maximum track length to 50.6cm
|23:03:48.893|   (DEBUG) [I:DepositionGeant4] Using particle pi+ (ID 211).
|23:03:48.893|   (DEBUG) [I:DepositionGeant4] Detector dut uses charge creation energy 3.64eV and Fano factor 0.115
|23:03:58.580|    (INFO) [I:WeightingPotentialReader:dut] Plotting weighting potential: done 
|23:03:58.821|   (DEBUG) [I:ElectricFieldReader:dut] Electric field maps to SENSOR
|23:03:58.823|   (DEBUG) [I:ElectricFieldReader:dut] Assuming file type "INIT"
|23:03:58.824|   (ERROR) [I:ElectricFieldReader:dut] Requesting to interpret INIT field as units "V/cm" while file header states internal units
|23:04:52.743|    (INFO) [I:ElectricFieldReader:dut] Reading field data: finished.
|23:04:52.838|    (INFO) [I:ElectricFieldReader:dut] Set electric field with 1x200x100000 cells
|23:04:52.840|   (DEBUG) [I:ElectricFieldReader:dut] Electric field will be scaled with factors (0.000769231,1)
|23:04:52.841|   (DEBUG) [I:ElectricFieldReader:dut] Electric field has offset of (0,0) fractions of the field size
|23:04:52.841| (WARNING) [I:ElectricFieldReader:dut] Field map size is (1.3mm,1.3mm) but expecting a multiple of the pixel pitch (1.3mm, 1.3mm)
                                                     The area to which the field is applied can be changed using the field_scale parameter.
|23:04:53.398|    (INFO) [I:TransientPropagation:dut] Selected mobility model "jacoboni"
|23:04:53.399|    (INFO) [I:TransientPropagation:dut] No charge carrier recombination model chosen, finite lifetime not simulated
|23:04:53.399|    (INFO) [I:TransientPropagation:dut] Selected recombination model "none"
|23:04:53.399|    (INFO) [I:TransientPropagation:dut] No charge carrier trapping model chosen, no trapping simulated
|23:04:53.399|    (INFO) [I:TransientPropagation:dut] Selected trapping model "none"
|23:04:53.399|    (INFO) [I:TransientPropagation:dut] No charge carrier detrapping model chosen, no detrapping simulated
|23:04:53.399|    (INFO) [I:TransientPropagation:dut] Selected impact ionization model "okuto"
|23:04:53.399| (WARNING) [I:TransientPropagation:dut] Charge multiplication enabled with maximum timestep larger than 1ps
                                                      This might lead to unphysical gain values.
|23:04:53.542| (WARNING) [I:DetectorHistogrammer:dut] Selected plotting granularity of (1300,1300) bins creates very large histograms.
                                                      Consider reducing the number of bins using the granularity parameter.
This command is no longer relevant. There is no longer any limit on the
number of display lists - except, of course, the available memory in
your computer. Keep an eye on that. Good luck!
|23:04:56.412| (WARNING) [I:ROOTObjectWriter] File "/Users/zhanglinnuo/allpix-squared/output/data.root" exists and will be overwritten.
|23:04:56.477| (WARNING) [I:ROOTObjectWriter] Writing all simulation objects to file, this will lead to large output files and possible performance penalties.
                                              It is advised to use the include and exclude parameters to select object types specifically.
|23:04:56.477|  (STATUS) Initialized 10 module instantiations
|23:04:56.478|   (DEBUG) [T:DepositionGeant4] Initializing run manager
|23:04:56.478|  (STATUS) Starting event loop
|23:04:56.478|    (INFO) Starting event 1 with seed 1100310943072377039
|23:04:56.479|   (DEBUG) (Event 1) [R:DepositionGeant4] Seeding Geant4 event with seeds 12406733743064119606 14253641635393164516
|23:04:56.479|   (DEBUG) (Event 1) [R:DepositionGeant4] Current Geant4 state: G4State_Idle
|23:05:07.155|   (DEBUG) (Event 1) [R:DepositionGeant4] Storing MCTrack with ID 1
|23:05:07.187|   (DEBUG) (Event 1) [R:DepositionGeant4] Dispatching 1 MCTrack(s) from TrackInfoManager::dispatchMessage()
|23:05:07.187|   (DEBUG) (Event 1) [R:DepositionGeant4] MCTrack originates at: (172.768um,594.46um,-1mm) and terminates at: (172.772um,594.462um,1.1mm)
|23:05:07.188|   (DEBUG) (Event 1) [R:DepositionGeant4] Found MC particle 211 crossing detector dut from (172.768um,594.46um,-25um) to (172.768um,594.46um,25um) local after 3.25392ps global / 0ns local
|23:05:07.188|   (DEBUG) (Event 1) [R:DepositionGeant4] Created deposit of 2626 charges at (172.768um,594.46um,-24.5um) global / (172.768um,594.46um,-24.5um) local in dut after 3.25392ps global / 0ns local
|23:05:07.189|   (DEBUG) (Event 1) [R:DepositionGeant4] Created deposit of 92 charges at (172.768um,594.46um,-23.5um) global / (172.768um,594.46um,-23.5um) local in dut after 3.25726ps global / 0.00333564ps local
|23:05:07.189|   (DEBUG) (Event 1) [R:DepositionGeant4] Created deposit of 1138 charges at (172.768um,594.46um,-22.5um) global / (172.768um,594.46um,-22.5um) local in dut after 3.26059ps global / 0.00667129ps local
|23:05:07.189|   (DEBUG) (Event 1) [R:DepositionGeant4] Created deposit of 16 charges at (172.768um,594.46um,-21.5um) global / (172.768um,594.46um,-21.5um) local in dut after 3.26393ps global / 0.0100069ps local

|22:54:52.140|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (155.574um,-197.755um,25um) in 0.75ns time, induced 7e, final state: halted
|22:54:52.142|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (150.683um,-193.13um,25um) in 0.53ns time, induced 7e, final state: halted
|22:54:52.144|   (DEBUG) (Event 20) [R:TransientPropagation:dut] Calculated local gain of 1 for step of 516.697nm from field of 97.1071kV/cm to 84.8807kV/cm
|22:54:52.144|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (152.117um,-195.885um,25um) in 0.55ns time, induced 7e, final state: halted
|22:54:52.146|   (DEBUG) (Event 20) [R:TransientPropagation:dut] Calculated local gain of 1.00009 for step of 537.06nm from field of 40.6874kV/cm to 254.729kV/cm
|22:54:52.146|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (151.77um,-193.641um,25um) in 0.49ns time, induced 7e, final state: halted
|22:54:52.147|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (154.099um,-196.381um,25um) in 0.51ns time, induced 7e, final state: halted
|22:54:52.149|   (DEBUG) (Event 20) [R:TransientPropagation:dut] Calculated local gain of 1 for step of 526.632nm from field of 110.948kV/cm to 125.586kV/cm
|22:54:52.149|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (152.315um,-192.229um,25um) in 0.48ns time, induced 7e, final state: halted
|22:54:52.151|   (DEBUG) (Event 20) [R:TransientPropagation:dut] Calculated local gain of 1 for step of 531.647nm from field of 12.7114kV/cm to 165.776kV/cm
|22:54:52.151|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (150.284um,-193.414um,25um) in 0.5ns time, induced 7e, final state: halted
|22:54:52.153|   (DEBUG) (Event 20) [R:TransientPropagation:dut] Calculated local gain of 1.00016 for step of 538.482nm from field of 5.74441kV/cm to 297.267kV/cm
|22:54:52.153|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (153.716um,-193.534um,25um) in 0.52ns time, induced 7e, final state: halted
|22:54:52.154|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (150.807um,-194.301um,25um) in 0.5ns time, induced 7e, final state: halted
|22:54:52.156|   (DEBUG) (Event 20) [R:TransientPropagation:dut] Calculated local gain of 1.00002 for step of 537.546nm from field of 8.35794kV/cm to 267.776kV/cm
|22:54:52.156|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (152.392um,-192.66um,25um) in 0.55ns time, induced 7e, final state: halted
|22:54:52.158|   (DEBUG) (Event 20) [R:TransientPropagation:dut]  Propagated 10 (initial: 10) to (152.284um,-191.724um,25um) in 0.49ns time, induced 7e, final state: halted

The gain is always 1, and the position of particles change unreasonably.

Here is my electric field!

[ElectricFieldReader]
model = "mesh"
file_name = "test2n165_ElectricField.init"
field_mapping = SENSOR
field_scale = 0.00076923077 1

pschutze · March 22, 2024, 12:08pm

Dear @Nora ,

this looks like good process, but indeed it looks like there is an underestimation of the gain due to the propagation parameters, in particular the timestep that was selected in TransientPropagation, see this part of the printout:

|23:04:53.399| (WARNING) [I:TransientPropagation:dut] Charge multiplication enabled with maximum timestep larger than 1ps. This might lead to unphysical gain values.

Let’s look at the second part of the printout you posted:

|22:54:52.153| (DEBUG) (Event 20) [R:TransientPropagation:dut] Calculated local gain of 1.00016 for step of 538.482nm from field of 5.74441kV/cm to 297.267kV/cm

What happens here is that a charge carrier moves 538 nm, which is half a micron and thus around half of the thickness of your sensor’s gain layer within a single step. This means that in this particular case, the carrier steps into the gain layer in one step and out of the gain layer in the next step. The problem with this is, that for the calculation of the local gain we (linearly) average the electric field from the beginning and the end of the step (in the mentioned case that’s roughly 150 kV/cm), but the gain roughly has an exponential dependency on the electric field, see the documentation. Hence, we tend to underestimate the local gain. The best way to avoid this underestimation is to strongly decrease the timestep, as this leads to a much finer “sampling” of the electric field, the local gain and thus a strongly improved result. As the above warning claims, we suggest a timestep of less than 1 ps.

In the configurations you posted previously, you don’t specify the timestep parameter, which leads to using the default of 10 ps (see documentation).

Let us know whether this leads improves your simulation.

Cheers
Paul

Nora · March 22, 2024, 1:03pm

Dear @pschutze ,
Thanks for your advice! I have changed tilmestep. Good news is that the movement of each step seems to be reasonable now. But the gain is still around 1 even with the electric field around 250kV/cm.

|20:55:59.456|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.00002 for step of 53.2523nm from field of 137.37kV/cm to 166.227kV/cm
|20:55:59.456|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.00027 for step of 53.4128nm from field of 166.227kV/cm to 187.742kV/cm
|20:55:59.456|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.00104 for step of 53.4967nm from field of 187.742kV/cm to 201.301kV/cm
|20:55:59.456|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.00218 for step of 53.5541nm from field of 201.301kV/cm to 211.606kV/cm
|20:55:59.456|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.00423 for step of 53.6277nm from field of 211.606kV/cm to 226.612kV/cm
|20:55:59.457|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.00827 for step of 53.6932nm from field of 226.612kV/cm to 242.011kV/cm
|20:55:59.457|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.01519 for step of 53.739nm from field of 242.011kV/cm to 259.911kV/cm
|20:55:59.457|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.0163 for step of 53.608nm from field of 259.911kV/cm to 246.469kV/cm
|20:55:59.457|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.00732 for step of 53.8067nm from field of 246.469kV/cm to 216.085kV/cm
|20:55:59.457|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.01751 for step of 53.7954nm from field of 216.085kV/cm to 294.515kV/cm
|20:55:59.457|   (DEBUG) (Event 5) [R:TransientPropagation:dut] Calculated local gain of 1.03438 for step of 53.6848nm from field of 294.515kV/cm to 264.131kV/cm

[TransientPropagation]
temperature = 293K
multiplication_model = okuto
timestep = 0.5ps
integration_time =10ns

I would appreciate it very much if you have any ideas about it!

pschutze · March 25, 2024, 8:34am

Dear @Nora ,

you could decrease the timestep even further, as your electric field varies a lot within this region (it will however increase the computing time by a lot). However, with electric fields in the order of 250 kV/cm, the gain will presumably not be very large, as the impact ionisation coefficient is rather small at this field, especially for the Okuto-Crowell impact ionisation model that you are using. Have a look e.g. at Figure 11 (left) of this publication, showing the coefficients for different models vs the electric field and showing the Okuto-Crowell model to have rather low coefficients at low fields. I also checked the calculations leading to the local gain in your printout and they are consistent.

From the electric field you posted previously, there should be regions with field amplitudes larger than 300 kV/cm, which will lead to higher gain, but I don’t see high fields of that order in your printout. There could be two reasons for that:
a) the charge carriers of your printout are at a wrong lateral (x-y) position
b) the timestep is still too large such that the carriers move over this part too quickly.

May I ask what makes you expect a larger gain? Do you have simulations or measurements that you are comparing the simulations to? Also, to get more statistics, please have a look at the graphs generated by the TransientPropagation module by using the paramter output_plots = true, they will give you more statistics on the gain, which should be easier and reliable than looking at the printout.

Best
Paul

Nora · March 26, 2024, 2:42am

Dear @pschutze ,

Thank you for your advice! There have been regions and info about electric field larger than 300kV/cm, though still with a gain around 1. I expect the gain around 5.

Besides, someone else has simulated it before (maybe using a weighting potential field, instead of directly using electric field, but I think this won’t lead to too much different?) , and we also have a beam test result. Now I am working on reproducing the simulation results and adjust the parameter to match the beam test results.

Best
Nora

pschutze · March 26, 2024, 8:53am

Dear @Nora ,

maybe one more explanation for clarification: the printouts you posted show the “local gain”, which is the charge multiplication factor estimated for the current step of the charge carrier propagation. While stepping through the sensor or the gain layer, the charge carriers will cause impact ionisation with that probability. Mathematically the “final gain” (in case of small numbers, omitting second order effects) is similar to the product of each local gain along its trajectory. E.g. if you have five steps within a region where the local gain is 1.05, the final gain will already be around 1.05^5 = 1.28.

This is why I would advise you to rather have a look at the gain distribution generated in the ROOT file rather than the printout of the local gain.

For the above, I advise to read through the documentation on the TransientPropagation module and the Impact Ionisation model applied in Allpix Squared.

Best
Paul

Nora · March 28, 2024, 8:32am

Dear @pschutze ,

thank you so much, Paul! I solved the problem I mentioned before which is due to the imprecise electric field I used.

However, I met an overflow error when doing the simulation. The printout information is

|13:48:25.327| (WARNING) (Event 20) [R:TransientPropagation:dut] Found impact ionization shower with level larger than 5, interrupting
|13:48:25.327| (WARNING) (Event 20) [R:TransientPropagation:dut] Found impact ionization shower with level larger than 5, interrupting
|13:48:26.496|    (INFO) (Event 20) [R:TransientPropagation:dut] Propagated 787930 charges
                                                                 Recombined 0 charges during transport
                                                                 Trapped 0 charges during transport
|13:48:35.651|    (INFO) (Event 20) [R:PulseTransfer:dut] Total charge induced on all pixels: 406257e
|13:48:53.738|    (INFO) (Event 20) [R:CSADigitizer:dut] Digitized 1 pixel hits
Fatal in <TBufferFile::AutoExpand>: Request to expand to a negative size, likely due to an integer overflow: 0x8000425e for a max of 0x7ffffffe.
aborting

For the warning, I found the answer under other’s problem, saying that it doesn’t matter. But for the overflow error, I have no idea. Maybe I think it is related to the propagation progress, processing too much data?

Much thanks
Nora

simonspa · March 28, 2024, 10:45am

Hi @Nora

thanks for the report! If you are able to reproduce this, would it be possible to produce a stack trace for us? You can this like follows:

Install the GNU debugger gdb, e.g. via sudo apt-get install gdb on Ubuntu
Run your simulation via gdb --args allpix -c yoursimulation.conf just as you do normally, but with the gdb --args before it
Then a console opens, type run to start the program
When it crashes, you end on the same console, now type thread apply all bt and copy the entire output for us.

This will help us to find out where this problem occurs!

All the best,
Simon

Nora · March 29, 2024, 7:38am

Dear @simonspa ,

Thank you for your reply! I forgot to mention that I use MacOS system, and find some problem in using GDB to run it.

Unable to find Mach task port for process-id 88940: (os/kern) failure (0x5).
 (please check gdb is codesigned - see taskgated(8))

Can I use lldb with the command “lldb – …/install/bin/allpix -c lgad.conf”? If it is also OK, all the outputs are here!

(lldb) thread backtrace all

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007ff8185afffe libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007ff8185e61ff libsystem_pthread.dylib`pthread_kill + 263
    frame #2: 0x00007ff818531d14 libsystem_c.dylib`abort + 123
    frame #3: 0x00000001083134fc libCore.6.30.so`TUnixSystem::Abort(int) + 28
    frame #4: 0x00000001081edb32 libCore.6.30.so`DefaultErrorHandler(int, bool, char const*, char const*) + 1778
    frame #5: 0x00000001082a72f7 libCore.6.30.so`ErrorHandler + 679
    frame #6: 0x00000001082020e7 libCore.6.30.so`TObject::Fatal(char const*, char const*, ...) const + 151
    frame #7: 0x00000001081d99a9 libCore.6.30.so`TBuffer::AutoExpand(int) + 105
    frame #8: 0x0000000107977f1b libRIO.6.30.so`TBufferFile::WriteFastArray(double const*, int) + 59
    frame #9: 0x00000001079fc9f9 libRIO.6.30.so`TGenCollectionStreamer::WritePrimitives(int, TBuffer&) + 377
    frame #10: 0x00000001079c029d libRIO.6.30.so`TCollectionClassStreamer::Stream(TBuffer&, void*, TClass const*) + 93
    frame #11: 0x00000001079783e4 libRIO.6.30.so`TBufferFile::WriteFastArray(void*, TClass const*, int, TMemberStreamer*) + 116
    frame #12: 0x0000000107b95e0b libRIO.6.30.so`int TStreamerInfo::WriteBufferAux<char**>(TBuffer&, char** const&, TStreamerInfo::TCompInfo* const*, int, int, int, int, int) + 13915
    frame #13: 0x0000000107a35072 libRIO.6.30.so`TStreamerInfoActions::GenericWriteAction(TBuffer&, void*, TStreamerInfoActions::TConfiguration const*) + 66
    frame #14: 0x000000010797af4d libRIO.6.30.so`TBufferFile::ApplySequence(TStreamerInfoActions::TActionSequence const&, void*) + 109
    frame #15: 0x000000010797adef libRIO.6.30.so`TBufferFile::WriteClassBuffer(TClass const*, void*) + 479
    frame #16: 0x00000001079783e4 libRIO.6.30.so`TBufferFile::WriteFastArray(void*, TClass const*, int, TMemberStreamer*) + 116
    frame #17: 0x0000000107b9da09 libRIO.6.30.so`int TStreamerInfo::WriteBufferAux<TVirtualCollectionProxy>(TBuffer&, TVirtualCollectionProxy const&, TStreamerInfo::TCompInfo* const*, int, int, int, int, int) + 5241
    frame #18: 0x0000000107a5fd51 libRIO.6.30.so`TStreamerInfoActions::GenericLooper::GenericWrite(TBuffer&, void*, void const*, TStreamerInfoActions::TLoopConfiguration const*, TStreamerInfoActions::TConfiguration const*) + 81
    frame #19: 0x000000010797b0c6 libRIO.6.30.so`TBufferFile::ApplySequence(TStreamerInfoActions::TActionSequence const&, void*, void*) + 134
    frame #20: 0x0000000107b95cc4 libRIO.6.30.so`int TStreamerInfo::WriteBufferAux<char**>(TBuffer&, char** const&, TStreamerInfo::TCompInfo* const*, int, int, int, int, int) + 13588
    frame #21: 0x0000000107a35072 libRIO.6.30.so`TStreamerInfoActions::GenericWriteAction(TBuffer&, void*, TStreamerInfoActions::TConfiguration const*) + 66
    frame #22: 0x000000010797af4d libRIO.6.30.so`TBufferFile::ApplySequence(TStreamerInfoActions::TActionSequence const&, void*) + 109
    frame #23: 0x000000010797adef libRIO.6.30.so`TBufferFile::WriteClassBuffer(TClass const*, void*) + 479
    frame #24: 0x0000000107978e31 libRIO.6.30.so`TBufferFile::WriteObjectClass(void const*, TClass const*, bool) + 385
    frame #25: 0x000000010797f42c libRIO.6.30.so`TBufferIO::WriteObjectAny(void const*, TClass const*, bool) + 316
    frame #26: 0x00000001079c5443 libRIO.6.30.so`TEmulatedCollectionProxy::WriteItems(int, TBuffer&) + 483
    frame #27: 0x00000001079c029d libRIO.6.30.so`TCollectionClassStreamer::Stream(TBuffer&, void*, TClass const*) + 93
    frame #28: 0x00000001079783e4 libRIO.6.30.so`TBufferFile::WriteFastArray(void*, TClass const*, int, TMemberStreamer*) + 116
    frame #29: 0x0000000107b95e0b libRIO.6.30.so`int TStreamerInfo::WriteBufferAux<char**>(TBuffer&, char** const&, TStreamerInfo::TCompInfo* const*, int, int, int, int, int) + 13915
    frame #30: 0x0000000107a35072 libRIO.6.30.so`TStreamerInfoActions::GenericWriteAction(TBuffer&, void*, TStreamerInfoActions::TConfiguration const*) + 66
    frame #31: 0x000000010797af4d libRIO.6.30.so`TBufferFile::ApplySequence(TStreamerInfoActions::TActionSequence const&, void*) + 109
    frame #32: 0x0000000103966117 libTree.6.30.so`TBranch::FillImpl(ROOT::Internal::TBranchIMTHelper*) + 391
    frame #33: 0x0000000103972484 libTree.6.30.so`TBranchElement::FillImpl(ROOT::Internal::TBranchIMTHelper*) + 244
    frame #34: 0x00000001039cf606 libTree.6.30.so`TTree::Fill() + 694
    frame #35: 0x00000001006814cd libAllpixModuleROOTObjectWriter.dylib`allpix::ROOTObjectWriterModule::run(this=0x0000000126769e10, event=<unavailable>) at ROOTObjectWriterModule.cpp:232:22 [opt]
    frame #36: 0x0000000105eae3b0 libAllpixCore.dylib`void allpix::ModuleManager::run(this=0x00006000033f3208, event=std::__1::shared_ptr<allpix::Event>::element_type @ 0x000000012a5b18f8 strong=1 weak=1, module_iter=std::__1::list<std::__1::shared_ptr<allpix::Module>, std::__1::allocator<std::__1::shared_ptr<allpix::Module> > >::iterator @ 0x00007ff7bfefdfb0, event_time=0, self_func=0x00006000033f3258)::$_1::operator()<$_1&>(std::__1::shared_ptr<allpix::Event>, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, long long, $_1&) at ModuleManager.cpp:816:33 [opt]
    frame #37: 0x0000000105eadc1c libAllpixCore.dylib`std::__1::__packaged_task_func<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>, std::__1::allocator<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&> >, void ()>::operator()() [inlined] decltype(__f=<unavailable>, __args=<unavailable>, __args=<unavailable>, __args=<unavailable>)::$_1&>(fp)(static_cast<std::nullptr_t&>(fp0), static_cast<std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>&>(fp0), static_cast<int&>(fp0), static_cast<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>(fp0))) std::__1::__invoke<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t&, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>&, int&, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>(allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t&, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>&, int&, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&) at type_traits:3918:1 [opt]
    frame #38: 0x0000000105eadc01 libAllpixCore.dylib`std::__1::__packaged_task_func<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>, std::__1::allocator<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&> >, void ()>::operator()() [inlined] std::__1::__bind_return<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1, std::__1::tuple<std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1>, std::__1::tuple<>, __is_valid_bind_return<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1, std::__1::tuple<std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1>, std::__1::tuple<> >::value>::type std::__1::__apply_functor<allpix::ModuleManager::run(__f=<unavailable>, __bound_args=<unavailable>)::$_1, std::__1::tuple<std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1>, 0ul, 1ul, 2ul, 3ul, std::__1::tuple<> >(allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::__1::tuple<std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1>&, std::__1::__tuple_indices<0ul, 1ul, 2ul, 3ul>, std::__1::tuple<>&&) at bind.h:257:12 [opt]
    frame #39: 0x0000000105eadbfd libAllpixCore.dylib`std::__1::__packaged_task_func<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>, std::__1::allocator<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&> >, void ()>::operator()() [inlined] std::__1::__bind_return<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1, std::__1::tuple<std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1>, std::__1::tuple<>, __is_valid_bind_return<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1, std::__1::tuple<std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1>, std::__1::tuple<> >::value>::type std::__1::__bind<allpix::ModuleManager::run(this=<unavailable>)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>::operator()<>() at bind.h:292:20 [opt]
    frame #40: 0x0000000105eadbf4 libAllpixCore.dylib`std::__1::__packaged_task_func<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>, std::__1::allocator<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&> >, void ()>::operator()() [inlined] decltype(__f=<unavailable>)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>(fp)()) std::__1::__invoke<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>(std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&) at type_traits:3918:1 [opt]
    frame #41: 0x0000000105eadbf4 libAllpixCore.dylib`std::__1::__packaged_task_func<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>, std::__1::allocator<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&> >, void ()>::operator()() [inlined] std::__1::__bind_return<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>, std::__1::tuple<>, std::__1::tuple<>, __is_valid_bind_return<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>, std::__1::tuple<>, std::__1::tuple<> >::value>::type std::__1::__apply_functor<std::__1::__bind<allpix::ModuleManager::run(__f=<unavailable>)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>, std::__1::tuple<>, std::__1::tuple<> >(std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&, std::__1::tuple<>&, std::__1::__tuple_indices<>, std::__1::tuple<>&&) at bind.h:257:12 [opt]
    frame #42: 0x0000000105eadbf4 libAllpixCore.dylib`std::__1::__packaged_task_func<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>, std::__1::allocator<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&> >, void ()>::operator()() [inlined] std::__1::__bind_return<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>, std::__1::tuple<>, std::__1::tuple<>, __is_valid_bind_return<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>, std::__1::tuple<>, std::__1::tuple<> >::value>::type std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(this=<unavailable>)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>::operator()<>() at bind.h:292:20 [opt]
    frame #43: 0x0000000105eadbf4 libAllpixCore.dylib`std::__1::__packaged_task_func<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>, std::__1::allocator<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&> >, void ()>::operator()() [inlined] decltype(__f=<unavailable>)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>&>(fp)()) std::__1::__invoke<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>&>(std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>&) at type_traits:3918:1 [opt]
    frame #44: 0x0000000105eadbf4 libAllpixCore.dylib`std::__1::__packaged_task_func<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>, std::__1::allocator<std::__1::__bind<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&> >, void ()>::operator(this=<unavailable>)() at future:1687:12 [opt]
    frame #45: 0x0000000105eb0818 libAllpixCore.dylib`std::__1::packaged_task<void ()>::operator()() [inlined] std::__1::__packaged_task_function<void ()>::operator()() const at future:1869:12 [opt]
    frame #46: 0x0000000105eb0812 libAllpixCore.dylib`std::__1::packaged_task<void ()>::operator(this=<unavailable>)() at future:2089:9 [opt]
    frame #47: 0x0000000105ea7a8c libAllpixCore.dylib`allpix::ModuleManager::run(allpix::RandomNumberGenerator&) [inlined] auto allpix::ThreadPool::submit<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>(this=0x00007ff7bfefe320)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&)::'lambda'()::operator()() at ThreadPool.tpp:191:13 [opt]
    frame #48: 0x0000000105ea7a72 libAllpixCore.dylib`allpix::ModuleManager::run(allpix::RandomNumberGenerator&) [inlined] auto allpix::ThreadPool::submit<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>(this=0x0000000124bd9140, n=18446744073709551615)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&) at ThreadPool.tpp:196:13 [opt]
    frame #49: 0x0000000105ea78cd libAllpixCore.dylib`allpix::ModuleManager::run(allpix::RandomNumberGenerator&) [inlined] auto allpix::ThreadPool::submit<std::__1::__bind<allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&>(this=0x0000000124bd9140)::$_1&, std::nullptr_t, std::__1::__list_iterator<std::__1::shared_ptr<allpix::Module>, void*>, int, allpix::ModuleManager::run(allpix::RandomNumberGenerator&)::$_1&>&) at ThreadPool.tpp:176:16 [opt]
    frame #50: 0x0000000105ea78cd libAllpixCore.dylib`allpix::ModuleManager::run(this=<unavailable>, seeder=<unavailable>) at ModuleManager.cpp:888:37 [opt]
    frame #51: 0x0000000105eecc20 libAllpixCore.dylib`allpix::Allpix::run(this=0x000000010981ce00) at Allpix.cpp:222:19 [opt]
    frame #52: 0x0000000100020b22 allpix`main(argc=<unavailable>, argv=0x00007ff7bfefec18) at allpix.cpp:247:14 [opt]
    frame #53: 0x000000010003952e dyld`start + 462
thread #2
    frame #0: 0x00007ff8185ab04a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007ff8185e3034 libsystem_pthread.dylib`_pthread_wqthread + 426
    frame #2: 0x00007ff8185e1f57 libsystem_pthread.dylib`start_wqthread + 15
  thread #4
    frame #0: 0x00007ff8185a996a libsystem_kernel.dylib`mach_msg_trap + 10
    frame #1: 0x00007ff8185a9cd8 libsystem_kernel.dylib`mach_msg + 56
    frame #2: 0x00007ff8186ad29d CoreFoundation`__CFRunLoopServiceMachPort + 319
    frame #3: 0x00007ff8186ab928 CoreFoundation`__CFRunLoopRun + 1276
    frame #4: 0x00007ff8186aad6c CoreFoundation`CFRunLoopRunSpecific + 562
    frame #5: 0x00007ff818732d2b CoreFoundation`CFRunLoopRun + 40
    frame #6: 0x00007ff82b80eb78 DebugSymbols`SpotlightQueryThread(void*) + 472
    frame #7: 0x00007ff8185e64e1 libsystem_pthread.dylib`_pthread_start + 125
    frame #8: 0x00007ff8185e1f6b libsystem_pthread.dylib`thread_start + 15
  thread #5
    frame #0: 0x00007ff8185ab04a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007ff8185e3034 libsystem_pthread.dylib`_pthread_wqthread + 426
    frame #2: 0x00007ff8185e1f57 libsystem_pthread.dylib`start_wqthread + 15
  thread #6
    frame #0: 0x00007ff8185ab04a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007ff8185e3034 libsystem_pthread.dylib`_pthread_wqthread + 426
    frame #2: 0x00007ff8185e1f57 libsystem_pthread.dylib`start_wqthread + 15
  thread #7
    frame #0: 0x00007ff8185ab04a libsystem_kernel.dylib`__workq_kernreturn + 10
    frame #1: 0x00007ff8185e3034 libsystem_pthread.dylib`_pthread_wqthread + 426
    frame #2: 0x00007ff8185e1f57 libsystem_pthread.dylib`start_wqthread + 15

Best
Nora

pschutze · April 10, 2024, 8:19am

Dear @Nora ,

it looks like ROOT cannot cope with the vast amount of data you are trying to write, I’m afraid. Judging from this 0x8000425e for a max of 0x7ffffffe it looks like it’s not a lot missing. You could try to slightly reduce the integration_time, e.g. from 10 ns to 8 ns (maybe check before whether you expect any signals after that time). We’re also investigating on our side on how to solve this issue.

Best regards
Paul

Nora · April 16, 2024, 12:45pm

Dear @pschutze,
Thank you for your reply!
I met a strange phenomenon now, which confused me a lot. As what I learnt, GenericPropagation Module and TransientPropagation have difference in the process of producing induced charge on the readout pad. In this case, I think I can get a same result about the gain using these two modules. However, I find it strange that the gain distributions for location are really different, and cause a unreasonable gain histogram.
I would appreciate it very much if you could give me any advice.

[GenericPropagation]
log_level = "DEBUG"
temperature = 293K
#charge_per_step = 10
multiplication_model = "okuto_optimized"
timestep_start = 0.2ps
timestep_min = 0.05ps
timestep_max = 0.2ps
#integration_time =5ns
output_plots = 1

[TransientPropagation]
temperature = 293K
multiplication_model = "okuto_optimized"
#multiplication_model = "okuto"
#charge_per_step = 1000
timestep = 0.5ps
integration_time =4ns
#multiplication_threshold = 50kV/cm
output_plots = 1
#output_plots_phi = 0
#output_linegraphs = 1
#output_animations = true

Here are the results using [TransientPropagation]

Here are the results using [GenericPropagation]

I don’t think the gain is going to change that dramatically in the xy direction. In addition, the percentage of gains of 1 should not be so high.

Here is my electric field map.

pschutze · April 17, 2024, 9:44am

Hi @Nora ,

there are indeed major differences in the way the two modules work, hence there are several reasons why different results are expected. Here’s two things I spotted:

Timestep: as we discussed, the timestep is a crucial parameter for the simulation of impact ionisation. If you’d like to study the difference between the two propagation modules more precisely, you could fix the timestep of the GenericPropagation by setting _min, _max and _start to the same number.
Carrier Type: by default, in GenericPropagation only electrons are propagated. If not defined otherwise, everytime a secondary carrier is generated, only the secondary electron is propagated and the hole is ignored. However, the hole could again cause impact ionisation if propagated. To mitigate that effect, I suggest switching the propagation of both electrons and holes on by propagate_electrons = true and propagate_holes = true. In the TransientPropagation, both types of charge carriers are propagated anyways.

It would be great if you could implement these changes and let us know whether this improves the similarity between the two modules.

Cheers
Paul

Nora · April 23, 2024, 2:11am

Hi, @pschutze , Thank you for your reply!
Now I know the difference is due to the carrier type. However, I am really confused about why the carrier type I choose will influence the the gain distribution in x or y direction. In my view, the number of charge is equal to the hole during the propagation process, so I think it will only influence the pulse on the readout pad instead of the the gain’s distribution. The electric filed is equivalent in the gain region, so I don’t understand why the gain is lower in the very center.
I would appreciate it very much if you could give me any advice.
Best regards,
Nora