オープンCAEWiki OpenCAE Wiki

「OpenFOAM v2206 リリースノート」の版間の差分

OpenFOAM v2206 リリースノート (ソースを閲覧)

2022年7月2日 (土) 10:38時点における版

84,663 バイト追加 、 2022年7月2日 (土) 10:38
編集の要約なし
(ページの作成:「= ESI OpenCFD Release OpenFOAM® v2206 = OpenCFDは、2022年6月にOpenFOAM® v2206をリリースすることをお知らせします。このリリースでは、コードの多くの領域でOpenFOAM-v2112の機能を拡張しています。新機能は、OpenCFDのお客様がスポンサーとなった開発、内部資金による開発、OpenFOAMコミュニティからの機能および変更の統合を表しています。 OpenFOAMは、OpenCFDによ…」)
 
 
(同じ利用者による、間の4版が非表示)
21行目: 21行目:
= Upgrading =
= Upgrading =


=== v2206 User Upgrade Guide ===
== v2206 ユーザーアップグレードガイド ==


== Input Dictionaries ==
=== 入力ディクショナリー ===
The dictionary inputs for coordinate systems and planes now support a simpler syntax. The changes are subtle but should feel more natural to write.
座標系と平面の辞書入力が、よりシンプルな構文でサポートされるようになりました。この変更は微妙なものですが、より自然に書けるようになるはずです。


=== Coordinate Systems ===
==== 座標系 ====
The <code>transform</code> or <code>coordinateSystem</code> entries now accept an inline specification of the rotation type:
transform と coordinateSystem の項目で、回転タイプのインライン指定ができるようになりました。
  <code>transform
  <code>transform
  {
  {
35行目: 35行目:
     angle  45;
     angle  45;
  }</code>
  }</code>
As well as the longer form:
長編と同様に。
  <code>transform
  <code>transform
  {
  {
46行目: 46行目:
     }
     }
  }</code>
  }</code>
Using <code>coordinateRotation</code> was previously silently aliased to the <code>rotation</code> sub-dictionary but is now deprecated verbosely. Similarly, the older long names <code>axesRotation</code>, <code>EulerRotation</code> and <code>STARCDRotation</code> are now reported as aliases for the corresponding short names <code>axes</code>, <code>euler</code> and <code>starcd</code>, respectively.
coordinateRotationの使用は、以前はrotationサブディクショナリへのサイレント・エイリアスでしたが、現在は冗長に非推奨となりました。同様に、古い長い名前axesRotation、EulerRotation、STARCDRotationは、それぞれ対応する短い名前axes、euler、starcdのエイリアスとして報告されるようになりました。


For translation only, can either use an explicit ''none'' rotation:
移動のみの場合、明示的な回転なしを使用することも可能です。
  <code>transform
  <code>transform
  {
  {
54行目: 54行目:
     rotation none;
     rotation none;
  }</code>
  }</code>
or the implicit <code>axes</code> specification with identity axes:
または、同一軸を持つ暗黙の軸の指定。
  <code>transform
  <code>transform
  {
  {
62行目: 62行目:
  }</code>
  }</code>


=== Plane ===
==== プレーン ====
Since a plane is very frequently (almost invariably) specified by reference point and its normal, the <code>planeType</code> dictionary entry and any corresponding sub-dictionary have become fully optional. The default assumes a point/normal specification. For example, a sampled cutting plane:
平面は、参照点とその法線によって指定されることが非常に多いため（ほとんど必ず）、planeType辞書項目とそれに対応するサブ辞書は完全にオプションになりました。デフォルトでは、点/法線の指定が想定されています。たとえば、サンプリングされた切断面です。
  <code>slice
  <code>slice
  {
  {
70行目: 70行目:
     normal  (0 0 1);
     normal  (0 0 1);
  }</code>
  }</code>
instead of the much more verbose version:
の代わりに、より冗長なバージョンを使用します。
  <code>slice
  <code>slice
  {
  {
82行目: 82行目:
  }</code>
  }</code>


=== Cylinder topo sources ===
==== シリンダートポソース ====


* The <code>cylinderToCell</code>, <code>cylinderToFace</code> and <code>cylinderToPoint</code> topoSet sources have been updated to accept <code>point1</code> and <code>point2</code> as the preferred names for the cylinder end points, which improves input consistency with the searchable cylinder specification.
* cylinderToCell、cylinderToFace、cylinderToPoint topoSetソースが更新され、シリンダー端点の好ましい名前としてpoint1およびpoint2を受け入れるようになり、検索可能なシリンダー仕様との入力の整合性が改善されました。


=== Sampled sets ===
==== サンプルセット ====
The updates in coordSetWriter will largely be transparent to the end-user except that in some cases the output filenames for ''raw'' format will be slightly different. The <code>sets</code> input can now be specified as a ''dictionary'' entry (similar to sampled-surface), which permits use of <code>changeDictionary</code> to modify content.
coordSetWriter の更新は、raw フォーマットの出力ファイル名が若干異なることを除けば、エンドユーザーにはほとんど透過的です。セット入力は、辞書エントリとして指定できるようになりました（sampled-surfaceと同様）ので、changeDictionaryを使用してコンテンツを変更することができます。


The function properties associated with sample sets are now qualified by the name of the respective subset. The unqualified property names now correspond to ensemble values (of all the subsets), whereas in previous versions this was broken (it would only return the value from the last subset). This means that if the existing workflow only had a single subset the net change will be non-breaking. It is, however, advisable to use the more precise specification to future-proof your workflow. For example,
サンプルセットに関連付けられた関数プロパティは、それぞれのサブセット名で修飾されるようになりました。修飾されていないプロパティ名は、以前のバージョンでは壊れていた（最後のサブセットからの値のみを返していた）アンサンブル値（すべてのサブセットの）に対応するようになりました。これは、既存のワークフローが単一のサブセットしか持っていない場合、正味の変更はないことを意味します。しかし、より正確な仕様を使用することで、ワークフローの将来性を確保することが望ましい。たとえば、以下のようになる。
   
   
  <code>sample1
  <code>sample1
113行目: 113行目:
  }</code>
  }</code>


* sampled sets also have an additional special-purpose <code>probes</code> setFormat that collects all of the specified sampled location points into a single aggregate ensemble output with a raw probed format.  In some cases it can be more convenient to specify probe locations as multiple sets of arrays/lines instead of as a large number of individual points.
* サンプルセットには、指定されたすべてのサンプルロケーションのポイントを、生のプローブフォーマットで単一の集合アンサンブル出力に収集する特別な目的のプローブセットフォーマットも追加されています。場合によっては、プローブ位置を多数の個別点としてではなく、複数のアレイ/ラインのセットとして指定する方が便利なことがあります。


== v2206 デベロッパーアップグレードガイド ==


== Pre-processing ==
=== 新しいソルバーリンクの要件 ===
多相及び熱連成ソルバーのリストラクチャリングの副作用として、新しいサーモツールライブラリが導入されました。このライブラリには、現在、様々な派生境界条件が含まれていますが、将来的には拡張されることが期待されています。


独自のソルバーで境界条件を利用できるようにするには、compressibleTurbulenceModelsライブラリが現在リンクされている場所（それぞれのMake/optionsファイル内）にthermoToolsライブラリをインクルードする必要があります。ほとんどの場合、EXE_INC エントリを調整する必要はなく、EXE_LIBS エントリを調整するだけで十分でしょう。例えば


* 旧Make/options
<syntaxhighlight lang="c++">
EXE_LIBS = ... \
    ...
    -lcompressibleTurbulenceModels \
    -lcompressibleTransportModels \
    ...
</syntaxhighlight>


== Numerics ==
* 新Make/options
<syntaxhighlight lang="c++">
EXE_LIBS = ... \
    ...
    -lcompressibleTurbulenceModels \
    -lthermoTools \
    -lcompressibleTransportModels \
    ...
</syntaxhighlight>


* 古い/新しいOpenFOAMのバージョン用にコンパイルする特別な場合、ライブラリリンクは以下のように分離することができます。
<syntaxhighlight lang="c++">
#if (OPENFOAM >= 2206)
LIB_THERMO_TOOLS := -lthermoTools
#else
LIB_THERMO_TOOLS :=
#endif


EXE_LIBS = ... \
    ...
    -lcompressibleTurbulenceModels \
    $(LIB_THERMO_TOOLS) \
    -lcompressibleTransportModels \
    ...
</syntaxhighlight>


== Solvers and physical models ==
=== 非推奨と削除 ===


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


* OS システムメソッド domainName と完全修飾版 hostName は、現在では非推奨です。これらの関数は OpenFOAM のコードベースでは未使用で、次のような欠陥があります。
** POSIX 版では、非推奨の gethostbyname() 関数を使用します。
** Windows版では全く動作しない


== Boundary conditions ==
==== 削除されたメソッド ====


* 未使用の IOobject::isHeaderClassName(const word&) メソッドを削除しました。コンパイル時の診断をより良くするため，代わりにテンプレートで型付けされたバージョンを使用することが望ましい/推奨される．必要であれば、文字列ベースのチェックもまだ可能です。


<code>(io.headerClassName() == "foo")  //<- OLD: io.isHeaderClassName("foo")</code>


== Post-processing ==
* 場合によっては、新しい IOobject::hasHeaderClass() メソッドは、 (!headerClassName().empty()) と等価で、読み込みが成功したかどうかを確認するのに便利なテストを提供することができます。
* IOobject::isHeaderClass() メソッドが IOobject::isHeaderClassName() から短縮されました。


* 非推奨の fvMeshSubset::setLargeCellSubset() メソッドを削除しました。これはJUL-2018以降、コンパイル時に非推奨とされていましたが、現在は削除されています。


==== メソッドの名称変更 ====


== Parallel ==
* lessEqOp と greaterEqOp のオペ名は、Eq が比較タイプではなく、割り当てを意味する他の形式（例えば plusEqOp）があるため、意味のあいまいさを解消するために変更されました。


{| class="wikitable"
|+
!old op name
!new op name
!meaning     
|-
|lessEqOp
|lessEqualOp
|<code><=</code>
|-
|greaterEqOp
|greaterEqualOp
|<code>>=</code>
|}


* この名称変更は、より目的を反映し、また、std::less_equal や std::greater_equal などの C++ <関数> 名称とより整合性を持たせています。


