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

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

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

2023年9月9日 (土) 18:06時点における版

38,005 バイト追加 、 2023年9月9日 (土) 18:06
→‎Upgrading
(ページの作成:「OpenCFDは、OpenFOAM® v2306の2023年6月リリースを発表します。このリリースは、コードの多くの領域にわたってOpenFOAM-v2212の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。 OpenFOAMはOpenCFDによってGPLライセンスの下で配布されています。…」)
 
1行目: 1行目:
OpenCFD is pleased to announce the June 2023 release of OpenFOAM® v2306. This release extends OpenFOAM-v2212 features across many areas of the code. The new functionality represents development sponsored by OpenCFD's customers, internally funded developments, and integration of features and changes from the OpenFOAM community.
OpenFOAM is distributed by OpenCFD under the GPL License. In addition to source code packages suitable for compilation on a variety of Linux and other POSIX systems, this release also has a number of pre-compiled binary packages
* Ubuntu Linux: packaged installation for Ubuntu 22.04 (LTS), 20.04 (LTS), 18.04 (LTS), 23.04, 22.10
* openSUSE Linux: packaged installation for Leap15.5
* Redhat Linux variants: packaged installation for epel-9; Fedora 37
Windows users have three options for pre-compiled packages (more information):
* Using Windows Subsystem for Linux (based on Ubuntu, openSUSE etc.)
* Native executables with cross-compiled
* A docker installation
OpenFOAM apptainer support is provided via description files rather than pre-assembled images
* See packaging/containers
Mac OSX users have the option to compile from source, or use Docker containers for pre-compiled packages (more information).
OpenCFDは、OpenFOAM® v2306の2023年6月リリースを発表します。このリリースは、コードの多くの領域にわたってOpenFOAM-v2212の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。
OpenCFDは、OpenFOAM® v2306の2023年6月リリースを発表します。このリリースは、コードの多くの領域にわたってOpenFOAM-v2212の機能を拡張しています。この新機能は、OpenCFDの顧客からのスポンサーによる開発、内部資金による開発、OpenFOAMコミュニティからの機能や変更の統合を表しています。


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


Ubuntu Linux: Ubuntu 22.04(LTS)、20.04(LTS)、18.04(LTS)、23.04、22.10 用パッケージインストール
* Ubuntu Linux: Ubuntu 22.04(LTS)、20.04(LTS)、18.04(LTS)、23.04、22.10 用パッケージインストール
* openSUSE Linux: Leap15.5用パッケージインストール
* Redhat Linux: epel-9 用パッケージ・インストール; Fedora 37
 
Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢があります（詳細）：
 
* Windows Subsystem for Linux（Ubuntu、openSUSEなどベース）を使用する。
* クロスコンパイルされたネイティブ実行ファイル
* docker インストール
 
OpenFOAMのapptainerサポートは、事前にアセンブルされたイメージではなく、記述ファイルによって提供されます。
 
* パッケージング/コンテナ参照
 
Mac OSXユーザーは、ソースからコンパイルするか、Dockerコンテナを使ってコンパイル済みのパッケージを使用するオプションがあります（詳細）。
 
== アップグレード ==
 
=== 省略と削除 ===
 
==== 境界条件 ====
exprFixed境界条件とexprMixed境界条件に、ランタイム非推奨の警告が表示されるようになりました。同じ機能（およびそれ以上）は、それぞれuniformFixedValue境界条件とuniformMixed境界条件で利用できます。
 
=== 名前変更 ===
 
=== ファンクションオブジェクト：patchPostProcessingとpatchParticleHistogram ===
ラグランジュ関数オブジェクトpatchPostProcessingとpatchParticleHistogramは、わかりやすさと理解を深めるために、それぞれparticlePostProcessingとparticleHistogramに名称が変更されました。
 
=== 入力辞書 ===
不必要な丸め誤差や精度低下を避けるため、#calcと#evalの固定フォーマットと精度制限が削除された。式が評価される際の文字列展開がより一貫したものになるはずです。
 
==== 表現 ====
 
* パッチ式で、face()/area()と書く代わりに、normal()を使って単位法線を求めることができるようになりました。
 
==== 関数オブジェクト: electricPotential ====
電場（E）の計算と出力は、以前のキーワード writeDerivedFields に代わって、オプションのキーワード electricField を使用することで有効または無効にすることができます。また、電場（E）の名前は、新しいキーワード E で指定できるようになりました。
 
==== 関数オブジェクト: yPlus, wallShearStress ====
yPlusとwallShearStressの両方で、オプションのwriteFieldsフラグが追加され、ボリュームフィールドの出力を無効にできるようになりました。これは、ログに記録された情報のみに関心がある場合に、ディスク容量を節約し、速度を向上させるのに便利です。
 
=== パラレル ===
 
