OpenFOAM® v2512 新リリース

OpenFOAM Teamは、2025年12月リリースとなるOpenFOAM® v2512を発表しました。

このリリースでは、OpenFOAM-v2506の機能を、コードの多くの領域にわたって拡張しています。

新しい機能は、Keysightの顧客による支援を受けた開発、社内資金による開発、およびOpenFOAM communityから提供された機能や変更を統合したものです。

OpenFOAMはKeysightによってGPL Licenseの下で配布されています。

さまざまなLinuxおよびその他のPOSIXシステムでコンパイル可能なソースコードパッケージに加え、このリリースでは複数のコンパイル済みバイナリパッケージも提供されています。

Ubuntu Linux: Ubuntu 24.04（LTS）、22.04（LTS）など向けのパッケージインストール。
openSUSE Linux: Leap 16.0、15.7、15.6向けのパッケージインストール。
Red Hat Linux系: EPEL 9、Fedora 41、42向けのパッケージインストール。
Apptainer images: Docker Hubから`openfoam-dev:2606-apptainer`および`openfoam-dev:apptainer`として利用可能。

Windowsユーザーには、コンパイル済みパッケージを利用するための3つの選択肢があります（詳細情報）。

Windows Subsystem for Linuxを使用する方法（Ubuntu、openSUSEなどをベースとする）。
クロスコンパイルによるネイティブ実行ファイルを使用する方法。
Dockerを使用する方法。

OpenFOAMのApptainerサポートは、事前に構築されたイメージではなくdescription fileによって提供されます。

packaging/containersを参照してください。

macOSユーザーは、ソースコードからコンパイルするか、コンパイル済みパッケージをDocker containerから利用できます（詳細情報）。

ニュース

OpenFOAMリポジトリのGitLabへの移行が完了しました。

v2506のリリース発表以降、OpenFOAMのすべてのcore repositoryは、従来のhttps://develop.openfoam.comから、新しいhttps://gitlab.com/openfoamへ正常に移行されました。

現在、OpenFOAMのすべてのcore repositoryには以下からアクセスできます。

https://gitlab.com/openfoam/core/openfoam

ユーザーはGitLabアカウントを作成することで、repositoryへのアクセス、issueの投稿、およびmerge requestによる貢献が可能です。

今回の移行は、コミュニティでの共同開発をさらに進めるための重要な一歩となります。

GitLabプラットフォームは、version control、merge request、code review workflowのための強化されたツールを提供しており、世界中のcontributorがOpenFOAMの開発へより容易に参加できるようになります。

新しいrepository locationで作業を開始するには、remote URLを更新してください。また、OpenFOAMへの貢献を予定している場合はGitLabアカウントを作成してください。

以前のプラットフォームのユーザー情報については、アカウント名の競合により完全には移行できませんでした。ただし、新しいGitLabアカウントは簡単に作成でき、作成後すぐにすべてのrepository機能を利用できます。

OpenFOAM Teamはコミュニティからの貢献を歓迎しています。GitLabへの移行以降、すでに複数のmerge requestを受け取り、対応しています。

このような共同開発の取り組みにより、主要なオープンソースCFDプラットフォームとしてのOpenFOAMの位置付けがさらに強化されます。

前処理

コミュニティ貢献: leak-path検出の改良

shortestPathSetは、2組の点群を受け取り、その2組を接続する「mesh」上の経路を特定するline-sampling手法です。

これは通常、メッシュのデバッグに使用されるほか、snappyHexMeshメッシュジェネレータでも使用されています。

今回のリリースではRobert Perryによる貢献が取り込まれ、複雑な並列計算ケースにおいて複数の経路が存在する場合に、より適切に処理できるようになりました。

`sets` Function Objectを使用してleak pathを検出する代表的な入力例を以下に示します。

leakFind
{
    type            sets;

    writeControl    timeStep;
    interpolationScheme cell;
    setFormat       vtk;

    // Needs at least one field
    fields          ( processorID );

    sets
    {
        leakFind
        {
            type    shortestPath;
            insidePoints   ((3.0001 3.0001 0.43));
            outsidePoints  ((1 0 1.3));
            axis    xyz;
        }
    }
}

ソースコード

$FOAM_SRC/sampling/sampledSet/shortestPath/shortestPathSet.H

チュートリアル

$FOAM_TUTORIALS/mesh/snappyHexMesh/insidePoints
$FOAM_TUTORIALS/mesh/snappyHexMesh/motorBike_leakDetection

GitLab Issue

Issue #3464
Issue #3453

Merge request

Merge request #779

貢献者

Robert Perryによる貢献です。

コミュニティ貢献: createPatchの改良

createPatchユーティリティを使用して、boundary faceを既存または新規のpatchへ移動できるようになりました。

今回のリリースでは、以下の機能が追加されています。

patch fieldに対して指定された入力値を使用します（Alexey Matveichevによって提供されたpatch）。
サイズが0のpatchを作成できるようになりました。

`patchFields`を使用した設定例を以下に示します。

//- Optional override of added patchFields. If not specified
//  any added patchFields are of type calculated.
patchFields
{
    p
    {
        type            fixedValue;
        value           uniform 300;
    }
}

ソースコード

$FOAM_UTILITIES/mesh/manipulation/createPatch

GitLab Issue

Issue #2726
Issue #3410

貢献者

Alexey Matveichevによる貢献です。

数値計算

gradient cachingの改良

既存のgradient caching機能を発展させ、今回のリリースではgradientをin-placeで更新する機能が導入されました。これにより繰り返し行われていたメモリ割り当てが不要となり、gradient計算を多用する解析における計算オーバーヘッドが削減されます。

Gradient cachingは`system/fvSolution`ファイルで設定します。ユーザーはpattern matchingを使用して、すべてのgradientまたは特定の変数のgradientについてcachingを有効にできます。

例えば、

cache
{
    "grad(.*)";
}

と設定します。

改良されたcachingシステムでは、gradient用のストレージを一度だけ割り当て、fieldの値が変化した際にはそのストレージ上で値を直接更新します。

これにより、わずかな設定だけで計算性能を向上させることができます。

デモケースは以下に用意されています。

