OpenFOAM v2106 リリースノートのソースを表示

== ESI OpenCFDリリース OpenFOAM® v2106 ==

OpenCFDは、2021年6月にOpenFOAM® v2106をリリースすることを発表します。このリリースでは、コードの多くの領域でOpenFOAM-v2012の機能が拡張されています。この新機能は、OpenCFDのお客様がスポンサーとなって開発したもの、社内で資金提供を受けて開発したもの、そしてOpenFOAMコミュニティからの機能や変更を統合したものです。

OpenFOAMは、OpenCFD社がGPLライセンスの下で配布しています。このリリースには、さまざまなLinuxおよびその他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加えて、次のようなコンパイル済みのバイナリパッケージも含まれています。

Ubuntu Linux: Ubuntu 18.04 20.04 20.10 21.04 用パッケージインストール
openSUSE Linux: Leap15.2, Leap15.3 用パッケージインストール
Redhat Linux：CentOS 7、8、Fedora 33用のパッケージをインストールします。
Windowsユーザーの方は、コンパイル済みパッケージの選択肢が3つあります（詳細はこちら）。

Linux（Ubuntu、centos、openSUSEパック）でのWindowsサブシステムの使用
クロスコンパイルされたネイティブな実行ファイル
dockerによるインストール
Mac OSXをお使いの場合は、ソースからコンパイルするか、Dockerコンテナを使ってコンパイル済みのパッケージを利用するかを選択できます（詳細はこちら）。

== v2106ユーザーアップグレードガイド ==

=== 非推奨と削除 ===

非推奨モデル

=== 名前の変更 ===

=== 構成・環境 ===

=== 入力辞書 ===

スカラー/ラベルの解析

スカラーやラベル（浮動小数点や固定小数点の値）の辞書の読み方が緩和され、少し不規則な入力にも対応できるようになりました。
スカラーやラベル（浮動小数点や固定小数点の値）の辞書の読み方が緩和され、少し不規則な入力にも対応できるようになりました。
以下のような辞書入力を考えてみましょう。

<syntaxhighlight>
valueA  2;
valueB  - 2;
</syntaxhighlight>

辞書から値を取得するとき

<syntaxhighlight>
Info<< "val = " << dict.get<scalar>("valueB") << nl;
</syntaxhighlight>

これは、エントリーに2つの別々のトークンがあるため、通常は失敗します。
読み取りルーチンは，スカラーやラベルの有効な入力（ただし醜い）としてこれを
スカラーやラベルの有効な（しかし醜い）入力として受け入れるように調整されました。
最初のトークンが - であれば，それは次のトークンを否定するために使われます。
は有効な数値トークンでなければなりません。
この修正は、変数の拡張を伴う入力辞書を使用する際にすぐに役立つものです。
を使用する際にすぐに役立つものです。元の例では
変数で書き換えても、正しく読み取ることができます。

<syntaxhighlight>
valueA  2;
valueB  -$valueA;
</syntaxhighlight>

このような読み方の変更は低レベルで行われますので
ベクトルなどの複合型にも自動的に適用されます。
ここでは、バウンディングボックスを定義した簡単な例を紹介します。

<syntaxhighlight>
dim    100;

min    (-$dim -$dim -$dim);
max    ( $dim  $dim  $dim);
</syntaxhighlight>

以前のバージョンでは、同じ結果を得るためには、かなり劣っていました。
ユーザーフレンドリーではありません。

<syntaxhighlight>
dim    100;

min    #eval{ vector (-$dim, -$dim, -$dim) };
max    ( $dim  $dim  $dim);
</syntaxhighlight>

'''評価'''

辞書指示子#evalの構文上のシュガーは
ロバストです。例えば、以下のようになります。

<syntaxhighlight>
value1 #eval{ round (${variable} / 20) };
</syntaxhighlight>

単に最初の右ブレースで停止するのではなく、最後の「}」まで正しく解析されるようになりました。
まで正しく解析するようになりました。式の中の波括弧と大括弧は、まだバランスをとる必要があります。
式の中の波括弧と大括弧は、まだバランスをとる必要があります。

式の中の末尾の「;」は惜しみなく無視します。
これはよくあるユーザーのミスです。

は、#eval式のフィールド幅をサポートしています。例えば、以下のようになります。

<syntaxhighlight>
entry #eval 10 { vector(rand(), 0, 0) };
</syntaxhighlight>


=== 出力ヘッダー ===

リリースノートに記載されている通りです。

ASCIIフォーマットでもアーチ情報は必ず出力されます
ヘッダーメタ情報が追加されています。
照合されたフォーマットでは、data.classとdata.formatが追加されます。
エントリが追加されます。

=== 後処理 ===

スタティック・アンサイト・ジオメトリの出力位置が変更されました。この
"ジオメトリ」は、以前はEnSight caseディレクトリの直下に置かれていました。
ディレクトリに置かれていましたが、現在は一定のデータディレクトリに移されています。
例えば、以下のようになります。

<syntaxhighlight>
ensight/ensight.case
ensight/data/constant/geometry
ensight/data/000001
ensight/data/000002 ...
</syntaxhighlight>

追加のメッシュ領域を追加する際の処理が改善され、衝突の可能性が回避されました。

== v2106開発者アップグレードガイド ==


=== 非互換性 ===

fvMeshDistribute : 幾何学的公差が削除されました。
コンストラクタのパラメータが1つになりました。

protected UList::size(label) : renamed to setAddressableSize(label)

この低レベルの保護されたメソッドに長い名前を付けることで、曖昧さを解消します。
曖昧さがなくなり（例：resize, setSize）、より正確な継承パターンが可能になります。
より正確な継承パターンが可能になります。この名前は
PtrListDetail の内部構造と一致しています。

ITstream : parsing constructor

Elminateはバージョンを解析するための必須の名前です。これにより、ITstream
ITstream、IStringStream、UListStreamの使い分けが容易になります。

=== 非推奨と削除 ===

'''非推奨のクラス'''

partialFaceAreaWeightAMI : faceAreaWeightAMIクラスで置き換えられた機能。

fieldValueDelta : multiFieldValue関数オブジェクトが提供する同等の、より柔軟な機能。

'''非推奨のメソッド'''

内部のハッシュ化ファンクタはメソッド名で標準化されています。
標準 C++ との整合性を高めています。

<syntaxhighlight>
// Old:
FixedList<label, 3>::Hash<>()

// New:
FixedList<label, 3>::hasher()

// Unchanged:
labelHashSet::hasher()
Existing Hash<> functor namings are still supported, but deprecated.
</syntaxhighlight>

'''削除されたメソッド'''

グローバル関数longestEdgeは、非推奨となり、代わりに
face::longestEdge()メソッド(2017-04)が削除されました。

2つのイテレータからListというコンストラクタを削除しました。このコンストラクタは
このコンストラクタは、std::vectorとの類似性のために追加されましたが、依然として
煩わしいものです。ListOps::create()関数は、より長い代替手段を提供します。
長くなってしまいますが、この関数には
変換を行うことができます。

