Pith. sign in

REVIEW 2 major objections 5 minor 35 references

Gyrokinetic Simulations on Many- and Multi-core Architectures with the Global Electromagnetic Particle-In-Cell Code ORB5

T0 review · 2 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Pith's one-line read A refactored ORB5 gyrokinetic code, using one portable source with MPI, OpenMP and OpenACC, delivers effective performance on CPU and GPU supercomputers and scales to more than 24,000 GPUs.

desk verdict Solid, honest HPC porting paper—real engineering with open reporting of negative results; the main caveat is that the heavy-electron benchmark makes the 'production representative' claim shaky. read the letter →

arxiv 1908.02219 v2 pith:G3GCKQD7 submitted 2019-08-06 physics.comp-ph physics.plasm-ph

classification physics.comp-phphysics.plasm-ph
keywords gyrokineticsimulationparticle-in-cellGPUaccelerationOpenACCMPperformanceportabilityhigh-performancecomputingplasmaturbulence
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper sets out to show that a production-grade global electromagnetic gyrokinetic particle-in-cell code, ORB5, can run efficiently on modern hybrid CPU/GPU supercomputers without forking the source. It claims that a full refactoring, including structure-of-arrays particle data, an intermediate Larmor-ring data structure, OpenMP threading, and OpenACC GPU offloading, yields one codebase that performs well on CPU-only and GPU-accelerated nodes alike. Performance is reported on three leading systems using the identical source version, and the paper argues that the measured speedups and scalings demonstrate performance portability. The practical significance is that a community fusion code can follow hardware evolution through standard compiler directives instead of architecture-specific rewrites, which matters because gyrokinetic turbulence simulations are among the largest consumers of supercomputing time.

What carries the argument

The key mechanism is an intermediate 'Larmor ring data' structure that stores the real-space positions of Larmor markers separately from guiding centers. This turns the usual four-stage particle-in-cell loop into a six-stage loop—build Larmor, deposit, solve, get fields, gyroaverage, push—so that gyrokinetic finite-Larmor-radius operations are decoupled from ordinary particle-to-grid and grid-to-particle kernels. That decoupling allows standard PIC optimizations, notably sorting Larmor markers by grid cell to improve memory locality, and lets the same loops be offloaded to GPUs with OpenACC while MPI domain decomposition and domain cloning handle distributed memory. Particle data stays resident on the GPU, with only domain-crossing markers and field data transferred between host and device.

What would settle it

Run the same benchmark suite with the physical deuterium-to-electron mass ratio (about 1836) and a full production-length time loop, then compare per-step wall times and strong-scaling efficiencies; if the balance among particle kernels, the CPU-only field solve, and MPI communication shifts, the reported GPU speedups and scaling conclusions would not transfer.

Watch

Extended reading notes

Core claim

The central claim is that the refactored ORB5 achieves production-usable performance portability: the same source code, compiled with only architecture-specific compiler flags, runs across CPU-only and GPU-accelerated architectures and scales to tens of thousands of accelerators. On a single Summit node, using six V100 GPUs reduces wall time by about a factor of five overall and about eight for the GPU-resident kernels, with per-kernel speedups ranging from roughly five for deposition to thirty for field interpolation. Strong scaling is near ideal for CPU runs up to very large core counts; GPU runs scale well but lose efficiency faster because the field solver remains on the CPU and MPI communication grows relative to compute. The paper also shows that particle sorting speeds up deposition and field interpolation substantially but is not yet net-positive because the sort itself is costly. All timings include host-device and network transfers, and the tests use production-like parameters.

Load-bearing premise

The benchmarks are assumed to represent production runs even though they use electrons only 200 times lighter than ions instead of the physical ratio near 1836, and they cover only a small fraction of the time steps of a full simulation.

Editorial extensions

