Jain, that’s “developer documentation” vs. “user documentation”
Let’s move this offline…
I searched on the developer and user documentation but I am still struggling with the definitions here.
I don’t understand why there is such a difference between the three histograms, especially between the one created with the “getTotalDepositedCharge” method and the “deposited charge per event” from the output of DepositionGeant4.
Thanks,
Umberto.
Sorry @berto I haven’t had the time to look into your simulation in detail, but I still have it on my agenda…
Ciao @berto
I tried to reproduce your results but to no avail, running your configurations just yield this for me:
Is there a way you could reproduce this with a slightly more efficiently placed source 
Concerning your other questions:
I am using “number_of_events = 1000000” and “number_of_particles = 1” in the DepositionGeant4. What is the difference between the two?
The first tells the framework how many independent events it should simulate, the latter how many particles (or shots from your source) Geant4 should simulate per event.
Is it a difference in how the charge carriers are treated during diffusion?
As in “electrons versus holes”? Yes, certainly, because they have different mobilities and therefore diffuse differently. If you mean between the two above options of creating primary particles: no.
I have to assume that the “dut.charge_” is expressed everywhere in number of electrons
This is correct.
Is there a way of changing the framework unit to Coulomb from the configuration file?
Yes, you can add a DefaultDigitizer module with a zero threshold and noise, and then use either the gain factor or the QDC feature to convert to the units of your liking.
Cheers,
Simon
Hi Simon,
Thanks again for your super fast support
Yes, the “deposited charge per event” histogram gets a very high number of counts on the zero bin since the source is scattered and many electrons are lost and do not interact with the detector, however, if you simulate enough particles and you zoom in, the Landau distribution appears and you can find my previous figure. Do you suggest trying with a source closer to the detector and a different energy spectrum?
Many many thanks.
Umberto.
Hi @berto
I just didn’t want to let the simulation run for an hour just to reproduce the few entries you have. So if it would be simple for you to adjust the setup for me that’d be appreciated.
Simon
Hi @berto
I’m a bit late to the party here, but I have had a look at your setup as well.
Is there a reason for simulating a single pixel?
If your interest is the charge deposited in the sensor, you could make it much larger and thus not have to simulate so many zero-events. If you then later want to look at the response of a single pixel, you can pick that out in the resulting files using the pixel index in an analysis script.
If you want the deposited charge per pixel, which is my reading of your initial goal (comparing the deposited charge in a small vs larger pixel), the DepositedCharge object holds the deposition local position. From this and clever use of the modulo operator in an analysis script (i.e. deposition position modulo pixel size), you can get the deposited charge per pixel even if you simulate multiple pixels.
Kind regards,
Håkan
I started with a single pixel because I am fairly new to AllPix and I wanted to progress step by step but I will surely try to implement the multi-pixel detector to optimize my setup and I will try to extract the distribution from the deposition position as suggested by @hwennlof. I am interested in a source that irradiates the whole sensor surface to look at the total deposited charge, therefore I expect losing some particles.
Besides that, I wrote a source closer to the sensor to obtain more interactions.
Geometry.conf (63 Bytes)
main.conf (917 Bytes)
Detector.conf (271 Bytes)
Source.mac (10.2 KB)
but the difference is still present and I did not understand the deposited charge figures. Does the method “getTotalDepositedCharge())” reads the charge deposited along the whole particle track or only the charge deposited in the dut? I also tried enabling the Photoabsorption Ionization model but my simulations never finish (is it something I should expect for a my number of particles and photons?).
The only way of calculating the total charge deposited in dut is by analyzing the “deposition local position” as suggested by @hwennlof ?
Sorry to come back to the units but does the ROOTObjectWriter output (e.g. in “dut.charge_”) the number of electrons or the number of electron/hole pairs generated from the energy deposited? Thanks.
Umberto.
Hi!
The getTotalDepositedCharge() (when using [DepositionGeant4]) gives the number of charges deposited in all steps within the sensitive detector, i.e. the DUT. This means that you’ll get the sum of electrons and holes in the detector when using this function. In contrast, the charge_ in DepositedCharge gives the number of electrons (or holes) in a single deposit point. So, if you look in the DepositedCharge tree at dut.charge_, this just shows the charge deposited (electrons or holes, so not the sum of them) in a single step point for all the events. Two DepositedCharge objects are created for each point, one for electrons and one for holes. The unit will thus be in “number of electron charges”.
To get the total deposited charge from this, one has to sum up the charge in all the deposition points in an event. Note that the tree viewer does not display these things correctly, so you need to use an analysis script.
The PAI option can slow down the deposition calculation, but if your sensor is thin, it should be used. If I activate it with enable_pai = true in the config you sent, it works very nicely I would say. I’d recommend setting the log level a bit higher than FATAL, so one sees the events counting up. I would expect it to take a little longer, but it should still finish. Please let us know if it doesn’t, and we can focus in on that problem a bit more.
Kind regards,
Håkan
Hi~!
I’m sorry to bother you.
Would you mind telling me the version of allpix^2 you use or the specific use method of the function that you are using? When I tried to get the number of charge deposited by the MC particle using the same function as you, the system reported the following error:
error: no member named ‘getTotalDepositedCharge’ in ‘allpix::MCParticle’
output_charge_DepositedCharge.push_back(mc_part->getTotalDepositedCharge());
Hi @Isaac
fair enough, you caught us there. 
This is currently only available in the development version that will be released as Allpix Squared 3.0 in the near future…
Simon
hi~
Thanks all allpix-squared developers for your efforts. I’m really looking forward to the new version！
But for now, how do we do that analysis? I want to get the initial MCTruth Charge, which I think should be the deposition Charge. But I don’t have a good idea to get it.
Hi @Isaac
store DepositedCharge objects, loop over them and sum their getCharge() values. Make sure to not do double counting, electrons and holes are stored separately.
/Simon
What I don’t quite understand is the amount of deposition charge per event. How is the deposited charge stored? If you follow each step, is the number a bit too large? What rules are the storage of this object based on ? Can you tell me a little bit about it?
Dear @hwennlof
Thank you very much for your help. Your answer clarified the definitions and now I understand the figures. I got the total deposited charge with an analysis script by summing all the charges generated by each particle and I used the following lines of code:
for (int i = 0; i < mc_particle_tree->GetEntries(); ++i)
{mc_particle_tree->GetEntry(i);
for (auto &charge : deposited_charges)
{ if (charge->getType() == static_cast<allpix::CarrierType>(-1))
{ tCharge += charge->getCharge();
eh_pairs += 1; } } }
Regarding the pai model, I simulated 100000 particles with 200 cpu and the computational time is considerably longer. Without pai it only takes 1min:30s, while adding the model after 1h is still running. Do you think it is related to my source? Can it be a problem of step_length or range_cut? I noticed in the log file that it stays a lot of time executing the following type of line:
“(D) (E: 6947) [R:DepositionGeant4] Not storing MCTrack with ID 6”
I was wondering if I should expect these lines and if you know their meaning.
Thank you again
Best,
Umberto.
Ho @berto
wow, no, that’s certainly not expected. PAI usually runs some 5-10% slower, but that’s all. You might be unlucky and have an odd event… Which version are you on? If it’s not 2.4.1, please upgrade and try again.
By default we do not store MC particle information of particles that do not interact with the sensor, this is where that message is coming from.
You should, unless you set record_all_tracks = true in [DepositionGeant4] (see user manual)
Cheers,
Simon
I updated my version to the 2.4.1 and tried enabling “record_all_tracks” but nothing changed, it is still slowing down at these lines. Here you have the logs (trace format).
PAI_trace_log.txt (9.7 MB)
I am compiling the source code with make and maybe I am loosing something. Here you can see my cmake output.
cmake_output.txt (7.7 KB)
Is there a way to see the pai model log?
Thanks,
Umberto.
Hi @berto
have a look at the parameters described in the FAQ here: http://localhost:1313/docs/13_faq/06_debugging/#how-can-i-see-the-output-of-geant4 to see how you can make Geant4 talk to you.
Cheers,
Simon
Hi @simonspa
Thanks for the answer. I set the verbosity to 3 and I was able to see the Geant4 output. It seems that my program get stuck and continues to calculate always the same events (here the log).
output_verbosity3.txt (13.7 MB)
I also tried with the “example.conf” from the allpix folder by just adding the lines pai_model = paiphoton and enable_pai = true and I obtained the same result. Is there a way I can check my installation?
Best,
Umberto.
After a few searches on the forum, I think I am facing the same problem reported in a previous topic (Enable_pai flag in combination w/ gdml geometry and custom E-Field). From the Geant4 log, the particles seem stuck and I can finish my simulations only if I remove some geometry component.
I hope the problem with PAI model will be solved soon.
Thank you all for the support.
Umberto.