fileName::clean() constメソッドの削除
const/non-constに依存して動作を制御することは(inplace change
またはコピーを返す)の動作を制御するためにconst/non-constに依存することはあまりにも脆弱で、constバージョンはほとんど使われませんでした。
はほとんど使われていませんでした。現在は、必要に応じて2段階の処理に置き換えています。

<syntaxhighlight>
// OLD (2012 and earlier)
fileName sanitized = constPath.clean();

// NEW (2106)
fileName sanitized(constPath);
sanitized.clean());
</syntaxhighlight>

'''削除されたアイテム'''

=== 定義の変更 === 

=== 行動の変化 ===

サイズを持つ DynamicField の構築が、DynamicList と一致するようになりました。
空間のみを予約し、初期のアドレス可能なサイズはゼロのままになります。
アドレス可能な初期サイズはゼロのままです。

=== トークン化/パーシングの改善 ===

OpenFOAMの解析ルーチンをより有効に活用するために、トークンハンドリング
とITstreamが拡張され、多数のフェイルセーフ・アクセス・メソッドと型の直接チェックを含むようになりました。
メソッドや、型の直接チェックが含まれています。
句読点や単語のトークンを直接チェックします。例えば

<syntaxhighlight>
if (tok.isWord("uniform")) ..

while (!tok.isPunctuation(token::BEGIN_LIST)) ..
</syntaxhighlight>

の代わりに、同等の長さのものを使用しています。

<syntaxhighlight>
if (tok.isWord() && tok.wordToken() == "uniform") ..

while (!(tok.isPunctuation() && tok.pToken() == token::BEGIN_LIST)) ..
</syntaxhighlight>

ルックアヘッド・トークンのフェイルセーフ・バージョン。Istream peek(), ITstream
peek(), peekFirst(), peekLast(). 安全なトラバース。ITstream skip().
これにより、LALR(1)パーサーをOpenFOAMの
クラスを使ってLALR(1)パーサーを書くことができます。
例えば、以下のようになります。

<syntaxhighlight>
ITstream& is = dict.lookup(key);
if (is.peek().isWord())
{
    is.skip();
}
</syntaxhighlight>

=== 新しい方法 ===

顔のクラスは、最も低い頂点の値から始まり、次に低い値の方向に歩く対称的なハッシャーを持つようになりました。
頂点の値が最も低いところから始まり、次に低い値の方向に歩いていきます。これにより
これにより、ハッシュコードが顔の向きや回転に依存しないことが保証されます。
rotationに依存しないことが保証されます。

=== その他 ===

選択肢のマッチングのために、keyTypeをwordReに置き換えました。

Listやその他のコンテナのためのsize_bytes()のnoexceptバージョンです。
ループの外で is_contiguous のチェックが既に行われている場合に使用されます。
ループの外ですでに行われている場合に使用されます。命名はstd::spanに従います。


== 前処理 ==

=== snappyHexMesh：小さなギャップでの自動絞り込みの改善 ===

snappyHexMeshは、小さなギャップでの自動リファインメントをサポートしており、gapModeとgapLevelのエントリーで有効になります。gapModeは、アルゴリズムを適用するサーフェスのどちら側かを指定し、gapLevelは希望するレベルを指定します。これは、refinementRegionで選択されたセルに適用されます。

ギャップ検出は、1つのサーフェスから別のサーフェスに向かって歩き、以下を確認することで実行されます。

2つのサーフェスがgapLevelで指定された距離よりも近い。
2つのサーフェスの法線が十分に平行である。
(v2012) サーフェスが異なっている (gapSelf false)
(v2106) 2つのサーフェスがお互いを「見ていない」、つまり間に他のサーフェスが存在しない。

なお、以下の画像はv2012のgapSelfの開発時のもので、v2106の拡張版でも同様のケースが使用されています。

'''見る'''

Issue #1463

'''ソースコード'''

$FOAM_SRC/mesh/snappyHexMesh/meshRefinement

'''チュートリアル'''

(v2012) $FOAM_TUTORIALS/mesh/snappyHexMesh/gap_detection

===splitMeshRegionsユーティリティの改善===

splitMeshRegionsユーティリティは、共役熱伝達シミュレーションなどを実行するために、メッシュを複数の領域に分割します。テオロジー（どの面でも接続されていない領域）やセルゾーンに応じて分割することができます。通常、各神学領域または各セルゾーンは、それぞれ独立したメッシュ領域になります。このバージョンでは、セルゾーンのセットを1つのリージョンにまとめることができます。

'''使用方法'''

<syntaxhighlight>
splitMeshRegions \
    -cellZonesOnly \
    -combineZones '((zoneA "zoneB.*")(zoneC zoneD))'
</syntaxhighlight>

これにより、zoneA, zoneBはzoneA_zoneBのような合成名で同じ領域に入り、zoneC, zoneDも同様に、セオリーに関係なく、同じ領域に入る。したがって、zoneA_zoneB, zoneC_zoneDは、複数の切断された部分から構成されることになる。

に注意してください。

正確な名前は現在、マッチングプロセスに依存しており、事前に知ることができません。
ゾーン名にはワイルドカードが使用できる。
予約された名前「none」は、すべての未ゾーンのセルを意味する。
次の例では、論理的に分割した後、cellZonesの組み合わせに応じて分割しています。

<syntaxhighlight>
splitMeshRegions \
    -cellZones \
    -combineZones '((zoneA "zoneB.*")(zoneC zoneD))'
</syntaxhighlight>

これは、各リージョンが単一のセルゾーンまたはセルゾーンの組み合わせを含む単一の連結された部分を含んでいることを示しています。固有のゾーンの組み合わせがないので、合成されたリージョン名はregion0、region1などとなります。

'''ソースコード'''

$FOAM_UTILITIES/mesh/manipulation/splitMeshRegions

===extrudeMeshの新しいスプラインサポート===

これは、バージョン2012で導入された押し出しモデルポリラインを拡張したものです。エッジの定義にCatmull-Romスプラインをサポートしています。

使用方法

使い方は前回のリリースと同様で、extrudeModelをpolylineに設定し、polylineCoeffs辞書を使って頂点と辺を定義しています。ただし、エッジのタイプはスプラインにすることもできます。

<syntaxhighlight>
// Using spline edges
(
    spline 0 9
    (
        ( 0 0 0.05 )
        ( 0 0 0.5 )
        ( 0.5 0 0.5 )
        ( 0.5 0 0 )
        ( 1.5 0 0 )
        ( 1.5 -1 0 )
        ( 1.5 -1 1.183974596 )
    )
);
</syntaxhighlight>

'''チュートリアル'''

$FOAM_TUTORIALS/mesh/extrudeMesh/polyline

'''ソースコード'''

$FOAM_SRC/mesh/blockMesh/blockEdges/splineEdge/CatmullRomSpline.C

'''謝辞'''

コード拡張はGuanyang Xue issue #1983により提供されています。

===checkMeshのサーフェスフィールドの書き方を改善===

checkMeshに新しいオプションwriteAllSurfaceFieldsが追加され、関連するメッシュ品質フィールドを後処理用のsurfaceFieldsとして書き込むことができるようになりました。