$FOAM_TUTORIALS/incompressible/simpleFoam/pitzDaily_fused

このチュートリアルを使用した性能テストでは、以下のように段階的な性能向上が確認されています。

Gradient scheme             Time [s]
Gauss                       1.63
fusedGauss                  1.56
fusedGauss + cache all      1.40

ユーザーはdebug出力を有効にすることで、cachingの動作を確認できます。

DebugSwitches
{
    solution    1;
}

通常、以下のようなメッセージが表示されます。

Cache: Calculating and caching grad(U) : allocating and calculating a gradient.
Cache: Reusing grad(U) : found a cached grad(U) originating from the same U.
Cache: Updating grad(U) : found cached grad(U) but U has changed so update.

ソースコード

$FOAM_SRC/finiteVolume/finiteVolume/gradSchemes

チュートリアル

$FOAM_TUTORIALS/incompressible/simpleFoam/pitzDaily_fused

Merge request

Merge request #764

新しいexpression template

今回のリリースには、field演算の実行方法を変えるexpression template libraryの初期バージョンが含まれています。

この強力な最適化手法では、中間fieldのメモリ割り当てを排除し、複数の演算を単一の計算kernelへ統合するとともに、GPU offloadingを含むハードウェアアクセラレーションを可能にします。

基本機能はcontainer level（List）で動作し、さらにgeometric field level（volScalarFieldなど）で動作するよう拡張されています。

実用的な例として、fused scheme群があります。

なお、現在の機能仕様はまだ確定したものではなく、コードは引き続き活発に開発されています。

以下は、CPU上での`volScalarField` expressionのテスト例です。

単純な代数演算

c = a + b

複雑な代数演算

c = cos(a + 0.5*sqrt(b-sin(a)))

注意事項

GeometricFieldに対するexpression evaluationは、以下の3つの独立した評価に分けられます。

internal field
uncoupled patch field
coupled patch field

AMDから提供された革新的な機能により、fused patch evaluationが可能になりました。

この機能では、すべてのuncoupled patch（またはcoupled patch）が単一のkernelによって処理されます。これにより、多数のboundary patchを持つケースでは性能を大幅に向上できます。

用途

現在の機能は、基本的なListおよびGeometricFieldについてテストされています。
Off-loading機能は、AMDおよびNVIDIAの主要なunified-memory architecture上でテストされています。
現在の構文はかなり冗長であり、より簡単に使用できるようにするための開発が進められています。
Expression templatingは、surface fieldやfinite-area fieldなど、任意のGeometricFieldへ適用できます。
内部的には、incompressible kEpsilonおよびkOmegaモデルのexpression template版が作成されており、既存モデルを比較的容易に変換できることが実証されています。

ソースコード

$FOAM_SRC/OpenFOAM/expressionTemplates/ListExpression.H
$FOAM_SRC/OpenFOAM/expressionTemplates/GeometricFieldExpression.H
$FOAM_SRC/fused/finiteVolume/fusedGaussLaplacianSchemes.C

チュートリアル

$FOAM_TUTORIALS/incompressible/simpleFoam/pitzDaily_fused

Merge request

Merge request #764

AMI: 新しいcached interpolation addressingおよびweight

Arbitrary Mesh Interpolation（AMI）のstencilおよびweightをcacheできるようになりました。

これにより、特にコア数の多い環境において、移動メッシュ解析の性能を大幅に向上できる可能性があります。

新しいcaching機能では、保存されている情報を再利用することで、AMI構築時の並列通信およびstencil assemblyを不要にします。

初期テストでは、移動する車輪を含む外部空力解析において、コア数が多い場合に10～30%の高速化が確認されました。

固定時間刻みを使用し、1回転が整数個のtime stepに分割されている場合に最適な性能が得られます。この場合、cacheされた情報を直接再利用できます。

それ以外の場合には、cacheされたinstance間で線形補間が適用されます。

Cacheされた値はangular binに保存されます。

binは`polyMesh/boundary`ファイルでpatchを定義する際に、オプションの`cacheSize`エントリを使用して指定します。

例えば、1度間隔でbinを作成する場合は以下のように設定します。

AMI1
{
    type            cyclicAMI;
    AMIMethod       faceAreaWeightAMI;
    neighbourPatch  AMI2;

    ...

    // New optional entries

    // Cache size: deactivated if not present/zero-sized
    cacheSize       360;

    // Always store a set of AMI data if the bin is empty
    forceCache      false;

    // Maximum number of bins from current bin to search to construct
    // the interpolation stencil. Default = 2
    nThetaStencilMax 2;
}

ソースコード

$FOAM_SRC/meshTools/AMIInterpolation/AMIInterpolation
$FOAM_SRC/meshTools/AMIInterpolation/AMIInterpolation/AMICache.H

チュートリアル

$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2D

Merge request

Merge request #744

GAMG: 新しいdecomposition agglomeration

GAMG solver向けの新しいdecomposition agglomeration手法では、既存の領域分割アルゴリズムを利用します。

これにより、研究者や上級ユーザーはmultigridのcoarsening strategyを検討する際に、より柔軟な設定を行えるようになります。

入力例を以下に示します。

p
{
    solver          GAMG;
    smoother        GaussSeidel;
    agglomerator    decomposition;
    decompositionCoeffs
    {
        numberOfSubdomains  8;
        method              scotch;
    }

    // Optional renumbering
    // renumber         true;

    // Optional avoid enforcing connectedness of each coarse level
    // forceConnected   false;

    interpolateCorrection   true;
    nCellsInCoarsestLevel   8;

    ...
}

`numberOfSubdomains`パラメータを制御することで、ユーザーは個々の問題特性および計算要件に合わせてcoarsening levelを細かく調整できます。一般的に、2段階を超えるcoarsening levelを使用する場合には、second-order correctionを使用することが推奨されます。

interpolateCorrection true;

decomposition methodは起動時に各coarse cellに対して呼び出されるため、計算全体のコストが増加することに注意が必要です。 Connectivity enforcement処理では、領域の接続性を維持するためにcoarse levelのcellが追加生成される場合があります。ただし、`forceConnected`を`false`に設定することで、この処理を無効化できます。

