Pith. sign in

REVIEW 3 major objections 7 minor 61 references

Building an Accelerated OpenFOAM Proof-of-Concept Application using Modern C++

T0 review · 3 major / 7 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A single standards-compliant C++ codebase, switched by one compiler flag, can offload the assembly phase of OpenFOAM's laplacianFoam to NVIDIA GPUs, reaching up to 11.14x speedup over a full MPI node on the largest mesh tested.

desk verdict A credible PSTL/OpenFOAM GPU proof-of-concept, but the 'just a compiler flag' claim is untested without a -stdpar=multicore baseline. read the letter →

arxiv 2507.18268 v1 pith:KMBKP65L submitted 2025-07-24 cs.MS cs.PFcs.PL

Giulio Malenza , Giovanni Stabile , Filippo Spiga , Robert Birke , Marco Aldinucci This is my paper · ORCID
classification cs.MScs.PFcs.PL
keywords OpenFOAMGPUaccelerationC++17parallelalgorithmsPSTLstdparNVIDIAHPCSDKlaplacianCUDAUnifiedMemory
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

This paper claims that a single C++ codebase using only the standard library's parallel algorithms can run an OpenFOAM application on multicore CPUs or NVIDIA GPUs by changing one compiler flag. It demonstrates this on laplacianFoam, OpenFOAM's simplest solver, porting the assembly phase (the Laplacian operator) and the PCG linear solver to C++17 execution policies with the nvc++ '-stdpar' mode and CUDA Unified Memory. The load-bearing result is that assembly-phase speedups reach 11.14x on a Grace-Hopper system and 9.93x on a two-socket H100 system for the largest mesh, compared with full-node MPI, after expanding the memory pool allocator. End-to-end gains are much smaller because file I/O and MPI-bound solver phases remain unaccelerated and dominate once the GPU runs the rest. The authors acknowledge the demonstration is deliberately narrow: one simple application and NVIDIA hardware only.

What carries the argument

The central mechanism is the C++17 Parallel Standard Template Library (PSTL): execution policies such as std::execution::par applied to standard algorithms, compiled by nvc++ with -stdpar into either multicore or GPU code. The load-bearing data-structure transformation is a compressed list-of-lists reordering of OpenFOAM's owner and neighbour face arrays: sorting face indices by owning cell and building offsets with std::exclusive_scan converts a face-scatter loop with shared writes into a per-cell gather loop with no shared writes. That reordering is what makes the gradient-assembly loop safe to offload without atomics or critical sections.

What would settle it

Compile the published of-stdpar branch with a non-NVIDIA standard-parallelism compiler, such as AdaptiveCpp or ROCm's stdpar, and run the same laplacianFoam cases on an AMD or Intel GPU; the central claim is falsified if the code fails to compile, silently executes on the CPU, or produces wrong results because some dereferenced object was not moved.

Watch

Extended reading notes

Core claim

The central claim is that OpenFOAM's assembly phase can be expressed as standard C++17 parallel algorithms and compiled to GPU kernels by the NVIDIA nvc++ compiler with the -stdpar=gpu flag, with no vendor-specific API in the user code. Sequential loops in surface interpolation, gradient evaluation, field division, and boundary correction are replaced by std::for_each, std::transform, std::fill_n, std::exclusive_scan, and related standard algorithms. The key algorithmic change is reorganising OpenFOAM's owner and neighbour face-connectivity lists into compressed per-cell lists, so each parallel iteration writes to a distinct cell; this makes the gradient scatter loop free of data races without atomics. With CUDA Unified Memory handling page-by-page data movement, the same source is claimed to build for multicore with -stdpar=multicore and for GPU with -stdpar=gpu. The paper does not claim every OpenFOAM phase is accelerated, only that this pattern is enough for a working end-to-end proof of concept.

Load-bearing premise

Everything rests on the compiler automatically moving every dynamically allocated object between CPU and GPU, a behaviour demonstrated here only with one NVIDIA compiler; any stack-resident or otherwise unmanaged piece of data inside a parallel algorithm would break the single-codebase, flag-only approach.

Editorial extensions

If this is right

  • With the appropriate compiler flag, the same laplacianFoam source builds for multicore CPUs or NVIDIA GPUs, so no CUDA or OpenMP code needs to be written or maintained for the ported operators.
  • Assembly-phase gains grow with mesh size: the largest mesh shows 11.14x on Grace-Hopper and 9.93x on Two-Phases versus a fully populated MPI node, once the memory pool allocator is enlarged.
  • The owner/neighbour list-of-lists pattern is a general recipe for any face-to-cell scatter in finite-volume assembly, suggesting the approach can be reused for other OpenFOAM operators beyond the Laplacian.
  • End-to-end speedups are capped by Amdahl's law: when assembly and solver run on the GPU, file I/O goes from under 5% to the dominant serial cost in the tested cases.
  • Without setting the allocator environment variables, large meshes can run slower on one GPU than on MPI (down to 0.47x assembly speedup on Mesh-L/XL), so the headline speedups are conditional on memory-pool configuration.