==== FOAM_IORANKSの柔軟な取り扱い ====
 
* は、従来のOpenFOAMのリストと同様に、プレーンなリスト(スペースまたはカンマ区切り)も受け付けます。これにより、ジョブスクリプトでの引数の取り扱いが簡単になります。例えば
<syntaxhighlight lang="bash">
simpleFoam -ioRanks 0,4,8 ...
 
</syntaxhighlight>対<syntaxhighlight lang="bash">
simpleFoam -ioRanks '(0 4 8)'  ...
 
</syntaxhighlight>ホストごとにIOランクを選択することも可能である：<syntaxhighlight lang="bash">
simpleFoam -ioRanks host  ...
</syntaxhighlight>
 
==== MPIスレッドのコマンドライン指定 ====
 
* MPI_THREAD_MULTIPLE を持つことは、通常、パフォーマンス上好ましくないが、リンクされたライブラリがMPI_THREAD_MULTIPLE を期待する場合には必要な場合もある。mpi-threads コマンドラインオプションを使用すると、MPI_THREAD_MULTIPLE を明示的に指定することができます。
 
==== parProfilingの詳細 ====
parProfilingは、より詳細な情報を得るために、異なるMPIオペレーションをより分離するようになった：
 
* ブロードキャスト・タイムとリデュース／ギャザー／スキャッター・タイムを分離
* 一般的な待ち時間とすべての待ち時間の比較
* リクエストの時間/カウントを他のカウントと分離して、呼び出しカウントをサポートする（他のカウントがマスクされないようにするため）。
 
=== 有限面積の改善 ===
最小エッジ長のチェックがより一貫性を持ち、小さなエッジの存在下でもロバスターとなった。2次元テンソルの逆変換の取り扱いが改善され，有限面積における最小二乗法がロバスターになった．
 
=== メッシュ生成 ===
 
==== makeFaMesh ====
スター "接続の中心や、パッチ面が実際にはバッフルであるために発生する、多重接続された有限面積のエッジを処理するためのヒューリスティックが追加された。
 
直列の場合、これらの内部エッジはモデル化という点ではかなり疑わしいが、プロセッサーのドメインにまたがって分割されると、かなりの問題を引き起こす。接続性を一意に決定するのに十分な情報があるとは限らないが、エッジを結合するための何らかの救済措置はしばしば可能である。余分な "ぶら下がった "エッジは無視パッチに追いやられ、別々に扱われるようになります。
 
これらのヒューリスティックは、遭遇したいくつかの問題を解決するものではあるが、さらなる研究が必要である。
 
=== メッシュチェック／後処理 ===
 
==== checkMesh ====
 
* checkMeshとmakeFaMeshにグローバルトポロジーチェックを追加し、境界パッチがエッジ間で多重接続されている場合にそれを検出するようにした。
* checkMeshの新しい-write-edgesオプション：トポロジー的に問題のあるエッジをディスクに書き出すことができます。この新機能は有用な診断補助となります（特に、不正なエッジがあっても壊れにくい有限面積メッシュの場合）。
 
==== foamToVTK ====
foamToVTKを-no-internalおよび-no-boundaryオプションで実行すると、フィールドの読み込みと報告がすべて抑制され、速度が大幅に向上する。


openSUSE Linux: Leap15.5用パッケージインストール
フィールドを用いた通常の変換では、ロードされたボリュームフィールドは点補間で再利用するために一時的にキャッシュされる。これにより、入力IOが削減され、実行時間が改善される。


Redhat Linux: epel-9 用パッケージ・インストール; Fedora 37
== 前処理 ==


Windowsユーザーには、コンパイル済みパッケージについて3つの選択肢があります（詳細）：
=== snappyHexMesh：過剰なバランシングの回避 ===
snappyHexMeshはセルを並列に精錬する際に自動的にメッシュのバランスを取ります。snappyHexMeshDict入力ファイルのcastellatedMeshControlsセクションの新しいコントロールはこの処理を調整するために使用することができます：
 
* maxCellUnbalance : [オプション] 絶対的なアンバランス開始トリガー。セル数が少ない場合に、最初の洗練反復でバランシングを回避するために使用される。トリガー値はバランシングをスキップするために使用される：
** どのプロセッサでも、新しく追加されたセルの数 <= maxCellUnbalance の場合
** いずれかのプロセッサの場合：（プロセッサの新しいセル数 - 理想的なセル数） <= maxCellUnbalance
* balanceAtEnd : [オプション] maxCellUnbalanceエントリーがメッシュのアンバランスを引き起こす可能性があるため、メッシュが完全にリファインされた後に強制的にバランシングを行う。
* (existing) maxLoadUnbalance : ある程度のアンバランスを許容する。
 
