OpenFOAM v2312リリースノート

提供：オープンCAEWiki OpenCAE Wiki
2023年12月24日 (日) 17:21時点におけるMmer547 (トーク | 投稿記録)による版
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
ナビゲーションに移動 検索に移動

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

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

Ubuntu Linux: Ubuntu 22.04(LTS)、20.04(LTS)、18.04(LTS)、23.04、22.10 用パッケージインストール

openSUSE Linux: Leap 15.5 用パッケージインストール

Redhat Linuxの亜種: epel 9用のパッケージインストール; Fedora 37

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

Windows Subsystem for Linux（Ubuntu、openSUSEなどベース）を使用する。

クロスコンパイルによるネイティブ実行ファイル

docker インストール

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

パッケージング/コンテナ参照

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

Upgrading

v2312ユーザーアップグレードガイド

挙動の変化

デフォルトのEnSightフォーマット

  • 関数オブジェクトとライターが使用するデフォルトの ensight 出力が、シミュレー ション controlDict で指定される \c writeFormat に依存するのではなく、より一貫して ˶c binary format を使用するようになりました。この変更により、foamToEnsight などのユーティリティや、他のファンクション・ オブジェクトやライターとの動作がより一貫したものになります。

Function object: Lambda2

Lambda2関数オブジェクトの出力が、支配方程式の変更、特に符号の反転によって修正されました。その結果、Lambda2のv2312以前のバージョンで観測された負のフィールド値は、v2312リリースでは正のフィールド値になりました（逆も同様）。

名前変更

Function object: WeberNumberReacting

ラグランジュ関数オブジェクトクラスWeberNumberReactingは、新しいラグランジュ雲関数オブジェクトKinematicWeberNumberとの整合性を確保するため、ReactingWeberNumberと改名された。

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

非推奨と削除

削除された項目

  • faMesh::operator()が削除され、代わりにmesh()またはthisDb()が使われるようになりました。
  • typeGlobal() グローバル関数が is_globalIOobject<Type> traits 構造体に置き換えられました。IOobject::typeHeaderOk との一貫性を保つために、補助的な typeFilePath() グローバル関数が IOobject::typeFilePath のメンバとしてのグローバル関数に取って代わられました。

定義の変更

  • ReadFieldsは、格納されたオブジェクトを処理するためのLIFOを実装するためにDynamicListを使用するようになりました。古いLIFOStackインターフェースは、より多くの割り当てとオーバーヘッドを必要とするため、非推奨とマークされています。
  • いくつかの IOobjectList::sorted() const-access メソッドを非推奨とし、新しい csorted() メソッドを採用した。これにより、HashTableとのメソッド名の一貫性が保たれ、戻り値の型が明確になります。
  • 内部辞書の区切り文字が'.'から'/'に変更され、（fileNameのような）内部処理が簡素化され、辞書名を明確なアドレッシングで使用できるようになった。この変更による副作用は、生の辞書名がコード内で直接解析された場合を除き、特に期待されません。

相続の変化

fvMeshで使われていたデータクラスは、polyMeshレベルのメンバーデータに置き換えられました。開発者にとっては、これは以下の（壊れやすく醜い）コードが確実に壊れることを意味する！ 

obr.lookupObject<fvMesh>("data")   // This was never a good idea

移設されたメソッド

ListOps::identityをFoam::identityに昇格させる。int32とint64の両方のバージョンを処理します。

コンテナの改良／変更

多くのリリースがそうであるように、基礎となるOpenFOAMコンテナは、様々な方法でアップグレードされ、調整されている。いくつかの焦点は、より多くの場所でC++アルゴリズムを利用することによって、内部のコピー、充填、データ移動を近代化することです。一般的なコード削減とは別に、アルゴリズムへの移行は、将来的に異なる実行モデル（例えば、std::execution::parallel_unsequenced_policy）を提供するのに役立ちます。

ハッシュテーブル構造体

HashTableとHashSetのデフォルトのコンストラクタは、本当にゼロ・サイズのコンストラクタに対応するようになり（つまり、割り当てを必要としない）、noexceptでもある。これは、ハッシュセットのリストなどを管理するときに特に便利で役立ちます。移動コンストラクタも同様にnoexceptになった。

  • 未使用の HashTable(Istream&, label) コンストラクタが削除されました。

HashTableのサイズ改良

  • サイズ変更時に、未入力のHashTableをより早く削除する：テーブルが既にクリアされている（つまり、エントリがない）場合、新しいサイズのテーブルを再割り当てする前に、古い内部テーブルを即座に削除することができます。
  • メソッド： std::unordered_mapに準じた命名と一般的な動作。resize()メソッドと似たような動作をしますが、容量ではなく要素数が渡されます。さらに、reserve()は、DynamicListやstd::vector、std::stringなどに似た振る舞いをするテーブルの容量を増やすだけです。
// old:
    labelHashSet set;
    set.resize(2*nElems);

// now:
    labelHashSet set;
    set.reserve(nElems);

リスト作成／割り当て

SLList（単一リンクリスト）からListまたはFixedListの構築または代入は削除されました。moveコンストラクトや代入はまだ残されていますが、次のバージョンまでにはその有用性が失われることが予想されます。

リストの読み書き

入力サイズが既知でないリストを読み込む場合、これらのブラケット・リストは、単一リンク・リストを使用する代わりに、チャンク単位で読み込まれるようになった。積分型やベクトル空間型（スカラー、ベクトルなど）では、各要素に対する中間アロケーションを避けることができる。

DynamicList::readList()メソッドが完全に実装され、List::readList()にリダイレクトされるようになりました。

IOストリームの変化

Ostreamの書き込みメソッド write(const string&) が write(const std::string&) に変更され、中間コピーなしでstd::stringを書き込めるようになった。これは、中間コピーなしで std::string を書き込むことを可能にする。しかし、これは Ostream から派生したクラスに調整が必要になることを意味する。

Ostreamクラスはまた、将来のスパンとstring_viewのサポートに役立つ新しいwriteQuoted(const char* str, std::streamsize len, bool)メソッドを受け取った。

メモリーストリームの更新と強化

カバレッジを拡張して、すべての標準ストリームのバリアントを含むようにし、単純にOpenFOAM IOstreamタイプ用にリラップします。これにより、継承パターンが単純化され、icharstream/ocharstreamを他のラッパーでistringstream/ostringstreamのドロップイン置き換えとして再利用できるようになります。

  • Classes
    • icharstream / ICharStream [old: none / IListStream]
    • ocharstream / OCharStream [old: none / OListStream]
    • ispanstream / ISpanStream [old: uiliststream / UIListStream]
    • ospanstream / OSpanStream [old: none / UOListStream]

