DepositedCharge from RootObjectWriter or DepositionGeant4

Simulation / Configuration Questions
21

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

22

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?

23

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 :slight_smile:
Best,
Umberto.

24

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

26

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.

27

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

28

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.

29

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.