If this is right

  • A single ORB5 source now supports CPU-only and GPU runs, so scientists can move between systems without maintaining separate code versions.
  • On current hardware, GPU acceleration buys roughly a factor of five in per-node wall time, with the largest gains in field interpolation and particle push.
  • The CPU-only field solver is the main remaining bottleneck on GPUs; porting it should further improve speedups and reduce host-device transfers.
  • Particle sorting accelerates deposition and get-field by roughly 30 to 60 percent, so a cheaper sorting scheme would yield a net performance win.
  • Scaling to more than 24,000 GPUs is demonstrated, with near-ideal CPU scaling and somewhat weaker GPU scaling due to communication and the non-accelerated solver.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the field solver is moved to the GPU, the per-step data transfers that currently move field data between host and device would disappear, so the GPU scaling efficiency should approach the CPU versions' more closely.
  • A benchmark with the physical electron mass ratio would show whether the measured speedups hold when particle kernels take a different share of the runtime; that is the most natural next test of the paper's portability claim.
  • Other gyrokinetic PIC codes facing the same finite-Larmor-radius nonlocality could adopt the intermediate Larmor-ring data structure, since it cleanly separates physics-specific gyroaveraging from generic PIC kernels.
  • The clone-based use of six GPUs per node, achieved with two subdomains times three clones, suggests a general recipe for filling non-power-of-two accelerator counts on fat nodes.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 5 minor

Summary. The paper reports the refactoring of ORB5, a global electromagnetic gyrokinetic particle-in-cell code, to exploit modern hybrid HPC architectures. The refactoring introduces structure-of-arrays particle data, a separate Larmor-ring data structure, OpenMP multithreading for CPU multi-core, and OpenACC offloading for GPU acceleration, all retained in a single source code version. Performance is measured on three production systems (Marconi, Piz Daint, Summit) with configurations tuned at the application level, and the paper reports single-node kernel breakdowns, the effect of particle sorting, and strong/weak scaling up to 4096 nodes. The main claims are performance portability of the directive-based approach, a roughly 5x single-node GPU speedup on Summit, and near-linear CPU scaling with reduced but still useful GPU scaling at scale due to the non-accelerated field solver and communication overhead.

Significance. If the quantitative claims survive scrutiny, this is a valuable demonstration that a production-grade, physics-complete gyrokinetic PIC code can be made portable across CPU-only and GPU-accelerated leadership systems using directive-based programming, without rewriting the physics in a hardware-specific language. The paper's strengths include the explicit inclusion of all host-device and node-to-node transfer times in every measurement, honest reporting of negative results (particle sorting is net negative on both CPU and GPU, and GPU parallel efficiency drops at scale), and large-scale measurements up to more than 24,000 GPUs. These data are useful for the plasma-physics HPC community and for other legacy code refactoring efforts. However, the quantitative performance and scalability conclusions depend on the benchmark configuration being representative of production runs, and that representativeness is not yet established.

major comments (2)
  1. [Section 3, first paragraph (also Figs. 5, 7, 8)] The benchmarks use 'heavy' kinetic electrons with a mass ratio of only 200 instead of the physical ratio of about 1836, and only a small fraction of the timesteps of a production run. The adaptive Larmor-point count scales with the Larmor radius, so the heavy electrons have roughly three times the electron Larmor radius of physical electrons, which increases the cost of the electron gyroaveraging, build-Larmor, and deposition kernels. Since the field solve is the dominant non-accelerated kernel in the GPU runs (Fig. 5), a physical mass ratio would raise the field-solve fraction and likely reduce the reported GPU speedups (the factor ~5 overall and ~8 for GPU-enabled kernels on Summit in Sec. 3.2) and the GPU parallel efficiencies (47% for the smallest case in Sec. 3.4). The paper asserts that the tests are 'representative of production runs' but provides no sensitivity analysis or physical-mass-ratio data to support that assertion. Please add such a measurement or, at minimum, a quantitative argument showing that the kernel balance is insensitive to the electron mass ratio.
  2. [Sections 3.1-3.4] All timings are reported as single point values with no indication of the number of repetitions, the run-to-run variance, or whether the reported numbers are best, mean, or median. This is consequential for precise quantitative claims such as 'deposition routine is 59% faster with sorting' (Sec. 3.3) and the parallel efficiency of 47% (Sec. 3.4), which on shared HPC systems can be affected by run-to-run noise. Please report error bars or state how timing stability was assessed.