ストリーム・バッファ・コンテンツのstd::string_view（c++17）またはspan view（古いc++）をサポート。これにより、フォーマットと再解析が簡単になります。

並列（MPI）処理の変更

削除された機能

実験的なフルNBX PstreamBuffersアルゴリズム（OpenFOAM-v2306で追加）は、ハイブリッドNBX/PEXアプローチと比較して利点が見られなかったため、削除されました。

同様に、実験的な "ダブルノンブロッキング "NBXバージョンも削除された。このアイデアは、非常に大きなデータ転送のための受信のブロッキングを避けることであったが、それは通常、PstreamBuffersが可能にするようなNBX/PEXのハイブリッドアプローチでよりよく達成される。

新機能

broadcastList

新しいPstream::broadcastList()メソッドは、2段階のプロセスとして連続したコンテンツをブロードキャストする：

  1. サイズをブロードキャストし、レシーバーリスト用にリサイズする。
  2. 連続した内容を放送する（空でない場合）

これにより、シリアライズ／デシリアライズのメモリ・オーバーヘッドを回避できるが、ブロードキャスト・コールが追加される。サイズの余分なブロードキャストのトレードオフは、連続した大きなメッシュデータのメモリピークを避けることよりも重要ではないでしょう。

mpiAllGather

mpiAllGather 関数が拡張され、char 型に限定されていたものが整数型と浮動小数点型も含むようになった。

allToAllConsensus

Mapを受け取るallToAllConsensus関数は、Mapも返すようになり、使い方が単純化され、送信/再送信パラメータの曖昧さが回避された。このバージョンでは、Mapにゼロ値のデータが存在する場合、そのデータも送信されるようになった。

PstreamBuffers

registered "センドをサポートし、減少した通信を適切に処理するだけでなく、投機的センドも処理できるようにした。これは、アルゴリズム内でプロセッサ-プロセッサ間の通信が発生する可能性があるが、センドがすべて必要になるかどうか事前にはわからない場合に発生する。この場合、センドは通常通り行われるが、登録されるのは「実際の」センドのみである。すべてのセンドが終了した後、実際にどの情報を（もしあれば）送信する必要があるかを判断することができる。

例えば、

PstreamBuffers pBufs(UPstream::commsTypes::nonBlocking);

pBufs.initRegisterSend();

for (const polyPatch& pp : patches)
{
    const auto* ppp = isA<processorPolyPatch>(pp);
    if (ppp)
    {
        const label nbrProci = ppp->neighbProcNo();

        // Gather some patch information...
        UOPstream toNbr(nbrProci, pBufs);
        toNbr << patchInfo;

        // The send is needed if patchInfo is non-empty
        pBufs.registerSend(nbrProci, !patchInfo.empty());
    }
}

pBufs.finishedSends();

新しい PstreamBuffers::finishedSendsNBX() メソッドが追加され、デフォルトの設定パラメータに関係なく、all-to-all ではなくバッファサイズの NBX (ノンブロッキング転送) を指定できるようになった。

MPI ネイティブの bitOrOp を拡張する

  • bitOrOpは複数の値も扱えるようになった。これは例えば、グローバルな状態を追跡するために使用できる：
// Encode as 0:empty, 1:uniform, 2:nonuniform, 3:mixed
PackedList<2> uniformity(fields.size());

forAll(fields, i)
{
    uniformity.set(i, fields[i].whichUniformity());
}

reduce
(
    uniformity.data(),
    uniformity.size_data(),
    bitOrOp<unsigned>()
);

MPIリクエスト処理の改善

  • UPstream::waitSomeRequests()のスライス/レンジのサポートにより、受信のポーリングが簡素化され、送信から分離できるようになった。
  • UPstream::removeRequests(pos、len) を使用して、未処理のリクエストをキャンセル／解放し、未処理のリクエストの内部リストからセグメントを削除する。
  • mapDistribute でのリクエスト処理の改善
    • 受信してから送信
    • 自己送信の受信バッファへの直接コピー
    • 送信/再送バッファのPtrListを使った不要な再割り当てを無効にする。

グローバルインデックス

whichProcID() に代わる失敗しないメソッドとして、新しい findProc() メソッドを含む様々な改良。

C++の最低規格は、2024年にC++11からC++17に引き上げられる予定である。

Pre-processing

snappyHexMesh：自動リークパスクロージャーから面を書き込む

snappyHexMeshにはメッシュ内の任意の位置とメッシュ外の位置の間のパスとして定義されたサーフェスのリークを自動的に閉じるオプションがあります。このリリースではリークを閉じるために使用された面はpostProcessingディレクトリのファイルに書き込まれます。

下図は、ギャップのある球体（灰色）、スナップされたメッシュライン（青）、リークを閉じる面（赤）からなるテストケースを示しています：


ファイル書き込みフォーマットはsnappyHexMeshDictの新しいエントリーで選択できます：

//// Format for writing lines. E.g. leak path. Default is vtk format.
//setFormat ensight;

//// Format to use for surfaces. E.g. leak-closure faces. Default is vtk format.
//surfaceFormat vtk;

Tutorials

  • $FOAM_TUTORIALS/mesh/snappyHexMesh/sphere_gapClosure

Source code

  • $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C

snappyHexMesh：新しい複数の内側ポイント

snappyHexMeshのセルゾーンはinsidePointを指定することで作成できます：

refinementSurfaces
{
    ..
    cellZoneInside insidePoint;    // outside/insidePoint
    insidePoint    (1 1 1);        // if (cellZoneInside == insidePoint)
}

1つのinsidePointではなく、複数のinsidePointが用意された：

cellZoneInside insidePoints;      // outside/insidePoint
insidePoints   ((1 1 1));         // if (cellZoneInside == insidePoint)

下の図では、ジオメトリは2つのボックス（ワイヤーフレーム）で構成され、上のボックスは2つの切り離されたメッシュ領域をカバーしている。赤で示されたセルゾーンは、3つの別々のメッシュ領域を使用して作成されています。checkMeshユーティリティは、切断されたリージョンを表示するために使うことができます。

Tutorials

  • $FOAM_TUTORIALS/mesh/snappyHexMesh/insidePoints

