OpenFOAM v2312リリースノート
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 Developer Upgrade Guide
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 JSONmotorBikeチュートリアルでは、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
cyclicAMIorcyclicACMI
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++14Clang
clangベースのコンパイルで、ldリンカを使用するように明示的に指定できるようになりました（注意：clangがldを使用するかlldを使用するかはインストールに依存します）。リンカの選択は環境変数 WM_COMPILE_CONTROL の対応するエントリで定義されます：
- `+gold` : use gold linker
- `+link-ld` : use ld linker
- `+lld` : use lld linker
- `+mold` : use mold linkerOpenMP
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