minor comments (5)
  1. [Figure 4 caption] The phrase 'The percentages of the total time are relative to the top bar' is unclear; please clarify which percentages are shown and against which reference they are normalized.
  2. [Figure 9 caption and surrounding text] Normalizing Summit speedups to a 4-GPU Piz Daint baseline is unconventional, since the two systems run with different numbers of GPUs and different domain decompositions; please explain the rationale more explicitly or provide a platform-relative baseline as well.
  3. [Section 2.2, Figure 3] The label '6-fold scheme' is introduced without an explicit list of the six stages; please state them in the text so the reader does not have to infer them from the figure.
  4. [Section 4] The term 'GPUDirect' is used without a definition or reference; please add a brief explanation or citation.
  5. [Section 3, first paragraph] The phrase 'heavy kinetic electrons only 200 times lighter than ions' is confusing; consider using 'reduced mass ratio of 200' for readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central performance and portability claims are direct wall-clock measurements on external HPC systems, not derived quantities.

full rationale

This paper is an empirical HPC engineering and benchmarking study. Its central claims are that the refactored ORB5 code runs on Summit, Piz Daint, and Marconi from a single source version, and that the adopted MPI/OpenMP/OpenACC implementation gives the reported speedups and scaling efficiencies. These claims are established by direct measurements of time-to-solution on those external machines, including all host-device and node-to-node transfers as stated in Section 3. There is no fitted parameter later renamed as a prediction, no theoretical quantity defined in terms of the result it is said to predict, and no derivation chain whose conclusion is equivalent to an input by construction. The only self-citations are to the authors' prior test-bed codes ('PIC-engine' and 'GK-engine') and to a bucket-sort study; these are cited as design precedents that guided implementation choices, not as proofs of the present benchmark results. Even if those test-bed studies were weak, the current performance numbers stand independently as measurements on production code. The use of heavy kinetic electrons (200 times lighter than ions) and a small fraction of a full simulation's time steps is a stated representativeness assumption, disclosed in Section 3, but it is a potential limitation for extrapolating to full production workloads, not a circular step. No enumerated circularity pattern applies, so the appropriate score is 0.

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

The paper is an empirical performance study; no new physical entities or fitted scientific models are introduced. The central results rest on the representativeness of the chosen benchmarks, correct compiler behavior, and reliable timing measurements.

free parameters (1)
  • Parallel configuration (subdomain, clone, thread counts) = Varies per platform: e.g., 4 subdomains x 12 threads on Skylake; 2 subdomains x 3 clones for GPU runs; 2 subdomains x…
    Chosen by hand based on performance measurements; the reported speedups and scaling depend on these choices.
assumptions (3)
  • domain assumption The benchmark cases with heavy electrons and a truncated number of time steps are representative of production ORB5 workloads.
    Section 3 states 'the simulation parameters used in this paper are representative of production runs' but uses a reduced electron mass ratio and a small number of steps. If the computational profile differs substantially in real full-mass-ratio runs, performance conclusions may shift.
  • domain assumption The Intel and PGI compilers correctly implement the OpenMP and OpenACC features used by ORB5 on the target systems.
    Section 2.3 states OpenACC is a new standard with limited compiler support, and the paper relies on PGI 18.10 and Intel 17.0.4. Compiler behavior directly determines the measured performance.
  • domain assumption Wall-clock timings are stable and include all relevant communication and data-transfer overheads.
    The paper asserts 'all timings reported include all host-device and all across-node data transfers' (Section 3). It does not report repeated runs or variance, so a single set of timings is assumed to represent performance.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Gyrokinetic Simulations on Many- and Multi-core Architectures with the Global Electromagnetic Particle-In-Cell Code ORB5." pith.science (2026). https://pith.science/paper/G3GCKQD7

@misc{pith2026190802219,
  author       = {Pith},
  title        = {Pith review of: Gyrokinetic Simulations on Many- and Multi-core Architectures with the Global Electromagnetic Particle-In-Cell Code ORB5},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/G3GCKQD7}},
  note         = {Machine review of arXiv:1908.02219}
}
read the original abstract