これらの追加制御を用いることで、コア数が多い場合、キャステレーション段階で大幅なスピードアップが実現した。なお、スナッピングとレイヤー追加フェーズは影響を受けない。
 
Source code
 
* $FOAM_SRC/mesh/snappyHexMesh/snappyHexMeshDriver
 
Merge request
 
* MR!607
 
=== checkMeshの改良 ===
checkMeshは自動的にプロセッサ・パッチのレポートをフィルタリングしますが、そのプロパティは有用です。このリリースでは、プロセッサ・パッチのフィルタリングは並列実行のみに制限されています。
例として、シリアルで走る：
<code>checkMesh -case processor0 -allTopology -allGeometry</code>
報告：
<code>Checking patch topology for multiply connected surfaces...
    Patch              Faces    Points    Surface topology  Bounding box
    front              2275    2399    ok (non-closed singly connected)  (-0.572 -1 0.007621454194) (-0.17456 1 0.02497405934)
    ..
    procBoundary0to1    101      204      ok (non-closed singly connected)  (-0.19184 -1 -0.008375915288) (-0.17456 1 0.008375915288)
    ".*"                4796    4798    ok (closed singly connected)      (-0.572 -1 -0.02497405934) (-0.17456 1 0.02497405934)</code>
個々のプロセッサ境界のレポートに注意してください。これは、全体の境界面のエントリ（".*"）にも含まれます。並列実行の場合、v2212と同様に、プロセッサパッチはリストと全体の境界面から除外されます。
 
Source code
 
* $FOAM_UTILITIES/mesh/manipulation/checkMesh
 
Issue tracker
 
* !698
 
== 数値 ==
 
=== finiteAreaの新しいキャッシュグラデーションメカニズム ===
もともと有限体積フレームワークで利用可能だった）勾配キャッシング・メカニズムが、有限面積フレームワークにも適用された。
有効にすると、従属フィールドが変更されたときにのみ勾配フィールドが計算され、後で再利用できるようにメッシュデータベースのメモリに保存されるため、追加コストのかかる再評価を省くことができます。
 
system/faSolutionファイルでの使用例を以下に示す：
<code>cache
{
    grad(h);
    grad(Us);
}</code>
Source code
 
* $FOAM_SRC/finiteArea/finiteArea/gradSchemes/faGradScheme/faGradScheme.H
 
Merge request
 
* MR!611
 
=== 新しい並列プリコンディショナ ===
新しいプリコンディショナdistributedDILU, distributedDICは、DILU, DICプリコンディショナにRed-Black型の並列動作のバリエーションを追加したものである。これらの新しいプリコンディショナは、GAMGソルバーの最も粗いレベルを解くのに特に有用である：
<code>p
{
    solver          GAMG;
    // Explicit specify solver for coarse-level correction to override
    // preconditioner
    coarsestLevelCorr
    {
        solver          PCG;
        preconditioner  distributedDIC;
    }
} </code>
コア数が非常に大きい場合、スケーリングのボトルネックは、最も粗いレベルの解における大域的な削減となる可能性があり、分散プリコンディショナーは、（追加のハロースワップを犠牲にして）掃引量と削減量を減らすことができる。4096コアの大規模な場合：
 
この性能上の利点は、タイミングに表れている：
{| class="wikitable"
!preconditioner
!Execution time
|-
|DIC
|8687s
|-
|distributedDIC
|6326s
|}
分散型プリコンディショナの使用は、一般に、計算が大域的なリダクションに束縛される場合にのみ意味を持つことに注意してください。非分散型と比較すると、ハロースイープを追加する代償として、CGスイープ回数（および削減回数）を減らすことができます。少ないコア数では、これは有益ではないかもしれない。CG掃引の回数がとにかく少ない場合、例えば相対公差で解く場合も同様です。
 
同じ戦略は、他の結合境界条件、例えばサイクリック、サイクリックAMIにも適用できる。前方ループでは、'owner'パッチに対する'neighbor'の効果が含まれ、後方ループではその逆の効果が含まれます。これはcoupledスイッチで切り替えます（デフォルトはon）：
<code>solver          PCG;
preconditioner  distributedDIC;
coupled        false;  // do not precondition across non-processor coupled</code>
cyclicAMIの場合、2つのサイドが異なるプロセッサー上に排他的に存在するか、まったく分散されていない必要があるという制限がある。
 
新しいプリコンディショナーは構築するのにかなりコストがかかるため、線形ソルバー内部にキャッシュされる。これは、GAMG内部の最も粗いレベルの補正ソルバーにのみ影響する。
 
Source code
 
* $FOAM_SRC/meshTools/matrices/lduMatrix/preconditioners/distributedDILUPreconditioner/distributedDILUPreconditioner.H
* $FOAM_SRC/meshTools/matrices/lduMatrix/preconditioners/distributedDILUPreconditioner/distributedDICPreconditioner.H
 