Source code

  • $FOAM_SRC/mesh/snappyHexMesh/refinementSurfaces/surfaceZonesInfo.H

snappyHexMesh：並列メッシュの負荷分散

snappyHexMeshは並列実行時に自動的にメッシュのバランスをとることができます。それは以下のどちらかになります

  • 変更が小さすぎる場合はバランスを取らない - maxLoadUnbalanceまたはmaxCellUnbalance設定を参照。
  • maxLocalCells設定を参照してください。

このリリースでは、各ステップでメッシュのアンバランスがプリントされます：

Layer mesh : cells:353749  faces:1108448  points:406303  unbalance:0.00110248

精製前のバランスは、セルの重みを与えることで実装されることに注意。各精製されるセルは8ずつカウントされる。しかし、これは単純な分解法、例えば階層的な分解法にのみ有効である。scotch と KaHip メソッドでは、カット数を含む重みを使ってアンバランスを最小化する。

Tutorials

  • any parallel snappyHexMesh case

Source code

  • $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBaffles.C
  • $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C

Related issues

  • Issue 3034

snappyHexMesh：レイヤーごとの追加

OpenFOAM v2206リリースでは、snappyHexMeshが拡張され、nOuterIterエントリーを使用して複数パスでレイヤーを追加できるようになりました。ここでは、$FOAM_TUTORIALS/incompressible/pisoFoam/LES/motorBike/motorBikeチュートリアルを出発点として、どのように改良されたレイヤーの追加を実行できるかをデモしたいと思います：

relativeSizes false; // true

// Per final patch (so not geometry!) the layer information
layers
{
    "(lowerWall|motorBike).*"
    {
        nSurfaceLayers 16;
    }
}

// Expansion factor for layer mesh
expansionRatio 1.2;

重要な設定は、外側の反復回数とメッシュ・モーション・ソルバーである：

// Overall max number of layer addition iterations
nLayerIter      25;

// Add layers in multiple passes - gives layers a chance to rotate
nOuterIter      4;


meshShrinker    displacementMotionSolver;
solver          displacementLaplacian;
displacementLaplacianCoeffs
{
    diffusivity quadratic inverseDistance (lowerWall upperWall "motorBike*")
}

メッシュの品質基準を緩めることで、（全体的なメッシュ品質は維持したまま）この複雑な形状でもレイヤーカバレッジを劇的に向上させることができる。

Tutorials

  • $FOAM_TUTORIALS/mesh/snappyHexMesh/addLayersToFaceZone

Source code

  • $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C

Nastranサーフェスリーダーの改良

NASTRANパーサーが更新され、PSHELL名の新しいANSA規約に対応しました。これにより、snappyHexMeshなど、より多くの場所でNASTRANファイルを直接使用することができるようになりました。

Source code

  • $FOAM_SRC/surfMesh/surfaceFormats/nas/NASsurfaceFormat.C

Issue

  • Issue 3009

checkMeshユーティリティの改良

checkMesh ユーティリティに writeChecks オプションが追加されました：

checkMesh -writeChecks <format>

これにより、メッシュ・チェックのフォーマットを含むファイルが生成される：

  • dictionary : OpenFOAM dictionary;
  • json : JSON format.

例えば、コマンドを使う：

checkMesh -allGeometry -allTopology -writeChecks JSON

motorBikeチュートリアルでは、caseディレクトリにcheckMesh.jsonファイルが生成される：

{
    "maxNonOrth" : 64.9999,
    "aveNonOrth" : 9.92427,
    "maxSkew" : 9.25719,
    "nWarnSkew" : 12,
    "minDeterminant" : 0,
    "aveDeterminant" : 1.55371,
    "thresholdDeterminant" : 0.001,
    "nErrorDeterminant" : 1274,
    "minFaceWeight" : 0.0216708,
    "aveFaceWeight" : 0.465687,
    "thresholdFaceWeight" : 0.05,
    "nErrorFaceWeight" : 1143,
    "minFaceVolumeRatio" : 0.0101126,
    "aveFaceVolumeRatio" : 0.846049
}

Source code

  • $FOAM_UTILITIES/mesh/manipulation/checkMesh/checkMesh.C

subsetMeshユーティリティの改良

subsetMesh ユーティリティが更新され、通常の -patches 選択を変更する -exclude-patches オプションを受け付けるようになりました。

この変更により、最も近い露出パッチの指定が簡単になりました。

Numerics

コミュニティへの貢献 随伴形状最適化の改善

形状最適化のための感度微分を計算するためのE-SIとFI定式化間の整合性が改善されました。naca0012/laminar/moment/primalAdjointチュートリアルから取得した、変更前後のコード動作の例を以下に示します：

一貫した点／面の感度マップ

v2306とv2312で計算されたドラッグ感度マップを比較すると、a)新しいポイント-フェイス補間は、生の、つまり平滑化されていない感度でも、より滑らかな結果を生成する。

さらなる改善点は以下の通り：

  • 不必要に新しいアドジョイントフィールドを割り当てることなく幾何学的制約を定義するための新しいアドジョイントソルバ（null）と目的関数（geometric）タイプ
  • 不等式制約のある最適化問題に取り組むための3つの新しい更新法（ISQP, nullSpace, MMA）
  • 設計変数に境界を導入。ボリューメトリックBスプラインの場合、最適化を通してメッシュの品質をより良く保つことができます。
  • 最適化ループの収束基準の導入。

Tutorials

  • $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012/laminar/multipleConstraints

Guide

  • The updated user guide for v2312 can be found here

Source code

  • Merge request MR!649
  • Overhaul of the adjoint library to ease extension to flow physics other than incompressible flows - see Commit 9a89fcc0 for details;
  • Corrections/improvements to shape optimisation - see Commit 9a89fcc0 for details.

Attribution

  • The software was developed by PCOpt/NTUA and FOSS GP
  • Integration in collaboration with OpenCFD

コミュニティへの貢献 トポロジーに基づく新しいアジョイント最適化

OpenFOAM v2312では、空隙率ベースまたはレベルセットアプローチによる新しいトポロジー最適化機能が追加されました。どちらも、設計されたジオメトリをSTLとしてエクスポートする機能を備えており、製造やボディフィットグリッドによる再評価に利用できます。

空隙率ベースのアプローチは、計算領域の非生産的な部分を固めることでブロックする設計変数の場（人工空隙率α）に依存する。得られた解の平滑性を高めるために、正則化方程式を解いて中間場α̃を計算し、次にシャープニング/プロジェクションステップを経てほぼ二値の場βを計算します。後者は、固化した領域（すなわちβ≈1の領域）で流れ解をゼロにするソース項を流れ方程式に導入するために使用されます。上記のプロセスの手順を以下に示す。