下の図では、内部の面の非直交性の角度を可視化するために使用されています。

サーフェスフィールドの視覚化
面の非直交性
使用方法

newオプションは、-writeFieldsまたは-writeAllFieldsオプションと組み合わせて使用されます（例）。

<syntaxhighlight>
checkMesh -writeAllFields -writeAllSurfaceFields
</syntaxhighlight>

例えば、既存のmax-per-cell nonOrthoAngleフィールドとの衝突を避けるために、face_nonOrhoAngleのように、接頭辞face_を付けて、関連するフェースベースのフィールドを書き込みます。利用可能なフィールドは以下の通りです。

face_nonOrthoAngle: 直交しない角度
face_faceWeight: 線形補間の重み(一様なメッシュでは0.5)
face_skewness: 歪度
face_cellVolumeRatio: 顔の両側のセル体積の比率
face_minPyrVolume: 面の両側にあるピラミッドの最小体積
サーフェスフィールドは、例えばfoamToVTKを使って後処理を行い、VTK/ディレクトリにParaViewに読み込めるファイルを書き出すことができます。デフォルトの方法では、サーフェスフィールドを各面の中心にポイント値として書き込みます。

<syntaxhighlight>
foamToVTK -surfaceFields
</syntaxhighlight>

例えば、顔のセットをfaceSetとして選択し、faceZoneとして出力する場合、典型的なoSetDictは以下のようになります。

<syntaxhighlight>
actions
(
    {
        name intFaceSet;
        type faceSet;
        action new;
        source boundaryToFace;
    }
    {
        name intFaceSet;
        type faceSet;
        action invert;
    }
    {
        name intFaceZone;
        type faceZoneSet;
        action new;
        source setToFaceZone;
        faceSet intFaceSet;
    }
);
</syntaxhighlight>

このfaceZoneは、フィールドを持つフェイスベースのメッシュとして出力できます。

<syntaxhighlight>
foamToVTK -faceZones '(intFaceZone)'
</syntaxhighlight>

'''ソースコード'''

$FOAM__UTILITIES/mesh/manipulation/checkMesh

===ユーティリティー・リージョンの扱いを改善===

多くのノンソルバー・ユーティリティーは、複数のメッシュ領域をサポートするように拡張されています。これらは、コマンドラインオプションを使って選択できます。

-region <myRegion> : 単一の名前のリージョンです。
-allRegions : chtMultiRegionFoamソルバーなどで使用される定数/regionProperties辞書に記載されているすべてのリージョンを指定します。regionProperties辞書が存在しない場合は、デフォルトの地域が選択されます。
-regions '(region1 region2 ... regionN)' : 名前の付いたリージョンのリストです。個々のリージョンに正規表現を指定することもできますが，その場合は constant/regionProperties 辞書のリージョン名と一致します．

新領域オプションをサポートするユーティリティーは以下の通りです。

checkMesh
decomposePar
foamToEnsight
foamToVTK
redistributePar
renumberMesh
rotateMesh
transformPoints

リージョンは1つずつ反復され、結合されないことに注意してください。

'''ソースコード'''

$FOAM_SRC/OpenFOAM/include/getAllRegionOptions.H

===パッチ表現の改善===

v1912で導入されたパッチフィールド式では、snGrad(...)、internalField(...)、neighbourField(...)の各関数がサポートされています。これらの関数により、式の中でフィールドグラデーションを使用することができ、パッチフィールド値とパッチに近い内部フィールドとの間の差分演算を簡単に定義することができます。

パッチフィールド式とボリュームフィールド式の両方で、deltaT()関数を使って現在のタイムステップにアクセスできるようになりました。

'''チュートリアル'''

$FOAM_TUTORIALS/compressible/rhoSimpleFoam/squareBendLiq

'''ソースコード'''

$FOAM_SRC/OpenFOAM/expressions
$FOAM_SRC/finiteVolume/expressions

==数値化==

===AMIパフォーマンスの向上===

faceAreaWeightAMIメソッドの代わりに、新たにfaceAreaWeightAMI2D AMIメソッドが追加されました。主な違いは以下の通りです。

三角形の交点エリアは、2Dの点座標を使用する新しい三角形クラスを使用して実行されます。
ソースパッチとターゲットパッチ間の面の候補は、AABB（axis-aligned bounding box）ベースのアプローチを用いて特定される。
テストの結果、この新しい手法は、faceAreaWeightAMIと同様の補間ウェイトとアドレッシングを生成する一方で、全体的な実行時間を5％以上短縮することができました。

'''使用方法'''

新しいオプションは、constant/polyMesh/boundary ファイルで AMI を指定する際に AMIMethod エントリを使用して設定されます（例）。

<syntaxhighlight>
AMI
{
    type            cyclicACMI;
    AMIMethod       faceAreaWeightAMI2D; // new method
    Cbb             0.1; // optional coefficient
    nFaces          1000;
    startFace       100000;
    matchTolerance  0.0001;
    transform       noOrdering;
    neighbourPatch  AMI1;
    nonOverlapPatch AMI1_non_overlap;
}
</syntaxhighlight>

オプションのCbb係数は、顔の候補ペアを探す際に使用するバウンディングボックスの大きさをコントロールするもので、デフォルト値の0.1は幅広いテストケースでうまく機能した。AMIパッチのマッチングが悪い場合、例えば回転している場合には、空間的な離散化の違いによってパッチ間に「大きな」ギャップが生じるため、この係数を大きくする必要があるかもしれません。

'''ソースコード'''

$FOAM_SRC/meshTools/AMIInterpolation/AMIInterpolation/faceAreaWeightAMI2D

==ソルバーと物理モデル==

===新しいオーバーセットソルバー===

ベースとなる多相のInterPhaseChangeFoamとCompressibleInterFoamアプリケーションにオーバーセットのダイナミックメッシュ機能が追加され、overInterPhaseChangeDyMFoamとoverCompressibleInterDyMFoamが作成されました。

次のビデオは、新しいoverInterPhaseChangeDyMFoamアプリケーションを使用したtwoSimpleRotorsチュートリアルケースです。

'''ソースコード'''

$FOAM_SOLVERS/multiphase/compressibleInterFoam/overCompressibleInterDyMFoam
$FOAM_SOLVERS/multiphase/interPhaseChangeFoam/overInterPhaseChangeDyMFoam

'''チュートリアル'''

$FOAM_TUTORIALS/multiphase/overInterPhaseChangeDyMFoam/twoSimpleRotors
$FOAM_TUTORIALS/multiphase/overCompressibleInterDyMFoam/compressibleTwoSimpleRotors

===icoReactingMultiphaseInterFoamソルバーの改良===

icoReactingMultiphaseInterFoamにダイナミックメッシュ機能が追加され、AMIや剛体運動などの使用が可能になりました。

'''Tutorials'''

$FOAM_TUTORIALS/multiphase/icoReactingMultiPhaseInterFoam/mixerVesselAMI2D/

===新しい時間依存型太陽電池負荷モデル===

