OpenFOAM v2412 リリースノート

ESI OpenCFD Release OpenFOAM® v2412

OpenCFDは、OpenFOAM® v2412の2024年12月リリースを発表いたします。 このリリースは、コードの多くの領域にわたってOpenFOAM-v2406の機能を拡張しています。 この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。

OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。 様々なLinuxや他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加え、このリリースにはコンパイル済みのバイナリパッケージもあります。

• Ubuntu Linux: Ubuntu 用パッケージインストール (近日公開予定)
• openSUSE Linux: パッケージインストール (近日公開予定)
• Redhat Linux variants: パッケージインストール (近日公開予定)
• apptainer イメージ: dockerhub から入手可能 (近日公開予定)

Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢がある（詳細）：

• Linux用Windowsサブシステムの使用（Ubuntu、openSUSEなどがベース）
• クロスコンパイルによるネイティブ実行可能ファイル
• ドッカーのインストール

OpenFOAMのapptainerサポートは、事前に組み立てられたイメージではなく、記述ファイルによって提供されます：

• パッケージ/コンテナを確認する

Mac OSXユーザーには、ソースからコンパイルするか、コンパイル済みパッケージのDockerコンテナを使用するオプションがある（詳細はこちら）。

アップグレード

• ユーザー向けのヘルプは、ユーザー・アップグレード・ガイドに記載されています。
• 開発者向けのヘルプは、開発者向けアップグレードガイドに記載されています。

前処理

createPatchユーティリティの改良

createPatchユーティリティが拡張され、例えばcyclicACMIの作成時に重複した境界面を作成できるようになりました。 これは、外部生成メッシュ間のcyclicACMI接続を作成するために使用できます。

system/createPatchDictのサンプル：

// Patches to create.
patches
(
    {
        //- Master side patch
        name            central_inlet_couple;
        patchInfo
        {
            type            cyclicACMI;
            nonOverlapPatch central_inlet_blockage;
            neighbourPatch  inlet_central_couple;
        }
        constructFrom patches;
        patches (central_inlet);
    }
    {
        //- Blockage
        name            central_inlet_blockage;
        patchInfo
        {
            type            wall;
        }
        constructFrom patches;
        patches (central_inlet);
    }

    {
        //- Slave side patch
        name            inlet_central_couple;
        patchInfo
        {
            type            cyclicACMI;
            nonOverlapPatch inlet_central_blockage;
            neighbourPatch  central_inlet_couple;
        }
        constructFrom patches;
        patches (inlet_couple);
    }
    {
        //- Blockage
        name            inlet_central_blockage;
        patchInfo
        {
            type            wall;
        }
        constructFrom patches;
        patches (inlet_couple);
    }
);

注意：createPatchを実行する前に、作成するcyclicACMIパッチが存在してはならない。

チュートリアル

• $FOAM_TUTORIALS/mesh/createPatch/TJunctionSwitching_createPatch

ソースコード

• $FOAM_SRC/utilities/mesh/manipulation/createPatch
• $FOAM_SRC/utilities/mesh/manipulation/mergeMeshes

リクエストのマージ

• Merge request #702

snappyHexMeshの改良：スナップの前にレイヤーをバッファリングする。

スナップ前にメッシュにバッファレイヤーを追加できるようになり、スナップアルゴリズムをユーザーが選択できるようになりました。

snappyHexMeshDictの新しいトップレベル・エントリーを使用して、バッファー・レイヤーの追加とメッシュ・モーション機能の使用を選択できるようになりました：

// Type of mesh generation:
//  - castellated (default)
//  - castellatedBufferLayer
type            castellatedBufferLayer;

バッファ層の追加はすべてのメッシュ化されたパッチに適用されます。オプションで、addBufferLayersキーワードを使用してサーフェスごとにオーバーライドできます：

refinementSurfaces
{
    sphere
    {
        // Surface-wise min and max refinement level
        level (1 1);
        // Disable buffer layers
        addBufferLayers false;
    }
}

スナップ時に使用するメッシュ・モーション・ソルバの選択：