References
 
* Yousef Saad, Iterative Methods for Sparse Linear Systems (2nd edition)
 
Merge request
 
* MR!608
 
=== 新しいFPCG線形ソルバー ===
PCG線形ソルバーの新しいドロップイン代替であるFPCGは、1掃引あたりの削減回数を3回から2回に削減します。これにより、特にGAMG線形ソルバーで最も粗いレベルを解くときに、並列削減がボトルネックになる可能性のあるコア数が大きい場合に、並列スケーリングが改善されるはずです。
このソルバーは、リダクションの数と追加ストレージ/パイプライン量のトレードオフを提供します。これは、ハロースワップとリダクションをオーバーラップさせるPPCGソルバーと比較することができます（しかし、追加のストレージが必要です）。
 
FPCGは、1つの余分なプリコンディショニングステップを必要とするため、より複雑なプリコンディショナー（例えばGAMG）にとってはあまり有益でない可能性があることに注意されたい。
 
Attribution
 
* OpenCFD would like to acknowledge and thank Alon Zameret of Toga Networks for providing the code and elaborate discussions.
 
Source code
 
* $FOAM_SRC/matrices/lduMatrix/solvers/FPCG/FPCG.C
 
Merge request
 
* MR!601
 
=== テンソル反転の処理の改善 ===
テンソルの逆変換は、例えば最小二乗法計算に必要であり、テンソルの値が面内、例えば本質的に2Dである場合には特に厄介です。このような場合は、「安全な」逆変換アプローチによって処理されるようになり、擬似逆変換のようなコストのかかるオーバーヘッドなしにロバスト性が追加されます。この変更は、主にいくつかの有限面積スキームのロバスト性に影響します。
 
=== メッシュセル/ポイント計算の改善（高速化） ===
セルからポイント、またはポイントからセルへのアドレッシングの情報は、異なるアルゴリズ ムに必要とされる。このタイプのアドレッシングは計算するのに比較的コストがかかるので、可能な限りキャッシュされ、不足するアドレッシングを導き出すために再利用される。
これは通常1回限りのコストであるが、キャッシュされた値を無効にするようなトポロジーの変更を伴うメッシュでは、より大きな要因になる可能性がある。アドレッシングを再構築するための更新されたアプローチは、速度を1.4倍から2.4倍に向上させる。
 
Attribution
 
* OpenCFD would like to acknowledge and thank Toga Networks for providing the code and elaborate discussions.
* issue 2715
* MR!596
 
== ソルバーと物理モデル ==
 
=== 改良されたvanDriest LESデルタモデル ===
vanDriest LESデルタモデルでは、最も近い壁の特性（y*）が局所的な長さスケールを計算するために使用されます。以前のリリースでは、これらの壁のプロパティは、壁の距離（meshWave）を計算するために同じメカニズムを使用して輸送されていました。このリリースでは、アドレッシングは一度計算され、最も近い壁の情報を直接取得できるようにキャッシュされます。これにより、（余分なストレージを必要としますが）大きなメッシュで非常に大きなスピードアップが得られます。さらに、同じアドレッシングは、fvSchemesの新しいmeshWaveAddressing wallDistメソッドを使用して、壁の距離自体にも使用できます：
<code>wallDist
{
    method meshWaveAddressing;
    // Fetch the nearest wall normal
    nRequired      true;
    // Optional entry delaying wall distance update to every n steps
    // Default is 1 (update every step)
    updateInterval 5;
} </code>
次の画像は、ExaFoamプロジェクトの一環として実証された、これらの改善による強力なスケーリング性能を示している：
 
Source code
 
* $FOAM_SRC/TurbulenceModels/turbulenceModels/LES/LESdeltas/vanDriestDelta
 
Resolved bugs
 
* !2648
 
=== 新しいラグランジュ粒子力 クーロン ===
新しいクーロン有限体積オプション(fvOption)は、電場を評価するためのelectricPotential関数オブジェクトの本質的な基礎的な変更とともに、直径に基づいて粒子に作用する静電気力のモデルを提供します。カップリングは現在一方通行です。
最低限の使用例を以下に示す：
<code>subModels
{
    solution
    {
        interpolationSchemes
        {
            <Ename>      <interpolationScheme>;  // Electric field name
        }
    }
    particleForces
    {
        Coulomb
        {
            q      <Function1<scalar>>;  // Electric charge of particles
            E      <word>;              // Electric field
        }
    }
}</code>
Source code
 
* $FOAM_SRC/lagrangian/intermediate/submodels/Kinematic/ParticleForces/Coulomb
 
Merge request
 
* MR!602
 