太陽負荷モデルでは、直達日射量、拡散日射量、スペクトル分布などのTimeFunction1タイプの入力と同様に、時間に依存した入力が可能になりました。

時間依存の負荷を生成する以下の例は、simpleCarSolarPanelチュートリアルから引用しています。

<syntaxhighlight>
sunLoadModel timeDependent;

directSolarRad table
(
    // time irradiation
    (0 500)
    (5 500)
    (10 0)
);

diffuseSolarRad 0;

spectralDistribution table
(
    (0 (2.0 1.2))
    (1 (1.1 1.3))
);
</syntaxhighlight>

'''ソースコード'''

$FOAM_SRC/thermophysicalModels/radiation/radiationModels/solarLoad
$FOAM_SRC/thermophysicalModels/radiation/radiationModels/fvDOM

'''チュートリアル'''

$FOAM_TUTORIALS/buoyantSimpleFoam/simpleCarSolarPanel

===新しい乱流場の推定===

Spalart-Allmaras乱流モデルのk、ε、ω場を計算するための新しい推定関数が追加されました。これにより，turbulenceFields関数オブジェクトなどの様々なユーティリティーが，以前のリリースではゼロだった適切な値を返すことができるようになりましたが，今回のリリースではそれが可能になりました．

Reτ=180の平面チャネル流の直接数値シミュレーションに基づいたテストケースでは、Sparart-Allmarasモデルにおけるこれらの推定関数と、kとomegaが内部に存在するkOmegaSSTモデルの予測能力を比較しています。

'''ソースコード'''

$FOAM_SRC/TurbulenceModels/turbulenceModels/RAS/SpalartAllmaras

'''チュートリアル'''

$FOAM_TUTORIALS/incompressible/simpleFoam/airFoil2D

'''リファレンス'''

Bourgoin, A. (2019). Bathymetry induced turbulence modelling the Alderney Race site: regional approach with TELEMAC-LES. Normandie Université.

===ACMIパッチの新規レイヤー追加/削除===

これは、ダイナミックなレイヤーの追加/削除を拡張したものです。環状のACMIパッチ上でのレイヤーの追加/削除をサポートするようになりました。これにより、部分的な障害物の扱いが非常に簡単になりました。

下の写真（セルのレイヤーを追加する前と後）では、障害物（左、白い背景）がcyclicACMIに沿ってスライドしています。cyclicACMIは、左のセルと右のセルの間を、面の面積で重み付けされた補間を用いて接続します。

'''ソースコード'''

$FOAM_SRC/dynamicMesh/layerAdditionRemoval/addCellLayer.C

===改良型Ranz-Marshallモデル===

RanzMarshallモデルの新しい改良点は、ユーザーがカスタムの相関係数を入力できるようにすることで、ヌッセルト数の相関式を一般化することです。

最小限の例を以下に示します。
 
<syntaxhighlight>
subModels
{
    RanzMarshallCoeffs
    {
        // a + b Re^m Pr^n
        a 2.0;
        b 0.6;
        m 0.5;
        n 0.6666;
    }
}
</syntaxhighlight>

'''ソースコード'''

$FOAM_SRC/lagrangian/intermediate/submodels/Thermodynamic/HeatTransferModel/RanzMarshall

'''チュートリアル'''

$FOAM_TUTORIALS/lagrangian/sprayFoam/aachenBomb

===オーバーセットに対応した新しいマルチモーション===

ダイナミックオーバーセットメッシュ機能は、以前のリリースで複数のモーションソルバーに対応していたため、複数のオーバーラップするドメインが可能になりました。

今回のリリースでは、さらなる機能強化が図られています。

rigidBodyMotionにzoneMotionを追加しました。rigidBodyMotionソルバーの変位によって変形されるセルのサブセットを選択するのに便利なオプションです。
prescribedRotation拘束にPID（比例積分微分）制御を導入しました。所望の角運動量を得るために新しいPIDシステムを導入したことで、restrictedRotation拘束の数値的なロバスト性が向上しました。以下の入力辞書の例では、pは比例補正器、dは微分補正器、iは積分補正器、relaxは緩和係数を表しています。

<syntaxhighlight>
propellerRotation
{
    type                    prescribedRotation;
    body                    propeller;
    referenceOrientation    (1 0 0 0 1 0 0 0 1);
    axis                    (1 0 0);

    relax                   0.2;
    p                       0.001;
    d                       0.01;
    i                       0;
    omega                   table
    (
        (0       (0 0 0))
        (0.1     (149 0 0))
        (0.5     (628 0 0))
    );
}
</syntaxhighlight>

drivenLinearMotionは、6-Dofおよびリジッドボディソルバーで使用できます。drivenLinearMotionは、与えられた重心に「従う」ことができるリジッドボディモーションソルバーです。これにより、背景メッシュは、挿入されたリジッドボディメッシュ、つまり浮遊物体に合わせて移動することができます。これにより、挿入されたオブジェクトの変位が背景領域よりも大きい場合に、大きな背景メッシュを使用する必要がなくなります。

<syntaxhighlight>
backgroundMeshMotion
{
    ...

    motionSolver        solidBody;
    solidBodyMotionFunction drivenLinearMotion;

    cellSet             c0;
    cOfGdisplacement    CofG;
}
 
boat_propeller
{
    motionSolverLibs    (librigidBodyMeshMotion);
    motionSolver        rigidBodyMotion;

    report              on;
    cellSet             cHullProp;
     
    cOfGdisplacement    CofG;
    bodyIdCofG          1;

    ...

    bodies
    {
        hull
        {
            type            rigidBody;
            parent          root;

            ...
        }
        propeller
        {
            type            rigidBody;
            parent          hull;

            ...
        }
    }
}
</syntaxhighlight>

rigidBodyMotionには、そのボディ識別子（bodyIdCofG 1）の重心変位（cOfGdisplacement CofG）が格納され、drivenLinearMotionには、エントリーcOfGdisplacementが読み込まれます。

'''ソースコード'''

$FOAM_SRC/rigidBodyDynamics/restraints/prescribedRotation
$FOAM_SRC/dynamicMesh/motionSolvers/displacement/solidBody/solidBodyMotionFunctions/drivenLinearMotion

'''チュートリアル'''

$FOAM_TUTORIALS/multiphase/overInterDyMFoam/floatingBodyWithSpring
$FOAM_TUTORIALS/multiphase/overInterDyMFoam/rigidBodyHull

===有限領域並列サポートの改善===

makeFaMeshユーティリティとそれに対応するfiniteAreaインフラストラクチャが更新され、有限面積メッシュを並列に作成できるようになりました。典型的な使用例としては、ボリューム・メッシュがsnappyHexMeshなどで並列に作成されており、有限面積メッシュを持つリージョンが必要な場合が挙げられます。更新されたバージョンでは、有限面積メッシュの並列作成をサポートし、同時に有限面積フィールドを分解するようになりました。

有限領域メッシュの定義（faMeshDefinition）は、より柔軟になり、必須入力が少なくなり、一般的なコーナーケースにも対応できるようになりました。