== Usability ==
=== 行動の変化 ===
 
* List、DynamicList、DynamicField などの整理の一環として、SortableList からの構築と SortableList からの移動の割り当てが削除されました。両方とも使われることはなく、事前に shrink() を適用して、必要であれば通常のリストのように扱うことができます。一般的に、SortList は多くの場合、より軽いソートコンテナを提供します。
* これまで self への参照を返していた append() メソッドは void になり、サブクラスの派生がより簡単に、より一貫性をもって行えるようになりました。なぜなら、連鎖的な追加処理は実際にはどこにも発生せず、派生クラスで偶発的にスライスが発生することを恐れて依存しないためです。
 
=== 所在地変更 ===
 
==== 座標系 ====
座標系と座標回転を定義するクラスは、src/meshTools から src/OpenFOAM に移行しました。これにより、surfMesh のコアクラスでそれらを使用することができます。この移行は、リンクの要件には影響しません。
 
==== Foam::sort, Foam::sortedOrder ====
同様に、ポインタリスト版の Foam::sort は PtrListOps.H から UPtrList.H に移行されました。
 
PtrListOps::less と PtrListOps::greater ラッパーはそれぞれ UPtrList::less と UPtrList::greater として見つけられるようになり、それは UList::less と UList::greater ペンダントに揃いました。
 
==== fvMeshSubset (+ fvMeshSubsetter) ====
fvMeshSubset クラスは、コア機能（fvMeshSubset クラス）と拡張機能（新しい fvMeshSubsetter クラス）にリファクタリングされました。
 
* ダイナミックメッシュのトポロジー変更を使用しない、fvMeshSubsetでのサブセットの直接処理によるコアマッピング（補間）機能。fvMeshSubset は、src/dynamicMesh の代わりに src/finiteVolume の下に配置されるようになりました。
* 特殊な2段階のサブセットは、dynamicMeshのトポロジー変更を使用するfvMeshSubsetterクラスに追いやられています。このクラスは src/dynamicMesh の下にあります。
 
この定義の分割は、コア（fvMeshSubset）がすでにsrc/finiteVolumeにあり、新しい特別な2ステップのサブセットはほとんど使用されない（現在はsubsetMeshアプリケーション自体によってのみ使用される）ため、ユーザーのコンパイルに変更を加える必要はないと予想されています。
 
fvMeshSubsetに、ゼロサイズ（ダミー）のサブメッシュのための最適化されたコンストラクトとリセットが追加されました。
 
=== コンテナの変更 ===
 
===== CircularBuffer =====
新しい CircularBuffer コンテナは、リンクリストアプローチに関連する alloc/free オーバーヘッドなしで、循環バッファ (FIFO, LIFO またはその中間) としてオブジェクトの単純なリストを処理します。
 
===== コンパクトリストリスト =====
CompactListList は、1 つのテンプレート パラメータのみを必要とするように変更されました。古いセカンダリContainerテンプレート・パラメータは削除されました。作成には、pack() ファクトリーメソッドを使用する必要があります。unpack() メソッドは、古い operator() アクセスに取って代わり、改善されました。おなじみの values()、data()、cdata() メソッドで、コンパクトな内部リスト・データへの読み取りアクセスが可能になりました。
 
===== IndirectList =====
IndirectList クラスが拡張され、いくつかのファクトリーメソッドが追加されました。
 
* uniq() は、重複するエントリをフィルタリングした IndirectList を作成します。
* subset() は、条件述語を満たすポジションを持つ IndirectList を作成します。
* subset_if() は、与えられた述語を満たす値でIndirectListを作成します。
 
間接的なサブセットは、元のデータのサブセット・コピーを作成するよりも安価になり、また、修正も可能になることに注意したい。
 
=== 文字列処理・述語 ===
 
* wordReが少しスリム化されました。正規表現はポインタによってカプセル化されるようになり、リテラル文字列を表現する際のサイズとオーバーヘッドが削減されました。
* 統合された wordRes allow/deny フィルタリング、また wordRes::filter ファンクタとしてラップされています。これにより、stringListOpsにおけるwordRes::filterの直接サポートと、レジストリにクラウドフィールドをロードする際のallow/denyが可能になります。
* noOpが定義されていたのと似ているが、完全な転送を行うidentityOpを追加した。その動作はC++20のstd::identityの定義とほぼ同等である。
* scalarRangeのテストをミラーする単純なlabelRange述語gt0, ge0, lt0, le0を追加しました。これらは、中間体を作らず（ステートレス）、constexprとして使えるので、labelMinMax::ge(0)などを使うよりも低いオーバーヘッドを持っています。
 
=== ソートイテレーション ===
 