forceConnected false;

また、Scotchなどのdecomposition methodは、コンパイルオプションによって非決定論的な動作を示す場合があり、連続した計算実行の間で結果に差異が生じる可能性があることに注意してください。

ソースコード

$FOAM_SRC/parallel/decompose/decompositionMethods/decompositionAgglomeration

Merge request

Merge request #774

コミュニティ貢献: GAMGの再現可能な計算結果

この改良は、geometric agglomeration（faceAreaPairGAMGAgglomeration）を使用する解析の再現性に関するものです。

一部のアーキテクチャでは、agglomerationの結果が実行ごとに変化する場合があります。

これは、OpenMP形式のoffloadingを使用した場合に、agglomerationの構築処理が異なる経路をたどる可能性があることに起因します。

初期agglomerationに何らかの変化が生じると、その影響は最も粗いlevelに至るまで、agglomeration全体へ伝播します。

その結果、収束挙動にも違いが生じます。この影響はtoleranceを厳しくすることである程度軽減できます。

この問題を発見し、修正したAMDに感謝いたします。

ソースコード

$FOAM_SRC/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGAgglomerations/pairGAMGAgglomeration

GitLab Issue

Issue #3450

貢献者

Advanced Micro Devices（AMD）

ソルバーおよび物理モデル

乱流: kEpsilonモデル向けの新しいtwo-layer wall treatment

標準k-epsilonモデルは高Reynolds数モデルであるため、例えば`y+ < 11`のように壁面近傍を解像した格子では、壁面せん断応力および熱流束の予測が不正確になります。

この問題に対応するため、two-layer wall treatmentが導入されました。

壁面に近いinner-layerでは、代数関係式によって`νt`および`ε`を定義します。一方、outer-layerでは、これらの値を標準k-epsilonモデルから求めます。

このモデルは、オプションの`twoLayerTreatment`フラグによって有効化できます。

デフォルトでは、このフラグは無効になっています。

平板上の流れのケースでは、`y+ ∼ 1`の格子において、skin frictionおよびNusselt数の予測値が高くなることが確認できます。

これに対して、`twoLayerTreatment`フラグを使用すると、格子依存性が大幅に低減します。

ソースコード

$FOAM_SRC/TurbulenceModels/turbulenceModels/RAS/kEpsilon

Merge request

Merge request #783

Finite-area: 新しいzonal dynamicContactAngle

Finite-area frameworkに、zoneに基づいてcontact angleを指定する機能が追加されました。

これにより、液膜表面上で空間的に変化する濡れ特性を設定できるようになりました。

例えば、複数の材料で構成される表面や、領域ごとに異なる化学処理が施された表面など、領域によってcontact angleが異なる複雑な状況をモデル化できます。

Contact angleは、contact lineにおける力のバランス計算に影響するため、液膜が固体表面上でどのように広がり、時間発展するかを決定する重要な要素です。

従来は、finite-area surfaceごとに単一のcontact angle値しか指定できなかったため、不均一な濡れ挙動を表現する能力に制限がありました。

`dynamicContactAngle`モデルでは、persistent field storageを使用することで、zoneに基づく定義をサポートするようになりました。

これにより、`setFields`ユーティリティを使用して、空間的に変化するcontact angle分布を設定できます。

液膜のforce modelにおけるzone-based contact angleは、以下のように設定します。

// Mandatory entries
forces (dynamicContactAngle);

dynamicContactAngleCoeffs
{
    // Mandatory entries
    Ccf             <scalar>;

    // Optional entries
    mode            <word>;
    hCrit           <scalar>;
    distribution    <subDict>;

    // Conditional entries
        // Option-1: when 'mode' is 'zonal'
        // 'dynamicContactAngleForce:theta' field can be set using 'setFields'
        // utility. If there is no such field, a zero field is assigned
        // to the entire finite-area surface, ie single zone. The units of
        // the 'dynamicContactAngleForce:theta' field is [deg].

        // Option-2: when 'mode' is 'filmSpeed'
        Utheta           <Function1<scalar>>;

        // Option-3: when 'mode' is 'filmTemperature'
        Ttheta           <Function1<scalar>>;
}

ソースコード

$FOAM_SRC/regionFaModels/liquidFilm/subModels/kinematic/force/contactAngleForces/dynamicContactAngleForce/dynamicContactAngleForce.H

Finite-area: 新しいImmersed Boundary Method（IBM）

今回のリリースでは、finite area（FA）libraryに新しいImmersed Boundary Method（IBM）機能が追加されました。

これにより、境界形状に適合したメッシュを作成することなく、複雑な形状と薄膜との相互作用をより柔軟にモデル化できるようになりました。

このモデルは新しい`regionFaModel`として実装されています。

Velocity boundary fieldの設定で`kinematicThinFilmIBM`を選択することで有効化できます。

例えば、新しく追加されたwindshieldチュートリアルでは、`U`の境界条件を以下のように設定します。

myPatch
{
    type                velocityFilmShell;
    ...
    region              film;

    // New model: kinematicThinFilmIBM
    liquidFilmModel     kinematicThinFilmIBM;
}

このモデルを使用するには、`<constant>/regionFaIBMProperties`ファイルが必要です。

このファイルに各bodyを記述します。

例えば、以下のように設定します。

IBM1
{
    surface             "<constant>/surface1.obj";

    solidBodyMotionFunction ...;

    // Motion properties for body IBM1
    ...
}

IBM2
{
    surface             "<constant>/surface2.obj";

    solidBodyMotionFunction ...;

    // Motion properties for body IBM2
    ...
}

各obstacleは閉じたsurface geometry fileによって表現されます。

また、それぞれのobstacleには`solidBodyMotionFunction`を使用してmotionを設定できます。

ソースコード

$FOAM_SRC/regionFaModels/liquidFilm/kinematicThinFilmIBM/regionFaIBM

チュートリアル

$FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/windshield

Merge request

Merge request #784

後処理

Function Object: mapFieldsの改良

`mapFields` Function Objectが拡張され、mesh motionを扱えるようになりました。

代表的な入力dictionaryは以下のようになります。