ジオメトリの例では、元のメッシュが8つのサブドメインに分割されています。

この特定の分解は、有限領域が一部のドメインにしか存在しないことから、コーナーケースの一つとして選ばれました。有限領域はプロセッサとプロセッサの境界で正確に終了しますが、makeFaMesh ルーチンは物理的な流出境界を正しく定義し、初期フィールドの内部分解も正しく処理されます。

今回の変更により、ケースのセットアップが効率化されただけでなく、計算中にオンザフライで有限領域を定義することができるようになりましたが、これは今後のリリースで実現する予定です。

'''ソースコード'''

$FOAM_UTILITIES/finiteArea/makeFaMesh
$FOAM_SRC/finiteArea/faMesh
$FOAM_SRC/parallel/decompose/faDecompose
$FOAM_SRC/parallel/reconstruct/faReconstruct

'''チュートリアル'''

$FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder
$FOAM_TUTORIALS/finiteArea/sphereSurfactantFoam/sphereTransport
$FOAM_TUTORIALS/finiteArea/surfactantFoam/planeTransport

==境界条件==

===LES流入DFSEM条件の改善===

乱流DFSEMInlet境界条件の入力方法が拡張され、より柔軟になりました。

R、L、Uの入力項目がPatchFunction1タイプになりました。これはOpenFOAMのパッチフィールドで利用できる最も一般的な入力方法です。
R、L、Uの正規化係数として、スカラー量の2つの新しいデフォルトエントリーを追加しました。
Uref : 特性（基準）スケールスピード（デフォルト値=1)
Lref : 特性（基準）長さ（デフォルト値=1
これらの2つのエントリーは、入力されたR、L、Uをスケーリングします：例えば、R/Uref^2、L/Lref、U/Uref
C1正規化係数を調整するための新しいスカラー係数を追加します。
 scale：C1係数をスケーリングします（デフォルト値＝1）。
chan395DFSEMとPCFのチュートリアルをplanChannelとoneCellThickPlaneChannelのチュートリアルに置き換え、報告された結果を再現できるようにしました。
積分長スケールの入力ファイルを修正しました。planeChannelチュートリアルで得られた一連の結果（ユーザーが利用できるプロットスクリプト）を以下に示します。

'''ソースコード'''

$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/turbulentDFSEMInlet

'''チュートリアル'''

$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/planeChannel

===ジャンプ条件の改善===

ファン・ジャンプ境界条件にオプションの緩和下と最小ジャンプ値を追加しました。アンダーリラクゼーションは、非一様な空間ジャンプを適用する場合に、定常ケースの数値安定性を大幅に改善することができます。

次の図は，正方形パイプの定常ケースで，パイプの半分の位置にジャンプ面がある場合の，予測される圧力および速度場を示しています．最初のペアは、不均一なジャンプの場合、ケースが不安定になり、チェッカーボードのような不安定な状態になることを示しています。

アンダーリラクゼーションを設定すると、ケースは予想される圧力と速度のプロファイルにスムーズに進化します。

'''使用方法'''

<syntaxhighlight>
plane
{
    type            fan;
    patchType       cyclic;
    jump            uniform 0;
    value           uniform 0;
    uniformJump     false;

    // Optional minimum jump value
    minJump         0;

    // Optional under-relaxation
    relax           0.2;

    ...
}
</syntaxhighlight>

'''ソースコード'''

$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/fixedJump
$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/fan

'''チュートリアル'''

$FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/TJunctionFan

===多相流の新しい透過性境界条件===

開閉イベントを模倣してp_rghとUを更新するために、混相流用の新しい境界条件のペアを開発しました。

prghTotalPressureとfixedFluxPressureの間の動作の切り替えは、Volume of Fluid（VOF）フィールドのαによって引き起こされます。パッチにおけるαの値がαMinを超えると壁条件が、そうでない場合は全圧条件が適用されます。この組み合わせは、完全に開いた、あるいは閉じた透過性の壁の挙動を再現します。

'''使用方法'''

p_rghの仕様は以下の通りです。

<syntaxhighlight>
rightWall
{
    type            prghPermeableAlphaTotalPressure;
    alpha           alpha.water;
    alphaMin        0.01;
    p               uniform 0;
    value           uniform 0;
}
</syntaxhighlight>

Uの仕様は以下の通りです。

<syntaxhighlight>
rightWall
{
    type            permeableAlphaPressureInletOutletVelocity;
    alpha           alpha.water;
    alphaMin        0.01;
    value           uniform (0 0 0);
}
</syntaxhighlight>

'''ソースコード'''

$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/prghPermeableAlphaTotalPressure/
$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/pressurePermeableAlphaInletOutletVelocity/

'''チュートリアル'''

$FOAM_TUTORIALS/multiphase/interFoam/laminar/damBreakPermeable

==後処理==

===新しいmultiFieldValue関数オブジェクト===

multiFieldValue関数オブジェクトは、複数のfieldValue関数オブジェクト間で選択された操作を計算し、その操作は各fieldValueオブジェクトのすべての結果に適用されます。

各オブジェクトは、同じ数とタイプの結果を生成しなければならないことに注意してください。入力辞書の例を以下に示します。

<syntaxhighlight>
multiFieldValue1
{
    // Mandatory entries (unmodifiable)
    type            multiFieldValue;
    libs            (fieldFunctionObjects);

    // Mandatory entries (runtime modifiable)
    operation       subtract;

    // List of fieldValue function objects as dictionaries
    functions
    {
        region1
        {
            ...
        }
        region2
        {
            ...
        }

        ...

        regionN
        {
            ...
        }
    }

    // Optional (inherited) entries
    ...
}
</syntaxhighlight>

操作入力のオプションは以下の通りです。

add | sum : すべての値を加算する
subtract : 最初の値からすべての値を引く
min : 最小値
max : 最大値
average : 平均値

'''ソースコード'''

$FOAM_SRC/functionObjects/field/fieldValues/multiFieldValue

'''チュートリアル'''

$FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter

===新しいマルチリージョン機能オブジェクト===

multiRegion関数オブジェクトは、提供されたオブジェクトを各リージョンごとにクローン化するラッパーを提供します。これにより、複数のリージョンがある場合に同一の後処理要件を設定することが簡単になります。デフォルトでは、与えられた関数をすべてのリージョンに適用します。

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

</syntaxhighlight>
multiRegion
{
    type            multiRegion;
    libs            (utilityFunctionObjects);
    ...

    function
    {
        // Actual object specification
        type            fieldMinMax;
        libs            (fieldFunctionObjects);
        fields          (<field1> .. <fieldN>);
    }

    // Optional entries
    regions         (region1 region2);
}
</syntaxhighlight>

'''ソースコード'''

$FOAM_SRC/functionObjects/utilities/multiRegion

'''チュートリアル'''

$FOAM_TUTORIALS/heatTransfer/chtMultiRegionSimpleFoam/multiRegionHeaterRadiation

===改良型運動量エラー機能オブジェクト===