次の表は、同じケースの3つの異なるバリエーション、すなわち、Jpt＜Jpttarget制約（右）の下で、総圧力損失（Jpt）の最小化（左）、下部出口と右出口間の体積流量の均等配分制約（Jm）を伴うJptの最小化（中央）、および流れの均一性（Jun）の最大化（右）に対するトポロジー最適化の結果を示している。

ケースは、adjointOptimisationFoam/topologyOptimisation/monoFluidAero/turbulent/1_Inlet_2_Outlet/porosityBased/BPにあります。

次の表は、同様の目的関数と制約関数を持つ3次元多様体のトポロジー最適化の結果を示しています。最初の行は、最適化サイクル中の計算領域の流体部分と固体部分の境界の進行を示し、最後の行は、最適化された3つの形状のSTLファイルを示しています。後者の生成プロセスは自動化されており、各最適化サイクルの終了時に実行されます。これらのSTLファイルは、適切な境界条件によるボディフィットシミュレーションや、その後の形状最適化、さらには製造に使用することができます。

ケースはtopologyOptimisation/monoFluidAero/laminar/3DBoxにあります。

下位互換性

optimisationDict.optimisationの項目が少し変わりました。この変更は、例えば、$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/motorBikeのoptimisationDictを以前のものと比較することで確認できます。

Tutorials

  • $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation

Guide

  • The updated user guide for v2312 can be found here

Source code

  • Merge request MR!649
  • Overhaul of the adjoint library to ease extension to flow physics other than incompressible flows - see Commit 9a89fcc0 for details;
  • Corrections/improvements to shape optimisation - see Commit 9a89fcc0 for details.

Attribution

  • The software was developed by PCOpt/NTUA and FOSS GP
  • Integration in collaboration with OpenCFD

Solvers and physical models

fvOptionsの改良：ポイントの移動

有限体積オプション（fvOptions）フレームワークが改良されました：

  • 入力辞書の更新により、セル選択を実行時に更新できるようになりました。
  • 空間内を移動する点をモデル化する新しい方法。

最小限の使用例は以下の通り：

fvOption1
{
    // Optional entries
    updateSelection         true;

    ...
}

fvOption2
{
    // Mandatory entries
    selectionMode   movingPoints;

    movingPoints
    {
        point1        table
        (
            // time    position
            (  0 (0 0 0.75))
            (  1 (0 0 0.65))
            (  2 (0 0 0.55))
            (  3 (0 0 0.45))
            (  4 (0 0 0.35))
            (  5 (0 0 0.25))
        );

        point2        (-0.25 -0.25 0.5);
    }

    ...
}

Source code

  • $FOAM_SRC/fvOptions/cellSetOption/cellSetOption.H

Merge request

  • Merge request 630

新しい fvOption: マップされたフィールド制約

MapFieldConstraintは、外部メッシュからのソース・フィールドを使用して、<Type>型の指定フィールドに値の制約を課します。ここで、<Type>には{scalar, vector, sphericalTensor, symmTensor, tensor}を指定できます。オプションとして、ソースフィールドは時間経過とともに平行移動または回転させることができます。

考えられる用途は、例えば、移動する電気源の影響をモデル化することである。最小限の使用例を以下に示す：

MapFieldConstraint1
{
    // Mandatory entries
    type                MapFieldConstraint;
    field               <word>;
    srcMesh             <fileName>;
    mapMethod           <word>;

    // Optional entries
    consistent          <bool>;
    patchMapMethod      <word>;
    transform
    {
        // Optional entries
        position    <Function1<vector>>;
        origin      <vector>;

        direction   <Function1<vector>>;
        normal      <vector>;
    }

    // Conditional entries

        // when consistent=false
        patchMap        <HashTable<word>>;  // (<patchSrc> <patchTgt>);
        cuttingPatches  <wordList>;  // (<patchTgt1> ... <patchTgtN>);

    // Inherited entries

        ...
}

Source code

  • $FOAM_SRC/fvOptions/constraints/general/mapFieldConstraint/MapFieldConstraint.H

Merge request

  • Merge request 630

コミュニティへの貢献：新しい乱流技術委員会サブモジュール

OpenFOAMガバナンス内のTurbulence Technical Committeeのネストされたサブモジュールを含む新しいコミュニティサブモジュールが開始されました。このサブモジュールは、公開されている Turbulence Technical Committee のリポジトリでホストされています。

コミュニティ・サブモジュールは、乱流モデリングに関連する学術的・産業的な貢献のホストとして機能し、知識交換の場を作り、この分野とOpenFOAMの両方を発展させるコラボレーションを促進します。

BitbucketやGitHubのようなGitベースのソースコード・リポジトリ・ホスティング・サービスでホストし、このサブモジュールを介してOpenFOAMソフトウェアにリンクすることができます。

このリリースでは、サブモジュールにlibWallModelledLESライブラリーが組み込まれ、壁面モデルによるラージ・エディ・シミュレーション（WMLES）の領域でOpenFOAMの機能が拡張されました。この乱流モデリング手法は、乱流境界層の内部領域の解像度を回避することで、費用対効果の高いLESを可能にします。

Source code

  • $WM_PROJECT_DIR/modules/turbulence-community

Attribution

  • OpenCFD would like to acknowledge and thank Turbulence Technical Committee members for their contributions and help.

改善されたラグランジュ・ブラウン運動

このバージョンでは、ブラウン運動の3次分布のサポートが復活しました。しかし、特に指定がない限り、（互換性のために）デフォルトの球形分布が引き続き使用されます。

このバージョンでは、ブラウン運動の3次分布のサポートが復活しました。

しかし、特に指定がない限り、適度に小さな時間ステップでは不正確であるにもかかわらず、（互換性のために）デフォルトの球面処理が引き続き使用されます。

三次分布は、球面処理が明示的に無効化されている場合に使用される。例えば

subModels
{
    particleForces
    {
        sphereDrag;
        BrownianMotion
        {
            lambda     2e-10;
            turbulence false;
            spherical  false;
        }
    }
    ...
}

立方体分布と球形分布の違いは次の図に見られる。

変更の報告、検証、テストはGuanyang Xueの好意によるものである。

Source code

  • $FOAM_SRC/lagrangian/turbulence/submodels/Thermodynamic/ParticleForces/BrownianMotion/BrownianMotionForce.H

