OpenFOAM v2206 リリースノート

ESI OpenCFD Release OpenFOAM® v2206

OpenCFDは、2022年6月にOpenFOAM® v2206をリリースすることをお知らせします。このリリースでは、コードの多くの領域でOpenFOAM-v2112の機能を拡張しています。新機能は、OpenCFDのお客様がスポンサーとなった開発、内部資金による開発、OpenFOAMコミュニティからの機能および変更の統合を表しています。

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

• Ubuntu Linux: packaged installation for Ubuntu 22.04 (LTS), 20.04 (LTS), 18.04 (LTS)
• openSUSE Linux: packaged installation for Leap15.4, Leap15.3, Leap15.2
• Redhat Linux variants: packaged installation for CentOS/Rocky 9, 8, 7 and Fedora 36, 35, ...

Windowsユーザーは、プリコンパイルされたパッケージについて、3つの選択肢があります（詳細はこちら）。

• Using Windows Subsystem for Linux (based on Ubuntu, openSUSE etc.)
• Native executables with cross-compiled
• A docker installation

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

Upgrading

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

入力ディクショナリー

座標系と平面の辞書入力が、よりシンプルな構文でサポートされるようになりました。この変更は微妙なものですが、より自然に書けるようになるはずです。

座標系

transform と coordinateSystem の項目で、回転タイプのインライン指定ができるようになりました。

transform
{
    origin  (0 0 0);
    rotation axisAngle;
    axis    (0 0 1);
    angle   45;
}

長編と同様に。

transform
{
    origin  (0 0 0);
    rotation
    {
        type  axisAngle;
        axis  (0 0 1);
        angle 45;
    }
}

coordinateRotationの使用は、以前はrotationサブディクショナリへのサイレント・エイリアスでしたが、現在は冗長に非推奨となりました。同様に、古い長い名前axesRotation、EulerRotation、STARCDRotationは、それぞれ対応する短い名前axes、euler、starcdのエイリアスとして報告されるようになりました。

移動のみの場合、明示的な回転なしを使用することも可能です。

transform
{
    origin   (1 2 3);
    rotation none;
}

または、同一軸を持つ暗黙の軸の指定。

transform
{
    origin  (1 2 3);
    e1      (1 0 0);
    e3      (0 0 1);
}

プレーン

平面は、参照点とその法線によって指定されることが非常に多いため（ほとんど必ず）、planeType辞書項目とそれに対応するサブ辞書は完全にオプションになりました。デフォルトでは、点/法線の指定が想定されています。たとえば、サンプリングされた切断面です。

slice
{
    type    cuttingPlane;
    point   (0 0 0);
    normal  (0 0 1);
}

の代わりに、より冗長なバージョンを使用します。

slice
{
    type        cuttingPlane;
    planeType   pointAndNormal;
    pointAndNormalDict
    {
        point   (0 0 0);
        normal  (0 0 1);
    }
}

シリンダートポソース

• cylinderToCell、cylinderToFace、cylinderToPoint topoSetソースが更新され、シリンダー端点の好ましい名前としてpoint1およびpoint2を受け入れるようになり、検索可能なシリンダー仕様との入力の整合性が改善されました。

サンプルセット

coordSetWriter の更新は、raw フォーマットの出力ファイル名が若干異なることを除けば、エンドユーザーにはほとんど透過的です。セット入力は、辞書エントリとして指定できるようになりました（sampled-surfaceと同様）ので、changeDictionaryを使用してコンテンツを変更することができます。

サンプルセットに関連付けられた関数プロパティは、それぞれのサブセット名で修飾されるようになりました。修飾されていないプロパティ名は、以前のバージョンでは壊れていた（最後のサブセットからの値のみを返していた）アンサンブル値（すべてのサブセットの）に対応するようになりました。これは、既存のワークフローが単一のサブセットしか持っていない場合、正味の変更はないことを意味します。しかし、より正確な仕様を使用することで、ワークフローの将来性を確保することが望ましい。たとえば、以下のようになる。

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;
    }
}

• サンプルセットには、指定されたすべてのサンプルロケーションのポイントを、生のプローブフォーマットで単一の集合アンサンブル出力に収集する特別な目的のプローブセットフォーマットも追加されています。場合によっては、プローブ位置を多数の個別点としてではなく、複数のアレイ/ラインのセットとして指定する方が便利なことがあります。

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

新しいソルバーリンクの要件

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

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

• 旧Make/options