=== 新しいfvOption：fanMomentumSource ===
新しいfanMomentumSource有限体積オプション（fvOption）は、流れに対するファンの作用を表現する運動量ソースを追加します。
まず、セルゾーンを囲む上流側の面を通過する流量が計算される。上流側の面は流れ方向と周囲の面ゾーンを用いて自動的に決定される。続いて、流量の関数としてのファン圧力曲線とファン（測定部）の厚さから圧力勾配を求める。
 
最小限の使用例は以下の通り：
<code>fan
{
    // Mandatory entries
    type                fanMomentumSource;
    fanCurve            <Function1<scalar>>;
    flowDir            <vector>;
    thickness          <scalar>;
    cellZone            <word>;
    faceZone            <word>;
    // Optional entries
    gradient            <scalar>;
    rho                <scalar>;
    U                  <word>;
    // Inherited entries
    selectionMode      <word>;
    ...
}</code>
Source code
 
* $FOAM_SRC/fvOptions/sources/derived/fanMomentumSource
 
Merge request
 
* MR!604
 
Attribution
 
* OpenCFD would like to acknowledge and thank Vuko Vukcevic of SimScale GmbH for providing the code and elaborate discussions.
 
=== 新しい fvOption: limitTurbulenceViscosity。 ===
新しいlimitTurbulenceViscosity有限体積オプション(fvOption)は、計算の安定性を高める乱流粘度nutを制限するメカニズムを提供します。
乱流粘性場は、層流粘性に係数を乗じた上限値を適用することで、指定された領域内で補正される：
 
最小限の使用例は以下の通り：
<code>limitTurbulenceViscosity1
{
    // Mandatory entries
    type            limitTurbulenceViscosity;
    // Optional entries
    nut            nut;
    c              1e5;
    // Inherited entries
    ...
}</code>
Source code
 
* $FOAM_SRC/fvOptions/corrections/limitTurbulenceViscosity
 
=== 改良された剛体運動拘束：軸 ===
軸拘束は、ボディが固定軸の周りにしか回転できないような方向制限を課します。これは、例えばバタフライバルブをモデル化するために、最小回転角度と最大回転角度を追加することで強化されました。
さらに、すべての剛体運動制約がランタイムで調整可能になった。
 
最小限の使用例は以下の通り：
<code>constraints
{
    constrainRotation1
    {
        sixDoFRigidBodyMotionConstraint    axis;
        axis                                <vector>;
        // Optional entries
        maxClockwiseTheta                  <Function1<scalar>>;
        maxCounterclockwiseTheta            <Function1<scalar>>;
        thetaUnits                          <word>;
        referenceOrientation                <tensor>;
    }
}</code>
Source code
 
* $FOAM_SRC/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion/constraints/axis
 
Merge request
 
* MR!613
 
== 境界条件 ==
 
==== 新しい境界条件：鏡面放射 ====
fvDOM放射モデルは、新しいspecularRadiation境界条件を使用して、軸対称および対称面セットアップに適用できるようになりました。
この境界条件の最小限の例を以下に示す：
<code>{
    // Mandatory entries
    type                specularRadiation;
    // Optional entries
    interpolate        <bool>;
    // Inherited entries
    patchType          <word>;
    ...
} </code>
下図は、4つの異なる形状の内部無次元入射放射の観点から条件を検証したものである：
 
Source code
 
* $FOAM_SRC/thermophysicalModels/radiation/derivedFvPatchFields/specularRadiation
 
References
 
* Standard model:
** Kumar, P., & Eswaran, V. (2013). A methodology to solve 2D and axisymmetric radiative transfer problems using a general 3D solver. Journal of heat transfer, 135(12). DOI:10.1115/1.4024674
 
Merge request
 
* MR!610
 
Attribution
 
* OpenCFD would like to acknowledge and thank Hitachi Energy for sponsoring the development, and Bernardo Galletti and Marcelo Buffoni for elaborate discussions.
 
=== 新ユニフォーム混合コンディション ===
新しいuniformMixed境界条件は、既存のuniformFixedValue境界条件とuniformFixedGradient境界条件を補完するものです。
この条件は混合境界条件を定義するために使用され、値を定義するために関数を使用する。
<code>{
    type            uniformMixed;
    uniformValue    constant 0.2;
    uniformGradient constant 0.2;
    uniformValueFraction
    {
        type  sine;
        ...
    }
}</code>
しかし、境界条件は遅延定義を許可しているため、uniformValueまたはuniformGradientの一方だけを定義し、他のエントリーを暗黙的に定義することも可能である。
 
uniformMixedで使用される関数には式も含まれるため、この新しい境界条件は、将来非推奨となり削除される既存のexprMixed境界条件のより柔軟な形として使用することができる。
 
Source code
 
* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformMixed
 
Tutorial
 
* $FOAM_TUTORIALS/compressible/rhoPimpleFoam/RAS/TJunctionAverage/0/U
 