{
    // Mandatory entries
    type            mapFields;
    libs            (fieldFunctionObjects);
    mapRegion       myTetMesh;
    mapMethod       cellVolumeWeight;
    consistent      yes;
    fields          (U); // ("U.*" "p.*");
}

上記の例では、転送先メッシュ（`mapRegion`）は`cellDecomposer` Function Objectを使用して別途生成されていることに注意してください。

`cellDecomposer` Function Objectは、cellをtetrahedronへ分割することができます。

元ページの図は、`mixerVesselAMI2D`チュートリアルの移動メッシュ上のvelocity fieldを、静止メッシュへmappingした結果を示しています。

ソースコード

$FOAM_SRC/functionObjects/field/mapFields/mapFields.H

GitLab Issue

Issue #3472

Function Object: wallHeatFluxの改良と新しいgauge model

Heat-flux gaugeは、実験装置の壁面に設置される物理的な計測装置です。

その多くは水冷されているため、gaugeの温度は周囲の壁面温度とは異なります。

従来、このような計測装置をシミュレーションするには、OpenFOAMの`wallHeatFlux` Function Objectを使用するために、各gauge位置に小さな専用patchを作成する必要がありました。このため、メッシュ生成やケース設定が複雑になっていました。

新しいgauge wall-heat flux後処理機能では、個別のpatchを作成することなく、heat-flux gaugeを通過する対流および放射熱流束を計算できます。

これらのgaugeは任意の位置に指定でき、以下の物性を設定できます。

温度
吸収率
放射率

出力は、以下の熱流束予測値について、それぞれ個別のファイルとして提供されます。

対流熱流束
放射熱流束
全熱流束

さらに、`wallHeatFlux` Function Objectのリファクタリングが行われ、将来的に追加のheat flux modelを組み込めるような構造になりました。

なお、今回の更新には既存の`wallHeatFlux`設定との後方互換性が含まれています。

gauge modelの最小構成例を以下に示します。

FOwallHeatFlux
{
    // Mandatory entries
    type        wallHeatFlux;
    libs        (fieldFunctionObjects);
    model       gauge;  // or 'wall' for the existing wallHeatFlux model
    Tgauge      <scalar>;
    patch       <word>;

    // Optional entries
    absorptivity  <scalar>;
    emissivity    <scalar>;
    T             <word>;
    qin           <word>;
    alphat        <word>;
    convective    <bool>;
    radiative     <bool>;
    writeFields   <bool>;

    // Inherited entries
    ...
}

ソースコード

$FOAM_SRC/functionObjects/field/wallHeatFlux/wallHeatFlux.H

チュートリアル

$FOAM_TUTORIALS/compressible/rhoSimpleFoam/squareBend

Merge request

Merge request #767

Function Object: 新しいradiometer probes model

`radiometerProbes` Function Objectを使用することで、計算領域内の任意の位置における入射放射熱流束をモニタリングできるようになりました。

この機能により、放射解析をboundary surfaceだけでなく計算領域内部へ拡張できます。

例えば、以下のような用途に利用できます。

放射センサーの配置検討
内部熱環境の評価

従来、入射放射熱流束（`qin`）の計算はboundary patch faceに限定されており、解析可能な位置は表面上に限られていました。

そのため、計算領域内部の点で放射データを必要とする技術者や研究者には、直接的なsampling手段がありませんでした。

新しいFunction Objectは、OpenFOAMの`probes` sampling基盤を利用することでこの問題を解決し、ユーザーが指定した計算領域内の位置において、方向を考慮した入射放射を取得できるようにします。

`radiometerProbes` Function Objectの最小構成例を以下に示します。

radiometer
{
    // Mandatory entries
    type                radiometerProbes;
    libs                (utilityFunctionObjects);
    probeLocations      (<vectorList>);
    probeNormals        (<vectorList>);

    // Inherited entries
    ...
}

ソースコード

$FOAM_SRC/functionObjects/utilities/radiometerProbes/radiometerProbes.H

Merge request

Merge request #766

基盤機能

メモリ: メモリ割り当てを回避する新しいPatchField関数

この機能強化は、最新の計算機アーキテクチャ上でOpenFOAMの性能を向上させるための継続的な取り組みの一環です。

現在のprocessorでは、cache効率やmemory bandwidthが性能を左右する重要な要因となっており、メモリ割り当てに伴うオーバーヘッドの影響がますます大きくなっています。

まず、patch field関数はtemporary fieldを戻り値として返す代わりに、結果を格納するbufferを引数として受け取るようになりました。

例えば、

patchNeighbourField(UList<Type>& result)

が、

tmp<Field<Type>> patchNeighbourField()

に代わって使用されます。

次に、`GeometricField` objectのinternal storage部分は、`Field`ではなく`DynamicField`から派生するようになりました。

これにより、address可能なサイズを超えるstorageを自動的に扱えるようになります。

追加のstorageは一度だけ割り当てられ、その後はfieldとともに保持されます。

この追加storageは、API callによってデータを書き込むためのscratchpadとして使用されます。また、internal valueと取得したboundary valueに対して、同じindexingを使用できるようになりました。

このscratchpadを使用しない場合のオーバーヘッドは、単一の`label`のみであり、ほぼゼロです。

これらの拡張機能はfused discretisation methodで使用されています。

これにより、`fvPatchFields`に対する演算で発生するメモリ割り当ての大部分を回避できます。

さらに、offloadingを目的としたcell-based loopの実装も大幅に簡略化されます。

メモリ: Memory pool

最新の計算機アーキテクチャをサポートするための継続的な取り組みの一環として、OpenFOAMの`List`および`Field` containerでUmpire memory managementを使用できるようになりました。

Memory poolの使用は、特にGPUシステムやhigh-bandwidth memoryを搭載したシステムで重要となります。

OpenFOAMがUmpireを有効にしてコンパイルされている場合、その使用方法は`FOAM_MEMORY_POOL`環境変数または`memory_pool` optimisation switchによって制御できます。

現在は、以下のmemory poolを選択できます。

host memory
device memory
managed（unified）memory

さらに、memory poolのサイズやincrementに関するパラメータも設定できます。