EXE_LIBS = ... \
    ...
    -lcompressibleTurbulenceModels \
    -lcompressibleTransportModels \
    ...

• 新Make/options

EXE_LIBS = ... \
    ...
    -lcompressibleTurbulenceModels \
    -lthermoTools \
    -lcompressibleTransportModels \
    ...

• 古い/新しいOpenFOAMのバージョン用にコンパイルする特別な場合、ライブラリリンクは以下のように分離することができます。

#if (OPENFOAM >= 2206)
LIB_THERMO_TOOLS := -lthermoTools
#else
LIB_THERMO_TOOLS :=
#endif

EXE_LIBS = ... \
    ...
    -lcompressibleTurbulenceModels \
    $(LIB_THERMO_TOOLS) \
    -lcompressibleTransportModels \
    ...

非推奨と削除

非推奨のメソッド

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

削除されたメソッド

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

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

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

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

メソッドの名称変更

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

old op name	new op name	meaning
lessEqOp	lessEqualOp	<=
greaterEqOp	greaterEqualOp	>=

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

行動の変化

• 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() メソッドは、各エントリへのポインタのリストをソートすることで動作します。また、エントリの値にアクセスする際に二次的なチェックを行うこともありません。
  • これを書けるようになりました。

HashTable<someType> table = ...;

for (const auto& iter : table.sorted())
{
    Info<< iter.key() << " => " << iter.val() << nl;
}

• を、以前は

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;
}

注：HashTable の反復処理 key() の項目は、immutable であるため const として宣言されるようになりました。

フィールドハンドリング

ベクトル法

• vector::normalise メソッドは、ROOTVSMALL 以外の公差が望ましい場合のために、オプションの公差をサポートするようになりました。
• 新しい vector::removeCollinear メソッドは、共線成分を含まない法線ベクトルが頻繁に必要とされる形状を扱うときに便利です。removeCollinear メソッドは、より明確でコンパクトなコードを提供する。

vector edgeNorm = ...;

const vector edgeDirn = e.unitVec(points());

edgeNorm.removeCollinear(edgeDirn);
edgeNorm.normalise();

代わりに

vector edgeNorm = ...;

const vector edgeDirn = e.unitVec(points());

edgeNorm -= edgeDirn*(edgeDirn & edgeNorm);
edgeNorm /= mag(edgeNorm) + ROOTVSMALL;

フィールドノーマライズ

• Field コンテナ（および GeometricField などの関連クラス）には normalise() メソッドが追加されました。ほとんどのフィールドタイプでは、これは単純にno-opですが、vectorやsolveVectorのフィールドでは、これはvector::normaliseに相当しますが、各要素に適用されます。 これは、中間フィールドを作成するオーバーヘッド（または余分なコード行）なしで、ゼロ除算の保護で各要素を正規化します。

fld.normalise();

instead of

fld /= mag(fld) + VSMALL;

ラッピングされたIO出力クラス

データをコピーせずに参照で書き込むために、いくつかの派生した regIOobject ラッパーが追加されました。これらのラッパークラスは、外部コンテンツを参照するためにrefPtrを使用します。外部への読み込みは実装されていません(現在そのための要件はありません)。

base class	wrapped class
IOField	IOFieldRef
IOList	IOListRef
IOmapDistributePolyMesh	IOmapDistributePolyMeshRef

使用例

labelList addressing = ...;

io.rename("cellProcAddressing");
IOListRef<label>(io, addressing).write();

または

primitivePatch patch = ...;
IOFieldRef<vector>(io, patch.localPoints()).write();

便利な機能

• polyMeshのフィルタリングregionName() - staticおよびnon-staticメソッドを追加した。
  • メッシュリージョンを扱う場合、defaultRegion名（例えば、"region0"）をフィルタリングしたり削除したりするのが一般的です。これをポリメッシュ自体から、あるいは静的関数として、簡単に行うことができるようになりました。単純に次のように使用します。

const word& regionDir = polyMesh::regionName(regionName);

// or
const word& regionDir = mesh.regionName();

の代わりに、以前の長いコードを使用します。

const word& regionDir =
(
    regionName != polyMesh::defaultRegion
  ? regionName
  : word::null
);

以下は正しく動作します（文字列 '/' 結合演算子は、空の文字列をフィルタリングします）。

(polyMesh::regionName(regionName)/polyMesh::meshSubDir)

(mesh.regionName()/polyMesh::meshSubDir)

前処理

新しいsnappyHexMeshの自動リーククロージャー