Gyrokinetic codes in plasma physics need outstanding computational resources to solve increasingly complex problems, requiring the effective exploitation of cutting-edge HPC architectures. This paper focuses on the enabling of ORB5, a state-of-the-art, first-principles-based gyrokinetic code, on modern parallel hybrid multi-core, multi-GPU systems. ORB5 is a Lagrangian, Particle-In-Cell (PIC), finite element, global, electromagnetic code, originally implementing distributed parallelism through MPI-based on domain decomposition and domain cloning. In order to support multi/many cores devices, the code has been completely refactored. Data structures have been re-designed to ensure efficient memory access, enhancing data locality. Multi-threading has been introduced through OpenMP on the CPU and adopting OpenACC to support GPU acceleration. MPI can still be used in combination with the two approaches. The performance results obtained using the full production ORB5 code on the Summit system at ORNL, on Piz Daint at CSCS and on the Marconi system at CINECA are presented, showing the effectiveness and performance portability of the adopted solutions: the same source code version was used to produce all results on all architectures.

Figures

Figures reproduced from arXiv: 1908.02219 by the authors.

Figure 1
Figure 1. Larmor markers around a guiding center in the poloi [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. MPI 2-level parallelization of ORB5 in subdomains [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Main stages of an ORB5 time step. The 6-fold scheme [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Comparison of timings for different MPI and OpenMP p [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: ORB5 performance on different architectures: Skyl [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Comparison with and without sorting on Skylake (4 s [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Strong and weak scalings on Marconi (a), Piz Daint ( [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Breakdown of ORB5 kernel timings on the small data s [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 9
Figure 9. Figure 9: Comparison of strong scalings on Summit (cross sym [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

35 extracted references · 35 canonical work pages

  1. [1]

    Garbet, Y

    X. Garbet, Y. Idomura, L. Villard, and T.H. W atanabe. Gy- rokinetic simulations of turbulent transport. Nucl. Fusion , 50(4):043002, apr 2010

  2. [2]

    Dannert, A

    T. Dannert, A. Marek, and M. Rampp. Porting Large HPC Ap- plications to GPU Clusters: The Codes GENE and VERTEX. Adv. Parallel Comput. , 25:305–314, 2014

  3. [3]

    CGYRO Performance on Power9 CPUs and Volta GPUs

    I Sfiligoi, J Candy, and M Kostuk. CGYRO Performance on Power9 CPUs and Volta GPUs. In Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. No tes Bioinformatics), volume 11203 LNCS, pages 365–372. Springer, Cham, jun 2018

  4. [4]

    X. Meng, X. Zhu, P. W ang, Y. Zhao, X. Liu, B. Zhang, Y. Xiao, W. Zhang, and Z. Lin. Heterogeneous programming and op- timization of gyrokinetic toroidal code and large-scale pe rfor- mance test on th-1a. In Julian Martin Kunkel, Thomas Ludwig, and Hans W erner Meuer, editors, Supercomputing, pages 81–96, Berlin, Heidelberg, 2013. Springer Berlin Heidelberg

  5. [5]

    Madduri, K

    K. Madduri, K. Ibrahim, S. Williams, E.-J. Im, S. Ethier, J. Shalf, and L. Oliker. Gyrokinetic toroidal simulations o n leading multi- and manycore HPC systems. In Proc. 2011 Int. Conf. High Perform. Comput. Networking, Storage Anal. - SC ’11, page 1, New York, New York, USA, 2011. ACM Press

  6. [6]

    D’Azevedo, S

    E. D’Azevedo, S. Abbott, T. Koskela, P. W orley, S.-H. Ku, S. Ethier, E. Yoon, M. S. Shephard, R. Hager, J. Lang, et al. The fusion code xgc: Enabling kinetic study of multiscale ed ge turbulent transport in iter. In Exascale Scientific Applications , pages 529–552. Chapman and Hall/CRC, 2017

  7. [7]

    Abbott and E

    S. Abbott and E. D’Azevedo. Physics based optimization o f particle-in-cell simulations on gpus. In APS Meeting Abstracts , 2016

  8. [8]

    Tang and Z

    W. Tang and Z. Lin. Global gyrokinetic particle-in-cell simula- tion. In Exascale Scientific Applications , pages 507–528. Chap- man and Hall/CRC, 2017

Show all 35 references
  1. [9]

    T.-M. Tran, K. Appert, M. Fivaz, G. Jost, J. Vaclavik, and L. Villard. Global gyrokinetic simulation of ion-temperat ure- gradient-driven instabilities using particles. In J. W. Co nnor, E. Sindoni, and J. Vaclavik, editors, Th. of Fusion Plasmas , volume 18, page 45. Societ` ...

  2. [10]

    Jolliet, A

    S. Jolliet, A. Bottino, P. Angelino, R. Hatzky, T.-M. Tr an, B.F. Mcmillan, O. Sauter, K. Appert, Y. Idomura, and L. Villard. A global collisionless PIC code in magnetic coordinates. Comput. Phys. Commun. , 177(5):409–425, sep 2007

  3. [11]

    Bottino, T

    A. Bottino, T. Vernay, B. Scott, S. Brunner, R. Hatzky, S . Jol- liet, B.F. McMillan, T.-M. Tran, and L. Villard. Global simu - lations of tokamak microturbulence: Finite- β effects and colli- sions. Plasma Phys. Control. Fusion , 53(12):124027, dec 2011

  4. [12]

    Lanti, N

    E. Lanti, N. Ohana, N. Tronko, T. Hayward-Schneider, A. Bot- tino, B.F. McMillan, A. Mishchenko, A. Scheinberg, A. Bian- calani, P. Angelino, S. Brunner, J. Dominski, P. Donnel, C. Gheller, R. Hatzky, A. Jocksch, S. Jolliet, Z.X. Lu, J.P. Martin Collar, I. Novikau, E. Sonnendr...

  5. [13]

    Kim and S.E

    C.C. Kim and S.E. Parker. Massively Parallel Three- Dimensional Toroidal Gyrokinetic Flux-Tube Turbulence Si m- ulation. J. Comput. Phys. , 161(2):589–604, jul 2000

  6. [14]

    R. Hatzky. Domain cloning for a particle-in-cell (PIC) code on a cluster of symmetric-multiprocessor (SMP) computers. Parallel Comput., 32(4):325–330, apr 2006. 12

  7. [15]

    https://git-scm.com

    Git web homepage. https://git-scm.com

  8. [16]

    https://jenkins.io

    Jenkins web homepage. https://jenkins.io

  9. [17]

    Scheinberg, S

    A. Scheinberg, S. Ethier, C.-S. Chang, G. Chen, R. Bird, S. Slat- tery, and P. W orley. Kokkos and Fortran in the Exascale Com- puting Project plasma physics code XGC. In Proc. 2019 Int. Conf. High Perform. Comput. Networking, Storage Anal. - SC ’19, page 3. ACM Press, 2019

  10. [18]

    D. A. Beckingsale, T. R. W. Scogland, J. Burmark, R. Horn ung, H. Jones, W. Killian, A. J. Kunen, O. Pearce, P. Robinson, and B. S. Ryujin. RAJA: Portable Performance for Large-Scale Sc i- entific Applications. In 2019 IEEE/ACM International Work- shop on Performance, Portabili...

  11. [19]

    R. Keryell. SYCL: A Single-Source C++ Standard for Hete ro- geneous Computing. In 2019 IEEE/ACM International Work- shop on Performance, Portability and Productivity in HPC (P3HPC), 2019

  12. [20]

    H. Sugama. Gyrokinetic field theory. Phys. Plasmas , 7(2):466– 480, feb 2000

  13. [21]

    Tronko, A

    N. Tronko, A. Bottino, C. Chandre, and E. Sonnendr¨ ucke r. Hierarchy of second order gyrokinetic Hamiltonian models for particle-in-cell codes. Plasma Phys. Control. Fusion , 59(6):064008, jun 2017

  14. [22]

    L¨ utjens, A

    H. L¨ utjens, A. Bondeson, and O. Sauter. The CHEASE code for toroidal MHD equilibria. Comput. Phys. Commun. , 97(3):219– 260, sep 1996

  15. [23]

    Dominski, B.F

    J. Dominski, B.F. McMillan, S. Brunner, G. Merlo, T.-M. Tran, and L. Villard. An arbitrary wavelength solver for global gy roki- netic simulations. Application to the study of fine radial st ruc- tures on microturbulence due to non-adiabatic passing elec tron dynamics. Phys. Pl...

  16. [24]

    Vernay, S

    T. Vernay, S. Brunner, L. Villard, B.F. McMillan, S. Jol liet, T.-M. Tran, A. Bottino, and J.P. Graves. Neoclassical equi- libria as starting point for global gyrokinetic microturbu lence simulations. Phys. Plasmas , 17(12):122301, dec 2010

  17. [25]

    McMillan, S

    B.F. McMillan, S. Jolliet, T.-M. Tran, L. Villard, A. Bo ttino, and P. Angelino. Long global gyrokinetic simulations: Sour ce terms and particle noise control. Phys. Plasmas , 15(5):052308, may 2008

  18. [26]

    McMillan, P

    B.F. McMillan, P. Hill, A. Bottino, S. Jolliet, T. Verna y, and L. Villard. Interaction of large scale flow structures with g y- rokinetic turbulence. Phys. Plasmas , 18(11):112503, nov 2011

  19. [27]

    S. Jolliet. Gyrokinetic Particle-In-Cell Global Simula- tions of Ion-Temperature-Gradient and Collisionless-Tra pped- Electron-Mode Turbulence in Tokamaks . PhD thesis, EPFL, Lausanne, 2009

  20. [28]

    Mishchenko, A

    A. Mishchenko, A. Bottino, R. Hatzky, E. Sonnendr¨ ucke r, R. Kleiber, and A. K¨ onies. Mitigation of the cancellation p rob- lem in the gyrokinetic particle-in-cell simulations of glo bal elec- tromagnetic modes. Phys. Plasmas , 24(8):081206, aug 2017

  21. [29]

    Mishchenko, A

    A. Mishchenko, A. Bottino, A. Biancalani, R. Hatzky, T. Hayward-Schneider, N. Ohana, E. Lanti, S. Brunner, L. Vil - lard, M. Borchardt, R. Kleiber, and A. K¨ onies. Pullback scheme implementation in ORB5. Comput. Phys. Commun. , 238:194– 202, may 2019

  22. [30]

    Jocksch, N

    A. Jocksch, N. Ohana, E. Lanti, A. Scheinberg, S. Brunne r, C. Gheller, and L. Villard. Prediction of the inter-node com mu- nication costs of a new gyrokinetic code with toroidal domai n. In R. Wyrzykowski, J. Dongarra, E. Deelman, and K. Kar- czewski, editors, Parallel Proce...

  23. [31]

    Hariri, T.-M

    F. Hariri, T.-M. Tran, A. Jocksch, E. Lanti, J. Progsch, P. Mess- mer, S. Brunner, C. Gheller, and L. Villard. A portable platf orm for accelerated pic codes and its application to gpus using o pe- nacc. Computer Physics Communications , 207:69 – 82, 2016

  24. [32]

    Ohana, A

    N. Ohana, A. Jocksch, E. Lanti, T.-M. Tran, S. Brunner, C. Gheller, F. Hariri, and L. Villard. Towards the optimiza- tion of a gyrokinetic Particle-In-Cell (PIC) code on large- scale hybrid architectures. In J. Phys. Conf. Ser. , volume 775, page 012010. IOP Publishing, nov 2016

  25. [33]

    https://www.openmp.org/

    OpenMP web homepage. https://www.openmp.org/

  26. [34]

    https://www.openacc.org/

    OpenACC web homepage. https://www.openacc.org/

  27. [35]

    Jocksch, F

    A. Jocksch, F. Hariri, T.-M. Tran, S. Brunner, C. Ghelle r, and L. Villard. A bucket sort algorithm for the particle-in- cell method on manycore architectures. In R. Wyrzykowski, E. Dee l- man, J. Dongarra, K. Karczewski, J. Kitowski, and K. Wiatr, editors, Parallel Processing...

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.