---
title: 'AvalancheMicroscopic: CUDA Microscopic Simulator'
url: https://www.emergentmind.com/topics/avalanchemicroscopic
type: topic
---

# AvalancheMicroscopic: CUDA Microscopic Simulator

Searching arXiv for the target paper and closely related Garfield++ context.
arXiv search query: 2509.15377 Garfield++ AvalancheMicroscopic CUDA
AvalancheMicroscopic is the fully microscopic, collision-by-collision avalanche simulator in Garfield++, the gaseous-detector simulation toolkit used across design, operation, and calibration workflows. Within Garfield++, it is the most physically detailed and the most computationally demanding charge-transport algorithm: it follows individual electrons through microscopic free flights and collisions, creates secondaries in ionizing interactions, and continues this process until the avalanche terminates. In the CUDA implementation described in “Accelerating Garfield++ with CUDA,” AvalancheMicroscopic is ported to NVIDIA GPUs with the explicit goal of preserving the established Garfield++ physics and code structure while making large microscopic avalanche simulations practical for micro-pattern gaseous detectors [2509.15377].

## 1. Position within Garfield++

Garfield++ exposes three charge-transport algorithms, distinguished by the level at which transport is represented. AvalancheMicroscopic is the only one that resolves avalanches at the collision level rather than through macroscopic transport coefficients.

| Algorithm | Transport level | Characterization |
|---|---|---|
| Runge–Kutta–Fehlberg | Macroscopic | drift-line integration |
| AvalancheMC | Mesoscopic | stepwise transport using macroscopic coefficients plus Monte Carlo diffusion |
| AvalancheMicroscopic | Microscopic | fully microscopic tracking of electrons, modelling each collision individually |

AvalancheMicroscopic performs what the paper calls “microscopic avalanche simulations.” For each electron in the gas, it follows the motion in the electric field, determines the times and types of collisions with gas molecules based on microscopic cross sections from Magboltz, and handles ionization, attachment, elastic scattering, and related processes one collision at a time. In an ionizing collision, new secondary electrons are created and appended to the avalanche stack; each secondary is then tracked in the same manner until it is absorbed, exits the region of interest, or otherwise terminates. Detector gain is defined as the ratio of the number of electrons at the end of the avalanche to the number of starting electrons, and in the triple-GEM case study typical gains reach \(10^{4}\)–\(10^{7}\), so a single initial electron can generate \(10^{4}\)–\(10^{7}\) tracked electrons [2509.15377].

## 2. Microscopic transport and avalanche evolution

The physical model follows the established Garfield++ and Magboltz methodology. The benchmarks use micro-pattern gaseous detectors with numerically computed electric fields from ANSYS via finite or boundary element methods; those fields are stored in complex maps and accessed through an Octree for fast lookup. The processes represented are electron drift in an electric field, microscopic collisions with gas molecules, ionization, non-ionizing collisions, and termination processes such as electrons leaving the sensitive region or being absorbed. Penning transfers are explicitly disabled in the GPU version for now.

Algorithmically, AvalancheMicroscopic consists of electron transport plus stack processing. For each active electron, identified by status code \(0\), the code checks that the position is valid, finds the local field \(\vec{E}(\vec{x})\), adds a random time step until the next collision, propagates the electron during that step, processes the collision, and stores the updated state. The time to collision is sampled from the exponential distribution
\[
P(\Delta t) = \nu \exp(-\nu \Delta t),
\]
where \(\nu\) is the total collision rate. Equivalently, a free-flight distance can be sampled from
\[
P(\Delta s) = \frac{1}{\lambda}\exp\left(-\frac{\Delta s}{\lambda}\right).
\]
When the collision is ionizing, a secondary electron with its own energy and direction is created and added to the active stack. For non-ionizing collisions, the electron energy, direction, or status is modified without creating a new electron. The transport loop is repeated many times per electron; the diagram in the paper annotates \(1\textrm{--}100\times\) iterations within a single transport step, depending on conditions.

