Issue with Pulse information form ObjectWriter.root

Honorable Developers,
I am trying to read pulse information from the PropagatedCharge tree using getpulses() function. Unfortunately it gives me both positive and negative pulses. The simulation is supposed to produce pulses only negative. the colord plot is an example output.

Also trying from PixelPulse(in my case there is one pixel) i am getting a plot but with wrong scaling (maybe or i dont understand it).

.conf files are here.

Many thanks for your kind support.
diamond_detecor.conf (123 Bytes)
diamond_poly.conf (1.7 KB)
sorry i edited the PulseTransfer according to this Precise Simulation of Pulse Signal of a Diode Detector - #2 by simonspa suggestion. i,e
[PulseTransfer]
max_depth_distance = 0.01um
collect_from_implant = true
dimond_diode_collimator.conf (338 Bytes)
an ObjectWriter.root file
test_writer.root - Google Drive

Hi @sakzai

Could you please clarify what version you are running currently?

Best
Simon

Dear @simonspa
thank you for the look … i am using the latest version … source /cvmfs/clicdp.cern.ch/software/allpix-squared/latest/x86_64-centos7-gcc12-opt/setup.sh
I changed the plotting from graph to histogram and now it looks better


But i dont understand here the number of entries, if the number of entries are equivalent to the number of created e-h pairs, then it should be round about 0.85 million (for Am-241 alpha particle) but here it reaches 8 million, 10 times more than actual created e-h pairs.
thanks alot
Faiz

Hi @sakzai

Unfortunately, “latest” is not really precise since the version you point to changes whenever we update the main repository.

I recommend to always use released versions such as v3.1.0 from last week.

That said, your problem likely is an outdated parameter, induction_matrix which has been removed a while ago. Now you likely are using the default parameter distance = 1 which includes neighbor pixels in the induced current calculations. These pixels are very likely to see a negative pulse when the central pixel sees a positive one.

Best,
Simon

1 Like

Hi @simonspa
Thank you very much for the guidance.
Using 3.1.0 (source /cvmfs/clicdp.cern.ch/software/allpix-squared/3.1.0/x86_64-centos7-gcc12-opt/setup.sh) is output is the same (even giving 9119489 entries for an event). I am using One pixel so i think distance =1 (that i am still using) will not be a crucial factor.


UPDATE!
with putting log_level = TRACE in the TransientPropagation module, it was seen that charge was induced in very small partial increments of the 1e (each increment i.e. time step is an entry, i suppose), by increasing the time step from 10ps to 100ps in my case (the ratio of the histogram entries to deposited charge was almost 10 ) by setting (May be we can do it with charge_per_step also?)
timestep = 100ps
timestep_max = 100ps
It gives me the following histogram. Now the number of entries are equal to the induced charge and easy to compare with deposited charge. is this a right logic? I hope it will be not a random correlation

Thank you very much
Faiz