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

ナビゲーションに移動 検索に移動

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

2022年7月1日 (金) 23:39時点における版

18,585 バイト追加 、 2022年7月1日 (金) 23:39
→‎前処理
354行目: 354行目:
= 前処理 =
= 前処理 =


== 新しい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.


= 数値 =
= 数値 =
「https://wiki.opencae.or.jp/index.php/特別:携帯機器差分/694」から取得

案内メニュー