After all active electrons have been advanced through their current transport step, stack processing removes electrons whose status code is no longer \(0\) and appends newly created electrons. The cycle repeats until no active electrons remain. Although macroscopic growth can be summarized through an effective Townsend coefficient and mean gain scaling, AvalancheMicroscopic does not impose avalanche growth analytically; it emerges statistically from the discrete sequence of microscopic ionizing collisions [2509.15377].

## 3. Computational structure and scaling

AvalancheMicroscopic is computationally demanding because every secondary electron is tracked individually and because each electron typically undergoes many collisions before termination. On the CPU, Garfield++ tracks electrons sequentially, one after another, so runtime is effectively proportional to the total number of electrons created in the avalanche. In high-gain structures this becomes the dominant cost of fully microscopic simulation.

The implementation is especially suitable for parallel execution because each electron is treated independently and there are no space-charge or inter-electron interactions in this version. This makes the problem “embarrassingly parallel” at the electron level. The principal practical cost drivers are therefore the total avalanche size and the repeated access to field maps and gas data during microscopic transport. In the GEM examples used in the paper, field maps occupy about 100 MB–2 GB of device memory. These maps are copied once during initialization and reused thereafter, so their transfer time is not included in per-avalanche timings [2509.15377].

## 4. CUDA realization

The CUDA port parallelizes both parts of the algorithm. In the electron-transport stage, each active electron is assigned to a GPU thread; each thread performs the same sequence of operations—position check and field lookup, random time step to collision, collision processing, and state storage. Stack processing is also executed on the GPU through Thrust, which provides the parallel compaction and insertion operations needed to remove terminated electrons and append newly created ones.

A central design decision is that the core physics routines remain identical between CPU and GPU versions as far as possible. The implementation deliberately avoids physics-motivated rewrites for performance alone. This has several architectural consequences. Standard C++ STL containers are not supported on the device, so static data such as field maps and gas data are reimplemented as C-style arrays and structs in `*GPU` versions of Garfield++ classes, while dynamic stack handling uses Thrust rather than raw STL containers. Garfield++’s extensive use of dynamic polymorphism is flattened on the GPU side by replacing virtual dispatch with explicit class-type enumerations and `switch` or `if` selection. The codebase remains largely unified through preprocessor macros.

The paper also emphasizes GPU-specific limits. Thread occupancy is non-ideal because avalanches grow and decay in time: many cores are idle at the beginning, work becomes imbalanced during multiplication, and occupancy drops again near termination. Branch-heavy microscopic transport induces warp divergence because different threads encounter different collision types, termination states, and field-map regions. The authors explicitly accept this cost to preserve algorithmic fidelity.

For validation, random-number generation is handled by a pre-generated strategy rather than a native device RNG. Garfield++ uses ROOT’s `TRandom3` on the CPU; instead of porting it, the implementation generates 14.5 GB of random numbers on the CPU, transfers them to GPU memory, and maps each electron’s random draws to a dedicated segment indexed by electron ID. This allows CPU and GPU to use the same random sequences and supports bit-level comparison of physical outputs and gain distributions, isolating remaining discrepancies to floating-point ordering [2509.15377].

## 5. Integration, benchmarks, and practical use

The CUDA implementation is integrated into the Garfield++ main codebase, in the master branch since June 2024 with commit hash `c7d1b2f...`. Existing applications can enable GPU execution with minor source changes. The standard construction remains unchanged:

```cpp
AvalancheMicroscopic aval;
aval.SetSensor(&sensor);
```

GPU execution is selected by:

```cpp
aval.SetRunModeOptions(MPRunMode::GPUExclusive, 0);
```

where `MPRunMode::GPUExclusive` requests full GPU execution and the second argument is the GPU device index. Endpoints are then retrieved through GPU-specific accessors:

