I am simulating the deposited charge on a silicon sensor and I was wondering what is the difference between the “deposited_charge” (deposited charge per event) from the module DepositionGeant4 and the DepositedCharge saved by the RootObjectWriter? Which is the unit measure? The “type_” should contain information on the particles which have deposited the charge? In the global_position branch, which quantities are contained in R0, Eta, Mag2… ?
In my example, I expect to see a difference between the deposited charge in two sensor active areas (1mm^2 and 2mm^2). Still, I am not getting the expected output by making the integral of the “deposited charge per event” histogram. Maybe I am missing something (the sensor is 45um thick and the source is 6 MeV electrons).
The DepositionGeant4 simply fills a histogram, but there is nothing else you can do with this, it really just is a histogram for you to look at and to gauge whether your simulation went alright
The ROOTObjectWriter stores the actual result of your simulation, so the individual objects that have been simulated. Here, DepositedCharges are Allpix Squared objects that you can use in your analysis.
A few analysis examples (in C and Python) are available in the repository:
On a sidenote: usually it is not necessary to store all DepositedCharge ojbects, as typically you will look only at e.g. PixelHit or PixelCharge objects. Excluding them from storage will save you significant disk space as well as simulation speed. Have a look at the object description in the manual:
And also, what is the unit measure of the different objects from RootObjectWriter? The “type_” should contain information on the particles which have deposited the charge? In the global_position branch, which quantities are contained in R0, Eta, Mag2… ? I tried looking at the AllPix source code, but I am still not finding their definitions.
The left plot shows the charge per event which are deposited.
The right plot shows the charges that reached the implant in the DUT in total, i.e. the sum for all events.
Edit: I have to correct, I’m not sure the right plots shows the charges that reached the implant. Maybe you can provide more details on how you obtained the plots? But in any case, if you want to do analysis go with the data from ROOTObjectWriter and use an analysis script as Simon mentioned.
Note to @slachnit we should probably massively extend the documentation of the object types including their interface in the actual manual. Could you please take care of that?
Note to @slachnit we should probably massively extend the documentation of the object types including their interface in the actual manual. Could you please take care of that?
Thank you both, I checked the src/object folder and I found some interesting information.
I assume that the charge from DepositionGeant4 output plot is a histogram with a sum for all the events of charge deposition from each event (we can see the peak at 0 since many particles have not interacted with the dut, see img “DepCharge_DG4.PNG”).
I tried reading the MCParticle as in the analysis file by looping over all the particles and calling the “getTotalDepositedCharge” method:
mc_particle_branch->SetObject(&input_particles);
for (int i = 0; i < mc_particle_tree->GetEntries(); ++i)
{ mc_particle_tree->GetEntry(i);
for (auto &mc_part : input_particles)
{ h->Fill(mc_part->getTotalDepositedCharge());} }
With this code, I get a third histogram (see img “DepCharge_fromTotDepCharge.PNG”), different to the others. I assume this corresponds to the counts of particles which deposited a certain number of electrons in the detector. If this is correct, I still cannot explain the peaks in the results close to zero.
To calculate the total deposited charge, I calculate the weighted sum of all the bins. Is it correct?
I am using “number_of_events = 1000000” and “number_of_particles = 1” in the DepositionGeant4. What is the difference between the two? Is it a difference in how the charge carriers are treated during diffusion?
From the point of view of the units, from the documentation, I have to assume that the “dut.charge_” is expressed everywhere in number of electrons, is there a way of changing the framework unit to Coulomb from the configuration file?
Here you can find my configuration files (note that my source is not monoenergetic and both gamma and electrons are produced). main.conf (911 Bytes) source.mac (9.7 KB) Detector.conf (204 Bytes) Geometry.conf (205 Bytes)
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.
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.
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.
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.
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.
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.
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.
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.
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());
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…
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.
This is currently only available in the development version that will be released as Allpix Squared 3.0 in the near future…