Memory poolへのinterfaceは外部から詳細が見えないopaqueな構造として維持されています。

このため、既存のOpenFOAM installationにmemory pool supportを追加する場合でも、ごくわずかな再コンパイル（OSspecific）と再リンク（OpenFOAM）だけで対応できます。

ソースコード

VTK: OpenFOAM/VTK基盤の更新

将来的な新しいVTKHDF data formatへの対応を見据え、OpenFOAM/VTK基盤の調整がすでに進められています。

`globalOffset`などの並列計算基盤の更新に加え、unstructured（volume）meshの内部管理機構では、現在のstream-based formattingに代わる方法として、global addressing spaceをサポートするようになりました。

VTKHDF formatは新しい標準として引き続き発展しているため、今後のOpenFOAMリリースでもさらなる対応が追加される予定です。

ユーザビリティ

ParaView: reader moduleの改良

OpenFOAMのParaView向け追加reader module（`paraFoam`）が更新され、新しいmulti-area finite-area frameworkをサポートするようになりました。

Finite-area frameworkの更新の一環として、area fieldはvolume fieldおよびpoint fieldとは別に登録されるようになりました。

これに対応して、reader moduleには新しくarea fieldを選択する項目が追加されました。

ParaViewの`blockMeshDict` reader module（`paraFoam -block`）も更新され、異なるregionをサポートするようになりました。

また、blockMeshのpointについては、OpenFOAMで使用されているものと同じ精度（floatまたはdouble）が維持されるようになりました。

Repository: GitLabへの移行が正常に完了

OpenFOAM repositoryのGitLabへの移行が完了しました。

v2506のリリース発表以降、OpenFOAMのすべてのcore repositoryは、従来のプラットフォームであるhttps://develop.openfoam.comから、新しいhttps://gitlab.com/openfoamへ正常に移行されました。

現在、OpenFOAMのすべてのcore repositoryには以下からアクセスできます。

https://gitlab.com/openfoam/core/openfoam

ユーザーはGitLabアカウントを作成することで、repositoryへのアクセス、issueの投稿、およびmerge requestによる貢献が可能です。

今回の移行は、コミュニティによる共同開発をさらに進めるための重要な一歩となります。

GitLabプラットフォームは、version control、merge request、およびcode review workflowのための強化されたツールを提供しています。

これにより、世界中のcontributorがOpenFOAMの開発へより容易に参加できるようになります。

新しいrepository locationで作業を開始するには、remote URLを更新してください。また、OpenFOAMへの貢献を予定している場合には、GitLabアカウントを作成してください。

以前のプラットフォームのユーザー情報については、アカウント名の競合により完全には移行できませんでした。

ただし、新しいGitLabアカウントは簡単に作成でき、作成後すぐにすべてのrepository機能を利用できます。

OpenFOAM Teamはコミュニティからの貢献を歓迎しています。

GitLabへの移行以降、すでに複数のmerge requestを受け取り、対応しています。

このような共同開発の取り組みにより、主要なオープンソースCFDプラットフォームとしてのOpenFOAMの位置付けがさらに強化されます。

並列計算

Collated-IO

Collated formatを処理するコードが更新され、簡素化されました。

今回の変更では、データ転送時のメモリオーバーヘッドを削減するとともに、rank間で必要となる並列処理の協調動作（同期ポイント）の一部を削減することを目的としています。

Non-collatedのmaster-only writingでは、ファイル内容が利用可能になった時点で書き込みを行うpolling dispatch方式が使用されるようになりました。

従来のcollated writingに加えて、今回のバージョンではcollated formatのbackendとしてMPI-IOを使用するオプションも追加されています。

作成されるファイルは、既存および過去のcollated formatと完全な後方互換性があります。

つまり、MPI-IOを使用してcollated fileを作成し、それを古いバージョンのOpenFOAMで読み込むことができます。

一時的に使用する場合、ユーザーはcollated backendのoptimization switchを使用して選択できます。

例えば、

mpirun -np NN redistributePar \
    -decompose -parallel \
    -fileHandler collated -opt-switch collated.backend=1

と指定します。

継続的に使用する場合は、`etc/controlDict`内の対応するentryを変更できます。

OffsetRangeおよびGlobalOffset

新しい`OffsetRange`および`globalOffset` containerは、メモリおよび通信のオーバーヘッドを最小限に抑えながら、global addressingを簡単に扱うためのものです。

これらはいずれも、start、size、totalの情報を保持するシンプルで軽量なcollectionですが、slabまたはhyperslab addressingと呼ばれるaddressing方式の意味付けを提供します。

使用例を以下に示します。

globalOffset cellSlab = mesh.nCells();
globalOffset pointSlab = mesh.nPoints();
globalOffset faceSlab = mesh.nFaces();

Foam::reduceOffsets(comm, cellSlab, pointSlab, faceSlab);

Info<< "nCells:" << cellSlab.total() << nl;

// OR

List<globalOffset> slabs = ...;

Foam::reduceOffsets(comm, slabs);

ソースコード

$FOAM_SRC/OpenFOAM/primitives/ranges/offsets/OffsetRange.H
$FOAM_SRC/OpenFOAM/parallel/globalOffset/globalOffset.H

MPI Intrinsics

今回のバージョンでは、`Pstream` libraryにいくつかの小規模ながら有用な変更が加えられました。

`Pstream`はMPIへの中間interfaceであり、上位レベルのコードを特定のMPI versionやMPI vendorから分離する役割を持っています。

ScanおよびExscan

`Pstream` classに、これまで対応していなかった`MPI_Scan`および`MPI_Exscan`（exclusive scan）関数へのinterfaceが追加されました。

これらの機能はこれまで特に必要とされていませんでしたが、exclusive scan関数をsummationと組み合わせることで、globalに一貫したoffsetを生成するための非常に有用でscalableな方法を提供できます。

また、現在の`globalIndex`で必要となる通信よりも、通信オーバーヘッドを削減できます。

Broadcast

今回のバージョンではbroadcast機能が拡張され、任意のrankをrootとしてprimitive dataをbroadcastできるようになりました。

これにより、異なるprocessor rankが処理を担当し、データを配布するような協調アルゴリズムを構築できます。