```cpp
unsigned int endpoints =
    aval.GetNumberOfElectronEndpointsGPU();

double xe1, ye1, ze1, te1, e1;
double xe2, ye2, ze2, te2, e2;
int status;

for (unsigned int i = 0; i < endpoints; ++i) {
    aval.GetElectronEndpointGPU(
        i, xe1, ye1, ze1, te1, e1,
           xe2, ye2, ze2, te2, e2, status
    );
}
```

The CPU methods remain available. Because GPU launch and transfer overhead can dominate for small avalanches, Garfield++ also provides:

```cpp
aval.SetRunModeOptions(MPRunMode::GPUWhenAppropriate, 0);
```

In this mode, the library chooses CPU or GPU internally based on avalanche size.

The benchmarks illustrate two distinct scaling regimes. In the single-GEM case, initial electrons are varied from small numbers up to thousands, gains are moderate, CPU runtime grows linearly with \(N_{\text{initial}}\), and GPU runtime has a non-zero turn-on offset followed by a smaller linear slope. For an NVIDIA A100 versus the best tested CPU, the cross-over occurs at about \(N_{\text{initial}} \approx 350\), and for large \(N_{\text{initial}}\) the speed-up approaches \(S \approx 70\). In the triple-GEM case, the calculation starts from a single electron and pressure is varied to tune gain from about \(10^{4}\) at 1 bar up to \(10^{6}\)–\(10^{7}\). There the relevant variable is the final avalanche size \(N_{\text{final}}\): both CPU and GPU runtimes scale linearly with \(N_{\text{final}}\), GPU overtakes CPU around \(N_{\text{final}} \sim 10^{4}\), and measured A100 speed-ups are about \(60\) at \(G \sim 10^{6}\) and about \(100\) at \(G \sim 10^{7}\). This suggests that the main operational effect of CUDA is not merely faster execution of existing workflows, but a shift in which fully microscopic studies become computationally routine, including large parameter scans, high-statistics gain studies, discharge-probability investigations, and response-function calculations [2509.15377].

## 6. Validation, scope, and open development directions

The validation strategy is deliberately stringent. CPU and GPU are run on the same single large avalanche using the shared random-number pool: the event contains \(1.2 \times 10^{5}\) electrons and 160 total iterations of the transport loop. Up to just after the avalanche peak, CPU and GPU outputs are identical. Afterwards, a small deviation in avalanche size appears and reaches about \(0.15\%\). Tracking individual electrons shows positional differences at the \(10^{-8}\) level, arising from floating-point rounding differences caused by distinct execution orders on CPU and GPU. The paper interprets this as the irreducible numerical discrepancy expected when identical algorithms run on different architectures and compilers. A common misconception is that the GPU implementation changes the underlying physics for performance reasons; the validation results support the opposite reading, namely that the same physics and numerical steps are preserved and that the residual differences are cumulative floating-point effects rather than altered transport or collision models.

The present scope remains bounded. GPU AvalancheMicroscopic requires an NVIDIA GPU with CUDA support and uses CUDA-specific libraries, notably Thrust, so AMD and Intel GPUs are not supported in this version. Penning transfer is currently disabled on the GPU. The implementation is not yet available for semiconductors and not yet implemented for gaseous detectors with magnetic fields. Memory demand can also be substantial because the field maps alone occupy 100 MB–2 GB per sensor in the GEM examples, and validation runs with pre-generated random numbers add further device-memory pressure.

The paper identifies several development directions. These include extending GPU support to Penning transfers, semiconductors, and gaseous detectors with magnetic fields; revisiting the branching-heavy algorithm to better align it with GPU execution; exploring abstraction layers such as Kokkos for non-NVIDIA back ends while addressing Thrust dependencies; and distributing work across multiple devices through multi-GPU support. A plausible implication is that AvalancheMicroscopic is evolving from a specialized microscopic engine used selectively for expensive detector studies into a general-purpose high-fidelity transport backend for large-scale simulation campaigns, provided that these remaining physics and portability gaps are closed [2509.15377].

Source: https://www.emergentmind.com/topics/avalanchemicroscopic