=== 新しい有限領域境界条件 ===
有限面積計算でuniformFixedValue、uniformFixedGradient、uniformMixed境界条件が使用できるようになりました。
これらの境界条件はFinite Areaに関数と式のサポートを追加します。timeVaryingUniformFixedValue境界条件は非推奨となり、将来削除される予定です。
 
Source code
 
* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformFixedValue
* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformFixedGradient
* $FOAM_SRC/finiteArea/fields/faPatchFields/derived/uniformMixed
 
== 後処理 ==
 
=== ラグランジュ関数オブジェクトの改良 ===
ラグランジアン・クラウド・ファンクション・オブジェクトは複数のアップデートを受けた：
 
* patchPostProcessingとpatchParticleHistogramは、それぞれの機能をよりよく反映させるために、それぞれparticlePostProcessingとparticleHistogramという名前に変更されました；
* writeFileサポートが追加され、ファイル出力の制御が改善された。
* faceZoneのサポートが追加され、パーティクル収集のコントロールが向上しました。
 
最低限の使用例を以下に示す：
<code>ParticlePostProcessing1
{
    // Mandatory entries
    type                particlePostProcessing;
    maxStoredParcels    <scalar>;
    // Optional entries
    fields              (<wordRes>);
    // Conditional entries
        // Option-1
        patches          (<wordRes>);
        // Option-2
        faceZones        (<wordRes>);
    // Inherited entries
    // writeFile entries
    ...
}
particleHistogram1
{
    // Mandatory entries
    type                particleHistogram;
    nBins                <label>;
    min                  <scalar>;
    max                  <scalar>;
    maxStoredParcels    <scalar>;
    // Conditional entries
        // Option-1
        patches          (<wordRes>);
        // Option-2
        faceZones        (<wordRes>);
    // Inherited entries
    // writeFile entries
    ...
}</code>
Source code
 
* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/ParticleHistogram
* $FOAM_SRC/lagrangian/intermediate/submodels/CloudFunctionObjects/ParticlePostProcessing
 
Merge request
 
* MR!595
 
=== 改良されたファンクション・オブジェクト：力とforceCoeffs ===
力とforceCoeffs関数オブジェクトは、実行時間を短縮するために最適化されました。
テストによると、以前は複数の力とforceCoeffs関数オブジェクトを使用すると、主に速度勾配の計算とさまざまな内部フィールドに対して実行される冗長な計算が原因で、総実行時間が2～10％の範囲でスローダウンしていた。
 
例えば、simpleCarチュートリアルのテストでは、速度勾配をキャッシュすることで補完した場合、力関数オブジェクトの実行時間が約3分の1に短縮されることが実証された。
 
Source code
 
* $FOAM_SRC/functionObjects/forces/forces
* $FOAM_SRC/functionObjects/forces/forceCoeffs
 
Merge request
 
* MR!598
 
== パラレル ==
 
=== parProfiling 関数オブジェクトの改良 ===
並列プロファイリング関数オブジェクト parProfiling の拡張により、プロファイリングを線形ソルバーに制限することができます。この関数オブジェクトは，controlDictで次のように指定します．
<code>functions
{
    // Run parProfiling
    profiling
    {
        libs    (utilityFunctionObjects);
        #includeEtc "caseDicts/profiling/parallel.cfg"
        detail  2;
    }
}</code>
これは、fvSolutionファイル内の新しいparProfilingラッパー・ソルバーの形をとります：
<code>solvers
{
    p
    {
        solver          parProfiling;
        baseSolver      PCG;
        preconditioner  DIC;
        tolerance      1e-06;
        relTol          0.05;
    }
}</code>
上記の例では、PCG線形ソルバーに対してのみparProfiling関数オブジェクトを有効にしています。この拡張は、GAMGソルバー内の最も粗いレベルの線形ソルバーの効果を見るときに特に便利です。
 
典型的な出力だ：
<code>parProfiling:
    reduce    : avg = 72.7133s
                min = 2.37s (processor 0)
                max = 88.29s (processor 4)
    all-all  : avg = 14.9633s
                min = 11.04s (processor 5)
                max = 17.18s (processor 4)</code>
例えば、20台のプロセッサーを使ったキャビティ・リッド・ドライブ・チュートリアルのように、異なる線形ソルバーの効果を調べるには、両方を組み合わせることが非常に有効です：


Windows Subsystem for Linux（Ubuntu、openSUSEなどベース）を使用する。
PCG の parProfiling 出力：
<code>reduce    : ..
    ..
    counts  20(14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875 14875)</code>
FPCG の parProfiling 出力：
<code>reduce    : ..
    ..
    counts  20(11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914 11914)</code>
Source code


クロスコンパイルされたネイティブ実行ファイル
* $FOAM_SRC/functionObjects/utilities/parProfiling/parProfilingSolver.H


docker インストール
Tutorial


