「OpenFOAM v1812 リリースノート」の版間の差分
(ページの作成:「この記事はオープンCAE Advent Calendar 2018の23日目の記事です。 いつものごとく機械翻訳＋手直しでやってます。 参考程度に...」) |
(相違点なし)
|
2020年6月30日 (火) 23:51時点における最新版
この記事はオープンCAE Advent Calendar 2018の23日目の記事です。
いつものごとく機械翻訳＋手直しでやってます。
参考程度にお読みください。
メッシュリークのやつ、既視感がある……
// --------------------------------------------------------------------
OpenCFDは、2018年12月にリリースされたOpenFOAM®v1812を発表しました。 このリリースでは、コードの多くの分野でOpenFOAM-v1806の機能を拡張しています。 この新しい機能は、OpenCFDの顧客が後援する開発、社内資金による開発、そしてOpenFOAMコミュニティからの機能と変更の統合を表しています。 OpenFOAMはOpenPLDによってGPLライセンスの下で配布されています。
任意のLinuxシステムでコンパイルされるソースコード Linuxシステム用のコンパイル済みバイナリインストール Mac OS Xシステム用のコンパイル済みバイナリインストール MS Windowsインストーラ MS Windows 10用のWindows上のUbuntu上でのbash ダウンロード手順を参照してコードを入手してください。 開発リポジトリは公開されています。 これらのリポジトリは、バグ修正と新機能で定期的に更新されています。
Upgrading
ユーザーのヘルプは、ユーザーアップグレードガイドに記載されています。 開発者のためのヘルプは開発者アップグレードガイドにあります。
Pre-processing 新しいsnappyHexMesh方向ストレッチ
以前のリリースでは、方向性の調整機能が追加されました。 これは、細胞数を制限したり、洗練されたボリュームの変化を少なくするのに役立ちます（2：1対8：1）。 この後者の変更は、離散化誤差を少なくすることができます。 このリリースでは、さらにメッシュを所定の方向に引き伸ばして体積変化をさらに抑えることができます。 典型的な使い方
Source code
$FOAM_UTILITIES/mesh/generation/snappyHexMesh/snappyHexMeshDict
Examples
$FOAM_TUTORIALS/mesh/snappyHexMesh/aerofoilNACA0012_directionalRefinement
新しい漏れ検知
複雑なジオメトリでは、メッシュをジオメトリの内側から「こぼれさせる」ことは簡単です。このリリースでは、これらの「メッシュリーク」を検出する2つの方法があります。
snappyHexMesh内
snappyHexMeshでは、キーワードlocationsOutsideMeshはメッシュが通過してはいけない場所を指定します。以前のリリースでは、これはエラーメッセージを表示して終了します。今回のリリースでは、メッシュを分析し、locationInMeshとlocationsOutsideMeshの間でセルの中心からセルの中心へと移動する最短経路を決定し、その結果をsamplesSetとして書き込みます。これは、ポストプロセッサにロードすることができるポストベースのディレクトリ内に、例えば.objのような行ベースのフォーマットのファイルを生成する。パスがジオメトリと交差する場所を特定することは、通常リークの良い候補です。
このアルゴリズムはsnappyHexMeshの改良段階で実行されるため、これらのメッシュリークの検出は高速であるはずです。メッシュリークの出力は、オプションのsetFormatキーワードを使用して、samplesSetフレームワークでサポートされている任意の形式にすることができます。デフォルトの形式はvtkです。
サンプルユーティリティを使用してメッシュを後処理する
最短パスのサンプルセットを使用して、同じアルゴリズムを任意のメッシュでスタンドアロンで実行することもできます。例えばmotorBikeチュートリアルの裏側にあるバイザーパッチといくつかのパッチ面を削除すると、メッシュは（以前に閉じた）サーフェスにあふれます。これらのリークパスは、次の方法で識別できます。
functions {
processorField
{
type processorField;
libs ("libfieldFunctionObjects.so");
}
leakFind
{
type sets;
interpolationScheme cell;
setFormat vtk;
sets
{
leakFind
{
type shortestPath;
insidePoints ((3.0001 3.0001 0.43))
outsidePoints ((1 0 1.3));
axis xyz;
}
}
// Colour the leak path by the processor ID
fields (processorID);
}
}
注：shortestPathサンプル・セットは、操作するために少なくとも1つのフィールドを必要とします。 上記の例では、processorField関数オブジェクトを使用して、ローカルプロセッサ番号を含むフィールドを生成しています。
Source code
$FOAM_SRC/sampling/sampledSet/shortestPath
Examples
$FOAM_TUTORIALS/mesh/snappyHexMesh/motorBike_leakDetection
新しい均一等方性乱流（HIT）初期化 均質等方性乱流の減衰は乱流モデルを検証するための標準的なテストですが、初期化は困難であることがわかります。 Saad他の手順に基づいた新しいcreateBoxTurbユーティリティは、このプロセスを以下のように簡単にします。
周期的パッチを使った初期ボックスメッシュの作成
ユーザ指定のエネルギー量に従って、任意に並行して初期速度場を作成する
次の例では、256×256×256メッシュの計算されたエネルギースペクトルをComte-BellotおよびCorrsinの入力スペクトルと比較します。
結果として生じる減衰は以下の通りです。
Source code
$FOAM_UTILITIES/preProcessing/createBoxTurb
Examples
$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/decayIsoTurb
References
Saad, T., Cline, D., Stoll, R., Sutherland, J.C. ”Scalable Tools for Generating Synthetic Isotropic Turbulence with Arbitrary Spectra” AIAA Journal, Vol. 55, No. 1 (2017), pp. 327-331.
Comte-Bellot G. and Corrsin S. ”Simple Eulerian time correlation of full- and narrow-band velocity signals in grid-generated, ’isotropic’ turbulence” J. Fluid Mech. Vol. 48, part 2 (1971), pp. 273-337
トポセットと検索可能なサーフェスの改善
このバージョンでは、既存のセル/フェース/ポイント選択メカニズムはお互いにそしてそれらのsearchableSurfaceの対応物とより一貫性があるようにされました。 それらの予想される入力は、現在もAPIガイドに一貫して記載されています。
可能であれば、複数選択のサポートが追加されました。 パッチ、セット、およびゾーンだけでなく、パッチ、セット、およびゾーンを受け入れる。 これはユーザーの利便性ですが、中間書き込みが回避されるため、topoSetのパフォーマンスも向上します。
topoSetの辞書入力は、よりコンパクトでユーザーフレンドリな構文が与えられていて、sourceInfoエントリーは現在オプションです。 例えば、
{
name f0 type faceSet; action add; source patchToFace; patch inlet;
}
長い入力スタイルに対して
{
name f0
type faceSet;
action add;
source patchToFace;
sourceInfo
{
name inlet;
}
}
snappyHexDictでよく使用される検索可能なサーフェスは、長い名前の代わりに短い名前で使用できます。
New: box, cylinder, sphere … Longer: searchableBox, searchableCylinder, searchableSphere … 入力辞書の堅牢性の向上
テキスト駆動のコードとして、辞書の値を設定して操作することはOpenFOAMユーザーエクスペリエンスの中心にあります。 今回のリリースでは、辞書の入力を強化して、入力エラーを検出してローカライズする際のより強力な対話を提供することに焦点を当てています。
つまり、既存の入力辞書の中には、以前は検出されなかった構文エラーがある可能性があることを意味します。これらのエラーは、検出されてエラーとして報告されるようになります。
誤検知を発見した場合、つまりエラーとして誤って検出された場合は、gitlabの問題を報告してください。
これは、発生する可能性があるエラーの種類と、予想されるエラーメッセージまたは警告の種類のごく一部です。
行方不明者の場合を取り上げました。 新しい保護されたread辞書メソッドによって検出されたOpenFOAM v1806のエントリ上で： dict {
key1 true // oops no trailing ';' key2 "<case>/filename";
}
dict.get <bool>（key1）またはdict.lookupOrDefault（key1、true）などの保護された読み取りがプログラマによって使用されると、このタイプのエラーメッセージが引き起こされます。
--> FOAM FATAL IO ERROR: Entry 'key1' has 2 excess tokens in stream
3(true key2 "<case>/filename")
行方不明のとき。 が最後の辞書エントリである場合、保護された読み取りはそれを見つけることはできませんが、辞書読み取りで読み取り中にすでに検出されています。
dict {
key missing ending
}
2つの警告と1つのエラーが発生します。
--> FOAM Warning :
Reading "test.dict" at line 20 Too many closing '}' ... was a ';' forgotten?
--> FOAM Warning :
Reading "test.dict" at line 24 Imbalanced brackets
--> FOAM FATAL IO ERROR: "ill defined primitiveEntry starting at keyword 'key' on line 19 and ending at line 24"
このリリースでは、閉じている「}」が多すぎて辞書の読み取りが途中で止まっているかどうかも検出します。
dict1 {
key1 value1; key2 value2;
}
} // oops extra stray '}'
dict2 {
key1 value1; key2 value2;
}
これは通常辞書の終わりを知らせるので、辞書の読みは、迷いのある「}」に出会うと停止します。 以前のバージョンでは、これは上記のdict2がまったく読まれなかったことを意味していました。 OpenFOAM-v1812では、これは入力エラーとしてフラグが立てられるでしょう：
--> FOAM FATAL IO ERROR: Unexpected '}' while reading dictionary entry file: test.dict at line 23. 他の極端な例としては、辞書エントリを閉じるのを忘れることがあります。 ユーザーがそれを忘れた、ファイルがどういうわけか切り捨てられた、またはファイルが自動的に生成されたが、プロセス中に何か問題が発生した。 dict {
key1 value1; key2 value2;
// oops no trailing '}'
これは今このタイプのエラーメッセージを引き起こします：
--> FOAM FATAL IO ERROR: Unexpected EOF while reading dictionary entry file: test.dict at line 26. Numerics 拡張オーバーセットメッシュ機能 このリリースでは、ソルバーに関連した動的オーバーセットの場合の圧力 - 速度結合の一般的な改良が含まれています。
overRhoPimpleDyMFoam
overPimpleDyMFoam
overInterDyMFoam
メッシュの動きによって「マスク」から「計算」に変化する面上のフラックスの評価が修正されました。 ここで、前の反復からのフラックスは、現在のステップのバランス方程式を進めるために適切に更新される必要があります。 これは新しい計算されたセルの内挿値を使用して達成されます。これは、OpenFOAMのメッシュモーションのためのすべてのシングルリージョンダイナミックメッシュソルバーで使用されるアプローチと同じです。
これは、twoSimpleRotorsテストケースで以下に示すように、より現実的なプレッシャータイムの進化につながります。
もう1つの改善点は、「マスクされた」セルが1回の時間ステップで「計算」されると、新しいセルの初期値がドナーセルから補間されるようになったことです。 これにより、Co数を増やすことができます。
以前のリリースでは、コードは補間されていました（ドナーセルからアクセプターセルへ）。
解かれた後の任意の分野 oversetInterpolationRequiredテーブルに記載されている任意のフィールド。 このテーブルはトップレベルのソルバーによって生成されます。 pを含む、U
このリリースでは、コードが新しいoversetInterpolationSuppressedキーワードを検出すると、oversetInterpolationSuppressedテーブル内のフィールドを除くすべてのフィールドを補間します。 これにより、より複雑な場合の数値が大幅に向上します。
Examples
$FOAM_TUTORIALS/compressible/overRhoPimpleDyMFoam/twoSimpleRotors
動的精密化マッピングの改善
Technische Universitat Darmstadtからの細胞分裂のためのマッピングアルゴリズムを統合した。 詳細はアドオンリポジトリを見てください。いくつかのバグ修正に加えて、マッピングはメッシュ改良の間に新しく作成された面の値のより良い初期推定値を生成することに関連しています。
セルを2×2×2に分割すると、12個の新しい内部面が作成されます。 以前のリリースでは、このフィールドは、 これらの新しい面上のフラックスは、分割されていないセルの面の1つから初期化されました。 このリリースでは、マッピングは複数の面から内挿し、反転した面を正しく考慮してより良い初期推定値を与えます。
初期メッシュ、色付き球としての面の値 - 詳細はこちら
セルは2x2xに分割され、新しく作成された内部面と値が表示されます
注：マッピングは新しく作成された面に固有のものです。 以前のリリースでは、これらは元の顔の「コピー」として作成されていました。 今回のリリースでは、これらは自動的に改良されたメッシュ内のマッピングコード（dynamicRefineFvMesh）に独自のマッピングを実行する機会を与える「何もないところで」生成されます。
Source code
$FOAM_SRC/dynamicFvMesh/dynamicRefineFvMesh/dynamicRefineFvMesh.C
$FOAM_SRC/dynamicMesh/polyTopoChange/polyTopoChange/hexRef8/hexRef8.C
Examples
$FOAM_TUTORIALS/multiphase/interIsoFoam/damBreakWithObstacle
Boundary conditions 新しい波動生成モデル
波境界条件は、OpenFOAM v1612のリリースとともにOpenFOAMで最初に導入されました。以降のリリースでは、静的メッシュに対する追加の条件が追加されました。 今回のリリースでは、ピストン運動または羽ばたき運動のいずれかを使用してメッシュを移動することによって波を生成する新しいwaveMaker条件によって現在の機能が拡張されています。
Source code
$FOAM_SRC/waveModels/derivedPointPatchFields/waveMaker
Examples
$FOAM_TUTORIALS/multiphase/interFoam/laminar/waveMakerFlap
$FOAM_TUTORIALS/multiphase/interFoam/laminar/waveMakerPiston
Attribution
これらの境界条件はEnvironmental Hydraulics InstituteのIHCantabriaによって提供されました - commit 6f806aを参照 著者：ガブリエルバラハス
Integration
コードはOpenCFDによって更新され、interFoamファミリのソルバーで利用可能な$ FOAM_SRC / waveModelsライブラリに追加されました - commit da813dを参照してください。
新しい一般化境界条件
uniformFixedValueは、単一の値（したがって、uniform）をとる特別なバージョンのfixedValueです。 以前のリリースでは、これは、空間的に一様であるが追加の入力を伴う時間変化関数に制限されていた。 csvファイルから時間的に補間する：
type uniformFixedValue; uniformValue {
type csvFile; nHeaderLine 1; refColumn 0; componentColumns ( 2 ); separator ","; mergeSeparators no; file "<constant>/inlet.csv";
}
このリリースではこれが拡張されています。
このAPIは、空間的に異なる機能も可能にするように拡張されています（下記の例を参照）。 必要に応じてローカル座標系を指定できます。 uniformValueは、ローカル座標系にあると解釈されるようになりました。 これはスカラーフィールドには関係ありません。 必要に応じて、（ローカル座標系の）コンポーネントごとのスケーリングを指定できます。 これらのスケーリングはいずれもそれ自体がユーザー定義テーブルになることができます。
旋回速度境界条件の例：
// Define coordinate system coordinateSystem {
type cylindrical; e1 (0 1 0); e3 (1 0 0); // axis direction origin (0 0 0);
}
// Time-dependent uniform value (in local coordinates) // Velocity is 1 in axial and -1 in tangential direction uniformValue (0 -1 1); // Local-coordinate dependent scaling: // scale1 : per-component scaling according to coordinate 1(= 'r'): // - at r=0 only axial component is preserved (scale 1) // - at r=1 radial and tangential components multiplied by 2 scale1 table ((0 (0 0 1))(1 (2 2 1)));
タイムランピング環状プロファイルの例（半径方向に直線的に変化する場合）（スケールなしの矢印、速度の大きさで着色）
coordinateSystem {
type cylindrical; e1 (0 1 0); e3 (1 0 0); // axis direction origin (0 0 0);
}
// Ramp velocity from 0 to 10 in axial direction uniformValue table ((0 (0 0 0))(1 (0 0 10))); // Scale uniformValue according to 'r' component scale1 table ((0 (1 1 0))(1 (1 1 1)));
区分的線形（y方向）インレットプロファイルの例
inlet {
type uniformFixedValue;
uniformValue (10 0 0);
scale2 table
(
(0 (0 0 0))
(25.4e-3 (1 1 1))
);
}
注意：元のuniformFixedValue境界条件には、時変の一様値と（時間内の）2次ランニングの問題がありました。
古い時間フィールドを読むと（現時点では）再評価が行われ、誤った境界値が与えられます。 したがって、再起動、分解、または再構築が行われると、昔のフィールドでは誤った値になります。 これは境界上のあらゆる時間微分に影響を与えます。
これに対する修正は、値エントリが存在する場合、それが現在読み込まれて評価されないことを意味します（これは、常に一様な値を評価する以前の動作からの変更です）。 同様に、decomposePar、reconfigctParはuniformValueを評価せず、代わりにマッピングを使用します。
Source code
$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/uniformFixedValue
Examples
$FOAM_TUTORIALS/combustion/reactingFoam/RAS/chockedNozzle
改良された大気境界層条件
大気境界条件の性質を変化させることは、時間の関数として可能である。 流れの方向や地面の状態を変更するには：
Inlet {
type atmBoundaryLayerInletVelocity;
flowDir table
(
( 0 (1 0 0))
( 10 (1 0 0))
( 20 (0 1 0))
( 100 (0 1 0))
);
zDir (0 0 1);
Uref table
(
( 0 10)
( 10 10)
( 20 20)
( 100 20)
);
Zref 20; z0 uniform 0.1; zGround uniform 935.0;
}
ここで、flowDir、zDir、Uref、およびzRefエントリはFunction1タイプです。 表形式、多項式、CSVファイル形式を許可します。 さらに、z0およびzGroundエントリーはPatchFunction1タイプであり、ユーザーは時変フィールド値を設定できます。
Source code
$FOAM_SRC/atmosphericModels/derivedFvPatchFields
フリーストリーム状態の改善
固定流入値の制限はフリーストリーム境界条件から削除されました。これにより、ユーザーは新しいfreestreamBCエントリを介して流入値を課す条件を指定できるようになりました。 たとえば、大気流の場合は、大気境界層プロファイルに従って流入速度を設定すると便利です。
Inlet {
type freestream;
freestreamBC
{
type atmBoundaryLayerInletVelocity;
flowDir (1 0 0);
zDir (0 0 1);
Uref 10;
Zref 20;
z0 uniform 0.1;
zGround uniform 935.0;
}
value $internalField;
}
freestreamValueエントリを使用する以前のバージョンでは、下位互換性が維持されています。
Inlet {
type freestream; freestreamValue uniform (10 0 0);
}
Source code
$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/freestream
Post-processing VTKデータセットの新しい並列処理
VTK出力を生成するためのインフラストラクチャは全面的に改良されました。
foamToVTKユーティリティとvtkWrite関数オブジェクトは並列認識となり、複数領域のシミュレーションを処理するようになりました。
これらの通常の出力は、個々のコンポーネントを含むVTKマルチブロック（.vtm）ファイルです。 そのため、デフォルトの形式はxmlベースのVTK形式、つまり拡張子.vtm、.vtp、abd .vtuに変更されました。 必要に応じて、-legacyオプションを使用してレガシーフォーマットを生成できます。
これらの.vtmファイルに使用されるディレクトリ構造は、内部レイアウトを反映しています。
myCase_40.vtm
myCase_40/ |-- boundary | |-- buildings.vtp | |-- ground.vtp | |-- inlet.vtp | |-- outlet.vtp | - sides.vtp |-- boundary.vtm - internal.vtu
.vtmファイルは、VTKコンテンツを整理するための非常に軽量なコンテナを提供し、パッチの元の番号順を保持します。 便宜上、boundary.vtmファイルも境界/ディレクトリを使用して生成されます。これは、サーフェス上の値のみが必要な場合に便利です。
作成中に、対応する.vtm.series時系列ファイルがParaViewへのロードを容易にするために生成されます。
{
"file-series-version" : "1.0",
"files" : [
{ "name" : "myCase_00000025.vtm", "time" : 0.125 },
{ "name" : "myCase_00000050.vtm", "time" : 0.25 },
{ "name" : "myCase_00000075.vtm", "time" : 0.375 },
{ "name" : "myCase_00000100.vtm", "time" : 0.50 }
]
}
さらに、生成されたすべてのファイルに、ParaView内からアクセスできるグローバルTimeValueフィールド値が提供されるようになりました。
以前のバージョンでは、特定の特別な出力を得るために様々なトリックが必要でした。 いくつかのオプションはvtkWriteとParaView Catalyst functionObjectsとのより良い対応を提供するために変更されました、他はfoamToEnsightとより一致した振舞いを提供するために。 場合によっては、foamToEnsightの機能も適度に調整されています。
これは特定の特別な出力を得るために必要な変更の小さい概観です。
Internal mesh only
1806: foamToVTK -noFaceZones -excludePatches ’(".*")’ 1812: foamToVTK -no-boundary Boundaries only
1806: foamToVTK -noInternal -noFaceZones 1812: foamToVTK -no-internal No faceZone conversion
1806: foamToVTK -noFaceZones 1812: foamToVTK Convert all faceZones
1806: foamToVTK 1812: foamToVTK -faceZones ’( ".*" )’ Selected faceZone conversion
1806: foamToVTK #<-- manually discard unwanted files later 1812: foamToVTK -faceZones myzone
コマンドラインオプションの変更点の概要は、対応するfoamToVTK -help-compatの出力にあります。
$ foamToVTK -help-compat
8 compatibility options for foamToVTK
| Old option | New option | Comment |----------------------------|----------------------------|------------ | -allPatches | -one-boundary | until 1806 | -noLagrangian | -no-lagrangian | until 1806 | -noPointValues | -no-point-data | until 1806 | -noFaceZones | ignored | after 1806 | -noLinks | ignored | after 1806 | -poly | ignored | after 1806 | -useTimeName | ignored | after 1806 | -xml | ignored | after 1806 |----------------------------|----------------------------|------------
関心領域の出力
場合によっては、シミュレーションの特定の領域だけがより詳細な視覚化のために重要です。 vtkWriteおよびensightWrite関数オブジェクトは、柔軟な関心領域選択メカニズムをサポートするように拡張されました。 選択サブ辞書が指定されていない場合は、メッシュ全体が変換されます。 選択サブ辞書を使用すると、最初の選択は空になり、ユーザーは好みの出力領域を定義できます。 構文はtopoSetの構文に基づいています。 例えば、
mySubset {
type vtkWrite; ...
selection
{
box
{
action use;
source box;
box (-0.1 -0.01 -0.1) (0.1 0.30 0.1);
}
dome
{
action add;
source sphere;
origin (-0.1 -0.01 -0.1);
radius 0.25;
}
centre
{
action subtract;
source sphere;
origin (-0.1 -0.01 -0.1);
radius 0.1;
}
...
}
}
Source code
$FOAM_SRC/fileFormats/vtk
Examples
$FOAM_TUTORIALS/heatTransfer/chtMultiRegionFoam/multiRegionHeater
$FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/wingMotion/wingMotion2D˙pimpleFoam
$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/movingCone
$FOAM_TUTORIALS/incompressible/simpleFoam/motorBike
$FOAM_TUTORIALS/incompressible/simpleFoam/windAroundBuildings
$FOAM_TUTORIALS/incompressible/simpleFoam/windAroundBuildings
$FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter
$FOAM_TUTORIALS/mesh/snappyHexMesh/motorBike˙leakDetection
AMIパッチのパフォーマンスを計算するための新しい関数オブジェクト
巡回AMIパッチを採用する場合は、AMI補間重みの品質に敏感です。 実行時およびVTKベースのサーフェスの間にウェイト統計をファイルに書き込む新しいAMIWeights関数オブジェクトによって、ウェイトの詳細な検査が提供されるようになりました。 AMIごとの統計は次のとおりです。
パッチ名 パッチが並列配布されているかどうか 重みの最小値と最大値の合計（完全に一致させるには1にする必要があります） 最小および最大補間ステンシルサイズ
$ FOAM_TUTORIALS / incpressible / pimpleFoam / RAS / propellerの場合の出力例：
- AMI
- Time Patch nbr_patch distributed src_min_weight src_max_weight src_average_weight src_min_neighbours src_max_neighbours ...
0.001 AMI1 AMI2 true 9.264461e-01 1.047157e+00 1.000202e+00 1 9 ... 0.002 AMI1 AMI2 true 9.392015e-01 1.019850e+00 1.000039e+00 1 8 ... 0.003 AMI1 AMI2 true 9.239401e-01 1.049830e+00 1.000198e+00 1 9 ... 0.004 AMI1 AMI2 true 9.490245e-01 1.022364e+00 1.000048e+00 1 9 ... 0.005 AMI1 AMI2 true 9.216583e-01 1.047407e+00 1.000176e+00 1 9 ... 0.006 AMI1 AMI2 true 9.230133e-01 1.021246e+00 1.000040e+00 1 9 ... 0.007 AMI1 AMI2 true 9.201124e-01 1.050923e+00 1.000175e+00 1 9 ...
writeFieldsエントリがtrueに設定されている場合、重みの合計が1ではない場所を識別するために使用できるVTKファイルが書き込まれます。
Source code
$FOAM_SRC/functionObjects/field/AMIWeights
Examples
$FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/propeller
フィールドエクステントを計算するための新しい関数オブジェクト
新しいfieldExtents関数オブジェクトを使用すると、フィールドがどれだけ広がったかを定量化することが簡単になりました。 基準点とフィールドがしきい値を超える位置との間の距離を算出します。 rivuletPanelテストケースの例は、フィルムがパネルを横切る速度を示しています。
Source code
$FOAM_SRC/functionObjects/field/fieldExtents
Examples
$FOAM_TUTORIALS/lagrangian/reactingParcelFoam/rivuletPanel
改良残差関数オブジェクト
残差関数オブジェクトは、ソルバータイプ、ソルバー反復数、および方程式が指定された許容誤差内で解かれたかどうかに関するインジケータを含むように拡張されました。 全機能には以下が含まれます。
residual fields solver type initial residual final residual number of solver iterations convergecnce flag
Benard対流テストケースの出力例は次のとおりです。
- Residuals
- Time p_rgh_solver p_rgh_initial p_rgh_final p_rgh_iters p_rgh_converged
50 GAMG 9.294030e-03 4.311920e-05 4 1 100 GAMG 1.168520e-02 3.014190e-05 3 1 150 GAMG 6.986510e-03 1.489130e-05 3 1 200 GAMG 6.059480e-03 5.917190e-05 2 1 ...
Source code
$FOAM_SRC/functionObjects/utilities/residuals
Examples
$FOAM_TUTORIALS/heatTransfer/buoyantBoussinesqPimpleFoam/BenardCells
新しい運動量関数オブジェクト
線形および（オプションで）角運動量を計算し、積分値を報告し、オプションで場を書き込む、新しい運動量場関数オブジェクトが追加されました。 使用例は次のとおりです。
momentum1 {
type momentum;
libs ("libfieldFunctionObjects.so");
...
writeMomentum yes;
writePosition true;
writeVelocity true;
cylindrical true; origin (0 0 0); e1 (1 0 0); e3 (0 0 1);
}
Source code
$FOAM_SRC/functionObjects/field/momentum
Examples
$FOAM_TUTORIALS/incompressible/simpleFoam/pipeCyclic
新しいvtkCloud関数オブジェクト
vtkCloud関数オブジェクトはOpenFOAM-v1806で導入され、OpenFOAM-v1812用に拡張されました。
この関数オブジェクトは、シミュレーション中にラグランジュデータをVTK PolyData（.vtp）形式で書き込み、補助時系列（.vtp.series）ファイルに書き込まれたファイルに関する情報を同時に記録します。再起動の動作が改善されました。
vtkCloudが再起動されたシミュレーションで使用されると、既存の.seriesファイルを解析してファイルと時間のリストおよび不適切なエントリを取得します。これらは、その場所にはもう存在しないファイルであり、将来のシミュレーション時間に関連するファイルです。つまり、早い段階で再起動しました。
追加情報として、生成されたファイルにはTimeValueフィールドエントリも含まれるようになりました。これは、ParaViewで直接使用できます。
この関数オブジェクトの最大の変更点は、エクスポートする区画のサブセットを定義するためのセレクタの追加です。 Lagrangianシミュレーションは、後処理の視覚化で合理的に表現できるよりもはるかに多くの区画を持つことが多いので、全体の数を減らすために出力にストライドを課すことは有用なことがあります。さらに、非常に小さい粒子、動きが遅すぎる粒子などを排除することが望ましい場合があります。考えられるすべての組み合わせに対処するために、柔軟な選択メカニズムが追加されました。
選択フレームワークはアクションの組み合わせを使用します。柔軟な選択メカニズムを提供するために、加算、減算、サブセット、反転などの選択基準（ストライドベースまたはフィールドベース）を選択できます。これが一例です。
// Optional selection mechanism selection {
stride
{
// Every 10th parcelId
action use;
source stride;
stride 10;
}
T
{
// Only interested in a narrow temperature range
action subset;
source field;
field T;
accept (greater 280) and (less 300);
}
diameter
{
// No small particles
action subset;
source field;
field d;
accept (greater 1e-10);
}
Umin
{
// Remove slow parcels
action subtract;
source field;
field U;
accept (less 0.1);
}
}
区画選択メカニズムが使用されている場合、その結果はログに報告されます。 例えば、
vtkCloud output Time: 3.2 Applying parcel filtering to 994 parcels - use stride 4 - subtract field U : (less 0.2) After filtering using 214/994 parcels
Source code
$FOAM_SRC/functionObjects/lagrangian/dataCloud
Examples
$FOAM_TUTORIALS/lagrangian/coalChemistryFoam/simplifiedSiwek
$FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter
新しいdataCloud関数オブジェクト
新しいdataCloud関数オブジェクトは、区画位置と単一のフィールドを抽出する簡単な方法を提供します。 普通のASCIIファイルとしての直径。 この非常に単純なファイル形式は、スクリプト作成ツールを使用したり、スプレッドシートにインポートしたり操作したりする場合に特に便利です。
- x y z d
1.453011682 0.9934118847 0.05 0.0009759297884 1.478081409 0.9845705036 0.05 0.0009735625113 1.482924483 0.0582741528 0.05 0.0009742007613 1.472664559 0.9610647605 0.05 0.0009746270844 ...
vtkCloud関数オブジェクトと同様に、dataCloudはエクスポート用の区画のサブセットを選択する表現的な手段をサポートしています。
Source code
$FOAM_SRC/functionObjects/lagrangian/dataCloud
Examples
$FOAM_TUTORIALS/lagrangian/coalChemistryFoam/simplifiedSiwek
$FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter
新しい等値面法
新しいisoSurfaceTopoサーフェス生成ルーチンは、isoSurfaceおよびisoSurfaceCellオプションの代わりとして使用できます。 その利点は
それはより少ないメモリを使用し、より速いはずです エッジに沿ってトポロジカルカットを使用し、すべてのカットが同じ点を使用するようにします（ローカルプロセッサで）。 それはすべてのカットされたセルの外側を歩き、共通のフォーマットによってサポートされる単一の多角形ですべての三角形を置き換える異なるフィルタリングを含みます。 「vtk」、「ensight」 フィルタリングはより滑らかな表面を作り出す
典型的な使い方
isoSurface {
type surfaces;
libs ("libsampling.so");
writeControl writeTime;
surfaceFormat vtk; fields ( p U );
interpolationScheme cellPoint;
surfaces
(
isoSurfaceTopo
{
type isoSurfaceTopo;
isoField p;
isoValue 0.0;
}
);
}
snappyHexMesh上のisoSurfaceCellアルゴリズム
snappyHexMesh上のisoSurfaceTopoアルゴリズム
フィルタリングは非多様体曲面を生成することがあり、正則化をfalseに設定することで無効にすることができます。
さらに評価を進めた結果、この等値面法は将来のリリースでisoSurfaceCellオプションを置き換える可能性があります。
Source code
$FOAM_SRC/sampling/surface/isoSurface
Parallel 改良された並列前後処理ツール
-dry-runオプションがdecomposeParに追加されました。これにより、すべての分解ステップをテストできますが、結果として得られる分解はディスクにコミットされません。 このオプションは通常、-ViewDistオプションと組み合わせて、ParaViewで視覚化できるボリュームフィールドを書き込みます。
reconctParおよびmapFieldsParで使用される-fieldsオプションは、正規表現を処理するようになりました。
-allRegionsオプションがredistributeParに追加されました。
decomposeParの新しい幾何学的制約
メッシュの領域の分解を防ぐために、新しい幾何学的分解制約を使用することができる。 これは、シミュレーションドメインの特定の部分を同じプロセッサに配置する必要がある場合に便利です。
制約は、どのプロセッサが同じプロセッサ上で接続されたままになるかを定義するために使用されます。 幾何学的要素はsnappyHexMeshからおなじみの構文で定義されます。
constraint1 {
type geometric;
geometry
{
box1
{
type box;
min (-10 -10 -10);
max (1 1 1);
}
ball1
{
type sphere;
origin (-2 -2 1);
radius 1;
}
}
}
さまざまな幾何学的制約の影響を受けるセル分布を示しています。
Source code
$FOAM_SRC/parallel/decompose/decompositionMethods/decompositionConstraints/geometric
Examples
$FOAM_TUTORIALS/preProcessing/geometricConstraint
Usability 最新の座標系
座標系はそれらをより使いやすくそしてはるかに多目的にするために見直しを受けました。
ローカル座標系は、単にデカルト座標、円柱座標など、値がどのように解釈されるかについての情報と組み合わされた、空間内の位置と方向です。しかし、この単純さは以前のバージョンでは失われていました。
再構成されたコードは、よりクリーンで散らかった辞書仕様であなた自身の仕様を追加することをより簡単にします。
多くの場合、デカルト座標が必要であり、その軸は既知です。 この場合、仕様は非常にコンパクトです。
coordinateSystem {
origin (0 0 0); e2 (0 1 0); e3 (0.5 0 0.866025);
}
ただし、より説明的な仕様は、より複雑な状況でも利用できます。 例えば
coordinateSystem {
type cylindrical;
origin (0 0 0);
rotation
{
type axisAngle;
axis (0 1 0);
angle 30;
}
}
コード内では、一様変換と非一様変換の座標系を区別します。 回転行列は位置に依存しないため、円筒座標系は不均一変換の一例です。 これは現在、座標系クラスに含まれています。 位置に依存する順方向と逆方向がサポートされるようになりました。
outputVector = cs.transform(globalPoint, inputVector);
これは、複数の点と値の変換でもサポートされています。 しかし、状況によっては、一様変換と非一様変換を異なる方法で処理する方が便利で効率的な場合があります。 例えば、
if (cs.uniform()) {
// A single input and a single output vector xx = cs.transform(someVector); ...
} else {
// Non-uniform, so the transformed vector is different for each position List<vector> xx = cs.transform(manyPoints, someVector); ...
}
その他のアップデートは次のとおりです。
座標系の変換およびinvTransformメソッドには、標準のOpenFOAMデータ型、たとえばスカラー、ベクトル、テンソルが含まれる 新規ローテーション指定なし（恒等ローテーション） transformPoints -rotate-angleオプションに対応する新しい回転指定axisAngle。 いくつかのケースでは、これはもっと直感的になり得ます。 既存の座標回転仕様の新しい短い名前。 以前の名前は後方互換性のためにサポートされています。 New name Old name axes axesRotation euler EulerRotation starcd STARCDRotation
更新された機能は、新しいPatchFunction1クラスのローカル座標系をサポートするために使用されています。
Source code
$FOAM_SRC/src/meshTools/coordinate
Examples
$FOAM_TUTORIALS/compressible/rhoPimpleFoam/RAS/angledDuct/constant/fvOptions
$FOAM_TUTORIALS/incompressible/pisoFoam/laminar/porousBlockage/constant/fvOptions
新しい環境管理
OpenFOAM-v1812で行った変更の1つは、OpenFOAMバージョンの概念をどのように扱うかを変更することです。 今までは、この情報をetc / bashrcファイルとetc / cshrcファイル内の変数に登録し、その後この値を使用していました。
たとえば、次のようなエントリがあります。
export WM_PROJECT=OpenFOAM export WM_PROJECT_VERSION=v1812
OpenFOAMとThirdPartyの予想ディレクトリ名は次のようになります。
/path/parent
|-- OpenFOAM-v1812 - ThirdParty-v1812
そして、ユーザ設定（etc）ファイルの発見は、これと同じWM_PROJECT_VERSION値に従います。
$HOME/.OpenFOAM/v1812 $HOME/.OpenFOAM
しかし、あなたがあなたのバージョンに最新のバグ修正をパッチしたとき、数ヶ月のうちに何が起こるか。 これをどのように文書化しますか。
1つの方法は、変更を反映するようにバージョン名を変更することです。 例えば、
export WM_PROJECT_VERSION=v1812.update01
しかし、これはディレクトリ名も変更する必要があるという当面の困難を引き起こします。
/path/parent
|-- OpenFOAM-v1812.update01 - ThirdParty-v1812.update01
しかし、WM_PROJECT_VERSIONの変更はOpenFOAMが現在異なる場所を調べていることを意味するので、本当の煩わしさはユーザファイルにあります。
$HOME/.OpenFOAM/v1812.update01 $HOME/.OpenFOAM
これらの問題のいくつかはシンボリックリンク、または他の巧妙さで管理できます。 しかし、回避策を必要とせずに、OpenFOAMの処理方法を変更してこれらの煩わしさの多くを解決することが、はるかに理にかなっています。
新しい基本規則
OpenFOAMバージョンの基本レベルは、そのAPIレベルによって決まるようになりました。これは、OpenFOAM wmake規則で与えられているように、OPENFOAMコンパイル定義の4桁の数値に正確に対応します。 この値は、メジャーリリースごとに定義されます（例：1806、1812など）。
このAPI情報はパッチレベルで補完されます。 リリースは定義上パッチが適用されていないため、パッチ値は0になります。それ以降のパッチはパッチレベルで記録されます。 パッチレベルは参考情報であり、ファイルの検索方法には影響しません。
出荷されているOpenFOAM-v1812バージョンでは、ユーザーに変更は必要ないため、この変更はすぐにはわかりません。
つまり、ファイル設定は同じです。
export WM_PROJECT=OpenFOAM export WM_PROJECT_VERSION=v1812
そしてOpenFOAMとThirdPartyのディレクトリ名は同じに見えます。
/path/parent |-- OpenFOAM-v1812 - ThirdParty-v1812
ただし、ユーザー構成ファイルはWM_PROJECT_VERSION値ではなくAPI値に従うようになりました。 つまり、バージョン名に依存していた古いシステムではなく、APIバージョンのディレクトリが使用されます。
$HOME/.OpenFOAM/1812 $HOME/.OpenFOAM
ディレクトリ名のv1812から1812への微妙な変更に気付くには、もっとよく見る必要があるかもしれません。 ただし、前に示したのと同じ方法を使用することにした場合は、これらの変更の影響をすぐに確認できます。
ここでも、意味のあるバージョン名を決めます。
export WM_PROJECT_VERSION=v1812swak
しかし、それ以外は何も変わらない。 ディレクトリ名を変更する必要はありません。
/ path / parent | - OpenFOAM-v1812
- ThirdParty-v1812
APIは同じなので、ユーザーファイルの場所は変わりません。
$HOME/.OpenFOAM/1812 $HOME/.OpenFOAM 現在使用しているバージョンを確認する方法
以前のバージョンでは、おそらくWM_PROJECT_VERSION環境値、またはアプリケーションに組み込まれているビルド時情報を使用していました。 たとえば、blockMesh -helpから表示されるように、
Using: OpenFOAM-v1806.update01 (see www.OpenFOAM.com) Build: v1806.update01-6592c67716d3 Arch: "LSB;label=32;scalar=64"
この情報から、これは1806 APIレベルを使用していると推測（または希望）することができます。これらの値はバージョンまたはビルド命名のどこかに現れることがあるからです。
新しいバージョン管理では、現在のパッチレベルと同様に、APIレベルがビルド情報の一部になります。 説明のために、このバージョンのOpenFOAMに何度かパッチがあてられたあとに、この文書をもう一度読むことを想像してください。 これは、blockMesh -helpが表示する情報の種類です。
Using: OpenFOAM-v1812swak (1812) (see www.OpenFOAM.com) Build: afadff77f-20181219 (patch=20190401) Arch: LSB;label=32;scalar=64
この出力は私達が必要とするすべてのより興味深い情報が含まれています：
item value version v1812swak api 1812 commit afadff77f author date 20181219 patch-level 20190401 この例からわかるように、git build情報は変更が作成された日付によって補完されます。これはリポジトリにローカルの変更が含まれている場合に役立ちます。 現在のAPIとパッチのレベルを簡単に知りたい場合は、foamEtcFileスクリプトまたは新しいwmakeBuildInfoスクリプトを-show-apiオプションまたは-show-patchオプションのいずれかと共に使用できます。 例えば、 $ foamEtcFile -show-api 1812
$ foamEtcFile -show-patch 20190401
WM_PROJECT_API環境変数も定義されていますが、これは便宜上のものであり、現在アクティブな環境内で行われたパッチの変更を反映していない可能性があります。
プログラマーズノート：APIとビルド情報は新しいFoam :: foamVersion名前空間内の変数とメソッドを通して内部的にアクセス可能です。
今どうなっているの？
OpenFOAMディレクトリの名前は自由に選択できるようになりました。つまり、特定の環境変数（FOAM_INST_DIR、WM_PROJECT_INST_DIR）は必要なく、意味もありません。
自由に選択可能なディレクトリ名とそれが$ WM_PROJECT_VERSIONの値から独立しているということは、興味深い組み合わせを安全に使用できることを意味します。 例えば：
WM_PROJECT_VERSION=functionalityTests
これは通常のOpenFOAMディレクトリ構造で/ some / path / openfoam-sandbox1812としてインストールされます。
/some/path | - openfoam-sandbox1812
|-- applications |-- bin |-- doc |-- etc | |-- etc/bashrc | - etc/cshrc |-- platforms |-- src - wmake
このタイプの柔軟な命名が可能であるとき、ThirdPartyディレクトリがどのように見つけられるべきであるかに関して自然な問題が生じます。
ThirdPartyディレクトリ
OpenFOAMには通常、サードパーティソフトウェアのディレクトリが付属しており、OpenFOAMに必要な、あるいは少なくとも非常に有用な、いくつかのサードパーティソフトウェア用のスクリプトを構築しますが、必ずしもすべてのオペレーティングシステムまたはクラスタインストールですぐに利用できるわけではありません。
これらのサードパーティのソースは通常OpenFOAMディレクトリと同じディレクトリにあります。 例えば、
/path/parent |-- OpenFOAM-v1812 - ThirdParty-v1812
ただし、この単純な規則では不十分な場合が多くあります。
追加のサードパーティソフトウェアが実際には必要ない場合（つまり、オペレーティングシステムまたはクラスタインストールによって提供される場合） OpenFOAMのディレクトリ名を任意のディレクトリ名に変更したとき。 openfoam-sandbox1812など インストールが単一のディレクトリ構造内にカプセル化されていることを確認するために、追加のサードパーティソフトウェアをOpenFOAMディレクトリ内に配置することを希望する場合。 これはクラスタのインストールに必要な場合もあれば、個々のワークステーションに対してソフトウェアのロールアウトを実行するための便利な手段になる場合もあります。 さまざまな機能をテストまたは開発するためのさまざまなOpenFOAMディレクトリがありますが、それらすべてに同じサードパーティソフトウェアを使用または再利用したい場合。
これらの問題に対する解決策は、ThirdPartyディレクトリを見つける際の次の優先順位を持つ、より新しく、よりインテリジェントな発見です。
PROJECT/ThirdParty
単一ディレクトリインストール用 PREFIX/ThirdParty-VERSION
これは伝統的なアプローチに対応します PREFIX/ThirdParty-vAPI
ThirdPartyという名前を変更することなく、VERSIONの更新値、たとえばv1812-myCustomを使用できます。 APIの値は「1812」のままで、オリジナルのThirdParty-v1812 /が見つかります。 PREFIX/ThirdParty-API
これは前の例と同じですが、手付かずのAPI値を使用しています。 これは、選択されたバージョン名がその命名に未定義のAPI値も使用している場合にも意味があります。例えば、1812-patch190131、1812.19W03 PREFIX/ThirdParty-common
さまざまなバージョンで最大限の再利用を許可しますが、潜在的なバージョンの非互換性を知っている経験豊富なユーザーのみ
これらのディレクトリがどれも適切でないとわかった場合は、（ディレクトリが存在しなくても）PROJECT / ThirdPartyをダミーの場所として使用することに戻ります。 これはOpenFOAMディレクトリ構造内にあり、悪影響を及ぼさないと信頼できるため、これは安全な代替値です。
上記では、次の表記法が使用されています。
name value meaning PROJECT $WM_PROJECT_DIR The OpenFOAM directory PREFIX dirname $WM_PROJECT_DIR The OpenFOAM parent directory API foamEtcFiles -show-api The api or release version VERSION $WM_PROJECT_VERSION The version we’ve chosen 誤検出の可能性を減らすために（おそらく他のソフトウェアもその名前にThirdParty-xxxを使用しています）、ディレクトリテストにはOpenFOAM固有の健全性テストが伴います。 OpenFOAMのThirdPartyディレクトリには、Allwmakeファイルまたはplatform /ディレクトリが含まれています。
グループで働く
OpenFOAMクラスタインストールが複数の異なる人々や興味グループによって使用されているとき、共通の設定やカスタムライブラリとカスタムアプリケーションを共有することは非常に興味深いかもしれません。 これがOpenFOAMのサイト（グループ）設定が非常に役に立つところです。
OpenFOAMサイト設定のディレクトリの場所は、WM_PROJECT_SITE環境変数によって定義されます。 これが定義されていない場合、デフォルトではPROJECT / site（つまりOpenFOAMディレクトリ内にあるサイトディレクトリ）が使用されます。 以前のバージョンではPREFIX / siteが代替として使用されていましたが、これはほとんどのクラスタパッケージ要件と矛盾します。
この$ WM_PROJECT_DIRディレクトリ内で、OpenFOAMディレクトリ構造の要素を反映したディレクトリ構造を使用できますが、ある程度のバージョン管理も含まれています。
$WM_PROJECT_SITE
|
|-- API
| |-- bin
| - etc
|-- VERSION
| - platforms
| |-- bin
| - lib
|-- bin
- etc
OpenFOAM関連の便利なスクリプトはbinディレクトリに置くことができます。 スクリプトが特定のバージョンのOpenFOAMでしか動作しない場合は、それに応じてそれをAPI / binディレクトリに配置するのが合理的です。
同様に、特定の設定や設定が複数の人に役立つ場合は、それらをサイト（またはグループ）リソースとして一元的に配置するのが合理的です。 例えば、
$WM_PROJECT_SITE | - etc
|-- caseDicts
- config.sh
|-- openmpi
- paraview
いくつかの共同で役に立つcaseDictsとopenmpiのための適切な設定のために、paraview。
foamEtcFile -listオプションは、どの場所で設定ファイルが検索されるかについての概要を提供します。次の優先順位が使用されます。
user:
$HOME/.OpenFOAM/API $HOME/.OpenFOAM group:
WM˙PROJECT˙SITE/API/etc WM˙PROJECT˙SITE other:
WM˙PROJECT˙DIR/etc
アプリケーションとライブラリをグループ内で共有する場合、一般的なアプローチは、1人の担当者が内部コードリリースの管理を担当するというものです。 彼らは、通常のユーザーディレクトリにコードをコンパイルします。つまり、通常はユーザーの宛先があります。
$FOAM_USER_APPBIN $FOAM_USER_LIBBIN
For distribution at the group level, these files would be synchronized to the corresponding group directories:
$FOAM_USER_APPBIN -> $FOAM_SITE_APPBIN $FOAM_USER_LIBBIN -> $FOAM_SITE_LIBBIN 設定を変更する
OpenFOAMの設定ファイルとの最初の出会いはいくらか威圧的です。 実際、OpenFOAMの使用に関連するソフトウェアはかなりの数種類あります。それぞれ、異なる推奨バージョン、可能な場所、ライブラリディレクトリの命名規則が異なります。 さらにそれは個々のユーザが彼ら自身の設定選択をすることを可能にするべきです。 すべてのcshellバリアントをサポートすることで、さらに多くのファイルがミックスに追加されます。
幸いなことに、ユーザーはいくつかの簡単な変更を加えるだけでよく、詳細の大部分を無視することができます。また、コマンドラインから直接共通の複数の変更を行うためのfoamConfigurePathsツールも提供します。
設定ファイルは一般にそれらがどの値を期待するかについての詳細な情報を含んでいます、そしてユーザーが編集可能な部分もそのように明確にマークされています。 例えば、
- ------------------------------------------------------------------------------
- USER EDITABLE PART: Changes made here may be lost with the next upgrade
ParaView_VERSION=5.6.0 ParaView_QT=qt-system cmake_version=cmake-system
- END OF (NORMAL) USER EDITABLE PART
- ------------------------------------------------------------------------------
それにもかかわらず、変更を加える前に、これらの変更が実際に行われるべき場所（そしてその理由）を理解しておくと便利です。 話を簡単にするために、POSIX（bash）についてのみ説明しますが、ほとんどの点はcshellの変種にも当てはまります。
OpenFOAM設定の主なエントリポイントはetc / bashrcです。 ファイルの最初の部分はバージョンを確定し、OpenFOAMディレクトリがどこにあるのかを判断するのに役立つスクリプト「魔法」を含んでいます。 ファイルのバランスには、OpenFOAM特有の一般的な設定がいくつか含まれています。これはガイダンスとして使用できますが、一般的には次の点に注意する必要があります。 このbashrcファイルに加えた変更は、次回のアップグレードで失われる可能性があります。 このファイルを編集するのではなく、<prefs.sh>ファイルで上書きする必要があります。 etc / bashrcファイル（これが私たちのエントリポイントでした）は、制御をetc / config.sh / setupファイルに渡します。これは、残りの設定アクションをディスパッチします。
OpenFOAM環境の設定は、処理ツリーの観点から説明できます。
source etc/bashrc [args]
|
|-- constants
|-- directory discovery magic
|-- defaults
|-- define OpenFOAM directory
|
- setup
|-- discovery of ThirdParty locations
|-- admin overrides (prefs.sh file)
|-- user overrides (prefs.sh file)
|-- user overrides (arguments)
|-- settings (compiler, os)
|-- mpi
|-- paraview
|-- mesa / vtk
|-- boost / CGAL mpi
|-- scotch
|-- FFTW
- aliases
そして、このプロセスのほとんどの場所では、ユーザーがファイルの代替バージョンを提供することによって使用される値に影響を与える可能性があります。例えば、単にファイル$ HOME / .OpenFOAM / config.sh / FFTWを作成すると、それがソーシング中にfoamEtcFileメカニズムによって見つけられるようになります（どのディレクトリーが検索されるかについての注意についてはfoamEtcFile -listを参照してください）。
OpenFOAM自体の基本設定（コンパイラ、mpi、データサイズなどの選択）に影響を与える最も恒久的な変更は、通常prefs.shファイルで定義されるべきです。この種の変化は、彼らが特別な扱いを受けるのに十分に重要です。
PROJECT / etc / prefs.shとして入手できる場合は、baseまたはadminのprefs.shファイルを使用します。これにより、システム管理者は、コンパイラやベンダー固有のMPIライブラリなど、サイト全体の設定を定義するための信頼できる場所を得ることができます。 ユーザーまたはグループprefs.shが存在する場合はそれを使用します。
素早いまたは一時的な変更のためには、etc / bashrcを読み込むときの引数の特別な解釈が非常に便利です。このメカニズムにより、ファイルを編集することなく変数を直接設定できます。たとえば、OpenFOAM環境を異なるコンパイラで調達するには、次のようにします。
source /path/to/OpenFOAM-v1812 WM_COMPILER=Clang
引数が変数の代入ではないと思われる場合は、ファイルとして解決できるかどうかを確認してから、それを参照します。 このプロパティを使用すると、ユーザーはお気に入りの設定をまとめて一時的に切り替えることができます。 例えば、いくつかの定義済み構成を作成することによって、
- file = $HOME/.OpenFOAM/gcc82
export WM_COMPILER_TYPE=ThirdParty export WM_COMPILER=Gcc82 export WM_LABEL_SIZE=32
もしくは
- file = $HOME/.OpenFOAM/clang50-int64
export WM_COMPILER_TYPE=ThirdParty export WM_COMPILER=Clang50 export WM_LABEL_SIZE=64
そうすれば、異なる設定を簡単に切り替えることができます。
source /path/to/OpenFOAM-v1812 clang50-int64 source /path/to/OpenFOAM-v1812 gcc82
この情報を使用して、ユーザーはかなりの自信を持ってOpenFOAMの設定を調整できるはずです。 しかし、OpenFOAMディレクトリ内で直接エントリを直接変更することが、すべてのユーザーにとって新しい恒久的なデフォルト値として設定されていると便利で便利な場合もあります。 ユーザーが通常の柔軟性を必要としないクラスタインストールの場合も同様です。
このような場合には、foamConfigurePathsツールが役立ちます（そして強力です）。 たとえば、OpenFOAM ThirdPartyの依存関係なしでインストールし、さらにOpenFOAMディレクトリを固定の場所に設定する（bash探索の魔法を削除する）場合は、次のようにします。
bin/tools/foamConfigurePaths \
-project-path "/opt/openfoam-1812" \ -boost boost-system \ -cgal cgal-system \ -fftw fftw-system \ -kahip kahip-none \ -scotch scotch-system \ -scotch-path /usr/lib64/mpi/gcc/openmpi \ ;
このツールの使用にはいくつかの制限があります。
OpenFOAMプロジェクトディレクトリから呼び出さなければなりません 不用意な使用を避けるために、PATHには含まれていません。 このツールを使用してデフォルトのgcc、gmp、mpfrのバージョンを変更することはあまり正確ではありません。 Gcc48、Gcc82などを区別せずにgccのバージョンを変更します。 新しいマニュアルページ
アクセスしやすい情報を提供し、コマンドラインの変更に対してよりスムーズな移行を保証するために、さらなる努力が払われています。
各ソルバーとユーティリティは、通常の-helpオプションをサポートしています。これには、使用方法の概要といくつかの可能なオプションが含まれています。 これは、各ソルバーまたはユーティリティの目的に関する基本情報を含むように更新されました。 この情報は、オンラインのdoxygenフォーマットですでに利用可能であったものを大部分反映していますが、現在はより容易に利用可能になっています。
使用法は、オプションだけでなくコマンドライン引数に対するコメントの追加をサポートするように拡張されました。 これにより、情報を対応する引数に直接関連付けることが容易になります。 例えば、
$ surfaceBooleanFeatures -help
Usage: surfaceBooleanFeatures [OPTIONS] <action> <surface1> <surface2> Arguments:
<action> One of (intersection | union | difference) <surface1> The input surface file 1 <surface2> The input surface file 2
Options:
-case <dir> Specify case directory to use (instead of the cwd) ...
最も重要な情報を簡単に見つけられるようにするために、使用頻度の低いオプションや高度なオプションを除外します。 -help-fullオプションは、すべてのオプションを表示します。
互換性オプションが利用可能な場合、-help-compatオプションが使用法に表示されます。 互換性オプションを使用すると、オプションの透過的な名前変更、または適用されなくなったオプションの削除が可能になります。 例えば、
$ foamToEnsight -help-compat
2 compatibility options for foamToEnsight
| Old option | New option | Comment |--------------------|-------------------|------------ | -noLagrangian | -no-lagrangian | until 1806 | -noPatches | -no-boundary | until 1806 |--------------------|-------------------|------------
-help-fullの出力で明らかになったように、新しい-help-manオプションが利用可能になりました。 これは、すべてのOpenFOAMソルバーとユーティリティが、ヘルプ情報をマンページ形式で表示できるようになったことを意味します。 この出力は通常直接表示されませんが、man（1）システムで使用するために別の場所にリダイレクトされます。
foamCreateManpageツールは、いくつかの作業に役立ちます。また、OpenFOAMをオペレーティングシステムのインストールまたはクラスタにパッケージ化するときに使用できます。
例えば、
$ cd $WM_PROJECT_DIR $ bin/tools/foamCreateManpage -gzip
コンパイルされたすべてのOpenFOAMアプリケーションおよびユーティリティ用のマンページコンテンツを生成し、そのコンテンツをOpenFOAMのdoc / man1ディレクトリに配置します。 OpenFOAM環境が更新されると、このディレクトリはMANPATH変数に追加され、それらをman（1）システムで利用できるようになります。
$ man blockMesh
移植性の向上
OpenFOAMの移植性を向上させるためのいくつかのマイナーな変更が行われました。特にWSL（Linux用のWindowsサブシステム）を使用しているユーザーにとっては特にそうです。 つまり、$ PATH内の他の（OpenFOAM以外の）場所には、悪影響を及ぼすことなく名前に空白が含まれる可能性があります。
ただし、OpenFOAMディレクトリ自体は以前のように残り、名前に空白はありません。 これを回避するための標準的な方法は、空白のないディレクトリを作成するためのシンボリックリンクを作成することです。
例えば、
cd $HOME ln -s "/mounted volume/user/workdir" workdir cd workdir
- start working with OpenFOAM
このバージョンでは、これは期待通りに動作するでしょう。 OpenFOAMは、内部のcwd（）値を取得するときに、物理パスではなく論理パスを使用するようになりました。 必要に応じて、グローバルなcontrolDictのエントリを変更して古いデフォルトを復元できますが、必須ではありません。
意味の違いはシェルコマンドで簡単にテストし理解することができます。
$ pwd -P : The old OpenFOAM internal meaning for cwd() $ pwd -L : The new OpenFOAM internal meaning for cwd() Core 新しく改良された低レベルコンテナ
OpenFOAM-v1812では、コアコンテナにいくつかの緩やかな変更が加えられています。 これらの変更の多くは開発者だけが関心を持っていますが、一般のプログラマでさえリストのハッシュ化のための調整が役に立つと思うかもしれません。
リストのハッシュ
Hash <>関数がListとFixedListに追加されました。 これは、HashTableまたはHashSetのハッシュキーとして要素のリストを使用できるようになったことを意味します。 これが役立つ可能性がある実際的な例は、HashSetの面が必要な場合です。 これは今直接可能です。
HashSet<face> facesUsed; facesUsed.insert(someFace); ...
他の種類の「ハッシング」では、ラベルのFixedListを使うことも可能です。 bitSetの値を設定または設定解除するtriFace
正規化
顔法線などのベクトルを扱う場合、コーディング時に長さゼロのベクトルの扱いが問題になります。 これは現在、すべてのベクトル空間型に対するnormalize（）メソッドと、同等のグローバル正規化（）関数によって対処されています。 これらは、ゼロ除算を回避するための一貫した処理を提供します。 メソッド呼び出しは項目をその場で変更しますが、グローバル関数はコピーを返します。
以前のコードでは、この型構造はよく見られました：
vector vec1(...); vec1 /= mag(vec1) + VSMALL;
より現代的なアプローチは代わりにnormalize（）メソッドを使うでしょう：
vector vec1(...); vec1.normalise();
この変更により、一貫して使用することが容易になり、定数変数を作成するために使用できます。 例えば、
const vector vec2a( vector(...).normalise() ); const vector vec2b( normalised(vector(...)) );
関連トピックでは、面の法線を正規化する必要があるかどうか、または面積の大きさを含めるかどうかに応じて、面はunitNormal（）メソッドまたはareaNormal（）メソッドを使用するようになりました。
以前のバージョンでは、メソッド名normal（）が使用されていましたが、そこから単純にコードを読み取るだけで、これが面積法線を意味するのか単位法線を意味するのか（それはareaNormalである）。
PtrList
PtrListのエントリにアクセスするときは、get（）メソッドを使用して、参照の代わりにポインタアドレスを返すことができます。
PackedListとbitSet
プロセッサ間でパックコンテンツを転送するときに、デフォルトのunsigned intではなく、通信データに使用するデータサイズをより小さく指定することが可能になりました。 この機能はunpack（）メソッドによって提供されます。 例えば、
processorPolyPatch pp = ...; UOPstream toNbr(pp.neighbProcNo(), pBufs); toNbr << faceValues.unpack<uint8_t>(pp.range());
これはいくらかの帯域幅を節約し、同じデータ整列を必要としません。
globalIndex
globalIndexインデックスは、並列シミュレーションのサイズ調整を調整するときに使用されます。 現在では、空、リセット、localSizeなど、柔軟性を向上させる追加のメソッドがあります。
メッシュ関連のアドレス指定とクエリ
whichPatch（）メソッドは、高速検索のためにバイナリ検索を使用するようになりました。
座標系、polyBoundaryMesh、faBoundaryMesh、fvBoundaryMesh、およびZoneMeshのwordResマッチャーを使用すると、一致する名前またはインデックスを簡単に見つけることができます。
パッチグループマッチングの処理効率が向上しました。
fvMeshSubsetおよびfvMeshSubsetProxy
fvMeshSubsetクラスとfvMeshSubsetProxyクラスは、メモリのオーバーヘッドを減らしてパフォーマンスを向上させるために調整されました。
fvMeshSubsetは、メモリ効率の高いインタフェースと内部アカウンティングにbitSetを使用するようになりました。 サブセットは構築時にすぐに作成できるため、コーディングが簡単になります。 例えば、
return autoPtr<fvMeshSubset>::New(mesh, selectedCells);
現在コードでfvMeshSubsetを使用している人は誰でも、自分の目的に最も適した改善されたインタフェースを見つけるためにクラスのドキュメントを読むことをお勧めします。
新しいPatchFunction1クラス
新しいPatchFunction1はFunction1クラスの拡張であり、時間と空間的に変化するフィールド値を割り当てるための直接的なメカニズムを提供します。 uniformFixedValue境界条件に新しい機能を付与するのはこのクラスです。 現在の型はすべてのFunction1型から構成されています。
constant csvFile one polynomial scale sine square table tableFile uniformValue zero
そして2つの新しいタイプ
mappedFile item sampled
mappedFile型は、timeVaryingMappedFixedValue境界条件のすべての機能を実装しているため、constant / boundaryDataディレクトリから読み取られたファイルを補間できます。 サンプルタイプは、マッピングされた境界条件からの機能を実装するため、シミュレーション自体から値を再循環します。
現在Function1が適用可能でpolyPatchへのアクセスがある場所であればどこでも代わりにPatchFunction1を使用してすべての新しい型とローカル座標系機能を取得できます。 一般的に必要な唯一の追加の変更（Function1と比較して）は、autoMap、rmap呼び出しをフィードスルーすることです。 例えば参照。 uniformFixedValue境界条件
Source code
$FOAM_SRC/meshTools/PatchFunction1 $FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/uniformFixedValue
Documentation
New verification and validation cases more...
About us
OpenFOAM is produced by the core ESI-OpenCFD team
Andrew Heather
Mattijs Janssens
Sergio Ferraris
Mark Olesen
Prashant Sonakar
Pawan Ghildiyal
Roger Almenar
Matej Forman
Sebastien Vilfayeau
Siby Mandapathil Baby
Mayur Wala
Son Vo
Kutalmis Bercin
Karen Kettle
Fred Mendonca
With wider support from the global ESI team
ESI Group (GmbH)
ESI Group (ESI Software (India) Private Limited)
ESI Group (North America)
ESI Group (Nihon ESI)
And contributions from
The Environmental Hydraulics Institute IHCantabria
OpenFOAM.org
Technische Universitat Darmstadt
Useful links
Download OpenFOAM
OpenFOAM documentation
OpenFOAM services
OpenFOAM repositories
OpenFOAM compilation guide
OpenFOAM bugs and feature requests