snappyHexMeshが拡張され、到達不可能な位置（locationsOutsideMesh）が指定された場合、オプションで自動穴塞ぎを行うようになりました。以前のバージョンのSnappyHexMeshでは、可視化のためのリークパスを書き、内部点と外部点の接続が確認されるとエラーメッセージとともにメッシング処理が中断されました。

穴埋めアルゴリズムは、Zouina Aktoufらによる「A 3D-Hole Closing Algorithm」に基づいており、隙間を埋めるために必要な凸包（メッシュ面で）を決定する。これらの追加された面上の任意の点は、pointZone frozenPointsに追加され、任意のsnap-to-nearest-surfaceから除外され、平滑化のみが行われます。追加された面上のレイヤーの追加には特別な処理はないことに注意してください。

下図は、元のジオメトリ（右図）に三角形の欠落がある場合の例です。このギャップはその後、スナップフェーズで閉じられ、スムージングされます（左の図）。 この例では、ギャップは異なるリファインメントレベルの面で閉じられているため（メッシュはサーフェスのみでリファインされているため）、スムージングは完璧ではありません。

使用方法

新機能は、snappyHexMeshDictのcastellatedMeshControlsセクションに、エントリーを追加することで有効になります。

useLeakClosure true;

• 特定されたリークパスは、postProcessing ディレクトリの leakPath Ensight ファイルに書き込まれます。
• オプションのユーザー入力、leakLevel は、表面ごと、領域ごとに、どのセル レベルでリーク検出を開始するかを指定します。これは、中間洗練レベルの間、セルの最大数を制限するためにリークパスを「早期に」閉じることを可能にしますが、ギャップをブロックするために粗い面を使用する代償として、リークパスのクローズを行います。また、メッシュがまだ粗く、内側と外側の位置がまだ同じセル内にある場合、これは偽陽性を報告する可能性があります。

refinementSurfaces
{
    "sphere.*"
    {
        // Surface-wise min and max refinement level
        level (6 6);

        // Optional level at which to start early checking for leaks
        leakLevel 2;
    }
    ...

こちらもご覧ください

• 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によって、薄い隙間の自動閉鎖が導入されました。

refinementSurfaces
{
    "gap.*"
    {
        // Surface-wise min and max refinement level
        level       (2 2);

        // From cell level 2 onwards start checking
        // for opposite surfaces
        blockLevel  2;
    }
}

以前のバージョンでは、これは2つのパスで実行されました。

各サーフェスからメッシュを歩き、壁の距離を決定する。

すべてのセルについて、サーフェスの組み合わせごとに、セルがギャップの内側にあるかどうかを判断する

この分割は、大きなサーフェスと大きなメッシュで操作する場合、パス1からすべての情報を保存する必要があるため、メモリと性能に大きな制限があります。新しい実装では、壁の距離の歩行は、許容される最大ギャップサイズよりも多く歩いた場合に停止し、データ転送を劇的に少なくすることにつながっています。

パラレルコンシステントフェースゾーン

並列動作は、ランダム分解法に対する「標準」実行を比較することでストレステストされました。この結果、プロセッサパッチと一致するfaceZoneを処理しないことによる、faceZoneの割り当てアルゴリズムのわずかな違いが浮き彫りになりました。例えば、プロセッサパッチ上の顔の点の順序や方向が異なるために、顔とセルの中心を計算する際に切り捨てエラーが発生したり、セル内の顔の順序が異なるために、まだ完全に同じでない領域があるかもしれません。

チュートリアル

• $FOAM_TUTORIALS/mesh/snappyHexMesh/opposite_walls

ソースコード

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

snappyHexMeshのレイヤー追加を改善しました。

レイヤーを1回のパスで追加する代わりに、snappyHexMeshは複数のパスを使用できるようになりました。これにより、メッシュを縮小する段階で、追加のレイヤーのためのスペースを作る機会が増えます。この新しい動作はsnappyHexMeshDictのlayerParametersセクションにある新しいnOuterIterキーワードで有効になります。

// Outer loop iterations (each of which is up to nLayerIter). Default is 1.
nOuterIter      3;

例えば、20枚のレイヤーを要求した場合、1パスあたり7枚、7枚、6枚と3パスでレイヤーが追加されます。

• nOuterIter エントリに大きな数を設定すると、レイヤーを 1 枚ずつ追加することができます。
• は、追加すべきセルがない場合、あるいは品質制約のために追加できない場合に、外側のループを終了する。
• 一般に、レイヤーが追加されない外側の反復がさらなる成長を引き起こすことを避けるために、段階的なレイヤー終了をオフにすることが推奨されます。

nGrow -1;

• の場合、膨張率と最小厚さは一度だけ計算され、その後、外側の反復処理で一定に保たれます。
• レイヤーカバレッジフィールドを出力する場合。

writeFlags
(
    layerFields     // write volScalarField for layer coverage
);

結果のフィールドは、追加されたセルごとに追加されたセルの合計を表示します。

層添加の効果

2つの領域を持つ球のジオメトリを使用し、2つのパッチ（sphere_patch0, sphere_patch1）を生成することで、レイヤー追加プロセスに複数のパスを採用する効果を以下に強調します。nOuterIterなしで実行、つまり、すべてのレイヤーを一度に追加すると、次のようになります。

nOuterIter 3で、つまりレイヤーを1つずつ追加していく。

この場合、複数回のパスを使用することで、カバー率が若干向上する効果があります。

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辞書での典型的な使用法は以下の通りである。

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
);