find_first、find_last

新しい`UPstream::find_first()`および`UPstream::find_last()` methodは、異なるprocessor rank間で処理を協調させるための便利で低コストな手段を提供します。

使用例を以下に示します。

// Find the first rank with a valid reference point

label refCelli = mesh.findCell(<point>, ...);

label ranking = UPstream::find_first((refCelli >= 0), communicator);

if (ranking < 0)
{
    // Nobody found it - try something else
    ...
}

// Lowest rank takes the lead
if (ranking != UPstream::myProcNo(communicator))
{
    refCelli = -1;
}

この例では、有効なreference pointを検出した最初のrankを検索しています。

どのrankも検出できなかった場合には、別の処理を実行できます。

有効なreference pointが見つかった場合には、最も番号の小さいrankが処理を担当します。

この例をさらに拡張し、他のrankへ情報をbroadcastするかどうかを決定することもできます。

reduceOffset、reduceOffsets

新しい`Foam::reduceOffset()`および`Foam::reduceOffsets()`関数は、メモリおよび通信のオーバーヘッドを最小限に抑えながら、globalに一貫したoffset rangeを定義するための機能です。

これらの関数では、新たに追加された`Exscan`関数を利用して各rank固有のoffsetを決定します。

さらに、更新されたbroadcast methodと組み合わせることで、全体のsizeをすべてのrankへ通知します。

既存の`globalIndex`と比較すると、この新しい方法ではMPIの`Allgather`通信パターンを`Exscan`とbroadcastに置き換えることで、scalabilityを向上させています。

また、`reduceOffsets()`関数を使用することで、複数のoffset collectionをまとめて計算できます。

この関数では、すべての値をまとめて通信するため、必要となるMPI function callは正確に2回だけです。

プラグイン

新しいplugin: Research repository

`plugins` submoduleに新しいrepositoryであるResearchが追加されました。

新しいResearch repositoryは、OpenFOAM本体のリリースにはまだ含まれていない、実験的または研究用途のOpenFOAM開発成果を共有するためのプラットフォームとして導入されました。

このrepositoryは、以下のような開発成果を公開するためのstaging areaとして使用されます。

まだ開発が完了していないもの
非常に実験的なもの
特殊な用途に特化したもの
その他、core distributionへ含める準備が整っていないもの

一方で、これらの成果はユーザーや研究者にとって有用である可能性があり、同様のcustom applicationを開発する際の実装例としても利用できます。

このrepositoryの内容は現状のまま提供されます。

安定性、後方互換性、長期的なサポートは保証されていません。また、API、名称、動作などが予告なく変更される場合があり、componentそのものが削除される可能性もあります。

各開発成果は自己完結した構成となっており、通常は以下のものが含まれています。

コード
`README.md`または`README.pdf`によるドキュメント
オプションのtest case

Repositoryに最初に収録されたmodelとその概要は以下の通りです。

Directory                         Context                 Short description
redistributedResistivityAlgorithm Solver                  多孔質媒体向けRhie-Chow interpolation method
FastRK                            Solver                  fractional methodに基づくpressure-velocity coupling algorithm
PRECISE                           Incompressible solver   PISOに代わるpressure-velocity coupling algorithm
HelicalForce                      Lagrangian              指定した軸周りのparcelのhelical motion

各modelの詳細については以下を参照してください。

Re-Distributed Resistivity algorithm

CFDによる単相流体のmacro-scale porosity modellingでは、fluid-porous interface近傍で物理的に妥当な数値解を得ることが一般的な課題となります。

アルゴリズム上の特別な対策を行わない場合、このinterfaceにおける材料物性、特にporous resistivityの不連続性によって、数値解に望ましくない振動が発生する可能性があります。

Fluid-porous domainの急峻なinterface近傍で発生する非物理的な振動を回避する有望な手法として、Nordlund et al. (2016)によるRe-Distributed Resistivity（RDR）algorithmがあります。

この手法では、従来のPISO algorithmおよびRhie-Chow interpolation methodが修正されています。

さらに、PISOのpredictor stepの前に追加の処理が導入され、porous resistanceをinterfaceに隣接するcellへ再分配します。

高Reynolds数かつ低Darcy数の流れにおけるtime-stepの制約を回避するため、modeling termはimplicitに扱われます。

標準PISOとRDR algorithmを使用し、fluid-porous interfaceにおいて流れ方向に1-to-2のmesh refinementを適用したtest結果が示されています。

詳細およびその他のtestについては以下を参照してください。

redistributedResistivityAlgorithm::README.pdf

掲載されている比較結果は以下の通りです。

Mesh: 流れ方向に1-to-2 refinement
Streamwise flow speed: 流れ方向に1-to-2 refinement
Centreline streamwise-velocity profile: 流れ方向に1-to-2 refinement

Fast Runge-Kutta method

DES/LES approachを使用した非定常性の強いsimulationでは、SIMPLE系のpressure-velocity coupling algorithmは計算速度が遅いことが報告されています。

Pressure-velocity coupling algorithmの別の手法として、fractional-step（projection）algorithmがあります。

Fractional-step algorithmはSIMPLE系algorithmと比較して、大規模な非定常simulationにおける計算コストの面で有利であることが報告されています。

Karam & Saad (2023)によって提案された「FastRK」と呼ばれる有望な手法が実装されました。

このalgorithm familyは、velocity fieldを以下の成分に分解するHelmholtz decompositionに基づいています。

solenoidal（divergence-free）成分
irrotational（curl-free）成分

この手法では、まずincompressibility constraintを必ずしも満たさないintermediate velocity fieldを計算します。

その後、projection stepを実行してincompressibility constraintを満足させることで、pressureとvelocityをcouplingします。

例として、2次元Taylor-Green vortex問題において以下のsimulation CPU timeが得られています。

Solver      tcpu [s]    Difference vs pisoFoam
pisoFoam       12.47    -
RK00            7.95     4.52
RK01           18.74    -6.27
RK10           19.37    -6.90
RK11           26.51   -14.04
RK000           9.21     3.26
RK001          18.06    -5.59
RK010          20.23    -7.76
RK100          15.47    -3.00
RK101          23.24   -10.77
RK110          25.08   -12.61
RK011          26.34   -13.87
RK111          31.3    -18.83