OpenFOAM apptainerのサポートは、事前にアセンブルされたイメージではなく、記述ファイルによって提供されます。
* $FOAM_TUTORIALS/IO/cavity_parProfiling


パッケージングを参照
Merge request


* MR!603


== Upgrading ==
=== スコッチ - マルチレベル分解をサポート ===
multiLevel分解法は、ノード内（より高速な通信を使用）よりもノード間カット（低速な通信を使用）の量を優先的に制限するために使用することができる。この機能は、重みのセットを指定することで、スコッチ（ptscotchではない）分解法にネイティブに存在するようになった：
<code>method              scotch;
numberOfSubdomains  2048;
coeffs
{
    // Divide into 64 nodes, each of 32 cores
    domains (64 32);
    // Inside a nodes the communication weight is 1% of that inbetween nodes
    domainWeights (1 0.01);
}</code>
あるいは、そのレベルの重みを1として、第1レベルの分解を省略することもできる：
<code>method              scotch;
numberOfSubdomains  2048;
coeffs
{
    // Divide into 2048/32=64 nodes
    domains (32);
    // Inside a node the communication weight is 1% of that inbetween nodes
    domainWeights (0.01);
} </code>
下の画像は、20x20の単純なメッシュを32分割したものである：


マルチレベル・メソッドと比較すると、次のようになる。


* multiLevelサブセットは、各第1レベルの分解を第2レベルに分解する。セル数が多くなると、これがボトルネックになる。
* multiLevelメソッドで時々起こるような、過剰な数のプロセッサ・パッチを作成することを避けることができる。


== Pre-processing ==
残念なことに、この機能は外部のptscotchライブラリには実装されていない。いったん利用できるようになれば、ptscotch分解メソッドに追加するのは簡単だ。


Source code


* $FOAM_SRC/parallel/decompose/scotchDecomp/scotchDecomp.C


== Numerics ==
Merge request


* MR!599


== Solvers and physical models ==
=== ノンブロッキング線形ソルバー ===
並列で実行する場合、線形ソルバーは、受信したデータを使用して境界条件（'インターフェース'）を更新する前に、すべての通信が終了するのを待ちます。このため、通信の1つが他の通信より遅い場合、ボトルネックになることがあります。例えば、接続が遅い、インターフェイスの面が多いなどです。
これを避けるために、インターフェイスのポーリングを有効にし、インターフェイスが 「ready」になったときにインターフェイスの更新を実行するnPollProcInterfaces最適化スイッチが導入された。このスイッチは、一定の反復回数（その後にブロッキング待ちが続く）か、ポーリングのみの場合は「-1」（新機能）である：


etc/controlDictまたはローカルシステム/controlDictで、nPollProcInterfacesを-1に設定する：
<code>OptimisationSwitches
{
    // Fixed or infinite (-1) number of polling iterations
    nPollProcInterfaces -1;
}</code>
一般論として：


== Boundary conditions ==
* 十分なローカルワークがある場合、つまりプロセッサインターフェースの解を追加する場合、通信とオーバーラップさせることに意味がある場合に使用する。GAMGの最も粗いレベルでは、これは当てはまらない。
* プロセッサ・インターフェースの最小サイズと最大サイズ、つまり面の数に大きな差がある場合に使用する。これは、幾何学的分解法などではあり得るが、スコッチなどの位相分解法では一般的ではない。


大きな欠点は、解の追加順序が非決定的になり、例えば、pitzDaily非圧縮チュートリアルを（悪い）ソルバーの組み合わせで実行すると、切り捨て誤差に影響することです：
<code>p
{
    solver          PCG;
    preconditioner  diagonal;
    tolerance      1e-06;
    relTol          0.1;
}</code>
は、100回の繰り返しで顕著な解の違いを生み出す：


* ポーリングなし:


== Post-processing ==
    <code>diagonalPCG:  Solving for p, Initial residual = 0.012452, Final residual = 0.0012432, No Iterations 162</code>


* ポーリング:


    <code>diagonalPCG:  Solving for p, Initial residual = 0.012544, Final residual = 0.0012536, No Iterations 301</code>


== Parallel ==
=== マスターコースター凝集の改善 ===
多くのコアでGAMGを実行する場合、PCGなどの最も粗いレベルのソルバーがスケーリングのボトルネックになる可能性があります。これを回避する1つの方法は、粗いレベルの行列をより少ない、あるいは1つのプロセッサに集約することです。これは、プロセッサの行列を集めて、プロセッサ間の境界をすべて内部の面に置き換えた、単一の大きな行列を作成するものです。これにより、通信は回避されるが、この凝集行列を解くプロセッサの計算コストが増加する。例えば、元の凝集が10000個のプロセッサで1セルまでだった場合、凝集した行列は少なくとも10000個のセルを持つことになり、これを解くことがボトルネックになる可能性がある。
この開発では、masterCoarsestプロセッサーのアグロメレーションは、ローカルアグロメレーションを再スタートして、10000セルをより少ないセルに戻すことができる。この新しい動作はfvSolutionの新しいパラメータnCellsInMasterLevelによってトリガーされる。
<code>p
{
    solver          GAMG;
    ..
    smoother        GaussSeidel;
    //- Local agglomeration parameters
    nCellsInCoarsestLevel  1;
    //- Processor-agglomeration parameters
    processorAgglomerator  masterCoarsest;
    //- Optionally agglomerate after processor-agglomeration
    nCellsInMasterLevel    1;
}</code>