* HashTable, HashSet, Map, IOobjectList, objectRegistry クラスに asorted()` メソッドが追加されました。  sorted() および csorted() メソッドは、sortedToc() を作成する余分なステップを省き、一貫した順序でハッシュ化されたコンテンツを走査するための、より無駄がなく便利な手段を提供します。sorted() メソッドは、各エントリへのポインタのリストをソートすることで動作します。また、エントリの値にアクセスする際に二次的なチェックを行うこともありません。
** これを書けるようになりました。
 
<code>HashTable<someType> table = ...;
for (const auto& iter : table.sorted())
{
    Info<< iter.key() << " => " << iter.val() << nl;
}</code>
 
* を、以前は
<syntaxhighlight lang="c++">
HashTable<someType> table = ...;
 
for (const word& key : table.sortedToc())  //<- Additional overhead for full copy of keys!
{
    // Note: incurs a secondary lookup!
    Info<< key << " => " << table[key] << nl;
}
</syntaxhighlight>注：HashTable の反復処理 key() の項目は、immutable であるため const として宣言されるようになりました。
 
=== フィールドハンドリング ===
 
==== ベクトル法 ====
 
* vector::normalise メソッドは、ROOTVSMALL 以外の公差が望ましい場合のために、オプションの公差をサポートするようになりました。
* 新しい vector::removeCollinear メソッドは、共線成分を含まない法線ベクトルが頻繁に必要とされる形状を扱うときに便利です。removeCollinear メソッドは、より明確でコンパクトなコードを提供する。
<syntaxhighlight lang="c++">
vector edgeNorm = ...;
 
const vector edgeDirn = e.unitVec(points());
 
edgeNorm.removeCollinear(edgeDirn);
edgeNorm.normalise();
</syntaxhighlight>代わりに<syntaxhighlight lang="c++">
vector edgeNorm = ...;
 
const vector edgeDirn = e.unitVec(points());
 
edgeNorm -= edgeDirn*(edgeDirn & edgeNorm);
edgeNorm /= mag(edgeNorm) + ROOTVSMALL;
</syntaxhighlight>
 
==== フィールドノーマライズ ====
 
* Field コンテナ（および GeometricField などの関連クラス）には normalise() メソッドが追加されました。ほとんどのフィールドタイプでは、これは単純にno-opですが、vectorやsolveVectorのフィールドでは、これはvector::normaliseに相当しますが、各要素に適用されます。  これは、中間フィールドを作成するオーバーヘッド（または余分なコード行）なしで、ゼロ除算の保護で各要素を正規化します。
 
<code>fld.normalise();</code>
 
instead of
 
<code>fld /= mag(fld) + VSMALL;</code>
 
==== ラッピングされたIO出力クラス ====
データをコピーせずに参照で書き込むために、いくつかの派生した regIOobject ラッパーが追加されました。これらのラッパークラスは、外部コンテンツを参照するためにrefPtrを使用します。外部への読み込みは実装されていません(現在そのための要件はありません)。
{| class="wikitable"
|+
!base class
!wrapped class     
|-
|IOField
|IOFieldRef
|-
|IOList
|IOListRef   
|-
|IOmapDistributePolyMesh
|IOmapDistributePolyMeshRef
|}
使用例<syntaxhighlight lang="c++">
labelList addressing = ...;
 
io.rename("cellProcAddressing");
IOListRef<label>(io, addressing).write();
</syntaxhighlight>または<syntaxhighlight lang="c++">
primitivePatch patch = ...;
IOFieldRef<vector>(io, patch.localPoints()).write();
</syntaxhighlight>
 
=== 便利な機能 ===
 
* polyMeshのフィルタリングregionName() - staticおよびnon-staticメソッドを追加した。
** メッシュリージョンを扱う場合、defaultRegion名（例えば、"region0"）をフィルタリングしたり削除したりするのが一般的です。これをポリメッシュ自体から、あるいは静的関数として、簡単に行うことができるようになりました。単純に次のように使用します。
<syntaxhighlight lang="c++">
const word& regionDir = polyMesh::regionName(regionName);
 
// or
const word& regionDir = mesh.regionName();
 
</syntaxhighlight>の代わりに、以前の長いコードを使用します。<syntaxhighlight lang="c++">
const word& regionDir =
(
    regionName != polyMesh::defaultRegion
  ? regionName
  : word::null
);
</syntaxhighlight>以下は正しく動作します（文字列 '/' 結合演算子は、空の文字列をフィルタリングします）。<syntaxhighlight lang="c++">
(polyMesh::regionName(regionName)/polyMesh::meshSubDir)
 
(mesh.regionName()/polyMesh::meshSubDir)
</syntaxhighlight>
 
=== MPI / Pstreamの変更点 ===
 
= 前処理 =
 
== 新しいsnappyHexMeshの自動リーククロージャー ==
snappyHexMeshが拡張され、到達不可能な位置（locationsOutsideMesh）が指定された場合、オプションで自動穴塞ぎを行うようになりました。以前のバージョンのSnappyHexMeshでは、可視化のためのリークパスを書き、内部点と外部点の接続が確認されるとエラーメッセージとともにメッシング処理が中断されました。
 
穴埋めアルゴリズムは、Zouina Aktoufらによる「A 3D-Hole Closing Algorithm」に基づいており、隙間を埋めるために必要な凸包（メッシュ面で）を決定する。これらの追加された面上の任意の点は、pointZone frozenPointsに追加され、任意のsnap-to-nearest-surfaceから除外され、平滑化のみが行われます。追加された面上のレイヤーの追加には特別な処理はないことに注意してください。
 
下図は、元のジオメトリ（右図）に三角形の欠落がある場合の例です。このギャップはその後、スナップフェーズで閉じられ、スムージングされます（左の図）。 この例では、ギャップは異なるリファインメントレベルの面で閉じられているため（メッシュはサーフェスのみでリファインされているため）、スムージングは完璧ではありません。
 
=== 使用方法 ===
新機能は、snappyHexMeshDictのcastellatedMeshControlsセクションに、エントリーを追加することで有効になります。
<code>useLeakClosure true;</code>
 
* 特定されたリークパスは、postProcessing ディレクトリの leakPath Ensight ファイルに書き込まれます。
* オプションのユーザー入力、leakLevel は、表面ごと、領域ごとに、どのセル レベルでリーク検出を開始するかを指定します。これは、中間洗練レベルの間、セルの最大数を制限するためにリークパスを「早期に」閉じることを可能にしますが、ギャップをブロックするために粗い面を使用する代償として、リークパスのクローズを行います。また、メッシュがまだ粗く、内側と外側の位置がまだ同じセル内にある場合、これは偽陽性を報告する可能性があります。
 
<code>refinementSurfaces
{
    "sphere.*"
    {
        // Surface-wise min and max refinement level
        level (6 6);
        // Optional level at which to start early checking for leaks
        leakLevel 2;
    }
    ...</code>
こちらもご覧ください
 
* holeToFace faceSet source. This allows use of the algorithm on any existing mesh using topoSet. See $FOAM_ETC/caseDicts/annotated/topoSetSourcesDict.
 
チュートリアル
 
* $FOAM_TUTORIALS/mesh/snappyHexMesh/sphere_gapClosure (missing triangle in triangulated sphere)
* $FOAM_TUTORIALS/mesh/snappyHexMesh/motorBike_leakDetection (missing section of input surface)
 
ソースコード
 
* $FOAM_SRC/meshTools/topoSet/faceSources/holeToFace/holeToFace.C (hole closing algorithm)
* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBlock.C
 
== snappyHexMeshの最適化が改善されました。 ==
 
=== blockLevelのメモリ使用量 ===
バージョンv1912では、オプションの項目blockLevelによって、薄い隙間の自動閉鎖が導入されました。
<code>refinementSurfaces
{
    "gap.*"
    {
        // Surface-wise min and max refinement level
        level      (2 2);
        // From cell level 2 onwards start checking
        // for opposite surfaces
        blockLevel  2;
    }
}</code>
以前のバージョンでは、これは2つのパスで実行されました。
 
各サーフェスからメッシュを歩き、壁の距離を決定する。
 
すべてのセルについて、サーフェスの組み合わせごとに、セルがギャップの内側にあるかどうかを判断する
 
この分割は、大きなサーフェスと大きなメッシュで操作する場合、パス1からすべての情報を保存する必要があるため、メモリと性能に大きな制限があります。新しい実装では、壁の距離の歩行は、許容される最大ギャップサイズよりも多く歩いた場合に停止し、データ転送を劇的に少なくすることにつながっています。
 
=== パラレルコンシステントフェースゾーン ===
並列動作は、ランダム分解法に対する「標準」実行を比較することでストレステストされました。この結果、プロセッサパッチと一致するfaceZoneを処理しないことによる、faceZoneの割り当てアルゴリズムのわずかな違いが浮き彫りになりました。例えば、プロセッサパッチ上の顔の点の順序や方向が異なるために、顔とセルの中心を計算する際に切り捨てエラーが発生したり、セル内の顔の順序が異なるために、まだ完全に同じでない領域があるかもしれません。
 
チュートリアル
 
* $FOAM_TUTORIALS/mesh/snappyHexMesh/opposite_walls
 
ソースコード
 
* $FOAM_SRC/mesh/snappyHexMesh/meshRefinement/meshRefinementBlock.C
 
== snappyHexMeshのレイヤー追加を改善しました。 ==
レイヤーを1回のパスで追加する代わりに、snappyHexMeshは複数のパスを使用できるようになりました。これにより、メッシュを縮小する段階で、追加のレイヤーのためのスペースを作る機会が増えます。この新しい動作はsnappyHexMeshDictのlayerParametersセクションにある新しいnOuterIterキーワードで有効になります。
<code>// Outer loop iterations (each of which is up to nLayerIter). Default is 1.
nOuterIter      3;</code>
例えば、20枚のレイヤーを要求した場合、1パスあたり7枚、7枚、6枚と3パスでレイヤーが追加されます。
 
* nOuterIter エントリに大きな数を設定すると、レイヤーを 1 枚ずつ追加することができます。
* は、追加すべきセルがない場合、あるいは品質制約のために追加できない場合に、外側のループを終了する。
* 一般に、レイヤーが追加されない外側の反復がさらなる成長を引き起こすことを避けるために、段階的なレイヤー終了をオフにすることが推奨されます。
<syntaxhighlight lang="c++">
nGrow -1;
</syntaxhighlight>
 
* の場合、膨張率と最小厚さは一度だけ計算され、その後、外側の反復処理で一定に保たれます。
* レイヤーカバレッジフィールドを出力する場合。
<syntaxhighlight lang="c++">
writeFlags
(
    layerFields    // write volScalarField for layer coverage
);
</syntaxhighlight>結果のフィールドは、追加されたセルごとに追加されたセルの合計を表示します。
 
=== 層添加の効果 ===
2つの領域を持つ球のジオメトリを使用し、2つのパッチ（sphere_patch0, sphere_patch1）を生成することで、レイヤー追加プロセスに複数のパスを採用する効果を以下に強調します。nOuterIterなしで実行、つまり、すべてのレイヤーを一度に追加すると、次のようになります。
 
nOuterIter 3で、つまりレイヤーを1つずつ追加していく。
 
この場合、複数回のパスを使用することで、カバー率が若干向上する効果があります。
{| class="wikitable"
|+
!nOuterIter
!patch
!nLayers
|-
|1
|sphere_patch0
|2.38
|-
|
|sphere_patch1
|2.7
|-
|３
|sphere_patch0
|2.62
|-
|
|sphere_patch1
|2.91
|}
チュートリアル
 
* $FOAM_TUTORIALS/mesh/snappyHexMesh/addLayersToFaceZone
 
ソースコード
 
* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver/snappyLayerDriver.C
 
=== New holeToFace topoSet source ===
topoSetなどで使用できるholeToFace面ソースは、2つのメッシュ領域間のギャップを閉じるための最小限の面のセットを生成します。これは、Zouina Aktoufらによる "A 3D-Hole Closing Algorithm "で説明されているアルゴリズムを使用する。 topoSet辞書での典型的な使用法は以下の通りである。
<code>source  holeToFace;
points
(
    ((0.2 0.2 -10) (1.3 0.4 -0.1))  // points for zone 0
    ((10 10 10))                    // points for zone 1
);</code>
アルゴリズム
 
* は，すべての境界面およびオプションの faceSet に含まれる面をマークします．
* ゾーン間に接続があるかどうかを判断する（指定されたポイントで示される）。
* 穴を塞ぐ/ゾーンを切り離す内部/結合面の最小セットを決定する
 
このアルゴリズムは、SnappyHexMeshの新しい自動ホールクロージャーで使用されています。
 
チュートリアル
 
* $FOAM_TUTORIALS/mesh/snappyHexMesh/gap_detection (gap detection)
 
ソースコード
 
* $FOAM_SRC/meshTools/topoSet/faceSources/holeToFace
 
== createPatchユーティリティの改良 ==
createPatchが拡張され、フィールドの処理と、異なるリージョン間および単一リージョン上でのマッチング面の自動再パッチングが追加されました。
 
=== フィールドの取り扱い ===
createBafflesと同様に、新しく追加されたパッチに境界条件を指定することができるようになりました。サイクリックパッチなどの制約型パッチでは、自動的に関連する制約境界条件が使用されるため、一般にこれは必要ありません。境界条件の追加は、patchFields サブディクショナリが存在することで有効になります。
<code>// Dictionary to construct new patch from
patchInfo
{
    type        patch;
    //- Optional override of added patchfields. If not specified
    //  any added patchfields are of type calculated.
    patchFields
    {
        T
        {
            type            uniformFixedValue;
            uniformValue    300;
        }
    }
}</code>
パッチフィールドは、パッチがまだ0面であるときに作成されることに注意してください。つまり、辞書で完全に指定されていないパッチフィールドは、正しく初期化されません。
 
=== 自動パッチング ===
再パッチする面の選択が拡張され、重なりの自動計算が可能になりました。
<code>// How to select the faces:
//  - set : specify faceSet in 'set'
//  - patches : specify names in 'patches'
//  - autoPatch : attempts automatic patching of the specified
//                candidates in 'patches'.
//      - single region : match in the region itself
//      - multi regions : match in between regions only
constructFrom autoPatch;</code>
autoPatchで。
 
* リージョンはコマンドラインオプションとして提供されます。例えば、autoPatch -allRegions (constant/regionPropertiesファイルを読み込む)
* 各リージョンはそれ自身の system/<region>/createPatchDict を提供しなければなりませんが、非常に多くの場合、これらは同じファイルへのリンクである可能性があります。
* 複数の領域に適用した場合、自動パッチは異なる領域間のパッチ結合に限定される。
* は、1セットの面を複数のパッチにすることができるため、nameエントリーを接頭辞として使用するようになりました。実際のパッチ名は<name><region1>_to_<region2>となります。
* 名前項目を省いて接頭辞を取り除くことができる（辞書は空白語をサポートしない）。
* 顔の自動マッチングには、AMIフレームワークを採用しています。faceAreaWeightAMIメソッド（patchInfo辞書で上書き可能）を用いて、他のパッチと50%以上重なっている顔を検出し、自動的にパッチを生成して顔を移動させるのである。また、対応するリージョンにドナーの顔がある場合は、その面も移動します。これは、ある顔が複数のパッチのドナーであり、最初の AMI が「勝つ」場合、問題を引き起こす可能性があります。
* faceAreaWeightAMI および faceAreaWeightAMI2D メソッドが拡張され、最大マッチ距離 (および面と法線のアライメント) を指定できるようになりました。デフォルトのメソッドは、どの面が一致するかについて非常に緩やかであるため、近く異なる一致がある場合にこれらの設定が必要になることがあります。既存の AMIMethods はどれも不明瞭なパッチを扱わないことに注意してください。
* faceAreaWeightAMI と faceAreaWeightAMI2D の重みをチェックするために checkMesh ユーティリティが拡張され、-allGeometry オプションでマップされた境界の重みも出力されるようになりました、例えば次のコマンドは postProcessing ディレクトリに重みを書き込みます。
 
<code>checkMesh -allRegions -allGeometry</code>
 
* の場合、ソースパッチはパッチグループとして提供することもできます。これは、複数のリージョンがある場合に便利で、同じ createPatchDict をすべてのリージョンに適用することができます。
* 自動パッチは、CHTケースのセットアップをより簡単にすることができます。mappedPatchやmappedWallタイプのパッチは、どちらもAMIを使用することができるので、面の再パッチングに対して一貫した動作をすることができます。
 
<code>// Dictionary to construct new patch from
patchInfo
{
    type        mappedPatch;
    sampleMode  nearestPatchFaceAMI;
    AMIMethod  faceAreaWeightAMI2D;
    patchFields
    {
        T
        {
            type            compressible::turbulentTemperatureRadCoupledMixed;
            Tnbr            T;
            kappaMethod    solidThermo;
            value          uniform 300;
        }
    }
}</code>
なお、上記の patchField の指定は、前述したパッチのゼロフェースのために、実際には正しく動作しませんので、ご注意ください。
 
シンプルなチュートリアルは、下部に1つのソリッド領域（水色）、中央に2つの小さなソリッド領域（赤、オレンジ）、上部に流体領域（青）で組み立てられています。
 
温度分布（下の領域は加熱、上の領域は左から右への流れがある）
 
 
チュートリアル
 
* $FOAM_TUTORIALS/mesh/createPatch/multiRegionHeater_autoPatch (automatic patching of a CHT case)
 
ソースコード
 
* $FOAM_UTILITIES/mesh/manipulation/createPatch
* $FOAM_UTILITIES/mesh/manipulation/checkMesh (writing mapped weights)
 
== Improved triSurfaceMesh: detect inconsistent orientation ==
例えば、triSurfaceMeshをsearchableSurfaceToFaceを持つtpoSetで使用する場合、コードは、例えばtpoSetDictで、すべてのエッジが2つの面によって使用されているかをチェックすることによって、表面が閉じているかどうかを識別することになります。
<code>actions
(
    {
        name            collectorSet;
        type            faceSet;
        action          new;
        source          searchableSurfaceToFace;
        surfaceType    triSurfaceMesh;
        surfaceName    mySurface.obj;
    }
);</code>
2つの面の向きが一致しているかどうかのチェックが追加されました。チェックに失敗した場合は、警告メッセージが表示されます。
<code>--> FOAM Warning :
    From bool Foam::triSurfaceMesh::isSurfaceClosed() const
    in file searchableSurfaces/triSurfaceMesh/triSurfaceMesh.C at line 255
    Surface mySurface.obj is closed but has inconsistent face orientation
    at edge (0.97205 -0.46948 0.64841)(0.97167 -0.4683 0.64911)
    This means it probably cannot be used for inside/outside queries. Suppressing further messages.</code>
なお、同様のチェックは、surfaceCheckアプリケーションにもあります。
<code>Number of zones (connected area with consistent normal) : 2
More than one normal orientation.</code>
このトポロジカルエラーは、surfaceOrientアプリケーションを使用して修正することができます。
 
ソースコード
 
* $FOAM_SRC/meshTools/searchableSurfaces/triSurfaceMesh/triSurfaceMesh.C
 
== プリプロセッシングユーティリティsetTurbulenceFieldsの追加 ==
Lardeau and Manceau (2014)が指摘するように。
 
''多くのRANSモデルを使用する際に直面する主要な問題の1つは、計算の初期段階における遅い収束または非収束です。これは特に低レベリングモデルの場合、低レイノルズ減衰定式化から継承された分岐特性によるものとされています。Rumseyら(2006)は、初期条件と流入条件に依存して、別の収束解を得ることができることを示した。''
 
この問題を解決するために、ManceauのRANS計算のための2ステップ自動初期化手順に基づいて、setTurbulenceFieldsと呼ばれる新しい前処理ユーティリティが実装されています。
 
setTurbulenceFieldsは、入力として流れの基準速度のみを必要とします。オプションでεなどの乱流場や速度場を初期化することができ、最初の O(10) 時間ステップでの収束と結果の忠実度を向上させるのに役立ちます。
 
setTurbulenceFieldsによる初期化の効果は、NASAの2D Bump-in-channelケースで、新しい楕円混合レイノルズ応力乱流を採用した場合に見ることができます。
 
 
ソースコード
 
* $FOAM_UTILITIES/preProcessing/setTurbulenceFields/setTurbulenceFields.C
 
チュートリアル
 
* $FOAM_TUTORIALS/verificationAndValidation/turbulenceModels/planeChannel
 
マージ要求
 
* MR!545
 
参考文献
 
* Manceau, R. (n.d.). A two-step automatic initialization procedure for RANS computations. (Unpublished).
 
アトリビュート
 
* OpenCFD would like to acknowledge and thank Prof. Rémi Manceau for providing the governing equations for setTurbulenceFields, elaborate suggestions and critical recommendations.
 
= 数値 =
 
== コミュニティへの貢献 k-omega SST モデルの新しいアドジョイント ==
Spalart-Allmaras モデルの既存のアドジョイントを補完するために、k-ω SST 乱流モデルの新しいアドジョイントが利用可能になりました。
乱流の凍結」仮定、つまり最適化を通じて形状が変化しても乱流粘性場が変化しないと仮定すると、感度微分の計算が誤って行われることがあります。一例として、「凍結乱流」仮定と完全微分k-ω SSTモデルを使用してアハメド本体の表面で計算された抗力感度マップを以下に示しますが、乱流を微分しない場合に感度マップの符号が変化する領域があることが分かります。
 
これをさらに進めて、「凍結乱流」（FT）と「微分化乱流」（DT）で最適化を行うと、この場合のk-ω SSTモデルを微分化する必要性が浮き彫りになります。
 
DT法では20回の最適化で抗力が6%以上減少しましたが、FT仮定に基づく最適化では4回目で発散してしまいました。
 
この研究は，Kavvadiasらの研究に基づき，多くの微分演算子の離散化と，原始モデルで採用されている壁関数のアドジョイントの定式化を変更したものである．
 
ソースコード
 
* $FOAM_SRC/optimisation/adjointOptimisation/adjoint/turbulenceModels/incompressibleAdjoint/adjointRAS/adjointkOmegaSST
 
チュートリアル
 
* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012/kOmegaSST/lift
* $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/turbulent/kOmegaSST/opt
 
参考文献
 
* Kavvadias, I., Papoutsis-Kiachagias, E., Dimitrakopoulos, G., & Giannakoglou, K. (2014). The continuous adjoint approach to the k– SST turbulence model with applications in shape optimization. Engineering Optimization, 47(11), 1523-1542. <nowiki>https://doi.org/10.1080/0305215X.2014.979816</nowiki>
 
アトリビュート
 
* 参考文献にあるように、最初の実装は、Ioannis Kavvadias博士がPCOpt/NTUAの博士課程で行ったものです。
* 現在のバージョンはPCOpt/NTUAとFOSS GPによって刷新され、OpenCFDとのコラボレーションによって統合されたものです。
 
== コミュニティへの貢献：アドジョイント最適化の更新 ==
アドジョイント最適化ライブラリが更新され、3つの主要な側面に対処しています。
 
* ''既に実行された最適化の（部分的な）再実行がより簡単に、より正確になりました''
** Adjointソルバーは、I/Oによる精度の潜在的な損失を避けるために、均一なフォルダーの下でそれらの感度導関数を書き込み/読み込みます。
** 各最適化サイクルのVolumetric B-Splinesコントロールポイントはuniformの下で書き込まれ、さらにバイナリI/Oをサポートするようになりました。その結果、constant/dynamicMeshDictのcontrolPointsDefinitionは、継続を実行するためにfromFileに変更する必要がなくなり、ミスセットアップの原因となり得るものを取り除くことができました。
** アドジョイントグリッド変位フィールド(ma)は、アドジョイントソルバーが複数存在する場合、その名前が付加されるようになりました。この変更前は、最後のアドジョイントソルバーの ma フィールドのみがファイルに書き込まれていたため、この変更により継続が容易になりました。fvSchemes と fvSolution への変更は必要ありません。
* ''ターンアラウンドタイムの短縮''
** 随伴方程式の解のターンアラウンドタイムを短縮するための多くの変更（詳細はbac1d8baを参照してください）。簡単に言うと、高価だが一定の量のキャッシュと、コーディングの欠点の除去です。例えば、バイクのチュートリアルのアドジョイントソルバーの所要時間は約9.5%短縮されましたが、後者は多くの出口境界があるケースでより顕著になる可能性があります。
* ''ピーク時のメモリ消費量の削減''
** FI または E-SI アプローチを使用した場合，アドジョイントコードのメモリ消費量のピークは感度微分の計算中に発生します．これは，グリッド感度の空間勾配の乗数を計算するために，多数の volTensorField を操作する必要があるためです．コードのこの部分は、このピークメモリ消費量を減らすために書き直されました。
 
Attribution
 
* The adjoint library was updated/reviewed by PCOpt/NTUA, FOSS GP and OpenCFD
 
Source code
 
* $FOAM_SRC/optimisation/adjointOptimisation
 
== 改良型QR分解アルゴリズム ==
QR分解アルゴリズムは、オープンソースのTemplate Numerical Toolkit（TNT）のアルゴリズムを利用して、リファクタリング、簡略化、改良が行われました。
 
改良型 QRMatrix ソルバは，与えられたスカラー/複素矩形/正方行列 A に対して，以下のように QR 分解を行う．
<code>A = Q R</code>
または列のピボット化を伴う QR 分解の場合。
<code>A P = Q R</code>
どこ
 
* Q : ユニタリー/直交行列
* R : 上三角行列
* P: 順列行列
 
QR分解アルゴリズムでは、列のピボット化を伴う場合と伴わない場合のフルサイズおよびエコノミーサイズのQR分解を計算することができます。出力形式は、Q-matrix、R-matrixのいずれか、または両方を選択することができます。
 
ソースコード
 
* $FOAM_SRC/OpenFOAM/matrices/QRMatrix
 
チュートリアル
 
* $FOAM_TUTORIALS/../applications/test/matrices/QRMatrix/Test-QRMatrix.C
 
マージ要求
 
* MR!540
 
参考文献
 
* Pozo, R. (1997). Template Numerical Toolkit for linear algebra: High performance programming with C++ and the Standard Template Library. The International Journal of Supercomputer Applications and High Performance Computing, 11(3), 251-263. DOI:10.1177/109434209701100307
 
== 改良型半陰解法ソース ==
SemiImplicitSourceは、新しいexprField仕様をサポートするようになり、ソースの位置や強度を定義する際に柔軟性を持たせることができるようになりました。
<code>{
    type            scalarSemiImplicitSource;
    volumeMode      specific;
    selectionMode  all;
    sources
    {
        tracer0
        {
            explicit
            {
                type      exprField;
                functions
                {
                    square
                    {
                        type square;
                        scale 0.0025;
                        level 0.0025;
                        frequency 10;
                    }
                }
                expression
                #{
                    (hypot(pos().x() + 0.025, pos().y()) < 0.01)
                  ? fn:square(time())
                  : 0
                #};
            }
        }
    }
}</code>
SemiImplicitSource は、入力エントリを旧来の injectionRateSuSp 構文よりも直感的に理解できるように、明示的または暗黙的な寄与を持つ新しいソース辞書エントリを使用することに注意してください。
 
チュートリアル
 
* $FOAM_TUTORIALS/compressible/rhoSimpleFoam/squareBend
 
ソースコード
 
* $FOAM_SRC/fvOptions/sources/general/semiImplicitSource
 
= ソルバーと物理モデル =
 
=== 新ソリッドボディメッシュモーション ===
v2012 では、system/fvSchemes の新しいジオメトリ エントリを使用したジオメトリ計算のランタイム選択メカニズムが追加され ました。このリリースでは、回転 AMI/ACMI ケースなどの一部の移動メッシュ ケースのコストを削減することを目的とした、新しい solidBody ジオメトリ スキームが追加されました。
<code>geometry
{
    type    solidBody;
    // Optional
    partialUpdate yes; // default = yes
    cacheMotion yes; // default = yes
}</code>
新しい制度は、次のような前提で運用されています。
 
* ソリッドボディ（点数、面領域、セル体積が同じ）として表現できるものであり
* トポロジーの更新はありません。
 
そのため、solidBody スキームでは、完全なメッシュクリアを行う代わりに、移動するポイントに接続されたジオメトリのみを選択的に更新します。
 
性能向上（時間）はケースバイケースで、例えば、全セル数に対して移動セルの割合が少ないほど、メッシュ更新フェーズの利点は大きくなります。
 
追加エントリーの制御です。
 
* partialUpdate : falseに設定すると、メッシュの変更時に完全なメッシュのクリアアウトを実行します。
* cacheMotion : trueに設定すると、すべての時間ステップで移動する点、面、セルのアドレスをキャッシュする。
 
==== 後方互換性 ====
基本オプションはデフォルトであり、ジオメトリサブディクショナリが提供されない場合に適用される。
<code>geometry
{
    type basic;
}</code>
このオプションを選択すると、v2112（およびそれ以前のバージョン）の動作が復元されます。
 
チュートリアル
 
* $FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/propeller
 
ソースコード
 
* $FOAM_SRC/finiteVolume/fvMesh/fvGeometryScheme/solidBody
 
=== 新しいレイノルズ応力乱流モデル。EBRSM ===
新しいElliptic Blending Reynolds Stress Model（EBRSM）は、非圧縮性および圧縮性の流れに対する（Manceau, 2015）の研究をベースにしています。
 
このモデルは、標準的な弱不均一レイノルズ応力モデルを壁面近傍まで拡張し、レイノルズ応力と乱流量について一般に優れた流れ予測を提供します。
 
この新しいモデルは、様々な正則ケースで検証されている。ReTau=180 の平滑壁平面チャネル流れの DNS 研究に基づく検証ケースの結果を以下に示す(Moser et al., 1999)．
 
ソースコード
 
* $FOAM_SRC/TurbulenceModels/turbulenceModels/RAS/EBRSM/EBRSM.H
 
チュートリアル
 
* $FOAM_TUTORIALS/verificationAndValidation/turbulenceModels/planeChannel
 
マージ要求
 
* MR!544
 
参考文献
 
* Manceau, R. (2015). Recent progress in the development of the elliptic blending Reynolds-stress model. International Journal of Heat and Fluid Flow, 51, 195-220. DOI:10.1016/j.ijheatfluidflow.2014.09.002
 
アトリビュート
 
* OpenCFD は、Rémi Manceau 教授、Michael Karl Stoellinger 博士、Ardalan Javadi 博士の貢献、精巧な提案と支援、および批判的な勧告に感謝し、謝意を表したいと思います。
 
=== 壁面機能の向上 ===
壁関数とそのコードのドキュメントを改善しました。
 
従来は壁面機能
 
* epsilon、k、omegaなどの壁関数で必要とされる様々な共通の壁関数係数を取得するために、nutWallFunctionタイプのリファレンスが必要でした。
* Cmu, kappa, Eは、係数値の一貫性を確保するため、指定されたnutWallFunctionから取得した。
 
これらの選択は、特にナットベースの壁関数が期待されない場合、やや不可解な鋳造エラーが発生し、一部のセットアップでは過度に制限されるなど、しばしば混乱を招きました。例えば、壁際領域でのεの変動が通常非常に急で非単調である場合、専門ユーザーはε固有の係数を使用したいと思うかもしれません。
 
ソースコード
 
* $FOAM_SRC/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions
* $FOAM_SRC/TurbulenceModels/compressible/turbulentFluidThermoModels/derivedFvPatchFields/wallFunctions
* $FOAM_SRC/TurbulenceModels/turbulenceModels/derivedFvPatchFields/wallFunctions
* $FOAM_SRC/TurbulenceModels/incompressible/turbulentTransportModels/derivedFvPatchFields/wallFunctions
* $FOAM_SRC/regionModels/surfaceFilmModels/derivedFvPatchFields/wallFunctions
 
マージ要求
 
* MR!486
 
=== CHTソルバーのドライランを新たにサポート ===
chtMultiRegionFoam ソルバー群は、-dry-run コマンドラインオプションをサポートし、ケース設定に関するクイックフィードバックを提供するように拡張されました。
<code>chtMultiRegionFoam -dry-run</code>
これにより、ダミーメッシュが作成され、初期フィールドが読み込まれます。典型的な出力です。
<code>Operating in 'dry-run' mode: case will run for 1 time step.  All checks assumed OK on a clean exit
Creating simplified mesh using "openfoam/tutorials/heatTransfer/chtMultiRegionFoam/multiRegionHeater/constant/bottomWater/polyMesh"
Mesh bounds: (-0.1 -0.04 -0.05) (0.1 1.1564823e-18 0.05)
Creating dummy zone heater
Creating dummy zone leftSolid
Creating dummy zone rightSolid
Creating dummy zone topAir
Creating dummy zone bottomWater</code>
残念ながら、この処理は、明示的に結合されたパッチ（mapped, mappedWall）のマッチングの後半で失敗するため、完全な反復処理を終えることができません。
 
ソースコード
 
* $FOAM_SOLVERS/applications/solvers/heatTransfer/chtMultiRegionFoam
 
=== solidFoamの新しいタイムステップ制御 ===
solidFoamソルバーが拡張され、タイムステップの制御が可能になりました。これは、system/controlDictの設定により有効になります。
<code>//- Is time step adjustable
adjustTimeStep  yes;
//- Maximum diffusion number (default is 10)
maxDi          1;</code>
その他、時間ステップを制御する方法もサポートされています。
<code>functions
{
    timeStepping
    {
        type            setTimeStep;
        libs            (utilityFunctionObjects);
        enabled        yes;
        deltaT
        {
            type table;
            file "<system>/deltaTvalues";
        }
    }
}</code>
チュートリアル
 
* $FOAM_TUTORIALS/heatTransfer/solidFoam/movingCone
 
ソースコード
 
* $FOAM_SOLVERS/heatTransfer/solidFoam
 
=== 熱交換器のモデリングを改善 ===
effectivenessHeatExchangerSourceのfvOptionが書き込めるように拡張されました。
<code>#Time    Net mass flux [kg/s]    Total heat exchange [W]    Secondary inlet T [K]    Tref [K]    Effectiveness</code>
オプションとして、ユーザーは二次流の比熱容量である新しいオプション入力secondaryCpに基づいて、二次流出温度を計算することができます。
<code>effectivenessHeatExchangerSource1
{
    ...
    // when secondary outlet temperature is requested
    secondaryCp            <Function1<scalar>;
}</code>
ソースコード
 
* $FOAM_SRC/fvOptions/sources/derived/effectivenessHeatExchangerSource/effectivenessHeatExchangerSource.H
 
マージ要求
 
* MR!534
 
=== 新テーブル化された異方性熱伝導固体輸送 ===
この機能は、固体熱力学のための表形式異方性熱伝導特性を、オプションの座標系指定で指定することができるものです。
 
輸送モデルは tabulatedAnIso と呼ばれ、例として ThermophysicalProperties ファイルに以下のように指定されている。
<code>thermoType
{
    type            heSolidThermo;
    mixture        pureMixture;
    transport      tabulatedAnIso;
    thermo          hTabulated;
    equationOfState icoPolynomial;
    specie          specie;
    energy          sensibleEnthalpy;
}
mixture
{
    specie
    {
        molWeight  50;
    }
    transport
    {
        kappa      table
        (
            // T  kappa
            ( 200  (80 80 80) )
            ( 400  (80 80 80) )
        );
        // kappa    <Function1<scalar>>;
    }
    thermodynamics
    {
        Hf      0;
        Cp
        (
            ( 200 450)
            ( 400 450)
        );
        Sf      0;
    }
    equationOfState
    {
        rhoCoeffs<8>    (8000 0 0 0 0 0 0 0);
    }
}
coordinateSystem
{
    type        cylindrical;
    origin      (0 0 0);
    rotation
    {
        type    cylindrical;
        axis    (1 0 0);
    }
}</code>
ソースコード
 
* $FOAM_SRC/thermophysicalModels/solidSpecie/transport/tabulated/tabulatedAnIsoSolidTransport.H
 
マージ要求
 
* MR!546
 
=== 新型ソフトウォール6自由度拘束装置 ===
6自由度の剛体運動拘束に、新たにソフトウォール拘束を追加しました。
 
このモデルでは、アンカーと本体の取り付け位置refAttachmentPtの壁面法線方向の距離が負になると軟らかい壁として作用し、正になると力は作用しないダンパー線形バネ拘束を記述している。
 
dynamicMeshDictでの仕様は以下の通りです。
<code>restraints
{
    softWall
    {
        sixDoFRigidBodyMotionRestraint  softWall;
        anchor                          (0.5 0.5 0.7);
        refAttachmentPt                (0.5 0.5 0.58);
        wallNormal                      (0 0 -1);
        psi                            2.0;
        C                              0.01;
    }
}</code>
ソースコード
 
* $FOAM_SRC/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion/restraints/softWall
 
マージ要求
 
* MR!536
 
= 境界条件 =
 
==== 乱流デジタルフィルター条件の改善 ====
乱流DigitalFilterInlet境界条件のリファクタリング、簡略化、改良が行われました。
 
* この条件を拡張して、温度や汚染物質濃度などのスカラーの合成変動を生成する。
* 新しい入力項目タイプ。
** 平均応力とレイノルズ応力がPatchFunction1型になりました。
** 平均応力、レイノルズ応力の時変入力が可能になりました。
** 入力項目が大幅に削減されました。
* インレットパッチへの揺らぎのマッピングが改良され、一般化された
** ユーザーはマッピング操作の際にAMIのマッピング方法を選択することができます
* ドメインの回転/平行移動が改善されました。
** ユーザーがローカル座標系を設定することができます。
* フォワードステップワイズ法オプションでタイムステップを調整できるようにしました。
* 並列化、スケーリングが向上します。
* リスタートを改善しました。
* Taylor の凍結乱流の仮定は、流線積分スケールの計算では削除されます。
 
 
ソースコード
 
* $FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/turbulentDigitalFilterInlet
 
チュートリアル
 
* $FOAM_TUTORIALS/incompressible/pimpleFoam/LES/planeChannel
* $FOAM_TUTORIALS/verificationAndValidation/turbulentInflow/oneCellThickPlaneChannel
 
マージ要求
 
* MR!532
 
参考文献
 
* Xie, Z. T., Hayden, P., & Wood, C. R. (2013). Large-eddy simulation of approaching-flow stratification on dispersion over arrays of buildings. Atmospheric Environment, 71, 64-74. DOI:10.1016/j.atmosenv.2013.01.054
* Okaze, T., & Mochida, A. (2017). Cholesky decomposition–based generation of artificial inflow turbulence including scalar fluctuation. Computers & Fluids, 159, 23-32. DOI:10.1016/j.compfluid.2017.09.005
 
=== 新型アウトレットマップインレットの条件 ===
outletMappedUniformInlet境界条件が、時間的に遅延する入口-出口再循環と一般化された入力に対して改善されました。
 
* 1つのインレットに対して、任意の数のアウトレットを接続することが可能になりました。
* 各インレットは、異なる任意の組み合わせのアウトレットに接続することができます。
* オプションの filtration-fraction と offset の項目は Function1 タイプにアップグレードされる。
* 時間遅延再循環は、Function1タイプの新しいオプションの時間遅延エントリによって有効になります。
* 各インレットは、PatchFunction1タイプとして、オプションでベースインレットフィールドを持つことができるようになりました。
* 境界条件は、スカラー、ベクトル、テンソルなど、すべてのフィールドタイプに使用可能です。
 
この境界条件の最小限の例を以下に示す。
<code><patchName>
{
    // Mandatory entries
    type            outletMappedUniformInlet;
    outlets
    {
        <outletName.1>
        {
            fraction    <Function1<scalar>>;
            offset      <Function1<Type>>;
            timeDelay  <Function1<scalar>>;
        }
        <outletName.2>
        {
            fraction    <Function1<scalar>>;
            offset      <Function1<Type>>;
            timeDelay  <Function1<scalar>>;
        }
        ...
    }
    // Optional entries
    uniformValue    <PatchFunction1<Type>>;
    phi            phi;
    // Inherited entries
    ...
}</code>
ソースコード
 
* $FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/outletMappedUniformInlet
 
チュートリアル
 
* $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/airRecirculationRoom
 
マージ要求
 
* MR!531
 
=== 新種吸着条件 ===
流体/固体界面での収着過程をモデル化するために、 speciesSorption および enthalpySorption という 2 つの新しい境界条件が追加されまし た。これらの条件は、rhoReactingFoam のような、多成分、圧縮性、乱流の解を可能にする圧縮性多成分ソルバーで使用されるべきものです。
 
speciesSorption には、 吸着モデルを選択し、対応するモデルパラメータを指定するオプションがある。1つのモデルは吸着平衡モデル（Langmuir）に基づき、もう1つは動力学、すなわち一次モデルに基づくものである。
 
種境界条件は、表面への吸着種と脱着種の量を時間経過とともに記憶し続けるものである。
 
<code>base
{
    type                speciesSorption;
    equilibriumModel    Langmuir;
    kinematicModel      PseudoFirstOrder;
    kabs                10;                // [1/sec]
    kl                  0.01;              // [1/mol]
    max                0.1;                // [mol/Kg]
    thickness          uniform 1e-3;      // [m]
    rhoS                2000;              // [kg/m3]
    value              $internalField;
}</code>
どこで
 
* kabs: 吸収係数
* kl：ラングミュア係数
* max : ラングミュアモデルにおける壁面での平衡の比例係数
* thickness : ソリッドの厚さ
* rhoS : 固体密度
 
ここで重要なことは、動力学モデルは固体質量1kgあたりのソース[mol/kg/sec]を提供することである。種へのソース率[kg/m3/sec]を計算するためには、種が吸収される固体壁の質量を知る必要がある。
 
この条件は、壁での種のためのゼロ勾配タイプです。したがって、種のためのソースは、パッチに隣接するセルにソースを適用するfvOptionを介して追加されます。
 
fvOptions辞書では、次のように指定されています。
<code>patchCellsSource
{
    type            patchCellsSource;
    species        O2;
}</code>
EnthalpySorption条件は、温度フィールドに適用され、2つのモデル（推定と計算）を介して、種の吸着に関連する熱の追加または削除を説明します。
 
* estimated: 吸着エンタルピーは、ユーザー入力により計算されます。CとHvap
* 計算：質量負荷とエンタルピーのルックアップテーブルを必要とします。
 
<code>base
{
    type                enthalpySorption;
    enthalpyModel      calculated;
    enthalpyTable
    {
        type            table;
        values          ((0 0)(1 50));
    }
    C                  2;
    species            O2;
    includeHs          true;
    value              $internalField;
}</code>
のところです。
 
* enthalpyModel: 吸収モデル (計算値 / 推定値)
* enthalpyTable : 計算モデル用のテーブル
* C: 推定モデル定数を含む
* Hs: 種の感性エンタルピーを含む
* species: 検討中の種
 
チュートリアル
 
* $FOAM_TUTORIALS/combustion/rhoReactingFoam/groundAbsorption
 
ソースコード
 
* $FOAM_SRC/thermophysicalModels/reactionThermo/derivedFvPatchFields/speciesSorption
* $FOAM_SRC/thermophysicalModels/reactionThermo/derivedFvPatchFields/enthalpySorption
 
= 後処理 =
 
=== サンプル集合の再書き込み ===
非常に古いライタークラスは、以前に更新されたサーフェスライターと同様の概念を使用する新しい coordSetWriter クラスに置き換わりました。いくつかのケースでは、rawフォーマットの出力ファイル名がわずかに異なることを除いて、変更はエンドユーザーにとってほぼ透明です。
 
変更点は以下の通りです。
 
* フィールドのサンプリング/書き込みをワンステップで行う。これにより、ライターをストリーミング操作に使用することができる。  スカラー、ベクトルなど複数のフィールドタイプを1つの出力に集めることができます。これは特にVTKやEnsightのフォーマットで顕著で、生成されるファイルの数が減ります。  raw形式をバッファなし出力として直接書き込み、サーフェスライター用のraw形式と整合性のあるファイルレイアウトを実現。  書き込みを行わずに実行間隔で値を取得するsampleOnExecuteをサポート。これにより、不要なIO操作でディスクをスラッシングすることなく、functionObjectコントロールで使用するための内部サンプリングが可能になります。  sampleSurface の変更点と同様に、辞書エントリ（リストも含む）として入力を設定し、changeDictionary を使用してコンテンツを変更できるようになりました。  sampleSet の結果 (プロパティ) がセット名で修飾されるようになり、複数のサブセットを扱うことができるようになりました。  これは、いくつかのワークフローにとって潜在的に大きな変更となりますが、前バージョンの欠点を修正したものです。例えば
<syntaxhighlight lang="c++">
sample1
{
    scalar
    {
        average(line,T) 349.96521;
        min(line,T)    349.9544281;
        max(line,T)    350;
        average(cells,T) 349.9854619;
        min(cells,T)    349.6589286;
        max(cells,T)    350.4967271;
        average(line,epsilon) 0.04947733869;
        min(line,epsilon) 0.04449639927;
        max(line,epsilon) 0.06452856475;
    }
    label
    {
        size(line,T)    79;
        size(cells,T)  1720;
        size(line,epsilon) 79;
    }
}
</syntaxhighlight>注：値はセット自体の名前でスコープされるため、例えば「line」セットの平均温度は average(line,T) となり、既存のワークフローは壊れてしまう。
 
非限定名は、すべてのサブセットのアンサンブル値に対応するようになりました。これは、既存のワークフローが1つのサブセットしか持っていない場合、正味の変化はないことを意味します。しかし、ワークフローを将来的に保証するために、より正確な仕様を使用することが推奨されます。<syntaxhighlight lang="c++">
average(p)    // Ensemble average of all listed sets
</syntaxhighlight>
 
* sampledSets は、指定されたすべてのサンプルされた位置のポイントを、生のプローブされたフォーマットで単一の集合的なアンサンブル出力に収集する特別な目的のプローブsetFormatを追加しています。  この機能は、プローブの位置を個々の点ではなく、アレイ/ラインで指定する方が便利な場合に有効です。
 
ソースコード
 
* $FOAM_SRC/meshTools/coordSet/writers/common
 
=== Improved probes function object ===
プローブには sampleOnExecute オプションが追加され、出力や出力ディレクトリを生成することなく、実行間隔で最小/最大/平均/サイズを取得するための値のサンプリング/プロービングをサポートします。
 
ソースコード
 
* $FOAM_SRC/sampling/probes
 
=== サンプリング面を改善 ===
サンプリングされた表面は、以下のような複数のアップデートが施されています。
 
* 内部surfMeshにサンプリングするサポートを削除しました。これは、より柔軟なポリサーフェスのサンプル/ストレージが追加される前の応急処置として、ほとんど使用されない機能でした（FEB-2019）。
* サンプリングされたサーフェスの出力を強化しました。
* ポイント マージの改善。
 
サーフェスライターがフィールドスケーリングと幾何学変換をサポートするようになりました。fieldLevelは、例えば、任意のfieldScaleを適用する前に、一様なシフトを追加または削除するのに便利です。
<code>fieldLevel
{
    "p.*"  1e5;        // Absolute -> gauge [Pa]
    T      273.15;    // [K] -> [C]
    U      #eval{ 10/sqrt(3) };  // Uniform mag(U)=10
}</code>
fieldLevel が削除された後、任意の fieldScale が適用される、例．
<code>fieldScale
{
    "p.*"  0.01;      // [Pa] -> [mbar]
}</code>
これは、例えば、EnSight-formatが本質的に単精度に制限されている場合に、圧力フィールドの出力精度を上げるために特に有効です。
 
新しいオプションのトランスフォームエントリにより、サンプリングされたサーフェスの「再配置」が可能になりました。例えば、CADにインポートするために、異なる座標系に再配置する場合などです。
<code>formatOptions
{
    vtk
    {
        scale 1000;  // m -> mm
        transform
        {
            origin  (0.05 0 0);
            rotation axisAngle;
            axis    (0 0 1);
            angle  -45;
        }
    }
}</code>
これにより、ベクトルまたはテンソルフィールドが幾何学的回転に従って変換される。
 
=== runTimeControlファンクションオブジェクトの改良 ===
runTimeControlファンクションオブジェクトは、トリガーを使用して、さらにファンクションオブジェクトをアクティブにします。以前は、トリガーインデックスは前進することしかできませんでしたが、この変更セットにより、ユーザーはより小さな値を設定して、例えば、ファンクションオブジェクトのリサイクルを有効にすることができるようになりました。
 
これをNサイクル繰り返す。
 
# 空間のある点での圧力の平均化
# 平均が安定したら、さらに100回繰り返し実行する。
# 新しいパッチの入口速度を設定する
# を (1) に戻す。
 
このリリースでは、新しいトリガー値を設定するオプションで、パススルー/ノーオプとして機能するNone条件も含まれています。
 
チュートリアル
 
* $FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar
 
ソースコード
 
* $FOAM_SRC/functionObjects/utilities/runTimeControl
 
=== multiFieldValueファンクションオブジェクトの改善 ===
multiFieldValueファンクションオブジェクトは、結果エントリを生成するあらゆるファンクションオブジェクトで動作するようになり、fieldValueタイプのファンクションオブジェクトのみを使用するという制約がなくなりました。
 
例えば、以下のようにsurfaceFieldValueとvalueAverageファンクションオブジェクトの結果を平均化することができるようになった。
<code>averagePressure
{
    type    multiFieldValue;
    libs    (fieldFunctionObjects);
    operation  average;
    functions
    {
        inlet
        {
            type            surfaceFieldValue;
            operation      areaAverage;
            regionType      patch;
            name            inlet;
            fields          (p);
            writeFields    no;
            writeToFile    no;
            log            no;
        }
        outlet
        {
            type            surfaceFieldValue;
            operation      areaAverage;
            regionType      patch;
            name            outlet;
            fields          (p);
            writeFields    no;
            writeToFile    no;
            log            no;
        }
        average
        {
            type            valueAverage;
            functionObject  testSample1;
            fields          (average(p));
            writeToFile    no;
            log            no;
        }
    }
}</code>
また、出力もわかりやすく更新しています。
  <code>1 # Group0         
  2 #  - averagePressure:inlet:areaAverage(inlet,p)
  3 #  - averagePressure:outlet:areaAverage(outlet,p)
  4 #  - averagePressure:average:average(p)Mean
  5 # Operation      : add
  6 # Time              Group0           
  7 0.00120482          3.4483824485e+05
  8 0.00265769          3.0352523946e+05
  9 0.00439595          3.0338969991e+05</code>
追加のグループには、Group1、Group2 ... などのラベルが付けられます。GroupN などと表示されます。
 
チュートリアル
 
* $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter
* $FOAM_TUTORIALS/incompressible/pisoFoam/RAS/cavity
 
ソースコード
 
* $FOAM_SRC/functionObjects/field/multiFieldValue
 
=== 力およびforceCoeffs関数オブジェクトの改善 ===
force および forces 関数オブジェクトは、コードの複雑さを軽減し、コードの保守性を向上させるためにリファクタリングされました。binning機能は削除され、別のbinField関数オブジェクトとして利用できるようになりました。
 
力の係数を要求する際、以前はすべての寄与を書き込んでいましたが、オプションの「係数」項目を使って選択できるようになりました。
<code>coefficients    (Cd Cl(f) Cl(r));</code>
係数の全リストは以下の通りです。
 
* Cd, Cd(f), Cd(r) : 抗力, (フロントとリア)
* Cs、Cs(f)、Cs(r) : サイドフォース、(フロントとリア)
* Cl, Cl(f), Cl(r) : 揚力、(前・後)
* CmRoll : ロールモーメント
* CmPitch : ピッチモーメント
* CmYaw : ヨーモーメント
 
省略した場合は、すべての係数を書き込む。
 
チュートリアル
 
* $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike/system/forceCoeffs
* $FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar/system/forceCoeffs
 
ソースコード
 
* $FOAM_SRC/functionObjects/forces/forces
* $FOAM_SRC/functionObjects/forces/forceCoeffs
 
=== 新しいbinField関数オブジェクト ===
新機能オブジェクトのbinFieldは、指定したパッチやセルゾーンをセグメントに分割し、各セグメントごとに空間的に局所的な情報を出力するビニングデータを計算します。
 
2種類のビン型があります。
 
* singleDirectionUniformBin：指定された方向のビニングデータを計算する。
* uniformBin: 指定されたデカルト座標系または円筒座標系に従って、複数のセグメントでビニングデータを計算する。
 
出力変数は以下の通り。
 
* total: パッチと内部の合計
* patch: パッチデータ
* internal: 指定したセルゾーンのポーラスデータなど
* normalとtangential: パッチデータの直交成分
 
例として、forceCoeffs関数オブジェクトの以前のビニング動作を回復するために。
<code>forceCoeffs1
{
    type            forceCoeffs;
    libs            (forces);
    writeControl    writeTime;
    writeFields    true;
    patches        (body);
    p              p;
    U              U;
    rho            rhoInf;      // Indicates incompressible
    log            true;
    rhoInf          1;          // Required when rho = rhoInf
    liftDir        (0 1 0);
    dragDir        (1 0 0);
    CofR            (3.5 0 0);  // Axle midpoint on ground
    pitchAxis      (0 0 1);
    magUInf        10;
    lRef            4;          // Wheelbase length
    Aref            1;          // Estimated
    porosity        on;
}
binField1
{
    type                    binField;
    libs                    (fieldFunctionObjects);
    binModel                singleDirectionUniformBin;
    fields                  (forceCoeff);
    patches                (body);
    decomposePatchValues    yes;
    CofR                    ${..forceCoeffs1.CofR};
    cellZones              (porousZone);
    binData
    {
        nBin        20;          // output data into 20 bins
        direction  (1 0 0);    // bin direction
        cumulative  yes;
    }
    writeControl            writeTime;
}</code>
チュートリアル
 
* $FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar/system/forceCoeffs
 
ソースコード
 
* $FOAM_SRC/functionObjects/field/binField
 
=== ダイナミックモードデコンポジション（DMD）ツールの改善 ===
Dynamic Mode Decomposition機能オブジェクトが拡張され、DMD計算において複数のパッチを指定できるようになりました。
<code>DMD1
{
    // Optional entries
        // Option-1
        patch              <word>;
        // Option-2
        patches            (<wordRes>);
}</code>
また、STDMDの実装の中で最もコストのかかる部分を特定し、リファクタリングすることで、実行時間の短縮を実現し、パフォーマンスも向上しました。例えば、標準的な "cylinder2D "チュートリアルのタイミング、すなわち、すべてのSTDMD関数オブジェクトがアクティブな場合、12プロセッサの並列シミュレーションの時間は、約60%短縮されました。
 
ソースコード
 
* $FOAM_SRC/functionObjects/field/DMD
 
チュートリアル
 
* $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D
 
マージ要求
 
* MR!547
 
=== 新しい particleZoneInfo クラウド機能オブジェクト ===
新しい particleZoneInfo クラウド関数オブジェクトは、cellZone を横切る粒子の統計情報を生成します。クラウドプロパティファイルのcloudFunctionsサブディクショナリで指定されます。
<code>cloudFunctions
{
    particleZoneInfo1
    {
        type            particleZoneInfo;
        cellZone        leftFluid;
        // Optional entries
        writer          vtk; // vtk, raw, none
    }
}</code>
オプションの writer エントリを指定すると、クラウドデータが指定されたフォーマットで書き込まれます。生成される統計情報には粒子が含まれます。
 
* インデックスとその発信元プロセッサ
* セルゾーンに最初に入ったときの時刻、直径、質量
* 現在位置、直径、質量
* セルゾーンに滞在した時間
 
実行中、オブジェクトはクラウドソリューションの後に書き込む、など。
<code>particleZoneInfo:
    Cell zone                      = leftFluid
    Contributions                  = 257</code>
ここで、Contributions はこの時間ステップで記録された粒子移動の増分寄与の数を意味します。書き込み時には、出力が拡張される、など。
<code>particleZoneInfo:
    Cell zone                      = leftFluid
    Contributions                  = 822
    Number of particles            = 199
    Written data to "postProcessing/lagrangian/reactingCloud1/particleZoneInfo1/0.7/particles.dat"</code>
particles.dat ファイルには、粒子の統計情報などが含まれています。
<code># cellZone        : leftFluid
# time            : 1.0000000000e+00
#
# origID            origProc    (x y z)    time0    age    d0    d    mass0    mass
2 0 (1.2403730063e+00 6.3907929681e-01 5.0000000000e-02) 5.0400000000e-01 5.0400000000e-01 1.0000000000e-03 9.9733169015e-04 5.2359877560e-07 5.1941857822e-07
3 0 (1.2294005030e+00 7.1626530229e-01 5.0000000000e-02) 5.0400000000e-01 5.0225000000e-01 1.0000000000e-03 9.9733162350e-04 5.2359877560e-07 5.1941847408e-07
4 0 (1.2265565036e+00 6.5308628366e-01 5.0000000000e-02) 5.0400000000e-01 5.0100000000e-01 1.0000000000e-03 9.9733541220e-04 5.2359877560e-07 5.1942439366e-07</code>
チュートリアル
 
* $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter
 
ソースコード
 
* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects
 
=== cloudInfo クラウド機能オブジェクトの改良 ===
cloudInfo は、以下のような基本的な区画情報を報告するシンプルな雲機能オブジェクトである。
 
* 区画数
* システム内の質量
* 最大径
* D10 直径
* D32径
 
このたび、解析する区画の限定的な選択をサポートするために拡張されました。選択メカニズムは vtkCloud 関数オブジェクトと同じで、例．
<code>selection
{
    all
    {
        action  all;
    }
    T
    {
        action  subset;
        source  field;
        field  T;
        accept  (greater 280) and (less 300);
    }
    Umin
    {
        action  subtract;
        source  field;
        field  U;
        accept  (less 0.1);
    }
}</code>
チュートリアル
 
* $FOAM_TUTORIALS/lagrangian/reactingParcelFoam/filter
 
ソースコード
 
* $FOAM_SRC/functionObjects/lagrangian/cloudInfo
* $FOAM_SRC/functionObjects/lagrangian/common/parcelSelectionDetail.H
 
=== パーティクルドーズクラウド機能オブジェクトを新規に追加 ===
新しい線量クラウド機能オブジェクトは、粒子の吸収線量を放射線場Gに沿った粒子軌道の時間積分[w/m2]として計算します。
 
関数オブジェクトを指定する。
<code>cloudFunctions
{
    ParticleDose1
    {
        type            ParticleDose;
        GName            G;
    }
}</code>
チュートリアル
 
* $FOAM_TUTORIALS/lagrangian/coalChemistryFoam/simplifiedSiwek
 
ソースコード
 
* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/ParticleDose
 
=== 新しいノルム関数オブジェクト ===
new norm関数オブジェクトは、入力フィールドを選択されたノルムで正規化し、新しい正規化されたフィールドを書き込む。
 
最小限の使用例を以下に示します。
<code>norm1
{
    // Mandatory entries
    type            norm;
    libs            (fieldFunctionObjects);
    field          <word>;
    norm            <word>;
    // Conditional entries
        // when norm == Lp
        p              <scalar>;
        // when norm == composite
        divisor        <Function1<scalar>>;
        // when norm == divisorField
        divisorField    <word>;
    // Inherited entries
    ...
}</code>
には、以下のノルム項目があります。
 
* L1 : L1/Taxicabノルム
* L2 : L2/Euclidean ノルム
* Lp : pノルム
* max : 最大ノルム
* composite : 関数1 divisorを構成する合成ノルム
* divisorField : 与えられたフィールドで正規化する。
 
ソースコード
 
* $FOAM_SRC/functionObjects/field/norm
 
チュートリアル
 
* $FOAM_TUTORIALS/incompressible/pisoFoam/RAS/cavity
 
マージ要求
 
* MR!539
 
=== foamToVTKとfoamToEnsightの有限面積のサポートが改善されました。 ===
foamToEnsightとfoamToVTKの両方で、有限面積フィールドがデフォルトで検出および変換されるようになりました。必要であれば、-no-finite-areaオプションでこれを抑制することができます。以前の-finite-areaオプションは無視されるようになりました。
 
foamToEnsightおよびfoamToVTKユーティリティには、変換をより正確に制御するための-exclude-fieldsおよび-no-fieldsオプションが追加されています。
 
= パラレル =
=== singleProcessorFaceSets制約を改善しました。 ===
オプションの制約は、decomposeParDict の制約セクションを使用して、decomposePar ユーティリティに適用することができます。singleProcessorFaceSets 制約は、faceSet のすべての面を同じプロセッサーに配置するために使用できます。v2206では、ロジックが拡張され、redistributePar -parallelなどの並列で動作するようになりました。
 
典型的な使用方法は、cyclicAMIの面を1つのプロセッサで維持することです。例えば、暗黙的な実行やパーティクルトラッキングに必要な場合などです。
<code>method              ptscotch;
constraints
{
    keepCyclicAtOnePatch
    {
        type        singleProcessorFaceSets;
        sets
        (
            (fanLeftFaceSet -1)
            (fanRightFaceSet -1)
        );
        enabled    true;
    }
}</code>
チュートリアル
 
* singleProcessorFaceSets制約を持つすべてのチュートリアル
 
ソースコード
 
* $FOAM_SRC/parallel/decompose/decompositionMethods/decompositionConstraints
 
=== アップデートされたアルゴリズム ===
 
==== パラレル通信 ====
本バージョンでは、Pstreamライブラリに関連する低レベルMPI並列通信コンポーネントの一部を大幅に作り直しました。この変更には、通常のコード開発の一環としてのアップデート、exaFOAMプロジェクトの活動に関連する変更、そして富嶽の性能向上に取り組んでいるRISTの青柳哲雄、井上義明、阿左美彰の研究者への多大な感謝が含まれています。
 
RISTの研究者たちは、プロセッサの数が多くなると、interIsoFoamソルバーの性能が特に低下することに気づきました。これは、通信パターンが縮退していることに起因しています。
 
彼らのソリューションは、限定された通信ステンシルとMPIブロードキャストを組み合わせることで、多くのオール・トゥ・オール通信やポイント・トゥ・ポイント通信を回避しています。
 
interIsoFoamで達成した改善規模は実に印象的で、約1300秒だった通信時間を50秒以下にまで短縮しました
 
==== アップデートの簡単な概要 ====
Pstreamの再構築はかなり広範囲に及びますが、ここではいくつかの注目点を紹介します。
 
* 新しい Pstream::broadcast と Pstream::broadcasts の操作です。複数の1対多通信を1つのMPI_Bcastで置き換えることができます(RISTからの研究に基づいています)。
* ネットワークに最適化された MPI intrinsics を活用するために、ツリーベースの散布がブロードキャストに大きく置き換えられました。
* メモリの再利用を向上させるために、巻き戻し、ピークなどのPstreamアクセスメソッドを追加しました。
* PstreamBuffers通信モードの追加。すなわち、gather/scatter、neighbor/neighbourおよび特殊なトポロジカルパターン。
* float/double/(u)int32_t/(u)int64_t 型のためのネイティブ MPI min/max/sum リダクション。
 
= ユーザビリティ =
 
=== コンパイラーサポートの改善 ===
 
* ARM64 Nvidia コンパイラ用の新しい make ルールを追加しました。
* PGI コンパイラの wmake ルールを削除 (廃止)
* clang lld と金型リンカを使用するようにオプションで制御、例:
<syntaxhighlight lang="c++">
export WM_COMPILER=Clang140
export WM_COMPILE_CONTROL="version=14.0 +lld"
</syntaxhighlight>
 
* ローカルデバッグビルドの柔軟性を向上させました。コードを開発するとき、FULLDEBUG と組み合わせたり、場合によっては異なる最適化レベルで組み合わせると便利なことがあります。ファイルを編集することなく、wmakeコールから直接両者を組み合わせることができるようになり、便利になりました。
<syntaxhighlight lang="c++">
wmake -debug-O1 src/OpenFOAM
</syntaxhighlight>
 
* FOAM_EXTRA_CXXFLAGS は、オーバーライドしやすいように、コンパイルラインの最後に追加されるようになりました。
 
=== 座標回転の簡単な定義 ===
インライン定義による回転タイプの指定が可能になり、可読性が向上し、タイピングも少なくなりました。
<code>transform
{
    origin  (0 0 0);
    rotation axisAngle;
    axis    (0 0 1);
    angle  45;
}</code>
長編と同様に。
<code>transform
{
    origin  (0 0 0);
    rotation
    {
        type  axisAngle;
        axis  (0 0 1);
        angle 45;
    }
}</code>
古い coordinateRotation キーワード (OpenFOAM-v1806 以前) は、冗長的に非推奨となり、rotation が優先されるようになりました。
 
=== ロール-ピッチ-ヨー/ヨー-ピッチ-ロールの指定に対応。 ===
アプリケーションによっては、roll-pitch-yawは自然な方位表現なので、オイラー仕様の一部として直接サポートされるようになりました（例）。
<code>rotation
{
    type    euler;
    order  rollPitchYaw;
    angles  (0 20 45);
}</code>
非常に単純な回転（-rotate-x, -rotate-y, -rotate-z）が、transformPoints と surfaceTransformPointsで直接受け付けられるようになりました。
 
=== プレーンの簡単な定義 ===
多くの場合、平面を指定する最も自然な方法は、参照点とその法線である。そのため、辞書エントリーのplaneTypeはオプションとなりました。指定しない場合は、点/法線の定義が想定され、pointAndNormalDict サブエントリはオプションになります。
 
この変更により、より自然に指定することができるようになりました。例えば、サンプリングされた切断面の場合。
<code>slice
{
    type        cuttingPlane;
    point      (0 0 0);
    normal      (0 0 1);
    interpolate true;
}</code>
代わりに
<code>slice
{
    type        cuttingPlane;
    planeType  pointAndNormal;
    pointAndNormalDict
    {
        point  (0 0 0);
        normal  (0 0 1);
    }
    interpolate true;
}</code>
「https://wiki.opencae.or.jp/index.php/特別:携帯機器差分/692...697」から取得