momentumErrorとdiv関数オブジェクトは、特定のcellZonesに対して操作できるようになりました。下の画像は、aerofoilNACA0012チュートリアルケースの2つのゾーンに対して計算された運動量エラーの例です。

サブメッシュを使用することで、演算の計算コストを削減できます。規定のセルゾーンの誤差を正しく捉えるために、元のセルゾーンにセルの「ハロー」または「レイヤー」を追加することができます。これにより、数値ステンシルのサイズを考慮することで、フルメッシュとセルゾーンベースの予測の間で一貫した結果が得られます。

'''Usage'''

ゾーンベースの計算は、新しいcellZonesおよびnlayers辞書項目によって有効になります。

<syntaxhighlight>
momentumError1
{
    type            momentumError;
    libs            (fieldFunctionObjects);
    p               <pName>;
    U               <UName>;
    phi             <phiName>;
    cellZones       (z1 z2);
    nLayers         2;
}
</syntaxhighlight>

'''ソースコード'''

$FOAM_SRC/functionObjects/field/momentumError

'''チュートリアル'''

$FOAM_TUTORIALS/compressible/rhoSimpleFoam/aerofoilNACA0012

===新しいクラウド機能オブジェクト===

新しいReynoldsNumber、NusseltNumber、HeatTransferCoeffクラウド関数オブジェクトは、粒子のレイノルズ数、ヌッセルト数、熱伝達率のラグランジュフィールドを計算します。

'''使用方法'''

オブジェクトは、クラウド・プロパティ・ファイルのcloudFunctionsサブディクショナリで有効にすることができます（例）。

</syntaxhighlight>
cloudFunctions
{
    ReynoldsNumber1
    {
        type ReynoldsNumber;
    }

    NusseltNumber1
    {
        type NusseltNumber;
    }

    HeatTransferCoeff1
    {
        type HeatTransferCoeff;
    }
}
</syntaxhighlight>

'''ソースコード'''

$FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/ThermoReynoldsNumber
$FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/NusseltNumber
$FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/HeatTransferCoeff

'''チュートリアル'''

$FOAM_TUTORIALS/lagrangian/sprayFoam/aachenBomb

===ダイナミック・モード・デコンポジッション（DMD）ツールの改良===

OpenFOAM v2006では、新しい「ストリーミング・トータル・ダイナミック・モード・デコンポジッション」STDMDファンクション・オブジェクトが導入され、CPUやメモリの使用量を節約して実現可能な一般的なDMD機能を提供します。 本リリースでは、以下の改良が加えられています。

DMDモジュールのリファクタリング：ユーザーが独自のDMDモデルを実装するのを支援し、奨励するために、コードは使いやすいインターフェースとクラス階層のセットを提供するために更新されました。
postProcessユーティリティーの有効化：STDMDは、ランタイムおよびポストプロセスツールとして動作するようになりました。これにより、シミュレーションが完了した後、postProcessユーティリティーを介して既存のフィールド上でDMDモデルを実行することができます。postProcessユーティリティーを使用した最小限の例は以下の通りです（ユーティリティーはDMDの設定をsystem/controlDict.functionsから読み込みます）。

<syntaxhighlight>
 <solver> -postProcess -fields '(U p)' -time '10:'
</syntaxhighlight>

パッチフィールドでの操作が可能に：従来、STDMDの適用はボリューム/内部フィールドに限られていました。今回のリリースでは、進行中の計算やwallShearStressなどの後処理の際に、選択したパッチのパッチフィールド上でDMDモデルを並行して実行することができるようになりました。

'''ソースコード'''

$FOAM_SRC/functionObjects/field/DMD
$FOAM_SRC/functionObjects/field/DMD/DMDModels/derived/STDMD

'''チュートリアル'''

$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D

===改良された距離サンプルされた表面===

このバージョンでは、OpenFOAM-v2012からの変更点を引き継いで、距離サーフェスのフィルターメソッドが追加されています。前述の通りです。

distanceSurfaceの本来の目的(入力サーフェスからの距離でサンプリングされたサーフェスを作成する)に加えて、入力サーフェスからの距離をゼロにしてサンプリングするためにも使用できます。このモードでは、サーフェスを生成するためのセルカット法のように動作します。

新しいproximityRegionsologyフィルターは、同様の問題に対応しています。例えば、次のようなシナリオでは、薄肉のパイプが異なるゾーンローグを分けています。

これは、いわゆるダブルディー・パイプや、アクチュエータ・シャフトを備えたスリーブなどで発生します。

以前のバージョンでは，フィルターが不適切な領域を選択して大失敗するか，指定するのが面倒になっていました。この問題を解決するために、新しい proximityRegionsology フィルタは、顔の近接情報と学際的なセグメンテーションを組み合わせています。

このフィルタは、元の検索面に対する結果の顔の距離をチェックして、各論理的に接続された領域の面積加重距離に基づいてフィルタリングします。このフィルタは，元の検索面に対する結果の顔の距離をチェックし，各論理的に接続された領域の面積加重距離に基づいてフィルタリングを行います．

フィルタリングアルゴリズム（v2106およびv2012フィルタ）の定義は、Sven-Eric Salecker氏（NAVASTO GmbH, on behalf of AUDI AG）と共同で、非自明なテストジオメトリに対して行われました。

'''チュートリアル'''

$FOAM_TUTORIALS/compressible/rhoSimpleFoam/squareBend
$FOAM_TUTORIALS/compressible/rhoSimpleFoam/gasMixing/injectorPipe
$FOAM_TUTORIALS/incompressible/simpleFoam/squareBend

'''ソースコード'''

$FOAM_SRC/sampling/sampledSurface/distanceSurface
$FOAM_SRC/sampling/surface/distanceSurface

===データ変換の改善===

'''foamToEnsight'''

foamToEnsight ユーティリティでは、マルチリージョンの選択と新しい -allRegions オプションがサポートされました。これにより、共役熱伝達（CHT）ケースの後処理と変換が大幅に簡素化されます。改良の一環として、finiteArea出力をサポートするために、新しい-finite-areaオプションが追加されました（foamToVTKと同様）。

EnSightのファイルフォーマットはマルチリージョンのコンテンツに適しており、OpenFOAMの各リージョンを個別のEnSightケースファイルに対応させることができます（例）。

<syntaxhighlight>
EnSight/
|-- bottomAir
|   |-- bottomAir.case
|   `-- data
|-- heater
|   |-- data
|   `-- heater.case
|-- leftSolid
|   |-- data
|   `-- leftSolid.case
|-- rightSolid
|   |-- data
|   `-- rightSolid.case
`--Air
    |-- data
    `--Air.case
</syntaxhighlight>

これにより、個々の領域または複数の領域を読み込むことができ、T（温度）のように複数の領域にまたがるフィールドや、U（速度）のように特定の領域にのみ適用されるフィールドが可能になります。

ジオメトリとフィールドの分離は、finiteAreaの変換にも適用されます。

<syntaxhighlight>
EnSight/
|-- finite-area
|   |-- data
|   `-- finite-area.case
|-- data
`-- planeTransport.case
</syntaxhighlight>

'''チュートリアル'''