Issue

  • Issue 2922

Merge request 634

Post-processing

新しいAbaqusサンプルセット

新しい abaqusMesh セットは、Abaqus メッシュポイント形式を使用してファイルからサンプル位置を導出します。使用例：

sets
{
    cone25 // user-specified set name
    {
        type        abaqusMesh;
        file        "abaqusMesh.inp";

        // Optional entries

        // Scale, e.g. mm to m
        scale       0.001;

        // Search distance when the sample point is not located in a cell
        maxDist     0.25;

        ...
    }
}

Tutorials

  • TBA

Source code

  • $FOAM_SRC/sampling/sampledSet/abaqus

新しいAbaqusセットライター

新しいAbaqusセットライターはOpenFOAMセットデータをAbaqusフォーマットに変換します。使用例

T
{
    type sets;
    setFormat abaqus;
    fields (T);
    sets
    {
        ...
    }
}

オプションの書式オプションは、formatOptions辞書内のabaqusサブ辞書で提供されます：

formatOptions
{
    abaqus
    {
        format      ascii;

        // Optional entries

        // Custom header: $ entries are substituions
        header
        (
            "** OpenFOAM abaqus output"
            "** Project $FOAM_CASE"
            "** File $FILE_NAME"
            "** $FIELD_NAME Time t=$TIME"
        );

        // Write geometry in addition to field data
        writeGeometry yes;

        // Null value when sample value is not found
        // Default is scalar::min
        nullValue   0;

        // Insert additional time sub-directory in the output path
        // - yes : postProcessing/<fo-name>/<time>/<file>
        // - no : postProcessing/<fo-name>/<file>
        useTimeDir  no;

        // Available when 'useTimeDir' is 'no' to disambiguate file names

        // Time base for output file names:
        // - 'time' : <base>.inp_<field>.<time>
        // - 'iteration' : <base>.inp_<field>.<iteration>
        timeBase    iteration;

        // Optional start counters when using timeBase iteration
        writeIndex
        (
            T 1
        );

        ...
    }
}

Tutorials

  • TBA

Source code

  • $FOAM_SRC/meshTools/coordSet/writers/abaqus/abaqusCoordSetWriter.C

パッチ・シード・セットの改善

patchSeed sampled setがパッチ全体で一様にサンプルシードを計算するようになりました。以前の実装では、顔のインデックスをパッチ全体で一様にサンプリングしていましたが、その副作用として、より小さな顔に偏りがありました。

streamline5
{
    type                streamLine;
    libs                (fieldFunctionObjects);
    U                   U;
    fields              (U p);
    setFormat           vtk;
    direction           forward;
    lifeTime            20000;
    cloud               particleTracks;
    seedSampleSet
    {
        type            patchSeed;
        axis            xyz;
        patches         ("inlet1");
        maxPoints       40;
    }
    interpolationScheme cellPoint;
    trackLength         0.001;
}

Tutorial

  • $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike/system/wallBoundedStreamLines

Source code

  • $FOAM_SRC/sampling/sampledSet/patchSeed

Merge request

  • Merge request 647

新しいケース情報機能オブジェクト

新しい caseInfo 関数オブジェクトは、実行時または後処理の一部として、ソルバーとケースの情報を生成します。収集されるデータには以下が含まれます：

  • メタデータ：ケース名、パス、タイムディレクトリ数など。
  • 辞書エントリ : 任意の入力辞書からすべて/選択したものを抽出
    • fvSolutionからUリニアソルバーを取得するには、'solvers/U/solver'などのスコープを使用する。
    • はワイルドカードをサポートしている。例えば、fvSolution U ソルバー・キーワードが"(U|k|epsilon) "であった場合。
    • include'または'exclude'リストを使用して、含める/除外するエントリ名の選択を制限する。
  • メッシュ統計：点、面、セルの数、境界、ゾーン名など。
  • 関数オブジェクトの結果：関数オブジェクトの結果のキャッシュ値など

使用例：

caseInfo1
{
    type        caseInfo;
    libs        (utilityFunctionObjects);

    writeFormat json; // josn | dictionary

    // List of dictionaries - retrieve using 'path' or registered 'name'
    dictionaries
    {
        fvSolution
        {
            name        "fvSolution";

            // include all entries by default
        }
        controlDict
        {
            path        "system/controlDict";
            include
            (
                "application"
                "deltaT"
                "startTime"
                "endTime"
            );
        }
    }

    // Extract function object results
    functionObjects (pressureDifference sample1);
}

出力例

