• The file structure of the repository is aligned to the file structure of OpenFOAM tutorials (specifying type of the flow, particular solver, turbulence model etc.).
• The table structure within this overview is mainly organised according to the outline defined within the exaFOAM project (see the corresponding description).
• New benchmarks may be put in any of the provided (or newly defined) categories suitable for the case.
• Each benchmark case should provide a README.md file with a description and a thumbnail image to be included within this overview. These files should be located in the root directory of the case.
• The thumbnail image has to be 50 pixels high, the width is not constrained.

Motivation

Computational Fluid Dynamics performance on HPC is notably worse than idealised algorithms, due to inherent bandwidth needs, three-dimensional and time-date handling with non-sparse matrix dependencies, spatial domain decomposition requirements, I/O challenges. Independent software vendors (ISVs) have rightly concentrated their efforts on different customer demands such as complex physics modelling (turbulence, multi-phase, combustion/reactions, particulates, heat transfer). However, we see increasingly now that there is a commercial need to improve performance of industrial software and codes. There is an increasingly stated need to redress the balance between performance and functionality, perhaps even to re-learn the lessons of parallelism and vectorisation explored during the 1980s, due to the approaching of the hybrid pre-exascale era in HPC.

The ambitious exaFOAM project (2021-2024) aimed to overcome these limitations through the development and validation of a range of algorithmic improvements. Improvements across the entire CFD process chain (pre-processing, simulation, I/O, post- processing) were developed.

Benchmarks

The developments of the exaFOAM project are showcased by

• Grand Challenges (GC) that are designed to push available HPC systems to their limits and showcase the performance gains achieved over the duration of the project,
• Industrial Applications (B) that are primarily driven by the expectations of the project's industrial observer partners,
• Microbenchmarks (MB) that are derived from the Grand Challenges and Industrial and can be used for the continuous assessment of the software components during development.

The cases related to each other are identified via a separate column in the tables below. For some of the benchmarks, grid and restart files are available in the DaRUS data repository of the University of Stuttgart.

Key Performance Indicators

The KPIs defined during the project always represent the ratio of the KPI before and after (KPI_before / KPI_after) and are thus dimensionless. Common metrics are:

• TTS = time-to-solution
• CTS = cost-to-solution
• PTS = power-to-solution
• PMC = peak memory consumption
• SDU = scratch disc-space used

Non-quantifiable KPIs:

• ET = enabling technology: something that was impossible
• CBF = critical bug fix: a fix that is required to run the case
• EA = extending applicability: something that worked but was not usable for e.g. larger cases, HPC or depending on specific setups