Reading between the lines

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

  • If the pattern generalises, OpenFOAM's roughly one-million-line codebase could adopt standard C++ parallelism operator by operator without a rewrite, but the paper leaves the harder phases (linear solvers at scale, mesh topology changes, I/O) for future work.
  • The compiler-flag claim is, at heart, a toolchain claim: portability across vendors would require other stdpar implementations (for example AdaptiveCpp or ROCm's stdpar) to handle the same heap-managed unified-memory model, which the paper does not test.
  • A testable extension is to apply the same sort-and-scan face reordering to other legacy C++ finite-volume codes whose hot loops scatter face contributions into cells; those codes could become atomic-free and stdpar-offloadable with the same recipe.
  • The sensitivity to the memory pool allocator implies that production use would benefit from allocator auto-tuning or driver-side improvements; otherwise the 'just a flag' story fails whenever the default pool is smaller than the working set.
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

3 major / 7 minor

Summary. This manuscript presents a proof-of-concept port of the OpenFOAM 24.12 laplacianFoam application to ISO C++17 standard parallelism (PSTL), compiled with NVIDIA's nvc++ -stdpar flag. The authors rework the Laplacian assembly phase—surface interpolation, gradient computation, boundary corrections, and field arithmetic—onto std::for_each, std::transform, and std::fill_n with parallel execution policies, and reorganize the owner/neighbour face lists into sorted, compressed lists to avoid atomic updates. The native PCG solver is also ported so the application runs end-to-end on GPUs. Benchmarking four meshes (1M–64M cells) on four systems (V100, A100, Grace-Hopper H200, and up to four H100s) against best full-node MPI baselines, the paper reports assembly-phase speedups up to 11.14x (Grace-Hopper) and 9.93x (Two-Phases) for the 64M-cell mesh, obtained after tuning the NVIDIA memory-pool allocator with NVCOMPILER_ACC_POOL_* environment variables; under default allocator settings the same large meshes run at 0.45x–0.83x of the MPI baseline. Section 1.1 states that the novelty is 'proving that adopting the C++ Parallel Standard Template Library (PSTL) unlocks both multicore and GPU execution with just a compiler flag switch,' and Section 7 acknowledges NVIDIA-only testing, the narrow PoC scope, and the allocator sensitivity.

Significance. A standards-based single-codebase route to GPU offload is a useful direction for the OpenFOAM ecosystem, which is fragmented across CUDA-based forks such as RapidCFD and zeptoFOAM, and this paper is a concrete, honest data point with real strengths: five-run statistics with small error bars, explicit reporting of both tuned and default-allocator outcomes, identification of the I/O phase as the dominant end-to-end cost via Amdahl's argument, numerical verification against the upstream release, and a public source repository with build instructions. The significance is conditional, however. As submitted, the evidence supports a narrower statement than the central claim: the paper demonstrates that a substantially reorganized laplacianFoam assembly phase can be offloaded to one NVIDIA GPU with nvc++ and can beat full-node MPI on the large meshes once the allocator is tuned. It does not yet demonstrate the 'both multicore and GPU with a single flag' thesis, because no -stdpar=multicore results are reported and the GPU speedups are confounded with the data-structure reorganization, the allocator tuning, and the single-GPU-versus-full-node comparison.

major comments (3)
  1. [Section 1.1; Section 6 (Table 3)] The central claim of Section 1.1 — that PSTL 'unlocks both multicore and GPU execution with just a compiler flag switch' — is not tested in Section 6. Every of-stdpar result in Table 3 was obtained from the -stdpar=gpu build, and the only CPU baseline is the original, pre-PSTL OpenFOAM MPI code. Thus the 'multicore' half of the claim has no supporting evidence, and a reader cannot tell whether the rewritten codebase runs correctly (let alone efficiently) under -stdpar=multicore. Please add benchmarks of the same of-stdpar source compiled with -stdpar=multicore on the same meshes and systems, reported against both the original MPI baseline and the GPU build; alternatively, rescope the claim in the abstract, Section 1.1, and the conclusions to state that the demonstration covers GPU offload only.
  2. [Section 5.2; Section 6.1 (Table 3)] The headline assembly speedups (11.14x on Grace-Hopper and 9.93x on Two-Phases for Mesh-XL, Section 6.1) compare the rewritten of-stdpar GPU build against the original full-node MPI build, but Section 5.2 shows that the rewrite includes substantial algorithmic changes that are independent of PSTL: the owner and neighbour lists are sorted and compressed into ownerList_/ownerStart_/neighbourList_/neighbourStart_ (Listings 7–8), new facePatchIndex/facePatchStart boundary lists are introduced (Listing 10), the Field constructor is replaced by a fill_n-based constructor (Listing 6), and the TFOR_ALL_F_OP_F_OP_F macro is rewritten (Listing 12). These changes, plus the NVCOMPILER_ACC_POOL_* tuning, are confounded with the act of offloading, and the resource comparison is asymmetric (one H100/H200 versus 72–88 MPI ranks). The default-allocator columns in Table 3 (0.45x–0.83x for Mesh-L and Mesh-XL) show that the GPU flag alone does not produce the headline gains on large meshes. Please add an ablation — for example, the reorganized code compiled without -stdpar=gpu, so the PSTL algorithms run on the CPU, benchmarked on the same meshes — or restate the contribution so that the speedup is attributed to the combination of PSTL offload, algorithmic restructuring, and allocator tuning rather than to the flag switch alone.
  3. [Section 6.1 (Table 3); Section 7] The abstract and Section 1.1 present the work as demonstrating that 'it is possible to increase the performance of the OpenFOAM laplacianFoam application by offloading the computations on NVIDIA GPUs' and as a 'just a compiler flag switch' thesis, but Section 6.1 shows that the positive results for the large meshes require per-machine allocator configuration (NVCOMPILER_ACC_POOL_THRESHOLD=100 with NVCOMPILER_ACC_POOL_SIZE=10 GB on Grace-Hopper and Two-Phases, 40 GB on EpiTo, and 30 GB attempted on CascadeLake), and that under the default allocator the GPU assembly runs at only 0.47x–0.83x of the MPI baseline on the same meshes. Since the paper itself states that the allocator size 'strongly influences the performance' and that the tuning analysis is deferred to future work, the abstract and any condensed statement of the speedups should carry this qualification explicitly, or the flag-switch claim should be narrowed to target selection (multicore versus GPU) for the already-tuned codebase.
minor comments (7)
  1. [Section 2] The heading 'Releated Works' is misspelled and should read 'Related Works'.
  2. [Table 3 caption] The caption should state the MPI process counts corresponding to each 'best MPI' column (the text says all cores except for one system) and the allocator settings used for the 'GPU+A' columns, since these values appear only in the body of Section 6.1.
  3. [Section 5.2 (Listings 8 and 10)] In Listing 10, the unbounded std::views::iota(0).begin() with an end iterator borrowed from a second iota view is unconventional; a bounded iota(0, faceStart.size()-1) would be clearer. Also, the lambda parameters named 'facei' in Listings 8 and 10 actually iterate over cells (or boundary-face starts), not faces; renaming them would avoid confusion.
  4. [Section 6] Please clarify whether the one-time construction cost of the sorted/compressed owner, neighbour, and boundary facePatch lists is included in the reported assembly times; since the lists are built once per mesh, the amortization assumption matters for interpreting the 11.14x figure.
  5. [Section 6] The verification sentence ('We verify the accuracy ... by comparing them with the results obtained using the original OpenFOAM-24.12 release') reports no tolerance or error metric; a brief quantification (e.g., maximum relative difference) would make the claim verifiable.
  6. [Section 6.1] The reported Mesh-S assembly speedup range (1.98x–2.82x) mixes numbers from the default 'GPU' and tuned 'GPU+A' columns without saying which; please specify which columns feed the quoted ranges.
  7. [Section 7 and References] The conclusions contain passages with missing spaces between words (e.g., 'AcomplexapplicationlikeOpenFOAMposeschallengesandconstraints'), and reference [43] has an incomplete author field ('NVIDIA, . Thrust.'); please proofread the final version.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper's speedups are measured against the external OpenFOAM 24.12 MPI baseline, and no derived claim reduces to a fitted input or a self-citation.

full rationale

This is an empirical systems/performance paper, not a derivation chain, so most circularity patterns do not apply. The central quantitative claims are the assembly-phase speedups in Table 3, which compare the modified PSTL/GPU build against the original OpenFOAM 24.12 MPI build at full core count. That baseline is external to the paper and is not constructed from the paper's own outputs. The allocator-size tuning via NVCOMPILER_ACC_POOL_* is disclosed as configuration tuning, and the paper reports both default and tuned ('GPU+A') columns; the tuned results are presented as benchmark measurements, not as predictions derived from a fitted parameter. No quantity is defined in terms of another quantity it is supposed to predict. The references to HPC4AI, FastFlow, and prior parallelization work by the authors are contextual and are not load-bearing for the main claim. The most substantive weakness is that the stated novelty—'PSTL unlocks both multicore and GPU execution with just a compiler flag switch'—is not directly tested, because the same PSTL source is never benchmarked with -stdpar=multicore. That is an evidentiary gap and a correctness/scope concern, not circularity: the missing experiment does not mean the GPU results were produced by construction from their own inputs. Under the stated hard rules, circularity must be demonstrated by quoting a specific reduction to inputs or to a self-citation chain, and no such reduction exists here. Score 0.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The actual contribution is a source transformation supported by benchmarks. The performance claims carry a hardware-specific tuning parameter (allocator size), an implicit toolchain assumption (Unified Memory correctness), and an implicit numerical-equivalence assumption for the reordered mesh lists. No new physical or mathematical entities are introduced.

free parameters (2)
  • NVCOMPILER_ACC_POOL_SIZE and NVCOMPILER_ACC_POOL_THRESHOLD = POOL_THRESHOLD=100; POOL_SIZE=10 GB on Grace-Hopper and Two-Phases, 40 GB on EpiTo, 30 GB on CascadeLake
    Tuned per architecture to avoid per-iteration memory deallocation; without this tuning, large-mesh GPU assembly is slower than MPI.
  • Best MPI baseline process count = 40 (CascadeLake), 80 (EpiTo), 72 (Grace-Hopper), 88 (Two-Phases)
    The paper reports the best MPI configuration found, used as the denominator for speedups; this is a chosen baseline rather than a fixed hardware-equivalent comparison.
assumptions (4)
  • domain assumption nvc++ stdpar GPU offload is correct and complete under CUDA Unified Memory, and every pointer dereferenced in a parallel algorithm refers to CPU heap memory.
    Section 3 states that C++ has no explicit device-memory constructs and that nvc++ assumes CUDA Unified Memory with automatic page-fault migration.
  • domain assumption Reorganizing owner and neighbour lists into sorted compressed lists preserves the numerical result of the gradient assembly and eliminates data races without atomics.
    Section 5.2.2 and Listings 7 and 8 claim that per-cell accumulation is safe after reordering; the paper does not prove this formally and only states that results were verified.
  • standard math The user guarantees data-race freedom for std::execution::par algorithms.
    Section 3 notes that parallel algorithms do not protect users from data races and that the programmer must ensure correctness.
  • domain assumption Both the official OpenFOAM 24.12 and the modified version compiled with the same nvc++ compiler give comparable MPI baselines.
    Section 6 states both versions are compiled with nvc++-24.3 and GNU 12.2.0 using -O3; this fairness assumption is not independently checked.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Building an Accelerated OpenFOAM Proof-of-Concept Application using Modern C++." pith.science (2026). https://pith.science/paper/KMBKP65L

@misc{pith2026250718268,
  author       = {Pith},
  title        = {Pith review of: Building an Accelerated OpenFOAM Proof-of-Concept Application using Modern C++},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KMBKP65L}},
  note         = {Machine review of arXiv:2507.18268}
}
read the original abstract