{
    "meta" : {
        "case" : "heatExchanger",
        "path" : "chtMultiRegionSimpleFoam/heatExchanger",
        "regions" : ["air", "porous"],
        "nTimes" : 7,
        "nProc" : 1
    },
    "regions" : {
        "air" : {
            "mesh" : {
                "nGeometricD" : 3,
                "nSolutionD" : 3,
                "nPoints" : 252991,
                "nFaces" : 739260,
                "nCells" : 243000,
                "nPatches" : 4,
                "pointZones" : [],
                "faceZones" : ["rotorBlades", "baffleFaces"],
                "cellZones" : ["cylinder", "innerCylinder", "rotor"],
                "boundsMin" : [0, 0, 0],
                "boundsMax" : [5.000000e-01, 5.000000e-01, 5.000000e-01],
                "clouds" : []
            },
            "boundary" : {
                "types" : {
                    "walls" : "wall",
                    "inlet" : "patch",
                    "outlet" : "patch",
                    "blades" : "wall"
                },
                "fields" : {
                    "alphat" : {
                        "walls" : "compressible::alphatWallFunction",
                        "inlet" : "calculated",
                        "outlet" : "calculated",
                        "blades" : "compressible::alphatWallFunction"
                    },
                    "nut" : {
                        "walls" : "nutkWallFunction",
                        "inlet" : "calculated",
                        "outlet" : "calculated",
                        "blades" : "nutkWallFunction"
                    },
                    "p" : {
                        "walls" : "calculated",
                        "inlet" : "calculated",
                        "outlet" : "calculated",
                        "blades" : "calculated"
...

Source code

  • $FOAM_SRC/functionObjects/utilities/caseInfo

DMDによる新しい低次モデリング磁場再構成

動的モード分解（DMD）機能は、OpenFOAM v2006で導入され、その後OpenFOAM v2106で拡張されました。このリリースにより、OpenFOAMは、DMDの主な利点の1つである、任意の中間時点や将来の時点におけるCFD計算を必要とせずに、与えられたモードとそれに関連するダイナミクスに基づいて場を生成する機能を習得しました。

この機能により、ユーザーはシミュレーション全体をいくつかのモードとモードダイナミクスに凝縮し、CFD解析を追加することなく、任意の時間における場の生成や将来の状態の予測を行うことができます。

もう一つの潜在的な利点は、ユーザーがシミュレーションを短縮し、大規模なシミュレーションを行うことなく流れ場の将来の状態を予測できることである。これは、より短時間のシミュレーションで得られたモードとモードダイナミクスを使用することで実現できます。

結果の質は、基礎となる縮小モデルの能力と入力データの質に依存することに留意すべきである。再構成結果を改善するためには、流れからモードが正しく抽出されていることを確認する必要がある。

system/ROMfieldsDictを使った最小の例は以下の通り：

// Mandatory entries
ROMmodel        <word>;
field           <word>;
object          <word>;
deltaT          <scalar>;
time            <scalar>;
modes           <labelList>;
amplitudes      <complexList>;
eigenvalues     <complexList>;

// Optional entries
startTime       <scalar>;
dimensions      <dimensionSet>;

// Inherited entries
...

下の図は、2次元円柱チュートリアルから得られた速度場と、シミュレーションを実行せずにDMDモードとダイナミクスを使用して再構成したものです：

Source code

  • $FOAM_UTILITIES/postProcessing/miscellaneous/createROMfields/createROMfields.C
  • $FOAM_UTILITIES/postProcessing/miscellaneous/createROMfields/ROMmodels/DMD/DMD.H

Tutorial

  • $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D

References

  • Kiewat, M. (2019). Streaming modal decomposition approaches for vehicle aerodynamics. PhD thesis. Munich: Technical University of Munich. URL:mediatum.ub.tum.de/doc/1482652/1482652.pdf

Attribution

  • OpenCFD would like to acknowledge and thank Marco Kiewat for his contributions, elaborate suggestions and help, and critical recommendations.

Merge request

  • Merge request 639

ノイズ・ユーティリティの向上

ノイズユーティリティは、時間情報からのデフォルトの自動計算だけでなく、ユーザー定義のサンプリング周波数（キーワード：sampleFreq）もサポートするようになりました。読みやすさを向上させるため、周波数の上限と下限をminFreqとmaxFreqで指定できるようになりました（以前のキーワードも引き続きサポートされています）。

// Lower frequency limit, default 25 Hz, former name 'fl'
minFreq 25;

// Upper frequency limit, default 10 kHz, former name 'fu'
maxFreq 10000;

// OPTIONAL - Sample frequency
sampleFreq 100;

サンプリングされた時間から周波数を計算する際に時間が不均一であると評価された場合、deltaT が非常に小さい場合、不均一性は多くの場合偽のエラーであるため、ユーティリティはエラーではなく警告を発するようになりました。

Source code

  • $FOAM_SRC/surfMesh/writers/ensight/ensightSurfaceWriter.H
  • $FOAM_SRC/randomProcesses/noise/noiseModels/noiseModel/noiseModel.H

Tutorial

  • $FOAM_TUTORIALS//incompressible/pimpleFoam/LES/vortexShed

Issue

  • Issue 2999

エンサイトの出力向上

EnSightライターの時間値は、デフォルトの固定フォーマットと精度を使用する代わりに、ユーザーが指定できるようになりました。例えば

formatOptions
{
    ensight
    {
        timeFormat      general; // Format for time directory names (general | fixed | scientific); default scientific
        timePrecision   12;      // Default = 5
    }
}

これらの新しいフォーマットオプションは、例えばノイズユーティリティの圧力サンプリングと組み合わせて、小さなタイムステップを使用する場合に特に便利です。

Source code

  • $FOAM_SRC/surfMesh/writers/ensight/ensightSurfaceWriter.H
  • $FOAM_SRC/functionObjects/utilities/ensightWrite/ensightWrite.H

Issue

  • Merge request 634

新しいラグランジュ関数オブジェクト ウェーバー数

表面張力と比較した粒子の慣性の相対的な重要性を監視するために、ラグランジュ関数オブジェクトWeberNumberが運動学小包に導入されています。

最小限の使用例は以下の通り：

cloudFunctions
{
    KinematicWeberNumber1
    {
        // Mandatory entries
        type             WeberNumber;
        sigma            <scalar>;
    }
 
    ...

Source code

  • $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/KinematicWeberNumber/KinematicWeberNumber.H

Tutorial

  • $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk

Merge request

  • Merge request 648

空のサーフェス（surfaceFieldValue）の取り扱いが改善されました。

ワークフローによっては、サンプリングされたサーフェスが、シミュレーション中に現れたり消えたりするフェイスゾーンなどの量に依存する場合があります。そのため、空のサーフェスでサーフェスフィールドの値を評価することは、通常、セットアップに重大なエラーがあることを示しますが、このようなことが予想される場合もあります。追加キーワードempty-surfaceにより、空のサーフェスに遭遇したときの動作を指定することができます。

最小限の例：

surfaceFieldValueFaceZone1
{
    type            surfaceFieldValue;
    libs            (fieldFunctionObjects);
    ...
    regionType      faceZone;

    empty-surface   warn;  // default | warn | ignore | strict
}

Source code

  • $FOAM_SRC/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValue.H

Issue

  • Issue 2966

Parallel

結合パッチフィールド値の一貫性

結合された制約境界条件、例: プロセッサーとサイクリックは、その内部フィールド値と一致している必要があります。 たとえば、プロセッサ パッチでは、値フィールドに隣接するプロセッサ セルの値が含まれます。つまり、反対側のセルの値がキャッシュされます。 他の結合されたパッチ フィールドは、ローカルおよび隣接セル値の補間値を値として持つ場合があります。 経験則として、セル値を変更するコードはすべて、たとえば、 勾配計算では、値の更新を実行するために境界条件を修正する呼び出しを行う必要があります (プロセッサ境界フィールドでのハロー スワップに相当します)。 ただし、「ローカル」操作の場合、たとえば 乗算では、境界条件に値のみがあり、セル値に依存しない場合、これがスキップされることがあります。 ほとんどの「通常の」境界条件はこのカテゴリに分類されます。

結合境界条件の場合、プロセッサのパッチ フィールドにも適用されますが、たとえば、パッチ フィールドには適用されません。 環状、環状AMI のバリアント。 これにより、中間計算の値が一貫性制約に従わなくなります。

このリリースでは、制約パッチの値がいつでも最新であるように、ローカル操作の後の評価を強制しています。この選択はまだ調査中であり、将来更新される可能性があることに注意してください。

patchField の整合性チェックの結合

ビジュアルコードのチェックで、meshWaveメソッドとmeshWaveAddressingメソッドによって返される壁面距離フィールドが平行一貫していないことが確認されました。このようなエラーを発見しやすくするために、オプションで整合性チェックが追加されました：

DebugSwitches
{
    volScalarField::Boundary            1;
    volVectorField::Boundary            1;
    volSphericalTensorField::Boundary   1;
    volSymmTensorField::Boundary        1;
    volTensorField::Boundary            1;

    areaScalarField::Boundary           1;
    areaVectorField::Boundary           1;
    areaSphericalTensorField::Boundary  1;
    areaSymmTensorField::Boundary       1;
    areaTensorField::Boundary           1;
}

1 を指定するとチェックが有効になり、チェックに失敗すると FatalError が発生する。特に FOAM_ABORT と組み合わせることで、スタックトレースを生成することができます：

FOAM_ABORT=true mpirun -np 2 simpleFoam -parallel

デバッグ・スイッチはビットマップとして解釈される：

bit value(2^bit) effect
0 1 ローカル操作ごとにチェックを加える
1 2 プリントの入力と終了をチェックする
2 4 fatalErrorの代わりにwarning

比較の許容誤差はデフォルトで0に設定されている。プロセッサのハロースワップでは、まったく同じ操作がまったく同じ順序で実行されるため、許容誤差の問題はありません。しかし、サイクリックやサイクリックAMIなどの「補間」結合境界条件では、ローカル演算（定数による乗算など）が補間後に実行されるため、若干異なる切り捨て誤差が発生します。この場合、許容誤差をオーバーライドすることができます：

OptimisationSwitches
{
    volScalarField::Boundary::tolerance           1e-10;
    // .. and similar for all the other field types ..
}

下位互換性

新しい整合性操作は、周期的または周期的AMI境界条件、または結合境界条件を使用する非自明な乱流モデルを使用するケースの動作をわずかに変更します。

オプションとして、etc/controlDictのlocalConsistency設定をオーバーライドすることで、この振る舞いを以前の（一貫性のない！）形に戻すことができる：

OptimisationSwitches
{
    //- Enable enforced consistency of constraint bcs after 'local' operations.
    //  Default is on. Set to 0/false to revert to <v2306 behaviour
    localConsistency 0;
}

簡単なテストはcyclicAMIパッチを使ったチュートリアル、例えばpipeCyclicチュートリアルです。上記のDebugSwitchでチェックを有効にすると問題なく動作しますが、localConsistencyフラグを無効にすると不整合が検出されます：

[0] --> FOAM FATAL ERROR: (openfoam-2302 patch=230110)
[0] Field dev(symm(grad(U))) is not evaluated? On patch side1 type cyclicAMI : average of field = ...

Related issues

  • Issue 2783

Source code

  • $FOAM_SRC/OpenFOAM/fields/GeometricFields/GeometricField/GeometricBoundaryField.C

Merge request

  • Merge request 628

ノンブロッキング環状A(C)MI

cyclicAMI境界条件は、複数の隣接する面からの面積加重補間を実装します。これらの面はローカルであることも、リモートプロセッサに存在することもあり、並列通信を必要とします。

以前のリリースでは、それぞれのcyclicAMIの評価または線形ソルバーの行列寄与（ローカルでない隣接面の場合）が、独自の通信セットをトリガーし、次のcyclicAMIまたはプロセッサパッチに進む前に、これらの終了を待っていました。このリリースでは、すべての送受信を開始するプロセッサパッチと同様の経路をたどり、ローカル値を更新するためにリモートデータを使用する「消費」フェーズがあります。典型的な境界条件の評価や線形ソルバーの更新は、次のような形になります：

  • すべての initEvaluate/initInterfaceMatrixUpdate を行う（結合境界のみ）。プロセッサ、cyclicA(C)MI の場合、これはノンブロッキングの送受信を開始する。
  • すべての通信が終了するのを待つ（または、ポーリング（v2306 nPollProcInterfaces）を使用して以下と組み合わせる）。
  • すべてのevaluate/updateInterfaceMatrixを行う。これは、受信したデータを使用して、行列解への寄与を計算します。

cyclicA(C)MIからの通信をプロセッサの境界条件とまったく同じ方法で処理することで、ボトルネックが発生する可能性が低くなり、スケーリングが向上することが期待される。さらなる最適化として、ローカル送受信バッファは一度割り当てられ、再利用される。

Source code

  • $FOAM_SRC/finiteVolume/fields/fvPatchFields/constraint/cyclicAMI/cyclicAMIFvPatchField.H

Merge request

  • Merge request 641

Tutorial

  • any case with cyclicAMI or cyclicACMI

GAMG : プロセッサ・アグロメレーションにおけるcyclicAMIのサポート

GAMGソルバーは、ローカルアグロメレーションに加えて、プロセッサ間で行列を結合することができます（プロセッサアグロメレーション）。これは、コア数が多い場合に有益です：

  • 最も粗いレベルを解くコアの数を減らす - 世界的な削減のほとんどは、最も粗いレベルで起こる。
  • は、スムージングやプリコンディショニングなど、すべての演算の暗黙性を高める。

このリリースでは、cyclicAMIやcyclicACMIなど、すべての連成境界条件のプロセッサアグロメレーションを可能にするようにフレームワークが拡張されました。

テストとして、以下を比較した。

  • 40x10x1のブロック1つ、および
  • 2つの20x10x1ブロックがcyclicAMIを使って結合されている。

どちらのケースも4つに分解され、GAMGソルバーとmasterCoarsestプロセッサーのアグロメーターを併用することで、すべての行列がmaster(s)に結合された。

solvers
{
    p
    {
        solver                  GAMG;
        processorAgglomerator   masterCoarsest;
        ..
    }
  • シングルブロック（つまり、cyclicAMIはなく、プロセッサーフェイスのみ）：
                              nCells       nInterfaces
   Level  nProcs         avg     max       avg     max
   -----  ------         ---     ---       ---     ---
       0       4         100     100       1.5       2
       1       4          50      50       1.5       2
       2       1         100     100         0       0
       3       1          48      48         0       0

すべてのプロセッサ面が内部となるため、境界の数（nInterfaces）は0となる。

  • 2ブロックの場合（つまり、cyclicAMIとプロセッサフェイス）：
                              nCells         nInterfaces
   Level  nProcs         avg     max         avg     max
   -----  ------         ---     ---         ---     ---
       0       4         100     100           3       3
       1       4          50      50           3       3
       2       1         100     100           2       2
       3       1          48      48           2       2

ここでは、2つのcyclicAMIのみが保存されるため、境界の数は3つから2つに減る。

Notes

  • cyclicA(C)MI :
    • すべての面がローカルになると、動作は非分散にリセットされる。つまり、操作は追加のコピーなしで、提供されたフィールドに直接適用される。
    • 回転変換はまだサポートされていません。これは基本的な制限ではありませんが、変換を考慮するためにステンシルを追加で書き換える必要があります。
  • processorCyclic : (オーナーセルと隣接セルが異なるプロセッサ上にあるサイクリック) はまだサポートされていない。これは通常のプロセッサ境界として扱われるため、変換は失われる。processorCyclicはdecomposeParDictでパッチ制約を使うことで回避できることに注意。
constraints
{
    patches
    {
        //- Keep owner and neighbour on same processor for faces in patches
        //  (only makes sense for cyclic patches and cyclicAMI)
        type    preservePatches;
        patches (cyclic);
    }
}
  • masterCoarsestのみがテストされているが、コードは他のどのプロセッサー凝集法もサポートするはずである。
  • これまでの限られたテストでは、cyclicAMIのプロセッサー集積の利点は示され ていない。これは、ボトルネック、例えば、大域的削減の数や暗黙性が問題となる場合にのみ有効である。

Source code

  • $FOAM_SRC/OpenFOAM/meshes/lduMesh/lduPrimitiveMesh.C

Merge request

  • Merge request 645

redistributeParとファイルシステムの改良

このリリースでは、照合ファイル・フォーマットの一般的なサポートが改善され、redistributeParユーティリティの調整も行われました。これらの変更により、照合ファイル形式は以前よりも幅広いワークフローで使用できるようになりました。

これらの変更に加え、分散ファイルシステムによるダイナミックコードの取り扱いが改善された。このようなタイプのシステムでは、動的にコンパイルされたライブラリも対応するサブランクに配布されるようになった。

照合されたインクルードファイルの取り扱いが改善された

以前のバージョンでは、"include "ファイルを照合と組み合わせて使用すると、ファイルの内容がランタイムで変更可能なものとして扱われる場合、非常に壊れやすいことがあった。今回、ウォッチド・ファイルの取り扱いが更新され、プロセッサー・ランク間の適切な対応が保証されるようになった。

Usability

New verification and validation public repository

OpenFOAMソフトウェアの検証と妥当性確認に関するコミュニティへの貢献をホストする新しいパブリックリポジトリが開設されました： OpenFOAM Verification and Validation Repository。

このリポジトリの主な目的は、OpenFOAMコミュニティがソフトウェアの検証と検証の側面を共有、協力、強化するための一元化されたプラットフォームを提供することです。コミュニティの集合的な知識と専門知識を結集することにより、OpenFOAMシミュレーションの全体的な品質を向上させ、数値モデリングのベストプラクティスを推進することを目指しています。

このリリースでは、Taylor-Green渦問題と円形Couette流れが組み込まれ、ケースのセットアップとドキュメンテーションのために提供されたテンプレートの実用的な応用が示されています。

コンピレーション

General

OpenFOAMで使用されるC++標準は、GNUコンパイラでもc++14になりました。この変更により、推奨コンパイラの最小バージョンはgcc-7.5.0になりました。

将来のコード移行を支援するため、「より厳しい」非推奨警告を有効にできるようになりました。これは WM_COMPILE_CONTROL 環境変数の +strict エントリでグローバルに、または wmake -strict で一度だけ有効にできます。これは主に開発者向けのオプションと考えることができます（多くの警告を生成する可能性があります）が、モジュールを書くときに便利で面白いかもしれません。

MacOS

このバージョンには、MacOS上でのコンパイルと実行に関するいくつかの改良が含まれています。

  • AppleとARM64のFPE処理の改善（Guanyang Xue氏提供）
  • rpathハンドリング
  • xcrun サポート

MacOS のコンパイルでは、rpath のサポートがデフォルトで有効になり、Apple SIP (System Integrity Protection) の影響に対する回避策がいくらか減って、これらのシステムでの OpenFOAM の実行が簡単になりました。WM_COMPILE_CONTROL環境変数に~rpathを追加することで、rpath処理を無効にできます。

MacOSコンパイルでは、xcodeツール（xcrunなど）の使用もサポートするようになりました。これらはWM_COMPILE_CONTROL環境変数に+xcrunを追加することで有効になります。見つかると、これらのコンパイル・ルールが使用されます：

cc   := xcrun cc
CC   := xcrun c++ -std=c++14

Clang

clangベースのコンパイルで、ldリンカを使用するように明示的に指定できるようになりました（注意：clangがldを使用するかlldを使用するかはインストールに依存します）。リンカの選択は環境変数 WM_COMPILE_CONTROL の対応するエントリで定義されます：

- `+gold`    : use gold linker
- `+link-ld` : use   ld linker
- `+lld`     : use  lld linker
- `+mold`    : use mold linker

OpenMP

openmp と no-openmp の扱いが強化された。"+openmp" (wmake -openmp) よりも "~openmp" (wmake -no-openmp) の方が優先されます。

これにより、一般的に+openmpを指定する場合はrobusterとなり、特定のビルド・コンポーネント（スタティック・ライブラリやMPIブリッジ・コードなど）を指定する場合は~openmpとなる。

Profiling

このバージョンには、Extraeプロファイリング用のフックが含まれています。デフォルトでは、フックは常にOpenFOAMと一緒にビルドされますが、LD_PRELOADによってExtraeが実際にロードされるまで休止しています。これにより、OpenFOAMをその目的専用に再コンパイルすることなく、Extraeのトレースが可能になります。

Josep Pocurull（Barcelona Supercomputing Center）により提供され、exaFOAMプロジェクトの一部として使用されたコード。

Source code

  • $FOAM_SRC/OpenFOAM/global/profiling/profilingTrigger.C

Merge request

  • Merge request 652
「https://wiki.opencae.or.jp/index.php?title=OpenFOAM_v2312リリースノート&oldid=851」から取得