snapControls
{
  ..
  solver  displacementPointSmoothing;
  displacementPointSmoothingCoeffs
  {
      // Use laplacian to untangle problem areas
      pointSmoother           laplacian;
      nPointSmootherIter      10;
  }

下の画像は、回転したボックスの外側に追加されたバッファー・セルの単層で、セルはセル・インデックスに従って色分けされている：

2つ目の例は、バッファレイヤーを追加することで、内側と外側の両方の領域を維持しながら、フェイスゾーンにスナップするのに役立つことを示しています。 ここでは、セルは非直交性に従って色付けされている：

バッファレイヤーは（まだ）フィーチャーのエッジを考慮していないことに注意してください。

チュートリアル

• $FOAM_TUTORIALS/mesh/snappyHexMesh/rotated_block Meshing the outside of a rotated cube.
• $FOAM_TUTORIALS/mesh/snappyHexMesh/sphere_multiRegion Meshing the inside and outside of a sphere.

ソースコード

• $FOAM_SRC/utilities/mesh/generation/snappyHexMesh

リクエストのマージ

• Merge request #715

境界条件

pointMeshの境界処理の改善

pointMeshはパッチのリスト（オプション）を持つようになった。 通常の動作は、pointMeshはボリュームの'poly'メッシュと同じパッチのセットを使い、'poly'パッチのポイントで操作します。

ポイントパッチ条件をpolyMesh/pointMesh/boundaryファイルで指定できるようになり、フィーチャーのエッジ、ポイント、内部ポイントにも制約を適用できるようになりました。

チュートリアルのmesh/blockMesh/sphere7は、これを使用して球状のブロックメッシュを立方体に戻す方法を示しています。

このチュートリアルでは、プラグインのポイントスムーサーを使う、新しいdisplacementPointSmoothingモーションソルバーの使用例も紹介します：

• laplacian : 近隣点の平均位置
• geometricElementTransform : 最も直交する形状に移動する。

注

• 点の移動中に点法線が更新されない
• ポイントモーションでは、周期的なパッチは現在正しく処理されていません。
• これらの追加pointPatchは以下によってサポートされる：
  • moveDynamicMesh, subsetMesh
  • decomposePar, reconstructPar, redistributePar
  • some mesh motion solvers

チュートリアル

• $FOAM_TUTORIALS/mesh/blockMesh/pipe
• $FOAM_TUTORIALS/mesh/blockMesh/sphere7
• $FOAM_TUTORIALS/mesh/moveDynamicMesh/badMove
• $FOAM_TUTORIALS/mesh/moveDynamicMesh/bendJunction
• $FOAM_TUTORIALS/mesh/moveDynamicMesh/faceZoneBlock

ソースコード

• $FOAM_SRC/OpenFOAM/meshes/pointMesh/pointBoundaryMesh/pointBoundaryMesh.C

リクエストのマージ

• Merge request #715

新しいポイントパッチ機能

• topoSet に patchToPoint が追加されました : pointPatch のすべての点を選択します (patchToFace と faceToPoint を使って polyPatch の点を取得します)。
• 新しい点境界条件：edgeSlipとpointAttraction（新しいpointMesh境界条件のチュートリアルで使用されます。）
• symmetryPolyPatch : 平均方位を計算する際に、ゼロサイズの面を無視する。 これは、後の押し出しのために厚さゼロのレイヤーを追加できるようにするための便利な機能です。

数値

新しい融合離散化

新しい融合離散化手法は、中間補間ステップを回避し、面ベースの積分と融合する。 機能は通常の離散化と同等です：

• gradSchemes : fusedGauss
• divSchemes : fusedGauss
• laplacianSchemes : fusedGauss, fusedLeastSquares

これらの方式はメモリ操作を回避するため、パッチ数が多い場合や、GPUがCPUのデータにアクセスするなど、メモリアクセスが遅いノードに有利である。 logs-gauss'がデフォルトの動作、'logs-fused'がドロップイン置換融合スキームを示しています：

これは予備的な作業であり、明示的な操作しか考慮していないこと、また操作の順序が異なるために切り捨て誤差が異なることに注意されたい。

チュートリアル

• $FOAM_TUTORIALS/ncompressible/simpleFoam/pitzDaily_fused

ソースコード

• $FOAM_SRC/src/fusedDiscretisation

リクエストのマージ

• MR!712

新しいGAMGアグロメレーション・キャッシング

Moving mesh cases automatically rebuild the agglomeration for every time step (or even every pressure corrector). For most mesh motion cases, however, the GAMG agglomeration table can be kept for some iterations before needing to be recreated. For solid-body motion there is no need to update the table since the agglomeration logic only depends on the matrix coefficients. Caching is enabled via the new updateInterval entry. This can be a very large number for solid-body simulations; for general mesh motion this should be based on the expected mesh Courant number.

p
{
    solver              GAMG;
    ..
    cacheAgglomeration  yes;
    updateInterval      100000;
}

For verbose feedback on the agglomeration, activate the debug switches in the system/controlDict

DebugSwitches
{
    // Print agglomeration
    GAMGAgglomeration   1;
}

faceAreaWeight optimisation

The default agglomeration method employs a pair-wise combination of 'cells' based on the magnitude of the face weight connecting the cells. Currently this uses a face weight derived from face area vectors, perturbed to avoid jitter in the agglomeration boundary on an axis-aligned mesh.

When the updateInterval is not 1, the weights are calculated using unscaled, unperturbed face area magnitudes to be more consistent with Gaussian-type discretisation. This can yield a slight improvement in the number of GAMG cycles, e.g. the incompressible/pisoFoam/LES/motorBike tutorial using 10 iterations of simpleFoam showed an average reduction in cycles of around 10%:

Note that algebraic agglomeration can run with updateInterval; but it

• does not update cyclicA(C)MI and will do a bad job of the interpolation since it uses an old stencil at the coarser levels
• is based on the matrix coefficients which are changing during the simulation so would not be constant even during solid-body motion

Tutorials

• $FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/propeller

Source code

• $FOAM_SRC/finiteVolume/fvMatrices/solvers/GAMGSymSolver/GAMGAgglomerations/faceAreaPairGAMGAgglomeration

Merge request

• Merge request #707

Improved lduMatrix, lduAddressing

The scalar matrix class lduMatrix has been extended to make it easier to work with cell-based algorithms. The addressing lduAddressing includes a lowerCSRAddr accessor that returns the lower addressing, avoiding the additional indirection using loSortAddressing:

const labelUList& lduAddressing::lowerCSRAddr() const

This is constructed on-the-fly from the lowerAddr() addressing.

Additionally, the matrix has been extended with a lowerCSR() accessor that returns the corresponding reordering of the lower() coefficients, or can be constructed directly:

const scalarField& lduMatrix::lowerCSR() const

Availability of the addressing can be checked using the hasLowerCSR() function.

An example usage is given inside the lduMatrix::Amul routine:

if (hasLowerCSR())
{
    // Note: lowerCSR constructed from lower if available, upper otherwise
    //       so is handling symmetric()
    const scalar* const __restrict__ lowercsrPtr = lowerCSR().begin();

    for (label cell=0; cell<nCells; cell++)
    {
        scalar& val = ApsiPtr[cell];

        val = diagPtr[cell]*psiPtr[cell];

        // Add lower contributions
        {
            const label start = loStartPtr[cell];
            const label end = loStartPtr[cell+1];

            for (label i = start; i < end; i++)
            {
                const label nbrCell = lcsrPtr[i];
                val += lowercsrPtr[i]*psiPtr[nbrCell];
            }
        }
        // Add upper contributions
        {
            const label start = oStartPtr[cell];
            const label end = oStartPtr[cell+1];

            for (label i = start; i < end; i++)
            {
                const label nbrCell = uPtr[i];
                val += upperPtr[i]*psiPtr[nbrCell];
            }
        }
    }
}

Source code

• $FOAM_SRC/OpenFOAM/matrices/lduMatrix/lduAddressing/lduAddressing.H
• $FOAM_SRC/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrix.H
• $FOAM_SRC/OpenFOAM/matrices/lduMatrix/lduMatrix/lduMatrixATmul.C

Improved wall distance

The near-wall distance field used in e.g. turbulence wall functions, has been updated for wall faces, changing the behaviour of cells with faces on multiple wall patches. The nearest distance is calculated as the minimum distance from the cell centre to the local wall face or any local edge- or point-connected face. Note that this

• is not parallel consistent
• only considers one face

For more consistent behaviour the exact wall distance method should be employed.

Previous behaviour (OpenFOAM v2406 and earlier) can be obtained by deactivating the useCombinedWallPatch info switch in etc/controlDict or the local system/controlDict:

OptimisationSwitches
{
    useCombinedWallPatch    0;
}

With a skewed/tetified version of the cavity mesh, v2406 wall distance:

The new behaviour looks across the side patches as well as the top patch:

Source code

• $FOAM_SRC/meshTools/cellDist/cellDistFuncs.C
• $FOAM_SRC/finiteVolume/fvMesh/wallDist/nearWallDist/nearWallDist.C
• $FOAM_SRC/finiteVolume/fvMesh/wallDist/wallDistAddressing/wallDistAddressing.C
• $FOAM_SRC/meshTools/cellDist/patchWave/patchDataWave.C
• $FOAM_SRC/meshTools/cellDist/patchWave/patchWave.C

Merge request

• Merge request #700

Issue

• Issue #3215

Community contribution: Improved adjoint optimisation

OpenFOAM v2412 adds some quality-of-life changes to the adjoint library. The initial values of the design variables in topology optimisation can now be read through the 0/alpha field, which can be easily set using the topoSet/setFields utilities. Previously, this was only possible through 0/uniform/topOVars, which is harder to manipulate.

The multiplier of the term added to the mathematical optimisation problem of ISQP and MMA to guarantee feasibility (named 'c') can now be given by a Function1, to allow its manipulation throughout the optimisation loop. A typical example would be setting it to a small value in the first few optimisation cycles, to focus on optimality rather than feasibility, and gradually increase it.

Added the option to disable damping of the approximate Hessian in ISQP. In the general case, this is to be avoided but can accelerate the algorithm in some fringe cases.

Tutorials

• $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/1_Inlet_2_Outlet/porosityBased/R_10x-init

Source code

• $FOAM_SRC/optimisation/adjointOptimisation

Merge request

• Merge request #710

New zoneBlended scheme

The new zoneBlended scheme enables users to apply differencing schemes per-face-zone. Schemes are set in dictionary format according to:

divSchemes
{
    .
    .
    div(phi,U)      Gauss zoneBlended
    {
        default         defaultScheme;
        faceZone1       scheme1;
        faceZone2       scheme2;
        ...
        faceZoneN       schemeN;
    }
    .
    .
}

The default entry specifies the background scheme; additional schemes can be set per faceZone, e.g. scheme1 is applied to faceZone1, scheme2 is applied to faceZone2 etc.

Source code

• $FOAM_SRC/finiteVolume/interpolation/surfaceInterpolation/schemes/zoneBlended

Solvers and physical models

Community contribution: Improved shielding function for SA-DDES turbulence model

The Delayed Detached-Eddy Simulation (DDES) model [1] is a hybrid RANS/LES approach which aims to model all attached boundary layers via RANS and massively separated flow regions via LES. To prevent the activation of the LES mode inside of attached boundary layers, an additional safeguard function referred to as "shielding" function is implemented. Unfortunately, the standard formulation [1] can collapse on fine grids, leading to a decline of wall shear stresses and potentially premature flow separation. These phenomena are often referred to as "modelled stress depletion" and "grid-induced separation" in the literature. Deck & Renard [2] recently proposed an improved shielding function which offers more robust behaviour while still allowing a rapid switch to LES in separated shear layers. The formulation was developed for the ZDES mode 2 (2020) turbulence model, which is a variant of the SA-DDES model. The figures demonstrate the benefit of the improved shielding function for the flow around a NACA4412 airfoil with trailing edge separation. The grid on the suction side is strongly refined in the streamwise and spanwise directions, causing the standard shielding function to retreat and premature flow separation to occur. In contrast, the improved shielding function retains RANS mode in the entire attached boundary layer region on the suction side, and the prediction agrees well with reference RANS from the NASA code CFL3D.

following turbulence modelling features are included in the v2412 release:

• Improved shielding function formulation of Deck & Renard [2], implemented for SpalartAllmarasDDES, activated via the new option “shielding” (keyword “standard” selects the standard function [1], “ZDES2020” selects the improved formulation [2]).
• An additional option “usefP2” activates a more robust shielding mode for the Deck & Renard formulation (detailed in equation A.9 of [2]).

Example usage

simulationType LES;
LES
{
    LESModel         SpalartAllmarasDDES;
    SpalartAllmarasDDESCoeffs
    {
        // optional keywords for shielding function
        shielding    ZDES2020;    // default: standard
        usefP2       false;       // default: false
    }

    delta            maxDeltaxyz;

    turbulence       on;
    printCoeffs      on;
}

Note that the improved shielding function is not implemented for the kOmegaSSTDDES model, since the formulation presented in [2] was specifically derived for SA-based DDES.

Tutorial

• $FOAM_TUTORIALS/incompressible/pimpleFoam/LES/NACA4412

Attribution

• The improved shielding function of Deck & Renard (2020) [2] was implemented by Upstream CFD GmbH and integrated into OpenFOAM in collaboration with ESI-UK Ltd with funding by Volkswagen AG.

References

• [1] P. Spalart, S. Deck, M. Shur, K. Squires, M. Strelets, and A. Travin. A new version of detached-eddy simulation, resistant to ambiguous grid densities. Theoretical and Computational Fluid Dynamics, 20(3):181–195, 2006.
• [2] Deck, S., & Renard, N. (2020). Towards an enhanced protection of attached boundary layers in hybrid RANS/LES methods. Journal of Computational Physics, vol. 400, pp. 108970, 2020.

Improved Lagrangian injection model: coneNozzleInjection

This release introduces two minor enhancements to the coneNozzleInjection model:

• A new injection method that distributes particles uniformly at angular intervals across a disc;
• Inclusion of the injector's estimated speed to particle injection. While there is no change in the input or output behaviour for static injectors, the velocity of particles injected from moving injectors now includes the injector velocity.

A minimal example usage is as follows:

injectionModels
{
    model1
    {
        type    coneNozzleInjection;

        ...

        // The new injection method: discSegments
        injectionMethod         discSegments;
        nInjectors              10;
        initialInjectorDir      (1 0 0);
    }
}

Source code

• $FOAM_SRC/lagrangian/intermediate/submodels/Kinematic/InjectionModel/ConeNozzleInjection/ConeNozzleInjection.H

Merge request

• Merge request #719

Improved solid-body motion function: tabulated6DoFMotion

The tabulated6DoFMotion model now includes a linear interpolation option. A minimal example usage is as follows:

solidBodyMotionFunction tabulated6DoFMotion;

interpolationScheme     linear;  // spline;

Source code

• $FOAM_SRC/meshTools/solidBodyMotionFunctions/tabulated6DoFMotion/tabulated6DoFMotion.H

New finite-area framework: Film-separation models

Finite-area-based film curvature separation models have been updated, and a new film-separation model added for sharp edges. These updates improve the accuracy and flexibility of film-separation predictions under a wide range of geometric and flow conditions.

Key changes and additions:

• Owen-Ryley model:
  • The existing curvatureSeparation model has been re-implemented as the OwenRyleyModel, based on the work of Owen & Ryley (1983). This model assumes:
    • Once the film detaches from the surface, it immediately breaks into a fine mist of droplets. As a result, it may not accurately represent scenarios where the liquid leaves as a cohesive mass.
    • The film flows around a rounded corner with a fixed radius, potentially limiting its applicability at sharp corners where curvature is not well-defined.
    • Films are thinner than 1e-4 m, with viscous effects and surface disturbances neglected.
    • Uniform film velocity and thickness.
    • The separation criterion is not explicitly formulated, but rather inferred based on the model’s assumptions.
• New film-separation model for sharp edges:
  • A new model, FriedrichModel has been introduced to compute film-separation properties at sharp edges, covering both full and partial film-separation scenarios. This model is based on the work of Friedrich et al. (2008) and Zhang et al. (2018):
    • Friedrich et al. (2008):
      • Developed a separation criterion rooted in force equilibrium within a control volume at the detachment point.
      • Assumes a maximum film thickness of 1e-4 m.
      • Considers surface tension, gravity, and film inertia.
      • Known to be relatively reliable, though it can predict premature rupture.
      • Serves as the separation method implemented in ANSYS Forte 18.2.
    • Zhang et al. (2018):
      • Enhanced the Friedrich et al. model by introducing a mass-fraction criterion. Unlike models that assume the entire film in a cell detaches simultaneously, the Zhang et al. approach detaches only a fraction of the film based on these criteria. This leads to more realistic predictions of how much film actually separates.

Comprehensive serial and parallel test cases were conducted to ensure robust corner and separation identification, involving cases with sharp edges of various shapes and orientations relative to the flow direction, and multiple spatial resolutions and parallelization configurations.

As a result, users can expect improved consistency and reliability when simulating film-separation phenomena, regardless of mesh complexity or computational setup.

A minimal example usage is as follows:

injectionModels
{
    filmSeparation
}

filmSeparationCoeffs
{
    model              OwenRyley;
    definedPatchRadii  0;
    minInvR1           0;
    deltaByR1Min       0;
}

Source code

• $FOAM_SRC/regionFaModels/liquidFilm/subModels/kinematic/injectionModel/filmSeparation/filmSeparationModels

Tutorial

• $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/pitzDailyWithSprinklers

Merge request

• Merge request #714

Improved simpleFoam: new dynamicMesh support

simpleFoam now supports a dynamicFvMesh, similar to pimpleFoam. It reads constant/dynamicMeshDict if it is present and calls its update() routine every iteration. This enables, e.g. use of steady-state simulations with dynamic mesh refinement/unrefinement.

More information

• Issue #3269

Post-processing

New report generation

The foamReport function object provides a template-based text substitution system to collect OpenFOAM run data. The user-supplied template file can take the form of any plain-text file, e.g. markdown (.md), web (.html) and latex (.tex). Entries supplied using double handlebar syntax {{ENTRY}} are replaced (case insensitive). A set of common built-ins entries beginning with OF_ are provided, e.g.

• OF_HOST: Host machine name
• OF_CASE_NAME: Case name
• OF_API: OpenFOAM API level
• OF_DATE_START: Date when job was started
• OF_CASE_PATH: file path to case
• ...

The full set of built-in and user-supplied keys can be written using the debugKeys entry. User-defined substitutions are listed in dictionary format, where substitution models include:

• fileRegEx : regular expression from file
• functionObjectValue : retrieve function object result
• dictionaryValue : value from dictionary - file-based or from registry lookup
• environmentVariable : replace keyword with environment variable
• userValue : replace keyword with user-supplied string:

Example usage based on a markdown template:

foamReport1
{
    // Mandatory entries (unmodifiable)
    type            foamReport;
    libs            (utilityFunctionObjects);

    template        "/myReportTemplate.md";

    substitutions
    {
        divSchemes1
        {
            type        dictionaryValue;
            object      fvSchemes;

            entries
            {
                divSchemes      "divSchemes";
            }
        }
        fvSolution1
        {
            type        dictionaryValue;
            path        "/fvSolution";

            entries
            {
                solver_p        "solvers/p/solver";
                solver_p_tol    "solvers/p/tolerance";
                solver_p_reltol "solvers/p/relTol";
                solver_U        "solvers/U/solver";
                solver_U_tol    "solvers/U/tolerance";
                solver_U_reltol "solvers/U/relTol";
            }
        }
        controlDict1
        {
            type        dictionaryValue;
            path        "/controlDict";

            entries
            {
                initial_deltaT       "deltaT";
            }
        }
        continuityErrors
        {
            type        functionObjectValue;
            functionObject continuityError1;

            entries
            {
                cont_error_local    local;
                cont_error_global   global;
                cont_error_cumulative cumulative;
            }
        }
    }

    // Optional entries (runtime modifiable)

    // Inherited entries
    ...
}

Example markdown-based template file:

# {{OF_EXECUTABLE}} : {{OF_CASE_NAME}} tutorial

- Case: {{OF_CASE_PATH}}
- Submission: {{OF_CLOCK_START}} on {{OF_DATE_START}}
- Report time: {{OF_CLOCK_NOW}} on {{OF_DATE_NOW}}

---

## Run information

| Property       | Value              |
|----------------|--------------------|
| Host           | {{OF_HOST}}        |
| Processors     | {{OF_NPROCS}}      |
| Time steps     | {{OF_TIME_INDEX}}  |
| Initial deltaT | {{initial_deltaT}} |
| Current deltaT | {{OF_TIME_DELTAT}} |
| Execution time | {{executionTime}}  |

---

## OpenFOAM information

| Property       | Value              |
|----------------|--------------------|
| Version        | {{OF_VERSION}}     |
| API            | {{OF_API}}         |
| Patch          | {{OF_PATCH}}       |
| Build          | {{OF_BUILD}}       |
| Architecture   | {{OF_BUILD_ARCH}}  |

---

## Mesh statistics

| Property          | Value                |
|-------------------|----------------------|
| Bounds            | {{OF_MESH_BOUNDS_MIN}}{{OF_MESH_BOUNDS_MAX}} |
| Number of cells   | {{OF_MESH_NCELLS}}   |
| Number of faces   | {{OF_MESH_NFACES}}   |
| Number of points  | {{OF_MESH_NPOINTS}}  |
| Number of patches | {{OF_MESH_NPATCHES}} |

---

## Linear solvers

| Property | Value          | tolerance(rel)   | Tolerance(abs)      |
|----------|----------------|------------------|---------------------|
| p        | `{{solver_p}}` | {{solver_p_tol}} | {{solver_p_reltol}} |
| U        | `{{solver_U}}` | {{solver_u_tol}} | {{solver_u_reltol}} |

---

## Numerical scehemes

The chosen divergence schemes comprised:

mmer547 (トーク)
{{divSchemes}}
mmer547 (トーク)

---

## Graphs

Residuals

![]({{OF_CASE_PATH}}/postProcessing/residualGraph1/{{OF_TIME}}/residualGraph1.svg)

---

## Results

Forces

![]({{OF_CASE_PATH}}/postProcessing/forceCoeffsGraph1/{{OF_TIME}}/forceCoeffsGraph1.svg)

---

Source code

• $FOAM_SRC/functionObjects/utilities/foamReport

Tutorial

• $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike

Merge request

• Merge request #716

New graph generation

The graphFunctionObject enables users to generate SVG graphs of function object result values, e.g. to show the evolution residuals, or reduced data such as force coefficients.

A minimal example is shown below:

// Generate the result values
solverInfo1
{
    type            solverInfo;
    libs            (utilityFunctionObjects);
    fields          (U p);
}

// Describe the graph
residualGraph
{
    // Mandatory entries
    libs            (utilityFunctionObjects);

    functions
    {
        //entry
        //{
        //    // Mandatory entries
        //    object      ;
        //    entry       ;
        //
        //    // Optional entries
        //    title       ;      // Default: take from dict name
        //    colour      ; // labels in range 0-255 (255 0 0)
        //    dashes      ;   // (4 1 1)
        //}
        Ux
        {
            object      solverInfo1;
            entry       Ux_initial;
        }
        Uy
        {
            object      solverInfo1;
            entry       Uy_initial;
        }
        Uz
        {
            object      solverInfo1;
            entry       Uz_initial;
        }
        p
        {
            object      solverInfo1;
            entry       p_initial;
        }
    }

    // Optional entries
    //xMin            ;
    //xMax            ;
    //yMin            ;
    //yMax            ;
    //xlabel          ;  // "Iteration";
    //ylabel          ;  // "log10(Initial residual)";
    //width           ;
    //height          ;
    //strokeWidth     ;
    //logScaleX       ;
    //logScaleY       ;
    //drawGrid        ;

    // Inherited entries
    //...
}

Source code

• $FOAM_SRC/functionObjects/utilities/graphFunctionObject

Tutorial

• $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike

New finite-area function object: surfaceCourantNumber

A new finite-area function object, surfaceCourantNumber, calculates the surface Courant number field at finite-area face centres. This represents a conceptual shift from approaches like those used in the liquidFilmFoam solver, where the Courant number is computed at edge centres. By evaluating the Courant number at face centres, surfaceCourantNumber can provide a more localized and potentially more accurate measure for surface-based flow analyses.

A minimal example usage is as follows:

surfaceCourantNumber1
{
    // Mandatory entries
    type        surfaceCourantNumber;
    libs        (regionFaModels);

    // Optional entries
    area        <word>;
    result      <word>;
    phis        <word>;
    rho         <word>;

    // Inherited entries
    ...
}

Source code

• $FOAM_SRC/regionFaModels/functionObjects/surfaceCourantNumber/surfaceCourantNumber.H

Tutorial

• $FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder

Merge request

• Merge request #706

Improved solver function objects: Outer-loop convergence check

A convergence check for outer loops has been added to the solver function objects (scalarTransport, energyTransport and electricPotential), enabling the function object to detect and terminate when further iterations are no longer necessary. This improvement can help reduce computational overhead and streamline the solution process by eliminating unnecessary loops once convergence has been achieved. A minimal example usage is as follows:

scalarTransport1
{
    // Optional entries
    tolerance    <scalar>;
    ...
}

Source code

• $FOAM_SRC/functionObjects/solvers/scalarTransport/scalarTransport.H
• $FOAM_SRC/functionObjects/solvers/energyTransport/energyTransport.H
• $FOAM_SRC/functionObjects/solvers/electricPotential/electricPotential.H

Merge request

• Merge request #699

Parallel

Improved Non-Blocking Exchange (NBX)

In OpenFOAM-v2306 an experimental 'non-blocking consensus exchange' (NBX) option was introduced - see configuration switches It can have a dramatic effect on extreme core counts with moving meshes. On a case with multiple cyclicAMI on 8192 cores and the entry (in etc/controlDict or local system/controlDict):

OptimisationSwitches
{
    // Additional PstreamBuffers tuning parameters (experimental)
    //    0 : (legacy PEX)
    //        * all-to-all for buffer sizes [legacy approach]
    //        * point-to-point for contents
    //    1 : (hybrid PEX)
    //        * NBX for buffer sizes [new approach]
    //        * point-to-point for contents
    pbufs.tuning    1;
}

Provided the following timings:

NBX	Time (s)
No	28k
Yes	18k

Note that NBX does not guarantee that the 'receive and consume' order is the same as the 'send order', meaning the truncation errors may accumulate differently. This is more sensitive for longer messages, e.g. geometry in cyclicAMI, and care must be taken to ensure a unique 'tag' (not the default Pstream::msgType()).

Source code

• $FOAM_SRC/meshTools/AMIInterpolation/AMIInterpolation

Merge request

• Merge request #704

Improved finite-area framework

Several finite-area framework routines exhibit inconsistent behaviour under parallel operation, affecting planar and non-planar finite-area meshes—regardless of skewness or non-orthogonality. These inconsistencies mainly stem from differing algorithms applied to internal- and processor-edges. For example, when a corner edge of a non-planar finite-area mesh is shared between two processors, it can introduce a subtle positive/negative perturbation in the tangential direction. Over time, this perturbation may propagate and lead to unexpected flow behaviour, such as film separation.

A series of carefully tested commits improve parallel consistency, mainly to address the following core routines:

makeLPN
makeWeights
makeDeltaCoeffs
makeCorrectionVectors
makeSkewCorrectionVectors

Source code

• $FOAM_SRC/finiteArea/faMesh/faMeshDemandDrivenData.C
• $FOAM_SRC/finiteArea/faMesh/faPatches/constraint/processor/processorFaPatch.C

Merge request

• Merge request #708

Improved reconstructParMesh

The utility reconstructParMesh can reconstruct finite-area ('faMesh') meshes, useful when the finite-area mesh is generated in parallel. Source code

• $FOAM_UTILITIES/parallelProcessing/reconstructParMesh

Merge request

• Merge request #711

Improved distributed tri-surfaces

The distributedTriSurfaceMesh can now run with a different decomposition method compared to the rest of the simulation, by specifying a decomposition method in the relevant dictionary, e.g. system/snappyHexMeshDict:

box
{
    file "box.obj";
    type distributedTriSurfaceMesh;

    // Override the decomposition method
    numberOfSubdomains  8;
    method              hierarchical;
    n                   (2 2 2);
}

It can optionally run without duplicating triangles by specifying

decomposeUsingBbs   false;

This avoids excessive memory usage, and stores a per-vertex normal and so can be extended to have smooth normals.

With both changes we now recover identical results from running non-parallel or parallel on a simple mesh. In the figure below a slice shows the non-parallel mesh as a blue surface with the parallel mesh as red lines.

Tutorials

• $FOAM_TUTORIALS/mesh/snappyHexMesh/distributedTriSurfaceMesh

Source code

• $FOAM_SRC/parallel/distributed/distributedTriSurfaceMesh/distributedTriSurfaceMesh.H

Merge request

• Merge request #720

Usability

Updated to C++17

The minimum C++ standard has been increased from C++14 to C++17 to help support ongoing GPU developments

• Commit: #44f7a726
• Source: $WM_PROJECT_DIR/wmake/rules

New tutorial demonstrations

missingCorner

This is a simple tutorial to showcase various mesh utilities:

• cellDecomposition functionObject to create a tet mesh
• polyDualMesh to convert the tets to polyhedra
• surfaceMeshExtract to create additional pointPatches
• moveDynamicMesh to slightly morph the mesh. The mesh morphing is done using a Laplacian point smoothing ignoring the feature constraints so does a bad job of improving the mesh quality.

Source code

• $FOAM_SRC/functionObjects/field/cellDecomposer
• $FOAM_UTILITIES/mesh/manipulation/polyDualMesh

Tutorial

• $FOAM_TUTORIALS/mesh/polyDualMesh/missingCorner

damBreakLeakage

This is a variant of the damBreak tutorial to showcase using cyclicACMI to control flow. In this tutorial

• additional (cyclicACMI) baffles block the flow of the liquid
• at time 0.5s a set of faces at the bottom half of the blockage open
• this is done through a cyclicACMI which uses the scale factor to convert from fully uncoupled, i.e. wall, to fully coupled.
• the scale is set through a coded Function1 entry in the patch definition in constant/polyMesh/boundary
• Initial condition: closed blockage (red)

Source code

• $FOAM_SRC/OpenFOAM/primitives/functions/Function1/Coded
• $FOAM_SRC/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch

Tutorial

• $FOAM_TUTORIALS/multiphase/interFoam/RAS/damBreakLeakage

Community

The release of OpenFOAM v2412 builds upon ongoing efforts to engage the wider OpenFOAM community to unify OpenFOAM developments, acknowledging the efforts of contributions from outside of the core OpenFOAM team.

Some developments are integrated directly into the main code base, e.g.

• Community contribution: Improved adjoint optimisation more...
• Community contribution: Improved shielding function for SA-DDES turbulence model more...

If you would like to explore the possibility to collaborate and include your developments, please contact us.

New contributions to the Turbulence Technical Committee repository

We are pleased to announce the release of the following two repositories under the umbrella of the Turbulence Technical Committee repository:

• gammaSST : A three-equation transition and turbulence model.
• HelicitySpalartAllmaras : Spalart-Allmaras turbulence model with Liu et al.'s helicity correction.

Source code

• $FOAM_SRC/$WM_PROJECT_DIR/plugins/turbulence-community

Attribution

• OpenCFD would like to acknowledge and thank Jiří Fürst, Jeff Defoe, and their colleagues for their valuable contributions and assistance.

謝辞

謝辞

OpenFOAMに貢献してくれた以下の方々に感謝します。

特別感謝

• Johan Rønby Pedersen: マルチフェーズフレームワークの並列化に貢献
• マーカス・ノードランド：流体-多孔質界面のモデリングに関する技術的な議論に協力してくれている。

課題追跡への貢献

• ilyapopov (Ilya Popov) リポジトリ内の設定ファイルの迷子？ GL#3192
• carlo.fiorina (carlo fiorina) v2406 で READ_IF_PRESENT の動作に一貫性がない GL#3193
• xpqiu (xpqiu) SPDP モードで実行するとソルバがクラッシュする GL#3194
• gng015 (gng) reconstructParMesh がバイナリでメッシュが大きすぎる場合，メッシュの再構築でスタックする GL#3196
• stefano.garbin (Stefano Garbin) OF2406 で CFMESH 実行ファイルが見つからない GL#3198
• duyquang.tdm.bd (Quang Nguyen) OpenFOAM-v2406 での ccmToFoam のクロスコンパイル時のエラー GL#3199
• ChrisSessler (Christian Sessler) multiComponentMixture と組み合わせた hConst がすべての参照エンタルピーに最初の種の Tref を使用する Href GL#3200
• ChennaK85 (Chennakesava Kadapa) sixDoFRigidBody の Newmark および Crank-Nicolson スキームの問題 GL#3202
• santiagomarquezd (Santiago Marquez Damian) 3 次元未満でテンソルの球面部分が間違って計算される GL#3203
• DL (David Ludlow) overPimpleDyMFoam と v2406 における kOmegaSST 分割の不具合 GL#3204
• bPaillard (Benoit Paillard) オーバーセットチュートリアルにおける圧力変動 GL#3207
• mzy (Zeyao Ma) icoReactingMultiphaseInterFoam V2206 で凝固問題を解くと固相が常に動いてしまう GL#3208
• zzphub (Zhipeng Zhang) 2306 の debian12 ソースビルドに失敗 GL#3210
• Charlfmare (Charl Mare) SwirlFanVelocity が新しい OF バージョンで動作しない GL#3211
• lizhisongsjtu (zhisong li) bug: solitary wave - McCowan and Grimshaw GL#3212
• daniel.jasinski (Daniel) buoyantSimpleFoam の圧力制御の欠落 GL#3213
• pferro (Paulin FERRO) solidificationMeltingSource がバグっぽい GL#3214
• rbonin (Rémi Bonin) precompiled OpenFOAM (v2406 / Windows 10) で表面膜を使用すると reactingParcelFoam がクラッシュする GL#3216
• takuya (takuya yamamoto) blockMeshDict の project 関数のチュートリアルの記述が正しくない GL#3217
• snaka (Shinji Nakagawa) foamMonitor が Gnuplot バージョン 6 の 'reread' コマンドの非推奨のためにグラフの更新に失敗する GL#3219
• ilyapopov (Ilya Popov) energyTransport が dynamicRefineFvMesh と組み合わせて動作しない GL#3221
• ntilton (Nils Tilton) fixedProfile 条件が最後のタイムステップからシミュレーションを再開しない GL#3223
• porori (takashi suzuki) diffusionGasEvaporation: 例題の使い方とチュートリアルが不適切 <= アントワーヌ方程式の定義が一般的でない（第2項の符号が逆）． GL#3224
• raphalace (Raphael Aranha) SymmetryPlane と ABL シミュレーションの不具合 GL#3226
• porori (takashi suzuki) snappyHexMesh v2012 以降で、サーフェスがサイクリックタイプの境界に接続されている場合、サーフェスレイヤーを追加できない。 GL#3227
• Skolo (Robert) wallShearStress, yPlus の入力フィールドを指定できるようにした GL#3228
• flex99 (Felix Burger) メッシュとフィールドをインポートする際の vtkUnstructuredToFoam エラー GL#3230
• acassinelli (Andrea Cassinelli) v2406 が v2312 より最大 ~3% 遅くなった GL#3231
• croquemadame (Juan Salazar) 後処理のためにフォームファイルのサーフェスフォーマットをディスクから指定の場所に読み込むクラス (foamSurfaceReader) GL#3232
• gerlero (Gabriel Gerlero) CGAL 6 との互換性 GL#3234
• xuegy (Guanyang Xue) SolidificationMeltingSource の異なる液相線と固相線 GL#3235
• gerlero (Gabriel Gerlero) dl.openfoam.comがGitHub Actionsからのリクエストを拒否している GL#3236
• cthorenz (Carsten Thorenz) interFoam： 可変密度乱流モデル使用時のせん断応力計算が正しくない / 動作しない GL#3237
• mfikrikasim (Mohd Fikri Kasim) OpenFoam v2306 - SnappyHexMesh の問題 GL#3239
• hikassem (Hassan Kassem) ConeNozzleInjection が均一でない GL#3240
• jczhang07 (Junchao Zhang) "openfoam/etc/bashrc" が非常に遅い GL#3245
• jczhang07 (Junchao Zhang) Icx コンパイラで `pthread_create' への未定義参照のリンクエラー GL#3251
• djarecki (Dominic Jarecki) EASY FIX: アクティブ熱物理モデルに線形 EOS を含める GL#3252
• jczhang07 (Junchao Zhang) "petscFoam" を未定義のシンボルでロードできなかった GL#3253
• richardt (Richard Tribess) BUG: AMR および collisionModel pairCollision でラグランジアンソルバーを実行する際に storeGlobalPositions が呼び出されない GL#3256
• hungnguyenphd (Quoc Hung Nguyen) sphereDrag が非常に小さい粒子サイズで動作しない GL#3257
• rbonin (Rémi Bonin) 太陽計算機が 24 時間以上の実行時間で間違った太陽方向を提供する GL#3258
• jczhang07 (Junchao Zhang) '-fp-model precise は -fp-model=precise であるべき GL#3259
• porori (takashi suzuki) interCondensatingEvaporatingFoam with InterfaceHeatResistance モデルが蒸発による体積変化を適切に評価しない GL#3261
• licg1981 (CHENGGONG LI) foamInstallationTest が gcc/g++ のバージョンを読み込めない GL#3263
• lizhisongsjtu (zhisong li) of2206: vectorCodedSource が動作しない。 GL#3264
• cibanez (Cristóbal Ibáñez) dynamicMotionSolverFvMeshMAMI の再実装 GL#3265
• cthorenz (Carsten Thorenz) snappyHexMesh： レイヤー追加処理でパッチ形状が破壊されることがある GL#3270
• jczhang07 (Junchao Zhang) RPATH リンクの失敗 GL#3274
• janga (Jan Gärtner) v2406 における boundaryInternalField() のコンパイルエラー GL#3277
• johan_roenby (Johan Roenby) BUG: plicRDF が周期的なパッチを越えて正常に動作しない GL#3279
• haampie (Harmen Stoppels) stubs サブディレクトリへの rpath が見つからない GL#3283
• sreplogl (Scott Replogle) マスターの初期クローンは成功したが、無効なパスのためチェックアウトに失敗 GL#3284
• janga (Jan Gärtner) Parcels の origProcId の命名を統一する GL#3287

会社概要

OpenFOAMは、ESI-OpenCFDのコアチームによって制作されています。

• Andrew Heather
• Mattijs Janssens
• Mark Olesen
• Prashant Sonakar
• Pawan Ghildiyal
• Kutalmış Berçin
• Matej Forman
• Chiara Pesci
• Martin Lichtmes
• Jiri Polansky
• Ann Ronchetti
• Fred Mendonça
• Swapnil Salokhe

グローバルESIチームからの幅広いサポート

• ESI Group (GmbH)
• ESI Group (ESI Software (India) Private Limited)
• ESI Group (North America)
• ESI Group (Nihon ESI)
• ESI webteam

次からの寄付もある。

• Marian Fuchs: Upstream CFD GmbH
• Vaggelis Papoutsis: PCOpt/NTUA and FOSS GP
• The OpenFOAM Community