The modern trend in High-Performance Computing (HPC) involves the use of accelerators such as Graphics Processing Units (GPUs) alongside Central Processing Units (CPUs) to speed up numerical operations in various applications. Leading manufacturers such as NVIDIA, Intel, and AMD are constantly advancing these architectures, augmenting them with features such as mixed precision, enhanced memory hierarchies, and specialised accelerator silicon blocks (e.g., Tensor Cores on GPU or AMX/SME engines on CPU) to enhance compute performance. At the same time, significant efforts in software development are aimed at optimizing the use of these innovations, seeking to improve usability and accessibility. This work contributes to the state-of-the-art of OpenFOAM development by presenting a working Proof-Of-Concept application built using modern ISO C++ parallel constructs. This approach, combined with an appropriate compiler runtime stack, like the one provided by the NVIDIA HPC SDK, makes it possible to accelerate well-defined kernels, allowing multi-core execution and GPU offloading using a single codebase. The study demonstrates that it is possible to increase the performance of the OpenFOAM laplacianFoam application by offloading the computations on NVIDIA GPUs using the C++ parallel construct.

Figures

Figures reproduced from arXiv: 2507.18268 by the authors.

Figure 1
Figure 1. Representation of owners and neighbours. [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. List of List Taking inspiration from RapidCFD4 , one way to build these lists is to create a first list with the elements contained in the internal list and another one that contains the starting point of the previous list between two successive cell elements, see [PITH_FULL_IMAGE:figures/full_fig_p011_2.png] view at source ↗
Figure 3
Figure 3. Compressed format of a list of list [PITH_FULL_IMAGE:figures/full_fig_p012_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Sorting owner list The second list is slightly more challenging to compute. Starting from the reordered owner list, another list is appended at the end. This list has indices from 0 to the number of cells Ncell. Another list of size owner list size plus Ncell is create…
Figure 5
Figure 5. Figure 5: Starting index of the previous list These lists are helpful to parallelize the first gradient loop safely. To compute that loop in parallel, four lists are needed: the ownerList_, the ownerStart_, the neighbourList_ and the neighbourStart_. We insert these lists as std…
Figure 6
Figure 6. Figure 6: Compressed lists for the boundaries 13 [PITH_FULL_IMAGE:figures/full_fig_p013_6.png]
Figure 7
Figure 7. Figure 7: Simulation used to test our Proof-Of-Concept [PITH_FULL_IMAGE:figures/full_fig_p015_7.png]
Figure 8
Figure 8. Figure 8: Multi-GPUs simulations on TwoPhases. DEF and ALL labels indicate simulations executed with the default and 10 GB allocator sizes. I/O time is not considered [PITH_FULL_IMAGE:figures/full_fig_p018_8.png]
Figure 9
Figure 9. Figure 9: Multi-GPUs simulations on TwoPhases. DEF and ALL labels indicate simulations executed with the default and 10 GB allocator sizes. 18 [PITH_FULL_IMAGE:figures/full_fig_p018_9.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

61 extracted references · 42 canonical work pages

  1. [1]

    roc-stdpar: Standard parallelism for rocm platform

    Advanced Micro Devices, I., 2024. roc-stdpar: Standard parallelism for rocm platform. https://github.com/ROCm/roc-stdpar. Accessed: 2025-04-12

    work page 2024

  2. [2]

    Practical parallelization of scientific applications with openmp, openacc and mpi

    Aldinucci, M., Cesare, V., Colonnelli, I., Martinelli, A.R., Mittone, G., Cantalupo, B., Cavazzoni, C., Drocco, M., 2021. Practical parallelization of scientific applications with openmp, openacc and mpi. Journal of Parallel and Distributed Computing doi:https: //doi.org/10.1016/j.jpdc.2021.05.017

    doi:10.1016/j.jpdc.2021.05.017 2021

  3. [3]

    Aldinucci, M., Rabellino, S., Pironti, M., Spiga, F., Viviani, P., Drocco, M., Guerzoni, M., Boella, G., Mellia, M., Margara, P., Drago, I., Marturano, R., Marchetto, G., Piccolo, E., Bagnasco, S., Lusso, S., Vallero, S., Attardi, G., Barchiesi, A., Colla, A., Galeazzi, F., 2018. Hpc4ai: an ai-on-demand federated platform endeavour, in: Proceedings of the...

    work page arXiv 2018

  4. [4]

    Porting decision tree algorithms to multicore using fastflow, in: Machine Learning and Knowledge Discovery in Databases

    Aldinucci, M., Ruggieri, S., Torquati, M., 2010. Porting decision tree algorithms to multicore using fastflow, in: Machine Learning and Knowledge Discovery in Databases. doi:10.1007/978-3-642-15880-3_7

    work page doi:10.1007/978-3-642-15880-3_7 2010

  5. [5]

    Adaptivecpp stdpar: C++ standard parallelism integrated into a sycl compiler, Association for Computing Machinery, New York, NY, USA

    Alpay, A., Heuveline, V., 2024. Adaptivecpp stdpar: C++ standard parallelism integrated into a sycl compiler, Association for Computing Machinery, New York, NY, USA. URL: https://doi.org/10.1145/3648115.3648117, doi:10.1145/3648115.3648117

    arXiv 2024

  6. [6]

    Ginkgo: A Modern Linear Operator Algebra Framework for High Performance Computing

    Anzt, H., Cojean, T., Flegar, G., Göbel, F., Grützmacher, T., Nayak, P., Ribizel, T., Tsai, Y.M., Quintana-Ortí, E.S., 2022. Ginkgo: A Modern Linear Operator Algebra Framework for High Performance Computing. ACM Transactions on Mathematical Software 48, 2:1– 2:33. URL: https://doi.org/10.1145/3480935, doi:10.1145/3480935

    doi:10.1145/3480935 2022

  7. [7]

    Efficient management of par- allelism in object oriented numerical software libraries, in: Arge, E., Bruaset, A.M., Lang- tangen, H.P

    Balay, S., Gropp, W.D., McInnes, L.C., Smith, B.F., 1997. Efficient management of par- allelism in object oriented numerical software libraries, in: Arge, E., Bruaset, A.M., Lang- tangen, H.P. (Eds.), Modern Software Tools in Scientific Computing, Birkhäuser Press. pp. 163–202

    work page 1997

  8. [8]

    Raja: Portable performance for large- scale scientific applications, in: 2019 IEEE/ACM International Workshop on Performance, Portability and Productivity in HPC (P3HPC)

    Beckingsale, D.A., Burmark, J., Hornung, R., Jones, H., Killian, W., Kunen, A.J., Pearce, O., Robinson, P., Ryujin, B.S., Scogland, T.R., 2019. Raja: Portable performance for large- scale scientific applications, in: 2019 IEEE/ACM International Workshop on Performance, Portability and Productivity in HPC (P3HPC). doi:10.1109/P3HPC49587.2019.00012

    arXiv 2019

Show all 61 references
  1. [9]

    Chapter 26 - thrust: A productivity-oriented library for cuda, in: mei W

    Bell, N., Hoberock, J., 2012. Chapter 26 - thrust: A productivity-oriented library for cuda, in: mei W. Hwu, W. (Ed.), GPU Computing Gems Jade Edition. doi:https://doi.org/ 10.1016/B978-0-12-385963-1.00026-5

    2012 doi

  2. [10]

    PETSc4FOAM: a library to plug-in PETSc into the OpenFOAM framework

    Bna, S., Spisso, I., Olesen, M., Rossi, G., 2020. PETSc4FOAM: a library to plug-in PETSc into the OpenFOAM framework. URL: https://doi.org/10.5281/zenodo.3923780, doi:10.5281/zenodo.3923780

    2020 doi

  3. [11]

    Kokkos: Enabling manycore performance portability through polymorphic memory access patterns

    Carter Edwards, H., Trott, C.R., Sunderland, D., 2014. Kokkos: Enabling manycore performance portability through polymorphic memory access patterns. Journal of Parallel and Distributed Computing doi:https://doi.org/10.1016/j.jpdc.2014.07.003

    2014 doi

  4. [12]

    Cassell, T.L., Deakin, T., Alpay, A., Heuveline, V., Gadeschi, G.B., 2024. Efficient tree- based parallel algorithms for n-body simulations using c++ standard parallelism, in: SC24- W: Workshops of the International Conference for High Performance Computing, Network- ing, Stor...

    2024

  5. [13]

    Current Bottlenecks in the Scalability of OpenFOAM on Massively Par- allel Clusters

    Culpo, M., 2012. Current Bottlenecks in the Scalability of OpenFOAM on Massively Par- allel Clusters. URL: https://doi.org/10.5281/zenodo.807482, doi:10.5281/zenodo. 807482

    2012 doi

  6. [14]

    Gpu acceleration for the c++ standard template library

    DeLozier, C., 2012. Gpu acceleration for the c++ standard template library. URL:https: //api.semanticscholar.org/CorpusID:1464773

    2012

  7. [15]

    Enmyren, J., Kessler, C.W., 2010. Skepu: a multi-backend skeleton programming library for multi-gpu systems, in: Proceedings of the Fourth International Workshop on High- Level Parallel Programming and Applications, Association for Computing Machinery, New York, NY, USA. p. 5–...

    2010

  8. [16]

    Gpu cluster for high performance computing, in: SC ’04: Proceedings of the 2004 ACM/IEEE Conference on Supercomput- ing, pp

    Fan, Z., Qiu, F., Kaufman, A., Yoakum-Stover, S., 2004. Gpu cluster for high performance computing, in: SC ’04: Proceedings of the 2004 ACM/IEEE Conference on Supercomput- ing, pp. 47–47. doi:10.1109/SC.2004.26

    2004 doi

  9. [17]

    OpenFOAM, The OpenFOAM Foundation

    Greenshields, C.J., 2022. OpenFOAM, The OpenFOAM Foundation. OpenFOAM Foun- dation Ltd

    2022

  10. [18]

    Openfoam user guide

    Greenshields, C.J., et al., 2015. Openfoam user guide. OpenFOAM Foundation Ltd, version 3, 47

    2015

  11. [19]

    The C++ Standard Library

    Grimm, R., 2018. The C++ Standard Library. Packt

    2018

  12. [20]

    Concurrency with Modern C++

    Grimm, R., 2019. Concurrency with Modern C++. Packt

    2019

  13. [21]

    Unified Memory in CUDA 6

    Harris, M., 2013. Unified Memory in CUDA 6. Technical Report. NVIDIA. URL:https: //developer.nvidia.com/blog/unified-memory-in-cuda-6/

    2013

  14. [22]

    Unified Memory for CUDA Beginners

    Harris, M., 2017. Unified Memory for CUDA Beginners. Technical Report. NVIDIA. URL: https://developer.nvidia.com/blog/unified-memory-cuda-beginners/

    2017

  15. [23]

    Herdman, J.A., Gaudin, W.P., Perks, O., Beckingsale, D.A., Mallinson, A.C., Jarvis, S.A.,

  16. [24]

    Efficient execution of openmp on gpus, in: 2022 IEEE/ACM Interna- tional Symposium on Code Generation and Optimization (CGO)

    Huber, J., Cornelius, M., Georgakoudis, G., Tian, S., Diaz, J.M.M., Dinel, K., Chapman, B., Doerfert, J., 2022. Efficient execution of openmp on gpus, in: 2022 IEEE/ACM Interna- tional Symposium on Code Generation and Optimization (CGO). doi:10.1109/CGO53902. 2022.9741290

    2022

  17. [25]

    ISO/IEC TS 19570:2015(E) Information technology - Programming languages, their environments and system software interfaces - C Secure Coding Rules

    ISO/IEC JTC 1/SC 22/WG 14, 2015. ISO/IEC TS 19570:2015(E) Information technology - Programming languages, their environments and system software interfaces - C Secure Coding Rules. Technical Specification ISO/IEC TS 19570:2015(E). ISO International Or- ganization for Standardi...

    2015

  18. [26]

    ISO/IEC 14882:2011(E) Programming Languages - C++

    ISO/IEC JTC 1/SC 22/WG 21, 2011. ISO/IEC 14882:2011(E) Programming Languages - C++. Standard ISO/IEC 14882:2011(E). ISO International Organization for Standard- ization. URL: https://www.iso.org/standard/50372.html

    2011

  19. [27]

    Hpc comparison of hypre vs pstream as external linear algebra library for openfoam

    Ivan Spisso, G.A., 2018. Hpc comparison of hypre vs pstream as external linear algebra library for openfoam

    2018

  20. [28]

    Error Analysis and Estimation for the Finite Volume Method With Applications to Fluid Flows

    Jasak, H., 1996. Error Analysis and Estimation for the Finite Volume Method With Applications to Fluid Flows. Direct M. 23

    1996

  21. [29]

    Openfoam: Open source cfd in research and industry

    Jasak, H., 2009. Openfoam: Open source cfd in research and industry. Interna- tional Journal of Naval Architecture and Ocean Engineering 1, 89–94. URL: https: //www.sciencedirect.com/science/article/pii/S2092678216303879, doi: https:// doi.org/10.2478/IJNAOE-2013-0011

    2009 doi

  22. [30]

    Openfoam: A c++ library for complex physics simulations

    Jasak, H., Jemcov, A., Tukovic, Z., 2013. Openfoam: A c++ library for complex physics simulations

    2013

  23. [31]

    Johnston, B., Vetter, J.S., Milthorpe, J., 2020. Evaluating the performance and portability of contemporary sycl implementations, in: 2020 IEEE/ACM International Workshop on Performance, Portability and Productivity in HPC (P3HPC). doi:10.1109/P3HPC51967. 2020.00010

    2020

  24. [32]

    Investigating the hip programming model with regards to portability and performance portability

    Kerscher, N., 2022. Investigating the hip programming model with regards to portability and performance portability

    2022

  25. [33]

    Nvidia cuda software and gpu parallel computing architecture, in: Proceed- ings of the 6th International Symposium on Memory Management

    Kirk, D., 2007. Nvidia cuda software and gpu parallel computing architecture, in: Proceed- ings of the 6th International Symposium on Memory Management. doi:10.1145/1296907. 1296909

    2007 doi

  26. [34]

    Developing Accelerated Code with Standard Language Paral- lelism

    Larkin, J., 2017. Developing Accelerated Code with Standard Language Paral- lelism. Technical Report. NVIDIA. URL: https://developer.nvidia.com/blog/ developing-accelerated-code-with-standard-language-parallelism/

    2017

  27. [35]

    Cross-platform programming model for many-core lattice Boltzmann simulations

    Latt, J., Coreixas, C., Beny, J., 2021. Cross-platform programming model for many-core lattice Boltzmann simulations. PLOS ONE 16, e0250306. URL: https://doi.org/10. 1371%2Fjournal.pone.0250306, doi:10.1371/journal.pone.0250306

    2021 doi

  28. [36]

    Lin, W.C., Deakin, T., McIntosh-Smith, S., 2022. Evaluating ISO C++ Parallel Algorithms on Heterogeneous HPC Systems, in: International Workshop on Performance Modeling, Benchmarking and Simulation of High Performance Computer Systems held in conjunction with Supercomputing (P...

    2022

  29. [37]

    PARALUTION: Multi-GPU Linear Solvers for OpenFOAM

    Lukarski, D., 2013. PARALUTION: Multi-GPU Linear Solvers for OpenFOAM. Technical Report. Karlsruhe Institute of Technology

    2013

  30. [38]

    AmgX GPU Solver Developments for Open- FOAM

    Martineau, M., Posey, S., Spiga, F., 2021. AmgX GPU Solver Developments for Open- FOAM

    2021

  31. [39]

    OCCA: A unified approach to multi- threading languages

    Medina, D.S., St-Cyr, A., Warburton, T., 2014. OCCA: A unified approach to multi- threading languages. arXiv e-prints doi:10.48550/arXiv.1403.0968

    2014 doi arXiv

  32. [40]

    MultiGPU Implementation to Accelerate the CFD Simulation of a 3D Turbo-Machinery Benchmark Using the RapidCFD Library

    MolineroHernandez, D., Galván-González, S.R., Pacheco, J., Herrera, N., 2019. MultiGPU Implementation to Accelerate the CFD Simulation of a 3D Turbo-Machinery Benchmark Using the RapidCFD Library. pp. 173–187. doi:10.1007/978-3-030-38043-4_15

    2019 doi

  33. [41]

    The Finite Volume Method in Compu- tational Fluid Dynamics

    Moukalled, F., Mangani, L., Darwish, M., 2016. The Finite Volume Method in Compu- tational Fluid Dynamics. Springer International Publishing. URL:https://doi.org/10. 1007/978-3-319-16874-6, doi:10.1007/978-3-319-16874-6

    2016 doi

  34. [42]

    Amgx: A library for gpu accelerated algebraic multigrid and preconditioned iterative methods

    Naumov, M., Arsaev, M., Castonguay, P., Cohen, J., Demouth, J., Eaton, J., Layton, S., Markovskiy, N., Reguly, I., Sakharnykh, N., Sellappan, V., Strzodka, R., 2015. Amgx: A library for gpu accelerated algebraic multigrid and preconditioned iterative methods. SIAM Journal on S...

    2015 doi

  35. [43]

    NVIDIA, . Thrust. URL:https://developer.nvidia.com/thrust. accessed: 2023-01-01. 24

    2023

  36. [44]

    On the performance of a highly-scalable computational fluid dynamics code on amd, arm and intel processor-based hpc systems

    Ouro, P., Lopez-Novoa, U., Guest, M.F., 2021. On the performance of a highly-scalable computational fluid dynamics code on amd, arm and intel processor-based hpc systems. Computer Physics Communications 269, 108105. URL:http://dx.doi.org/10.1016/j. cpc.2021.108105, doi:10.1016...

    2021

  37. [45]

    Nav- igating performance, portability, and productivity

    Pennycook, S.J., Sewall, J.D., Jacobsen, D.W., Deakin, T., McIntosh-Smith, S., 2021. Nav- igating performance, portability, and productivity. Computing in Science & Engineering 23, 28–38. doi:10.1109/MCSE.2021.3097276

    2021

  38. [46]

    Productivity, performance, and portability for compu- tational fluid dynamics applications

    Reguly, I.Z., Mudalige, G.R., 2020. Productivity, performance, and portability for compu- tational fluid dynamics applications. Computers & Fluids 199, 104425. URL: https: //www.sciencedirect.com/science/article/pii/S0045793020300013, doi: https:// doi.org/10.1016/j.compfluid....

    2020

  39. [47]

    Gpu accelerated flow solver for direct numerical simulation of turbulent flows

    Salvadore, F., Bernardini, M., Botti, M., 2013. Gpu accelerated flow solver for direct numerical simulation of turbulent flows. Journal of Computational Physics 235, 129–142. URL: https://www.sciencedirect.com/science/article/pii/ S0021999112006018, doi:https://doi.org/10.1016...

    2013 doi

  40. [48]

    Openmp offload toward the exascale using intel® gpu max 1550: evaluation of streams compressible solver

    Salvadore, F., Rossi, G., Sathyanarayana, S., Bernardini, M., 2024. Openmp offload toward the exascale using intel® gpu max 1550: evaluation of streams compressible solver. J. Supercomput. 80, 21094–21127. URL:https://doi.org/10.1007/s11227-024-06254-y, doi:10.1007/s11227-024-06254-y

    2024 doi

  41. [49]

    Schieffer, G., Wahlgren, J., Ren, J., Faj, J., Peng, I., 2024. Harnessing integrated cpu- gpu system memory for hpc: a first look into grace hopper, in: Proceedings of the 53rd International Conference on Parallel Processing, Association for Computing Machinery, New York, NY, ...

    2024

  42. [50]

    Valgrind Documentation

    Seward, J., Nethercote, N., Hughes, T., Fitzhardinge, J., Weidendorfer, J., Mackerras, P., Parker, G., Mueller, D., Walsh, R., Assche, B.V., et al., C.A.B., . Valgrind Documentation. GNU Free Documentation License

  43. [51]

    Porting, optimization and bottleneck of openFOAM in KNL

    Spisso, I., Amati, G., Ruggero, V., Fiorina, C., 2018. Porting, optimization and bottleneck of openFOAM in KNL. URL: https://www.ixpug.org/images/docs/IXPUG_Annual_ Spring_Conference_2018/IXpug-OpenFOAM.pdf. intel eXtreme Performance Users Group (IXPUG)

    2018

  44. [52]

    The Standard Template Library

    Stepanov, A., Lee, M., 1995. The Standard Template Library. Hewlett-Packard Company

    1995

  45. [53]

    The C++ Programming Language

    Stroustrup, B., 2013. The C++ Programming Language. Addison-Wesley Professional

    2013

  46. [54]

    Tandon, S., Grinberg, L., Bercea, G.T., Bertolli, C., Olesen, M., Bna, S., Malaya, N., 2024. Porting hpc applications to amd instinct™ mi300a using unified memory and openmp®, in: ISC High Performance 2024 Research Paper Proceedings (39th International Conference), Prometeus G...

    2024

  47. [55]

    Complete piso and simple solvers on graphics processing units

    Tomczak, T., Zadarnowska, K., Koza, Z., Matyka, M., Mirosław, Ł., 2012. Complete piso and simple solvers on graphics processing units. arXiv preprint arXiv:1207.1571

    2012 arXiv

  48. [56]

    An Introduction to Computational Fluid Dynamics

    Versteeg, H., Malalasekera, W., 2007. An Introduction to Computational Fluid Dynamics. PEARSON

    2007

  49. [57]

    A tensorial approach to computational continuum mechanics using object orientated techniques

    Weller, H., Tabor, G., Jasak, H., Fureby, C., 1998. A tensorial approach to computational continuum mechanics using object orientated techniques. Computers in Physics 12, 620–

    1998

  50. [58]

    C++ Concurrency In Action

    Williams, A., 2019. C++ Concurrency In Action. Manning

    2019

  51. [59]

    Alpaka – an abstraction library for parallel kernel acceleration, in: 2016 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW)

    Zenker, E., Worpitz, B., Widera, R., Huebl, A., Juckeland, G., Knüpfer, A., Nagel, W.E., Bussmann, M., 2016. Alpaka – an abstraction library for parallel kernel acceleration, in: 2016 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW). doi:10.1...

    2016 doi

  52. [631]

    doi:10.1063/1.168744. 25

    doi

  53. [2014]

    doi:10.1109/WACCPD.2014.10

    Achieving portability and performance through openacc, in: 2014 First Workshop on Accelerator Programming using Directives. doi:10.1109/WACCPD.2014.10

    2014 doi

Pith tools

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