Avalanche photons in Garfield++

Garfield++
1

Dear all

I have a question regarding the handling of avalanche photons in AvalancheMicroscopic.

What I do in my code is to extract from TrackHeed the number of clusters, loop over all the clusters electrons and for each one start the avalanche with AvalancheElectron. After that I call GetNumberOfPhotons() but I always get 0 photons for every avalanche.

I’m using Ar/CO2/Isobutane 93/5/2 with Penning effect enabled, but I would expect on a big statistics at least some photon (in 5k avalanches I always get 0).

I have also tried to turn on/off EnablePhotonTransport in my AvalancheMicroscopic object, but I didn’t observed any change.

I’m wondering if this is not the right method or I’m missing something else.

Is it possibile that if I hadn’t turned on MediumMagboltz::EnableDeexcitation() before the production of my gas file I can’t get the avalanche photons information?

I remembered that I tried to do it with also EnableRadiationTrapping and the Magboltz simulation was completely stucked at high fields (order of 10k V/cm).

Thank you so much!

2

Welcome to the ROOT forum! Perhaps @hschindl can help you with this question

Aaron

4

Hello @lomarcel

Is it possibile that if I hadn’t turned on MediumMagboltz::EnableDeexcitation() before the production of my gas file I can’t get the avalanche photons information?

AvalancheMicroscopic doesn’t use the transport tables from the gas file; it computes the collision rates from the Magboltz cross-sections at run time. So long as you’re calling EnableDeexcitation() in the same job that runs the avalanches you’re good.

I’m using Ar/CO2/Isobutane 93/5/2 with Penning effect enabled

Photons are only produced by the de-excitation cascade after an excitation, which is only simulated if de-excitation is enabled. With Penning transfer alone, GetNumberOfPhotons() will always return 0. If you’re already calling EnableDeexcitation in that job, can you try enabling de-excitation without enabling Penning?

Looking at the code, an EnablePenningTransfer call followed by EnableDeexcitation switches Penning off. However, nothing in EnablePenningTransfer switches de-excitation off, even though it prints “Deexcitation handling will be switched off”. Are they meant to be mutually exclusive models, or is this a bug, @hschindl?

I have also tried to turn on/off EnablePhotonTransport in my AvalancheMicroscopic object, but I didn’t observed any change.

If de-excitation isn’t enabled, then AvalancheMicroscopic::EnablePhotonTransport() has no photons to transport.

I remembered that I tried to do it with also EnableRadiationTrapping and the Magboltz simulation was completely stucked at high fields (order of 10k V/cm).

I don’t think it’s related, but I also don’t know what could be behind this.

In any case, can you attach a reproducer and the job’s stdout/stderr? And the Garfield revision too, if you can.

Cheers,

Gabriel

5

hi @gabrielribcesario thank you for your help

Looking at my code I was enabling the de excitation before enabling the Penning transfer, so maybe this can explain why. I tried, as you suggested, to enable only the de excitation without the Penning transfer and I’ve observed two interesting things.

  1. If, in my AvalancheMicroscopic object the EnableMultithreading() option is activated the code at some points aborts due to a double free or corruption (out) Aborted (core dumped) error. Investigating a little bit further (compiling the macro with ASan) seems that TransportPhotons is somehow having some issues with the allocation of the memory:
ERROR: AddressSanitizer: attempting double-free 

freed by thread T61 here:
#1 Garfield::AvalancheMicroscopic::TransportPhoton(...)

previously allocated by thread T49 here:
#1 Garfield::AvalancheMicroscopic::TransportPhoton(...)
  1. So I tried disabling the multithreading and my macro was completely stucked. The only error that appeared was:

MediumMagboltz::CalcDiscreteLineCf: cfOth > cfOpt!
cfOpt = 110538.41
cfOth = 110538.41
cf discrete = 4.6713098e+08

It appeared several times with different values.

How do you think I can solve this?

Thank you for your support!

Lorenzo

6

Hi @lomarcel

Thanks for the details. Both problems, the double free with multithreading and the hang with CalcDiscreteLineCf: cfOth > cfOpt!, are fixed on the current master. Please update and try again.

By the way: with radiation trapping enabled, master limits the number of photon interactions per primary photon with AvalancheMicroscopic::SetPhotonTransportLimit(n) (default 1000). Photons still pending when that limit is hit are stored with status StatusCalculationAbandoned. It’s worth checking how many you get, and raising the limit if that number isn’t negligible.

Let me know how it goes, and please post the Garfield revision, reproducer and the job’s stdout/stderr as text files if anything still misbehaves.

Cheers,

Gabriel

7

Hi @gabrielribcesario

Thank you so much for your answer!

Actually I’m working through cvms, in particular sourcing:

/cvmfs/sft.cern.ch/lcg/views/LCG_110/x86_64-el9-gcc14-opt/share/Garfield/setupGarfield.sh

Do you know by chance where I can source the most recent Garfield++ release?

Thank you for your support

Cheers

Lorenzo

8

Hi @lomarcel

I just checked, and neither fix is in an LCG release yet.

However, they are in the dev3 nightly view (source /cvmfs/sft-nightlies.cern.ch/lcg/views/dev3/latest/x86_64-el9-gcc14-opt/setup.sh).

Alternatively, you can build Garfield++ from source (instructions here) and keep using the LCG view for the dependencies.

Cheers,

Gabriel