この結果は各solverのCPU timeを比較したものです。

詳細およびその他のtestについては以下を参照してください。

FastRK::README.pdf

PRECISE algorithm

Co-located-gridを使用したfinite-volume applicationでは、PISO algorithmがtime-stepおよびrelaxation factorに依存することが確認されています。

これは主としてRhie-Chow interpolation methodに起因することが知られています。

この問題に対する有望な手法の一つとして、Ammad et al. (2024)によって提案された「PRECISE」algorithmがあります。

PRECISEは、

PISO with consistent Rhie and Chow Interpolation and Second-Order Extrapolation

の略称です。

PRECISE algorithmでは、PISO algorithmにおけるtime-stepおよびrelaxation factorへの依存性が軽減されるとされています。

さらに、second-order interpolation unitを追加することで、計算挙動の安定性が向上しています。

元のtest caseを再現した結果に加え、under-relaxation factorおよびtime-step sizeを変化させた各種control studyの結果が示されています。

掲載されている比較は以下の通りです。

各solverにおけるlift coefficientの計算結果に対するunder-relaxation factorの影響の比較
各solverにおけるlift coefficientの計算結果に対するtime-step sizeの影響の比較

詳細およびその他のtestについては以下を参照してください。

PRECISE::README.pdf

ソースコード

$WM_PROJECT_DIR/plugins/research

貢献者

Markus Nordlund、Tony Saad、Ammad Ammad、およびその共同研究者の貴重な貢献と支援に感謝いたします。

コミュニティ

謝辞

OpenFOAMに貢献してくださった以下の方々に、心より感謝いたします。

貢献: Merge request

Robert Perry: leak path detection algorithmの`shortestPathSet`の改良: MR#779（merge済み）
- Sampling pointが複数のprocessorに分散している場合のmulti-processor robustnessを向上。
- Processor boundary付近のpointに対してperturbationを用いたcell searchを追加。
- Processor数が多い場合に処理が停止することを防ぐため、すべてのMPI reduction operationがすべてのprocessorから呼び出されることを保証。
- Target cellがlocalで見つからない場合に、最も近い有効なcellを検索するfallback mechanismを追加。

Yann R: `rhoCentralFoam`で`localEuler`を使用した場合にCourant numberが誤って出力される問題を修正: MR#776（merge済み）。

Christian Rohr: `simpleFoam`に`frozenFlow` optionを追加: MR#770（議論中）。

Carsten Thorenz: wall functionにおけるcell-to-wall distance計算に関する問題: MR#773（議論中）。

AMD: 再現性のあるagglomeration。

貢献: Issue tracking