アルゴリズム

• は，すべての境界面およびオプションの faceSet に含まれる面をマークします．
• ゾーン間に接続があるかどうかを判断する（指定されたポイントで示される）。
• 穴を塞ぐ/ゾーンを切り離す内部/結合面の最小セットを決定する

このアルゴリズムは、SnappyHexMeshの新しい自動ホールクロージャーで使用されています。

チュートリアル

• $FOAM_TUTORIALS/mesh/snappyHexMesh/gap_detection (gap detection)

ソースコード

• $FOAM_SRC/meshTools/topoSet/faceSources/holeToFace

createPatchユーティリティの改良

createPatchが拡張され、フィールドの処理と、異なるリージョン間および単一リージョン上でのマッチング面の自動再パッチングが追加されました。

フィールドの取り扱い

createBafflesと同様に、新しく追加されたパッチに境界条件を指定することができるようになりました。サイクリックパッチなどの制約型パッチでは、自動的に関連する制約境界条件が使用されるため、一般にこれは必要ありません。境界条件の追加は、patchFields サブディクショナリが存在することで有効になります。

// 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;
        }
    }
}

パッチフィールドは、パッチがまだ0面であるときに作成されることに注意してください。つまり、辞書で完全に指定されていないパッチフィールドは、正しく初期化されません。

自動パッチング

再パッチする面の選択が拡張され、重なりの自動計算が可能になりました。

// 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;

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 ディレクトリに重みを書き込みます。

checkMesh -allRegions -allGeometry

• の場合、ソースパッチはパッチグループとして提供することもできます。これは、複数のリージョンがある場合に便利で、同じ createPatchDict をすべてのリージョンに適用することができます。
• 自動パッチは、CHTケースのセットアップをより簡単にすることができます。mappedPatchやmappedWallタイプのパッチは、どちらもAMIを使用することができるので、面の再パッチングに対して一貫した動作をすることができます。

// 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;
        }
    }
}

なお、上記の 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つの面によって使用されているかをチェックすることによって、表面が閉じているかどうかを識別することになります。

actions
(
    {
        name            collectorSet;
        type            faceSet;
        action          new;
        source          searchableSurfaceToFace;
        surfaceType     triSurfaceMesh;
        surfaceName     mySurface.obj;
    }
);

2つの面の向きが一致しているかどうかのチェックが追加されました。チェックに失敗した場合は、警告メッセージが表示されます。

--> 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.

なお、同様のチェックは、surfaceCheckアプリケーションにもあります。

Number of zones (connected area with consistent normal) : 2
More than one normal orientation.

このトポロジカルエラーは、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. https://doi.org/10.1080/0305215X.2014.979816

アトリビュート

• 参考文献にあるように、最初の実装は、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 分解を行う．

A = Q R

または列のピボット化を伴う QR 分解の場合。

A P = Q R

どこ

• 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仕様をサポートするようになり、ソースの位置や強度を定義する際に柔軟性を持たせることができるようになりました。

{
    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
                #};
            }
        }
    }
}

SemiImplicitSource は、入力エントリを旧来の injectionRateSuSp 構文よりも直感的に理解できるように、明示的または暗黙的な寄与を持つ新しいソース辞書エントリを使用することに注意してください。

チュートリアル

• $FOAM_TUTORIALS/compressible/rhoSimpleFoam/squareBend

ソースコード

• $FOAM_SRC/fvOptions/sources/general/semiImplicitSource