$FOAM_TUTORIALS/finiteArea/surfactantFoam/planeTransport
$FOAM_TUTORIALS/heatTransfer/chtMultiRegionSimpleFoam/multiRegionHeaterRadiation

'''ソースコード'''

$FOAM_UTILITIES/postProcessing/dataConversion/foamToEnsight
$FOAM_UTILITIES/postProcessing/dataConversion/foamToVTK

'''VTKフォーマットの読み込み'''

レガシーVTKフォーマットは、近年、VTK内部の変更を反映して更新されており、すなわち、異なるレガシーフォーマットが存在します。このリリースには、新旧両方のレガシーVTKフォーマットを処理するためのVTK非構造化リーダーのアップデートが含まれており、surfaceMeshConvert、vtkUnstructuredToFoamなどの各種変換ユーティリティや、snappyHexMeshなどのその他のユーティリティに影響を与えます。

既存のワークフローを継続するために、OpenFOAMが生成するVTKレガシー出力は変更されません。ご要望に応じて、将来的には更新されたVTKレガシーフォーマットでの出力も含まれる予定です。

'''ソースコード'''

$FOAM_SRC/fileFormats/vtk/read

===ParaViewツールの改良===

ThirdPartyのソースパックにはParaView-5.9.1が同梱され、可視化モジュールは最新のVTKバージョンをサポートするように更新されました。しかし、その裏では後処理に大きな変化が起きています。

長期的には、自作のリーダーモジュールを廃止し、新しい機能をネイティブのParaView/VTKリーダーに直接組み込むことに注力したいと考えています。

ParaViewのFAQにあるように、また、ビジュアライゼーションのwikiエントリにあるように、自作のリーダーモジュールを使用する理由はほとんどありません。

ParaViewの次のリリース（5.10、2021年秋予定）には、OpenCFD Ltd.から提供された多くの修正や改善が組み込まれる予定です。

https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7273/commits
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7531/commits
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/7602/commits
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8030/commits

近い将来、追加機能を開発する予定です。

https://gitlab.kitware.com/vtk/vtk/-/issues/18157
 
==パラレル==

===ローカルワールドの新しいAMIサポート===

マルチプルワールドカップリングは、非コンフォーマルなインターフェース、すなわちAMI（Arbitrary Mesh Interface）結合パッチをサポートするように拡張されました。

'''使用方法'''

この設定では、sampleModeをnarrestPatchFaceではなく、narrestPatchFaceAMIに設定する必要があります。

<syntaxhighlight>
type                mappedWall;
sampleMode          nearestPatchFaceAMI;
sampleWorld         solid;
sampleRegion        bottomSolid;
samplePatch        ;
In the figure blow, the left boundary condition is set to a value of 1, the right 0, and it is solving a laplacian equation:
</syntaxhighlight>

'''チュートリアル''''

$FOAM_TUTORIALS/basic/laplacianFoam/multiWorld

'''ソースコード'''

$FOAM_SRC/meshTools/mappedPatches/mappedPolyPatch/mappedPatchBase.C

===起動時間の短縮===

大規模なシステムでの起動時間を改善するために、従来のOpenFOAMのollatedでないプロセッサディレクトリの取り扱いが更新されました。起動時間の遅さは、プロセッサ数が少ない場合には必ずしも顕著ではありませんが、プロセッサ数が多い場合には大きな問題となります。

以下の表に示すように、修正された処理では、プロセッサ数が多い場合の初期起動時間が約70倍に高速化されています。

{| class="wikitable"
|Configuration
|3072 procs
|6144 procs
|12288 procs
|24576 procs
|-
|old (uncollated)
|212s
|729s
|2441s
|timeout
|-
|updated (uncollated)
| 
| 
|33s
|80s
|} 

These improvements in startup times should apply for various types of filing systems.

Acknowledgements

This completes the changes initiated for OpenFOAM-v2012, which were based on the analyses and patches kindly provided by Akira AZAMI (RIST).

===Improved redistributePar performance===

redistributePar is a utility to decompose, redistribute and reconstruct cases (mesh and fields) in parallel. It can be used as a replacement for decomposePar, reconstructParMesh, and reconstructPar. The underlying algorithm to assemble the mesh and fields has been updated to a single step algorithm, yielding significant improvements when reconstructing large cases. The following table shows the timing results for a 14M cell case, running on 56 cores, timing in minutes:

{| class="wikitable"
|Application
|v2012
|v2106
|-
|reconstructParMesh
|4.32
|2.58
|-
|redistributePar -reconstruct
|11.40
|3.34
|}

redistributePar -reconstructを別のケースでのみテストします。

{| class="wikitable"
| Number of cells
|Number of processors
|v2012	
|v2106
|-
|1000
|8
|2s
|5s
|-
|1000000
|8
|15s
|13s
|-
|100000000
|8
|28m
|23m
|-
|100000000
|80
|1h15m
|19m
|}

'''備考'''

新しいアルゴリズムでは、追加の点結合ステップを必要としないため、-mergeTolオプション引数はもはや必要ありません。
これはまた、極端な状況下では、メッシュの点の連結性が若干異なる可能性があることを意味します。また、プロセッサ（面）パッチを介して別の点に接続された点は、論理的には同じ点であるというルールが厳密に適用されるようになったことに注意してください。つまり、両方の点が同じプロセッサ上にある場合は、自動的にマージされます。
古いアルゴリズムのサポートは， reconstructParMesh: reconstructParMesh -procMatch で維持されています．これは、将来のリリースでは廃止される予定です。

'''チュートリアル'''

$FOAM_TUTORIALS/mesh/parallel/cavity

'''ソースコード'''

$FOAM_SRC/dynamicMesh/fvMeshDistribute/fvMeshDistribute.C
$FOAM_SRC/dynamicMesh/polyMeshAdder/polyMeshAdder.C

===decomposeParユーティリティの改良===

decomposePar:に-domainsと-methodの-dry-runオプションが追加されました。これにより、実際に分解を行うことなく、分解の挙動や統計情報をすばやく調べることができます。dry-runを-cellDistと組み合わせて使用すると、可視化のためのVTKファイルが生成されます。

これにより、OpenFOAMのフィールドを追加する必要がなくなり、通常はロードが速くなります。また、複数の分解を検討する際に、volScalarFieldなどよりも名前の変更が容易です。

==ユーザビリティ==

===OpenFOAMパッケージの改善===

OpenFOAMは、OpenCFD社がGPLライセンスの下で配布しています。このリリースでは、さまざまなLinuxおよびその他のPOSIXシステムでのコンパイルに適したソースコードパッケージに加えて、以下のコンパイル済みバイナリパッケージも用意されています。

Ubuntu Linux：Ubuntu 18.04 20.04 20.10 21.04向けのパッケージ化されたインストール
openSUSE Linux: Leap15.2, Leap15.3用のパッケージ化されたインストール
Redhat Linux: CentOS 7、8、Fedora 33用のパッケージインストール
Windowsユーザーには、コンパイル済みパッケージの選択肢が3つあります（詳細はこちら）。