Johan Roenby（johan_roenby）: documentationおよびcommentの改善 GL#3457
Chris Schleicher（PorscheGTIII）: `dynamicMotionSolverFvMeshAMI`使用時のrestartに関する問題 GL#3456
Shinji Nakagawa（snaka）: Debian 12（Bookworm）向けprecompiled package（v2406）の不足 GL#3455
Martin Niemann（mniemann）: `waveModel`がinflowで誤った方向にphaseを生成する問題 GL#3454
Robert（Skolo）: 特定のcore数でのみleak path detectionによって`snappyHexMesh`がnullptr crashする問題 GL#3453
Ian Cowan（Tobermory）: `multiRegionHeater` tutorial scriptのbug GL#3448
Umut Can Coskun（umutcc）: `sphereDrop`の`Allrun-parallel`で`reconstructParMesh`が失敗する問題（v2406、v2506で確認） GL#3447
Kumar Krishna（kpishar20）: `kinematicParcelFoam`のsource termに修正が必要 GL#3446
Carsten Thorenz（cthorenz）: time steppingに関する問題 GL#3444
Julio Pieri（JulioPieri）: PaSR combustion model使用時にprocessor subdomain内でscalar fieldが自発的に拡散／生成される問題 GL#3442
Tobias Holzmann（shorty）: `ViscosityModels::read()`関数がどこからも呼び出されていない問題 GL#3441
Martino Pinto（mPinto_TUDelft）: `sampleLine`によってsimulationが停止するbug GL#3437
Martin Aunola（aunola）: `compressibleInterFoam`がrestartに失敗する問題 GL#3435
MANOEL SILVINO ARAUJO（silvino）: `Foam::multiphaseMixture::calcAlphas()`のerror GL#3434
muez abdalla（muez）: OpenFOAM MinGW版へのdead link GL#3433
Shinji Nakagawa（snaka）: `ArrheniusNewtonian` modelでtemperatureに応じてviscosityが更新されない問題 GL#3432
Sergey Lesnik（Serge）: parallel I/O性能を改善するcoherent mesh formatのリリース GL#3431
Daniel Jasinski（daniel.jasinski）: `Ranges minMaxOp`がcomment outされているにもかかわらずTurboWGで使用されている問題 GL#3430
Shinji Nakagawa（snaka）: Lee modelにおけるsolid-to-liquid mass transferの符号が誤っている問題 GL#3429
Thorsten Zirwes（g3）: AMRと`fieldAverage`に関する問題 GL#3428
Tomasz Gorniak（Gabriel777）: `https://dl.openfoam.com/add-debian-repo.sh`が停止している問題 GL#3425
Carsten Thorenz（cthorenz）: `potentialFoam`で`flowRateInletVelocity`が誤って動作するbug GL#3424
Charl Mare（Charlfmare）: OpenFOAM binary installationが動作しない問題 — `www.dl.openfoam.com`のアカウントが停止 GL#3423
Johan Roenby（johan_roenby）: openfoam.com Webページに古いAPI linkが残っている問題 GL#3420
Vigneshwaran Sankar（Vicky3141）: `foamFormatConvert` v2312で0以外のtimeについて`hostCollated` → `uncollated`のfield変換ができない問題 GL#3418
Bagus Hanindhito（bagus）: OpenFOAMをsourceからcompileする際のOpenQBMM libraryのcompile error GL#3394
Sam Mallinson（SamMallinson）: v2506のinstallation processが動作しない問題 GL#3417
Mohamed Shabara（mshabara）: 複数のnested overset mesh GL#3416
Christoph Petsch（zxchris）: Web site停止 GL#3415
O L（olly）: `dl.openfoam.com`が停止している問題 GL#3414
Ruyue Cheng（ruyue）: `patchFlowRateInjection` modelのbugにより、`sprayCloud`使用時にfloating point exceptionが発生する問題 GL#3413
Timofey Mukha（timofeymukha）: OpenFOAM solverにcustom MPI communicatorを使用させる機能 GL#3408
Mohammad Fazli（mostanad）: `icoReactingMultiphaseInterFoam`におけるsolid phase convection GL#3407
L C（Gallinator）: `momentumError` function objectがporosityを考慮していない問題 GL#3403
Aaron（aerogt3）: `surfaceHookup`がsurfaceを改善しないまま過剰なiterationを繰り返す問題 GL#3401
Vi Ig（viSig）: `snappyHexMesh`のbug — cyclic boundary使用時のcastellation error GL#3400
Filippo Pucci（filpucfd）: `chtMultiRegionSimpleFoam`における`decomposeParDict`と`useImplicit` GL#3399
Daniel Jasinski（daniel.jasinski）: macOSで`viewFactorsGen`がfailure exit codeで終了する問題 GL#3398
Aaron（aerogt3）: `noise` utilityがEnsightの`collatedTime` writeOptionを適用しない問題 GL#3397
Daniel Jasinski（daniel.jasinski）: Windows版の`memInfo::populate`実装 GL#3396
Marcelo Joao（gu1）: `prghPermeableAlphaTotalPressure`における`updateCoeffs(const scalarField& snGradp)`のERROR GL#3392
O L（olly）: Linux Ubuntu EC2 instanceでOpenFOAM installer scriptをdownloadできない問題 GL#3391
gng（gng015）: 64bit labelを使用したMinGWによるWindows向けcross compileができない問題 GL#3390
sariew8（sariew8）: `icoReactingMultiphaseInterFoam`のbug report GL#3388
Tobias Holzmann（shorty）: `RunFunctions`をprefixおよびlog file用log-directoryに対応させる改善 GL#3386
Saurabh Deshkar（saurabhd_cdac）: OpenFOAM v1706のcompatibilityについて GL#3385
Aaron（aerogt3）: v2506で多くの（またはすべての）utility／solverが`Finalising parallel run`の後に`opt-switch opt-switch`を出力する問題 GL#3384
Gerasimos Chourdakis（MakisH）: Ubuntu 25.04向けDebian package GL#3382
Thorsten Zirwes（g3）: time precisionの問題によりrestartできない問題 GL#3380
Guanyang Xue（BrushXue）: `variableHeatTransfer`でdivision by zeroが発生する問題 GL#3475
Ilya Popov（ipopov）: Web siteのRepositories pageが依然として古いrepositoryを参照している問題 GL#3473
Johan Roenby（roenby）: `dynamicMotionSolverListFvMesh`と`displacementMotionSolvers`の非互換性 GL#3471
Carsten Thorenz（cthorenz）: 複数のwall functionで誤ったcell-to-wall distanceが使用されているbug GL#3470
Daniel Jasinski（daniel.jasinski1）: scalar transportにおけるnon-uniform diffusion coefficient GL#3469
Frederic Simonis（fsimonis）: Ubuntu 25.10 Questing向けpackageの不足 GL#3467
Bernhard Gschaider（bgschaid）: OpenCFDに対するTalos Security Advisory（TALOS-2025-2292） GL#3466
Daniel Jasinski（daniel.jasinski1）: `porousBafflePressure`がDPM/MPPIC solverで動作しない問題 GL#3465
Robert Perry（skoloCFD）: 特定のcore数でのみleak path detectionによって`snappyHexMesh`がnullptr crashする問題 GL#3464
Yann R（Yann-R）: `rhoCentralFoam` — `localEuler`（LTS）使用時にCourant numberが誤って出力される問題 GL#3463
Dag Feder（dagfeder）: `rotorDiskSource` — blade angleを使用したpropeller thrustおよびtorqueの計算 GL#3462

OpenFOAM v2512 リリースノート

OpenFOAM® v2512 新リリース

ニュース

前処理

コミュニティ貢献: leak-path検出の改良

ソースコード

チュートリアル

GitLab Issue

Merge request

貢献者

コミュニティ貢献: createPatchの改良

ソースコード

GitLab Issue

貢献者

数値計算

gradient cachingの改良

ソースコード

チュートリアル

Merge request

新しいexpression template

注意事項

用途

ソースコード

チュートリアル

Merge request

AMI: 新しいcached interpolation addressingおよびweight

ソースコード

チュートリアル

Merge request

GAMG: 新しいdecomposition agglomeration

ソースコード

Merge request

コミュニティ貢献: GAMGの再現可能な計算結果

ソースコード

GitLab Issue

貢献者

ソルバーおよび物理モデル

乱流: kEpsilonモデル向けの新しいtwo-layer wall treatment

ソースコード

Merge request

Finite-area: 新しいzonal dynamicContactAngle

ソースコード

Finite-area: 新しいImmersed Boundary Method（IBM）

ソースコード

チュートリアル

Merge request

後処理

Function Object: mapFieldsの改良

ソースコード

GitLab Issue

Function Object: wallHeatFluxの改良と新しいgauge model

ソースコード

チュートリアル

Merge request

Function Object: 新しいradiometer probes model

ソースコード

Merge request

基盤機能

メモリ: メモリ割り当てを回避する新しいPatchField関数

チュートリアル

ソースコード

Merge request

メモリ: Memory pool

ソースコード

VTK: OpenFOAM/VTK基盤の更新

ユーザビリティ

ParaView: reader moduleの改良

Repository: GitLabへの移行が正常に完了

並列計算

Collated-IO

OffsetRangeおよびGlobalOffset

ソースコード

MPI Intrinsics

ScanおよびExscan

Broadcast

find_first、find_last

reduceOffset、reduceOffsets

プラグイン

新しいplugin: Research repository

Re-Distributed Resistivity algorithm