==== 結果 ====
単純なテストケースとして、pitzDailyチュートリアルを15プロセッサで並列実行するように修正しました（分解方法としてscotchを使用）。masterCoarsestを使用し、凝集の再起動を行わない場合、最初の反復は次のようになります。
<code>DICPCG:  Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0.0788583, No Iterations 6
DICPCG:  Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0.0150588, No Iterations 6
..
DICPCG:  Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0.0105486, No Iterations 6
GAMG:  Solving for p, Initial residual = 1, Final residual = 0.0759038, No Iterations 24</code>
nCellsInMasterLevel 1：
<code>DICPCG:  Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0, No Iterations 1
DICPCG:  Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 1.11661e-16, No Iterations 1
..
DICPCG:  Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0, No Iterations 1
GAMG:  Solving for p, Initial residual = 1, Final residual = 0.0799836, No Iterations 24</code>
Source code


* $FOAM_SRC/OpenFOAM/matrices/lduMatrix/solvers/GAMG/GAMGProcAgglomerations/masterCoarsestGAMGProcAgglomeration/masterCoarsestGAMGProcAgglomeration.H


== Usability ==
Merge request


=== New documentation system ===
* MR!600
The previous Extended Code Guide has been migrated from a Doxygen-based system to nanoc-based system (the same system as used by Gitlab.com) and made public for Community Contributions. The new content is available from <nowiki>https://doc.openfoam.com</nowiki>:


* v2306: <nowiki>https://doc.openfoam.com/2306/</nowiki>
=== 並列（MPI）処理の全般的な変更 ===
* v2212: <nowiki>https://doc.openfoam.com/2212/</nowiki> (old release)
最近のexaFOAMの活動から得られた知見により、OpenFOAMのPstreamライブラリ（MPIインターフェース）の低レベルの改良と、コードベース全体の通信ボトルネックを低減するためのアルゴリズムとコードの変更が多数行われました。しかし、これらの変更のほとんどは、大規模シミュレーションにおいてのみ効果が現れます。アルゴリズムの変更の一部は*プレビュー*の変更とみなされるため、デフォルトでは有効ではなく、設定スイッチによって有効になります。
コード開発者向けに、MPIリクエストとコミュニケータの取り扱いが拡張され、独自の並列アルゴリズムを書く際に、より柔軟に対応できるようになりました。ノンブロッキングコンセンサス交換(NBX)を使ったサイズ交換の取り扱いが、 全対全交換のドロップイン置き換えとして提供されます。


The site has a new look and feel, and has received significant content updates, including a quick start, many new boundary conditions, thermophysical models, tools including noise, and much more!
== ユーザビリティ ==


=== 新しい文書システム ===
以前の拡張コードガイドはDoxygenベースのシステムからnanocベースのシステム（Gitlab.comで使われているのと同じシステム）に移行され、コミュニティ貢献のために公開されました。新しいコンテンツはhttps://doc.openfoam.com：


The content is hosted at <nowiki>https://gitlab.com/openfoam/documentation</nowiki> - it is continuously evolving and further updates will follow.
* v2306: <nowiki>https://doc.openfoam.com/2306/</nowiki>
* v2212: <nowiki>https://doc.openfoam.com/2212/</nowiki> (old release)


We welcome your feedback, and encourage you to get involved - we're happy to receive pull requests!
このサイトは新しいルック＆フィールで、クイックスタート、多くの新しい境界条件、熱物理モデル、ノイズを含むツールなど、大幅なコンテンツ更新が行われた！


コンテンツはhttps://gitlab.com/openfoam/documentation。継続的に進化しており、さらなるアップデートが予定されている。


=== Changes to expressions ===
プルリクエストも喜んでお受けします！
Expression evaluation now includes normal() as a function. This returns the unit normal of mesh faces - a more robust equivalent to face()/area() with fewer operations.
=== 表現の変更 ===
式の評価関数にnormal()が追加されました。これはメッシュ面の単位法線を返すもので、face()/area()より少ない操作でよりロバストなものとなります。
「https://wiki.opencae.or.jp/index.php/特別:携帯機器差分/833」から取得

案内メニュー