Windows Subsystem for Linux（Ubuntu、centos、またはopenSUSEのパック）の使用
クロスコンパイルされたネイティブな実行ファイル
dockerによるインストール
Mac OSXでは、ソースからコンパイルする方法と、Dockerコンテナを使用してコンパイル済みパッケージを利用する方法があります（詳細はこちらをご覧ください）。

今回のリリースでは、よりスムーズな統合を実現するためにDockerコンテナが変更され、3つの標準サイズが用意されています。

-run : 小さなフットプリントのランタイムのみのイメージ
-dev : ランタイムとOpenFOAM開発環境がセットになっています。
-default : すべてを提供するイメージ

今回のリリースから、dockerコンテナはUbuntuのコンパイル済みパッケージを使用し、Windows Subsystem for Linuxコンポーネントも通常のLinuxのコンパイル済みパッケージを使用するようになりました。これにより、dockerコンポーネントとWSLコンポーネントの更新頻度がより安定します。

===スカラーとラベルのパーシング===

スカラーやラベル（浮動小数点や固定小数点の値）の辞書の読み方が緩和され、少し不規則な入力にも対応できるようになりました。これは、次のような簡単な例のように、変数展開を伴う辞書の場合に特に有効です。

<syntaxhighlight>
valueA 2;
valueB -$valueA;
</syntaxhighlight>

読みながら、辞書の展開によって次のように展開されます。

<syntaxhighlight>
valueA 2;
valueB - 2;
</syntaxhighlight>

辞書から値を取得するとき

<syntaxhighlight>
Info<< "val = " << dict.get<scalar>("valueB") << nl;
</syntaxhighlight>

これは、エントリーが2つの別々のトークンを持っているため、通常は失敗します。読み込みルーチンは，スカラーやラベルの有効な（しかし醜い）入力としてこれを受け入れるように調整されています。最初のトークンが - であれば，それは次のトークンを否定するために使われますが，次のトークンは有効な数値トークンでなければなりません。

トークン化された入力の読み取りに対するこの低レベルの変更により、ベクターのような複合型も自動的に処理されます。ここでは、バウンディングボックスを定義した簡単な例を示します。

<syntaxhighlight>
dim 100;
min (-$dim -$dim -$dim);
max ( $dim $dim $dim);
</syntaxhighlight>

以前のバージョンでは、同じ結果を得るための操作性はかなり劣っていました。

<syntaxhighlight>
dim 100;
min #eval{ vector (-$dim, -$dim, -$dim) };
max ( $dim $dim $dim);
</syntaxhighlight>

===コマンドラインでのファイル名の扱いを改善===

また、すべてのソルバーとユーティリティーは、コマンドラインからファイル名を取得する際に、args.get<fileName>(...)を統一的に使用するように修正されました。

これにより、MS-Windowsから発生するパス名が内部で一貫して処理されるようになりました。

===Function1、PatchFunction1の仕様===

定数、多項式、表の項目を辞書項目として指定できるようになりました。テーブルFunction1にTableFile機能が追加され、コンテンツの切り替えや変更が容易になりました。

コード化された境界条件とコード化されたFunction1の定義に対する辞書アクセスを提供しました。特に、新しいFunction1定義を作成するために、Function1エントリの簡単なマッシュアップを書くことが可能になりました。

===新しいコンパイラのサポート===

インテルの openapi コンパイラ・スイートを追加サポートしました。貢献 Jong-Gwan (Jason) Do

Gcc と Clang のコンパイラ設定の更新

===ビルド・バージョン管理===

内部の cmake ラッパーは、バージョニングに MPI 情報を含めるようになりました。これにより、runTimePostProcessingのようなモジュールを複数のMPIインスタンス用にビルドすることが可能になりました。

===ポータビリティの変更===

すべてのIOオブジェクトは、そのヘッダーにメタデータの概念をサポートするようになりました。このメタディクショナリーの内容は完全にフリーフォーマットであり、OpenFOAMによって再読されることはありません。メタデータの目的は、データヘッダのみからデータコンテンツの概要を提供することです。

メッシュゾーンは、この新しいコンテンツが使用される場所の一つです。例えば

<syntaxhighlight>
FoamFile
{
    version     2.0;
    format      binary;
    arch        "LSB;label=32;scalar=64";
    class       regIOobject;
    location    "constant/polyMesh";
    object      cellZones;
    meta
    {
        names 15( inlet outlet ... porous );
    }
}
</syntaxhighlight>

これにより、下流の消費者は、ファイル全体を解析することなく、利用可能なゾーン名に素早くアクセスできます。今後、ParaView/VTKリーダーに変更が加えられれば、最小限のオーバーヘッドで特定の地域を選択できるようになります。

同様の懸念から、照合ファイルの出力を更新しました。ここでは、ヘッダー情報に、ファイルに含まれるコンテンツに関する追加情報が追加されています。例えば、以下のようになります。

<syntaxhighlight>
FoamFile
{
    version     2.0;
    format      binary;
    arch        "LSB;label=32;scalar=64";
    class       decomposedBlockData;
    location    "constant/polyMesh";
    object      boundary;
    data.format ascii;
    data.class  polyBoundaryMesh;
}
</syntaxhighlight>

ここでは、外側のコンテナはバイナリ形式のdecomposedBlockDataですが、ペイロードの実際のコンテンツはascii形式のpolyBoundaryMeshです。従来のバージョンでは、分解されたデータの最初のブロックを実際に読み込んで、その内容を再解析しなければ、コンテンツのタイプやフォーマットを判断することはできませんでした。これらの情報をヘッダーに反映させることで、ファイルをスキャンする際の手間を減らし、IO効率を向上させることができます。

今回の変更は、メタ情報の追加と同様に、ParaView/VTKやその他のユーティリティのダウンストリームサポートを向上させるために行われました。

'''アーチ情報'''

すべての出力ファイルのヘッダに、アーチ情報が含まれるようになりました。アーチ情報は、ASCII形式の場合、乱雑になるため以前は抑制されていましたが、これがないと、ASCIIファイルに含まれるデータの種類を解釈するためのコンテキストがありません。

===標準化===

OpenFOAMでより多くの標準的なC++要素を使用するための継続的な取り組みとして、Foam::Swapの基本実装では、重複したコードを提供する代わりにstd::swapを使用するようになりました。基本型はstd::swapを使用するようになり、特別なセマンティクスに依存していないことが明確になりました。Foam::swap関数は、特殊な形式のスワップを呼び出すためにまだ使用されていますが、多くの場所では少なくなっています。

OpenFOAMのハッシュのオーバーロードは、すべての派生した文字列型と整数型を扱うように作り直されました。HashSet/HashTableのデフォルトのハッシャーは、hash-key型を使用するようになりました。これにより、疑わしいハッシュ呼び出しを回避したり、コンパイラの解決問題を回避したり、std::mapなどとの整合性を高めることができます。

これらの変更により、一貫性が向上し、誤ったマッピングが回避され、標準的な C++ のプラクティスとの整合性が高まりました。

詳細については、開発者向けアップグレードガイドをご覧ください。