OpenFOAM v1906 リリースノート

いつものやつです。

原文はこちらです。

https://www.openfoam.com/releases/openfoam-v1906/

OpenCFDリリースOpenFOAM®v1906

19/06/2019

OpenCFDは、2019年6月にリリースされたOpenFOAM®v1906を発表しました。 このリリースでは、コードの多くの分野でOpenFOAM-v1812の機能が拡張されています。 この新しい機能は、OpenCFDの顧客が後援する開発、内部資金による開発、そしてOpenFOAMコミュニティからの機能と変更の統合を表しています。

OpenFOAMはOpenPLDによってGPLライセンスの下で配布されています。

任意のLinuxシステムでコンパイルされるソースコード Linuxシステム用のコンパイル済みバイナリインストール Mac OS Xシステム用のコンパイル済みバイナリインストール MS Windowsインストーラ MS Windows 10用のWindows上のUbuntu上でのbash

ダウンロード手順を参照してコードを入手してください。

開発リポジトリは公開されています。 これらのリポジトリは、バグ修正と新機能で定期的に更新されています。

アップグレード

ユーザーのためのヘルプはユーザーアップグレードガイドにあります。 開発者向けのヘルプは開発者アップグレードガイドにあります。

プリプロセッシング 辞書の条件

辞書は#ifまたは#ifeqを使った条件付きをサポートするようになりました。 典型的な用途は、単一の辞書でさまざまなバージョンのコードをサポートすること、またはさまざまなアプリケーションに対してさまざまな入力をサポートすることです。

アプリケーションごとに異なる入力

例として、新しい「exactDistance」の壁距離計算を使用しようとしました。 現時点では、decomposeParDictディクショナリで選択されている階層的分解方法が必要です。 しかしながら、実際の分解のためには、例えばで実行することが好ましい。 スコッチ

numberOfSubdomains 10;

1. ifeq $FOAM_APPLICATION decomposePar

    method scotch;

1. else

    method hierarchical;     coeffs     {         n  (5 2 1);     }

1. endif

OpenFOAMのバージョンごとに異なる入力

次の例は、さまざまなコードバージョンにさまざまなキーワードを設定するための条件付きステートメントの使用方法を示しています。

1. ifeq $WM_PROJECT_VERSION plus

    // Get version number as dictionary entry. This is only so     // the follow-on test can use dictionary expansion     versionNo $FOAM_API;     // Do comparison (using dynamic code compilation)     #if #calc "$versionNo<1812";         version "pre-1812";     #else         version "post-1812";     #endif

1. else

    version "Unofficial version of OpenFOAM";

1. endif

foamDictionaryを使用してこの例を実行すると、v1906のバージョン1812以降とバージョン1818のバージョン1812前が印刷されます。 v1706

Source code $FOAM_SRC/OpenFOAM/db/dictionary Tutorial $FOAM_TUTORIALS/IO/dictionary/good-if.dict snappyHexMesh：ドライラン運転

snappyHexMeshは、空走機能で拡張されました。 そうなる：

snappyHexMeshDictのオプションではない辞書エントリをすべて確認してください。 エラー/警告はすべて照合されます。 入力ジオメトリ、つまりサーフェスとフィーチャの存在を確認する 初期メッシュが座標軸で整列しているかどうかを確認します（これは許可されているので警告です）。 ジオメトリが初期メッシュのバウンディングボックス内にあるかどうかを確認します（警告のみ） メッシュの内側/外側の位置が初期メッシュの内側にあるかどうかを確認します すべての改良レベルと初期セルサイズから予想されるセルサイズを出力する セル数の「推定値」を出力します。 これはInMeshの洗練レベルと位置を考慮に入れますが、機能の洗練とレイヤを見逃します。

一般的な出力は次のとおりです。

--> FOAM Warning :     motorBike bounds not fully contained in mesh         bounding box      : (-0.291665 -0.350289 -4.232e-05) (1.75115 0.332267 1.35152)         mesh bounding box : (-5 -4 0) (15 4 8)Cell size estimate :     Level  0 : 1     Level  6 : 0.015625

Voxellating initial mesh : (320 128 128)

Voxel refinement :     Initial                      : (5242880)     After removing outside cells : 1(0)     After surface refinement     : 6(0 0 0 0 0 3146)     After keeping inside voxels  : 6(5239395 0 0 0 0 3146)     After shell refinement       : 6(5116160 0 0 0 123574 3146) Estimated cell count : 149991

Source code $FOAM_SRC/mesh/snappyHexMesh snappyHexMesh：メモリ最適化

snappyHexMeshは、redistributeParフレームワークを使用して頻繁な負荷分散を実行します。 これには、すべてのプロセッサが受信するセル数を知る必要があります。 以前のバージョンでは、この情報はグローバルブロードキャストを使って配布されていました。 このバージョンでは、受信するセルのローカル量のみが通信されるため、約4000コア以降で大幅にメモリを節約できます。

Source code $FOAM_SRC/dynamicMesh/fvMeshDistribute/ Attribution Investigation and fix by Y. Inoue at RIST snappyHexMesh：リラックスしたパッチの地域化

デフォルトでは、snappyHexMeshはリージョン間のエッジをできるだけ維持します。セルが異なるパッチ上に2つ以上の同一平面上にある面を持っている場合、それらは接続メッシュエッジを維持するためにマージされません。ただし、この動作はメッシュ品質を低下させるため、レイヤの追加を妨げる可能性があります。

このリリースでは、snappyHexMeshDictに2つの新しいオプションコントロールがあります。

mergePatchFaces：デフォルトはtrue mergeAcrossPatches：デフォルトはfalse

mergePatchFacesがfalseの場合、パッチフェースのマージは行われません。これにより、リファインメントおよびスナップ後のメッシュは、リファインメント/アンリファインメントとの互換性が保たれます。

mergePatchFacesがtrue（デフォルト）の場合、mergeAcrossPatchesが確認されます。これがfalse（デフォルト）の場合、異なるパッチにある場合はフェイスはマージされません。

この設定の効果は、2つの領域を持つ単純な三角球をメッシュするときに見られます。

右側は、各面がサーフェス領域に対応するパッチ内にあるデフォルトの動作です。これにより、サーフェス領域間のメッシュエッジが維持されます。左側は、面がフィーチャエッジと交差する場所でmergeAcrossPatchesを有効にした場合の効果です。これは幾何学的メッシュの質を向上させるでしょうが、より正確でない幾何学的立体配座を犠牲にしてより良いレイヤカバレッジを与えます：

Source code $FOAM_SRC/mesh/snappyHexMesh

数値 新しいアシスタント最適化

OpenFOAM v1906には、連続随伴法による自動グラデーションベースの最適化ループを対象とした主要な新しい機能セットの最初のリリースが含まれています。このコードは活発に開発中であり、将来の正式なOpenFOAMリリースでさらなる拡張機能がリリースされる予定です。

随伴法は工学量の勾配（または感度微分）を計算するために使用され、通常目的関数と呼ばれる。いくつかのいわゆる設計変数に関して、ドラッグ、リフト。空力形状をパラメータ化する制御点。随伴法の主な利点は、この勾配を計算するコストが、実際には設計変数の数に依存しないことです。これを達成するために、１組の随伴ＰＤＥを解いて目的関数の勾配を計算する。この低コストにより、以下に示すように、いわゆる感度マップ、すなわち境界ノードの法線変位に対する目的関数の勾配を数千または数百万の設計変数で計算することが可能になる。感度マップは、設計の初期段階で設計者を導き、最適化の可能性が最も大きい領域を特定するのに役立つ貴重なツールです。

OpenFOAM v1906は、壁関数の有無にかかわらず、Spalart-Allmarasモデルの区別もサポートする、非圧縮定常流への随伴を含みます。利用可能な目的関数には、外部空気力学に対する力とモーメント、および内部空気力学に対する全圧力損失が含まれます。感度は、境界壁の節点/面の法線方向の変位を基準にして計算されます。

流れ方程式および随伴方程式を解き、感度微分を計算する主な実行可能プログラムはadjointOptimisationFoamであり、多点計算もサポートしている。すなわち、流れ方程式および随伴方程式を解き、いくつかの動作条件で感度を計算する。

adjointOptimisationFoamに関連するほとんどのパラメータは、システムディレクトリにあるinput optimisationDictディクショナリを通じて設定されます。新しいPDEが解決されると、fvSolutionおよびfvSchemes辞書に追加のエントリが必要になります。随伴フィールドの境界条件も開始時間ディレクトリーに指定する必要があります。

Source code $FOAM_SOLVERS/incompressible/adjointOptimisationFoam  $FOAM_SRC/optimisation/adjointOptimisation/adjoint Examples $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam Attribution

このソフトウェアは、PCOpt / NTUAおよびFOSS GPによって開発されました。

Evangelos Papoutsis-Kiachagias博士、 コンスタンティノスGragragounis、 Kyriakos Giannakoglou教授、 アンドリューヘザー博士

以前のバージョンからの投稿と貢献

Ioannis Kavvadias博士、 アレクサンドロスジマリス博士、 博士Dimitrios Papadimitriou

References A.S. Zymaris, D.I. Papadimitriou, K.C. Giannakoglou, and C. Othmer. Continuous adjoint approach to the Spalart-Allmaras turbulence model for incompressible flows. Computers & Fluids, 38(8):15281538, 2009. E.M. Papoutsis-Kiachagias and K.C. Giannakoglou. Continuous adjoint methods for turbulent flows, applied to shape and topology optimization: Industrial applications. 23(2):255299, 2016. I.S. Kavvadias, E.M. Papoutsis-Kiachagias, and K.C. Giannakoglou. On the proper treatment of grid sensitivities in continuous adjoint methods for shape optimization. Journal of Computational Physics, 301:118, 2015. Integration コードはOpenCFDとNTUAによって共同で統合されました 改善された再起動動作

このリリースには、円滑な再起動動作を可能にするための改善が含まれています。 テストにより、複雑度が低いから中程度の圧縮不可能なケースでは、ビットパーフェクトな再起動が示されました。

累積された連続性エラーは、ファイル / uniform /累積的ContErrから読み書きされ、印刷された連続性エラーが正しく復元されるようになりました。

乱流モデルは必要に応じて評価および更新されています。 nutUSpaldingWallFunction境界条件は、摩擦速度を取得するための反復手順を実行し、誤差が指定された許容範囲内に減少すると終了します。 これを指定することができ、再起動時に初期ナット値が十分に収束していればそれを保持します。

type            nutUSpaldingWallFunction; tolerance       1e-9;

実行中にこの特殊な動作が引き起こされるのを避けるために、この許容誤差は厳しくする必要があります。

Source code $FOAM_SRC/finiteVolume/cfdTools/general/include/initContinuityErrs.H  $FOAM_SRC/TurbulenceModels/turbulenceModels/lnInclude/nutUSpaldingWallFunctionFvPatchScalarField.H 新しい壁距離法

いくつかの乱流モデルは最も近い壁パッチまでの距離を必要とします。 この距離を計算するための一連の方法は、正確な方法を含むように拡張されています。 これは壁のジオメトリを三角形分割し、分解とは無関係に、最も近い壁面の最も近い三角形上の正しい最も近い点を返します。

新しいメソッドは、ライブラリlibdistributed.soをcontrolDictセットアップに追加することで利用可能になります。

libs            ("libdistributed.so");

Select in system/fvSchemes the correct wallDist scheme:

wallDist {     method exactDistance; }

結果の距離は、applications / test / wallDistのテストアプリケーションTest-wallDistでテストできます。 たとえば、次の図は、上のパッチだけが壁タイプである、修正されたキャビティチュートリアルのケースの距離フィールドを示しています。

注：正確な距離法は他の変形と比較して複雑であり、距離場を計算するのにかかる時間に反映される。 大規模なケースでは：

meshWave : 33 s exact : 859 s Source code $FOAM_SRC/lagrangian/intermediate/submodels/HeterogeneousReactingModel Solver $FOAM_SOLVERS/lagrangian/reactingParcelFoam/reactingHeterogenousParcelFoam Tutorial $FOAM_TUTORIALS/lagrangian/reactingHeterogenousParcelFoam/rectangularDuct 改良されたGAMGソルバーコントロール

GAMGフレームワークは、最も粗いレベルで残差補正を解くために線形ソルバーを使用します。 これは現在です：

directSolveCoarsestが選択されている場合は直接ソルバー 反復CGソルバー。 対称行列の場合はDICPCG、非対称行列の場合はDILUPBiCGStab。 このリリースでは、反復コースレベルソルバーコントロールはユーザーが選択できます。

GAMGを使用する各ソルバー辞書は、最粗レベルソルバーの設定を含むサブ辞書coarsestLevelCorrをオプションで提供できるようになりました。 指定しない場合、許容差は親レベルのGAMGエントリから取得されます。

pFinal {     solver          GAMG;     tolerance       1e-6;     relTol          0;     smoother        GaussSeidel;    coarsestLevelCorr     {         solver          PCG;         preconditioner  DIC;         relTol          0.05;     } }

上の例では、PCGソルバーと0.05の緩い相対許容誤差を選択しています。 絶対許容誤差はGAMGsettingsから取得されます。

nCellsInCoarsestLevelエントリで定義され、デフォルト値が10であるセルが非常に少ないため、一般に粗いレベルで利用可能な最良のソルバーを使用することをお勧めします。並列実行の場合、粗いレベルのソルバー内の通信オーバーヘッドはパフォーマンス ボトルネック ここで、GAMGサイクルの全体数をわずかに増やしたとしても、粗レベル掃引の数を減らすことは有利です。 2つの便利なコントロールは

relTol：相対許容誤差を上書きします。 maxIter：最大反復回数をオーバーライドします。

テストとして、$ FOAM_TUTORIALS / pisoFoam / LES / motorBike / motorBikeLESチュートリアルを10回繰り返し実行しました。 粗いレベルのソルバーに緩い相対許容誤差を採用すると、PCGソルバーのスイープ数が大幅に減少しますが、GAMGサイクルの数はほぼ一定のままです。

system / controlDictに次のデバッグスイッチを設定することで、粗いレベルのソルバーのパフォーマンスを観察できます。

DebugSwitches {     // Print GAMG residuals of coarse-level solver     GAMG  1;     // Print some statistics on the agglomeration     GAMGAgglomeration 1; }

出力は、粗レベルソルバーの残差を含みます。

DICPCG:  Solving for coarsestLevelCorr, Initial residual = 1, Final residual = 0.489419, No Iterations 1

Tutorial $FOAM_TUTORIALS/pisoFoam/LES/motorBike/motorBikeLES 新しい混合精度

OpenFOAMは、倍精度スカラ（デフォルト）または単精度スカラで実行するようにコンパイルできます。 一般的に、単精度で実行できるのは単純な場合のみです。より複雑な場合、線形ソルバーは収束しないことがよくあります。

このリリースでは倍精度を使用して線形ソルバーをコンパイルし、単精度を使用して残りのコードをコンパイルする新しいオプションが含まれています。 新しいモードはSPDPで、コマンドで選択できます

wmSPDP

同様に、倍精度の場合はwmDP、単精度の場合はwmSP。 これは以下を設定します。

環境変数WM_PRECISION_OPTION = SPDP コンパイルフラグWM_SPDP

OpenFOAMヘッダのArchフィールドは、solveScalarキーワードによって線形ソルバで使用される浮動小数点のタイプを表示するようになりました。

Build  : 313d4fe2b5-20190612 OPENFOAM=1904 Arch   : "LSB;label=32;scalar=32;solveScalar=64" Exec   : blockMesh

単精度で実行することによる主な利点は、使用されるメモリにあります。 単精度ビルドは、倍精度よりも約40％少ないメモリを使用します。 これはOpenFOAMのような帯域幅が制限されたコードのパフォーマンスにも直接影響します。 複合精度では、倍精度と比較して、メモリ使用量が約30％少なくなり、パフォーマンスが20％向上します。 内部テストの結果、新しい設定は、統計的にほとんど差がなく、さまざまな大規模な外部エアロケースにわたってロバストであることが示されました。

混合精度は線形ソルバーにのみ影響します。 問題の領域が線形ソルバーの外側にある場合は役に立ちません。 次のものが混合精度で実行されることはほとんどありません。

snappyHexMesh cyclicAMI combustion Lagrangian

線形精度ソルバーのみが倍精度で動作するため、混合精度のフィールドは単精度で書き込まれます。 単精度から倍精度および倍精度から単精度への転送は、ASCIIフォーマットでのみサポートされています。

wmマクロは、混合ワークフローでは便利です。

両方のバージョンをコンパイルします。

(cd $WM_PROJECT_DIR && wmSPDP && ./Allwmake && wmDP && ./Allwmake)

倍精度でセットアップを実行し、シミュレーションを混合して実行します。

wmDP && snappyHexMesh -overwrite && decomposePar wmSPDP && mpirun -np XXX simpleFoam -parallel

オーバーセットの改良

オーバーセットフレームワークには、主に2つの改善点があります。

逆距離加重ステンシルの高速版：trackingInverseDistance。 そして 遠隔貢献はより一貫して処理されます trackingInverseDistance

新しいoversetInterpolationメソッドは、ボクセルメッシュを使用して幾何学的クエリを高速化します。 これには、単一の境界ボックスを使用して定義された関心領域と、（メッシュごとに）x、y、およびz方向の分割数が必要です。

oversetInterpolation {     method              trackingInverseDistance;     searchBox           (-0.1 -0.5 0)(1.1 0.5 1);     searchBoxDivisions  (100 100 1)(100 100 1); }

この方法はまだ活発に開発されています、そこでテストはメッシュ更新時間の大きな改善を示しました。

パラレル補間

オーバーセットメソッドの主な構成要素は、セルからセルへの補間です。 移動メッシュの場合、ドナーセルが補間セル（アクセプタセル）と同じプロセッサ上にあるという保証はありません。 以前のバージョンでは、リモートセルの寄与は、ベクトル行列乗算（ほとんどの線形ソルバーのビルディングブロック）に一貫した効果をもたらしましたが、他のルーチンにはありませんでした。 このバージョンでは、リモートセルへの寄与は、動的にプロセッサ境界を構築することによって、「通常の」プロセッサ境界とまったく同じ方法で処理され、並列一貫線形ソルバーの動作につながります。

定数体の初期残差は1になります。 その結果、ソルバーの振る舞いは、並列でない実行とより一貫したものになります。 プロセッサ境界が処理されるのであれば、外部ソルバとの将来のインタフェースでは、オーバーセットの特別な処理は不要です。

v1812の例：

diagonalPBiCGStab:  Solving for Ux, Initial residual = 0.6815303164, Final residual = 0.00379988609, No Iterations 3 diagonalPBiCGStab:  Solving for Uy, Initial residual = 1, Final residual = 0.005178109042, No Iterations 3 diagonalPBiCGStab:  Solving for p, Initial residual = 1, Final residual = 0.009257022076, No Iterations 197

Same case v1906:

diagonalPBiCGStab:  Solving for Ux, Initial residual = 1, Final residual = 0.005575520264, No Iterations 3 diagonalPBiCGStab:  Solving for Uy, Initial residual = 1, Final residual = 0.005178109042, No Iterations 3 diagonalPBiCGStab:  Solving for p, Initial residual = 1, Final residual = 0.00980810632, No Iterations 196

Uxの初期残差には今や遠い寄与が含まれているので1に正規化されます。これも残差のスケーリングに影響します。 圧力の処理には若干の違いがあり、残差にわずかな違いがあることに注意してください。

ソルバーと物理モデル 不均一反応クラウド

Lagrangianライブラリに、新しい異種反応クラウドの機能が追加されました。 この雲は、最初は、気相と反応して以下の種類の反応によって粒子中に固体生成物を生成する単一の固体成分から形成される。

solid + gas -> product

反応速度は、非触媒反応MUCSアプローチのPapanastassiouとBitsianesのモデルに従います。

nuFuel*Fe3O4 + nuOx*O2 => nuProd*Fe2O3

reactCloud1Properties辞書では、次のように指定されます。

heterogeneousReactingModel  MUCSheterogeneousRate;

MUCSheterogeneousRateCoeffs {     D12         2.724e-4;     epsilon     0.41;     gamma       3.07;     sigma       1;     E           1;     A           3.14e4;     Aeff        0.7;     Ea          1.651e5;     O2          O2;

    nuFuel      2.0;     nuProd      3.0;     nuOx        0.5;     fuel        Fe3O4;     product     Fe2O3; }

初期の粒子組成はreactCloud1Properties辞書で指定されています。

singleMixtureFractionCoeffs {     phases     (         gas         {         }         liquid         {         }         solid         {             Fe3O4 1;             Fe2O3 0;         }     );     YGasTot0        0;     YLiquidTot0     0;     YSolidTot0      1; }

Source code

$FOAM_SRC/lagrangian/intermediate/submodels/HeterogeneousReactingModel Solver $FOAM_SOLVERS/lagrangian/reactingParcelFoam/reactingHeterogenousParcelFoam Tutorial $FOAM_TUTORIALS/lagrangian/reactingHeterogenousParcelFoam/rectangularDuct Reference D. Papanastassiou and G. Bitsianes, Modelling of Heterogeneous Gas-Solid Reactions, Metallurgical Transactions, 480. Volume 4. 1973

openfoam.orgからの多相拡張 psiMaxおよびpsiMinのテンプレート引数を組み込むためのMULES / CMULESインターフェースの拡張。 内部エネルギー（e）を一貫して処理するための熱力学的種の枠組みの作り直しと拡張。 多相Eulerソルバーの位相システムへのポピュレーションバランスモデルの組み込み 過冷却核沸騰レジームを処理するためのalphatWallBoilingWallFunctionの組み込み overBuoyantPimpleFoam

新しいoverBuoyantPimpleFoamソルバーは、buoyantPimpleFoamソルバーにオーバーセット機能を追加します。

Source code

$FOAM_SOLVERS/heatTransfer/buoyantPimpleFoam/overBuoyantPimpleFoam Tutorial $FOAM_TUTORIALS/heatTransfer/overBuoyantPimpleFoam/movingBox reactingTwoPhaseEulerChtMultiRegionFoam

新しいreactTwoPhaseEulerChtMultiRegionFoamソルバーは、reactTwoPhaseEulerFoamとchtMultiRegionFoamの機能を組み合わせて、固体/流体連成システムを解きます。領域インタフェースは、turberlentTemperatureTwoPhaseRadCoupledMixed境界条件を使用して結合されます。

一般に沸騰流の熱伝達係数をモデル化するために、遷移沸騰状態と膜沸騰状態はalphatWallBoilingWallFunction境界条件で利用可能な初期の単相沸騰状態と核沸騰状態を補完する。

壁機能は、熱を液相または気相に伝達するために分配法を使用します。現在、この機能は固定壁温モードで機能します。すなわち、核沸点からの偏差に達した後の熱伝達率の急激な変化（バーンアウト）については考慮されていない。 Ｓｒｉｎｉｖａｓａｎ ｅｔ ａｌ。 （2010）。

単相非沸騰レジームでは、標準のJayatilleke壁関数が使用されます。過冷却核沸騰レジームでは、以下の実行時選択可能サブモデルが利用可能です。

核形成サイト密度 バブル出発頻度 気泡発散径

これは、よく知られているRPI壁沸騰モデル（Kurul and Podowski、1991）のバージョンに基づいています。この実装は、Peltola and Pattikangas（2012）によって記述されたモデルと似ていますが、壁熱流束分割モデルによって強化されています。

遷移沸騰レジームフラックス（）は、限界熱流束（）と最小熱流束（）の間の温度に基づく線形補間に従って壁温度が核沸騰からの逸脱（）ととの間で線形補間が使用されるLeidenfrost Temperature（）。

以下のモデルが必要です。

ライデンフロスト温度モデル モデル サブクールモデル モデル モデル フィルム沸騰モデル

ＴＢＦレジームについての線形補間は以下の通りである。

ここで:

ここで、はモデル定数（既定値1）と壁温度です。 がより大きい場合、膜沸騰状態が適用されます。 このレジームでは、フィルムの沸騰モデルからの相関が壁からのCHTの計算に使用されます。

過冷却モデルは、過冷却条件が存在するときに修正されます。 以下のサブモデルが実装されています。

臨界熱流束（CHF）の相関 Zuber（1958）を参照 フィルム沸騰モデル Bromley（1950）を参照してください。 最小熱流束（MHF）モデル Jescharらを参照。 al。 （1992） ライデンフロスト温度モデル Ｓｐｉｅｇｌｅｒ ｅｔ ａｌ。 al。 （1963） サブクール沸騰流に対する臨界熱流束 Hua and Xu（2000）を参照。 核沸騰相関からの出発 Thelera and Freisba（）を参照してください。

Source code

$FOAM_SRC/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction  $FOAM_SRC/heatTransfer/chtMultiRegionFoam/chtMultiRegionTwoPhaseEulerFoam Tutorial $FOAM_TUTORIALS/heatTransfer/chtMultiRegionTwoPhaseEulerFoam/solidQuenching2D References Numerical simulation of immersion quenching process of an engine cylinder head Vedanth Srinivasan, Kil-Min Moon, David Greif, De Ming Wang, Myung-hwan Kim. Applied Mathematical Modelling 34 (2010) 2111-2128 On the modeling of multidimensional effects in boiling channels, Kurul, N., Podowski, M.Z., ANS Proceedings, National Heat Transfer Conference, Minneapolis, Minnesota, USA, July 28-31, (1991) Development and validation of a boiling model for OpenFOAM multiphase solver, Peltola, J., Pattikangas, T.J.H., CFD4NRS-4 Conference Proceedings, paper 59, Daejeon, Korea, September 10-12 (2012) A. Bromley, Heat transfer in stable film boiling, Chem. Eng. Prog. 58 (1950) 67-72. N. Zuber, On the stability of boiling heat transfer, Trans. ASME 80 (1958) 711 Jeschar, E. Specht, C. Kohler, Heat Transfer during Cooling of Heated Metallic Objects with Evaporating Liquids, Theory and Technology in Quenching, Springer, (1992). Chapter 4. Spiegler P., Hopenfeld J., Silberberg M., Bumpus J. and Norman A., Onset of stable film boiling and the foam limit, International Journal of Heat and Mass Transfer, 6,11, pp.987-989, (1963) T.C. Hua, J.J. Xu, Quenching boiling in subcooled liquid nitrogen for solidification of aqueous materials, Mater. Sci. Eng. A 292 (2000) 169-172. Theoretical Critical Heat Flux Prediction Based Non-Equilibrium Thermodynamics Considerations The Subcooled Boiling Phenomenon Thelera G. and Freisba D.. TECNA Estudios y Proyectos de Ingeniera S.A. Encarnacion Ezcurra 365, C1107CLA Buenos Aires, Argentina Westinghouse, Electric Germany GmbH, Dudenstrasse 44, 68167 Mannheim, Germany 反射放射モデルの拡張

太陽負荷モデルには反射放射フラックスが組み込まれているため、鏡面反射を計算することができます。

反射効果は、radiationProperties辞書の新しいuseRefectedRaysエントリによって有効になります。

useReflectedRays    yes;

reflecting {     nPhi                10;     nTheta              10; }

ここで、反射サブ辞書は、反射光線の立体角分解能を決定するために使用される。 単一の反射のみが考慮され、これらの入力は光線追跡法における光線の数とは無関係であるが、標的表面から光源への反射光線の探索アルゴリズムのための離散化角として使用されることに留意されたい。 以下の例は、バンド0のミラーパネルからの物体への一次熱流束（左）と反射された太陽荷重（左）を示しています。

Tutorials

$FOAM_TUTORIALS/heatTransfer/buoyantSimpleFoam/simpleCarSolarPanel  $FOAM_TUTORIALS/heatTransfer/chtMultiRegionFoam/externalSolarLoad  $FOAM_SRC/thermophysicalModels/radiation/radiationModels/solarLoad Boundary conditions LES / DESのための新しい合成乱流発生法

LESおよびDESの場合の合成乱流を生成するための新しいturbulentDigitalFilterInlet速度境界条件が、Klein et al。、2003のデジタルフィルタ法（DFM）およびXie and Castro、2008のForward-Stepwise Method（FSM）に基づいて実装されました。 。

主に白色雑音と一群の目標統計値とを含む乱数セット。 平均流、レイノルズ応力テンソルプロファイル、および長さスケールセットを組み合わせて、入口乱流を導き出します。

Random number sets ---->-|                          |                      DFM or FSM ---> New stochastic time-series consisting                          |           turbulence statistics Turbulence statistics ->-|

コメント付きオプションを使用したturbulentDigitalFilter境界条件指定の例を以下に示します。

<patchName> {     // Mandatory entries     type                turbulentDigitalFilter;     variant             digitalFilter;          // reducedDigitalFilter;     planeDivisions      (<planeDivisionsHeight> <planeDivisionsWidth>);     L                   (<Lxu> <Lxv> <Lxw> <Lyu> <Lyv> <Lyw> <Lzu> <Lzv> <Lzw>);     R                   (<Rxx> <Rxy> <Rxz> <Ryy> <Ryz> <Rzz>);     patchNormalSpeed    <characteristic patch-normal flow speed>;     value               uniform (0 0 0);        // mandatory placeholder    // Optional entries with default input     isGaussian          true;           // false    // always false for FSM     isFixedSeed         true;           // false     isContinuous        false;          // true     isCorrectedFlowRate true;           // false     interpolateR        false;          // placeholder     interpolateUMean    false;          // placeholder     isInsideMesh        false;          // placeholder     isTaylorHypot       true;           // placeholder     mapMethod           nearestCell;    // planarInterpolation     threshold           1e-8;     modelConst          -1.5707;        //-0.5*PI;     perturb             1e-5;    // Optional entries for only FSM with default input     const1FSM           -0.7854         //-0.25*PI;     const2FSM           -1.5707;        //-0.5*PI; }

辞書エントリのうち、2つのエントリをパッチプロファイルとして入力できます。

レイノルズ応力テンソル、R、 平均速度、UMean

プロファイルデータと対応する座標は次のディレクトリに入力されます。

$ FOAM_CASE / constant / boundaryData / <パッチ名> / points $ FOAM_CASE /定数/ boundaryData / <パッチ名> / 0 / {R、UMean}

プロファイルおよび座標データは、timeVaryingMappedFixedValueおよびturbulentDFSEMInletboundary条件で使用されるのと同じ形式を取ります。これは、空間座標のリストを含むポイントファイルと、座標ごとの値を提供するプロファイルデータファイルで構成されます。

新しい条件は、Re = 395での平滑壁平面チャネル流直接数値シミュレーションからMoser et al。、（1999）によって提供された一次および二次乱流統計量に関して直列および並列計算について検証された。

以下の図は、それぞれDFMおよびFSMの変種について、入口パッチでサンプリングされた4つのレイノルズ応力テンソル成分に関する検証結果を示しています。

Source code

$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/turbulentDigitalFilterInlet Tutorial $FOAM_TUTORIALS/verificationAndValidation/turbulentInflow ニューウェーブモデリング

波境界条件はOpenFOAM v1612のリリースとともにOpenFOAMで最初に導入されました。静的メッシュのための追加の条件はその後のリリースで追加されました。 このリリースでは、OpenFOAM v1812で導入されたwaveMaker条件を拡張して、以下の例に示すように孤立波を生成します。

Source code $FOAM_SRC/waveModels/derivedPointPatchFields/waveMaker Examples $FOAM_TUTORIALS/multiphase/interFoam/laminar/waves/waveMakerSolitary Attribution These extensions were supplied by the Environmental Hydraulics Institute IHCantabria - see commit 1eddbca63e Authors: Gabriel Barajas Integration The code has been integrated by OpenCFD - see commit 47eb0769bf 後処理 runTimePostProcessingの改善

runTimePostProcessing関数オブジェクトは、明確に定義された高スループットのワークフローのために、ParaView / Catalystインタフェースに代わる直接的なVTKによるその場での可視化を提供します。

修正された関数オブジェクトは多くの新機能を追加します。

並列VTKレンダリング ファイル形式へのシリアル化を必要とせずに、メモリに格納されているサンプル面のレンダリング 中間サンプリング段階なしでパッチと雲を直接レンダリング ンプリングされたサーフェスまたはメッシュパッチの面の中心にベクトル矢印をレンダリングできるようになりました。 より視覚的に魅力的な画像の場合は、新しい滑らかなオプションを使用できます。これは、顔データのセルからポイントへの補間を適用して、滑らかな外観を提供します。 VTK切断面アルゴリズムの直接使用 Tutorials $FOAM_TUTORIALS/lagrangian/coalChemistryFoam/simplifiedSiwek  $FOAM_TUTORIALS/incompressible/pimpleFoam/RAS/ellipsekkLOmega  $FOAM_TUTORIALS/incompressible/pisoFoam/LES/motorBike/motorBike  $FOAM_TUTORIALS/incompressible/simpleFoam/windAroundBuildings finiteAreaの新しいareaWrite関数オブジェクト

新しいareaWrite関数オブジェクトは、標準的な表面出力フォーマットでの有限領域メッシュとフィールドの書き込みをサポートします。 洞察力、そしてVTK。

Source code $FOAM_SRC/functionObjects/utilities/areaWrite Tutorials $FOAM_TUTORIALS/finiteArea/surfactantFoam/planeTransport  $WM_PROJECT_DIR/modules/avalanche/tutorials/wolfsgrube 更新された力と新しい力係数成分

forceおよびforceCoeffs関数オブジェクトは、横力とヨーモーメントを報告し、入力方向は座標系を使用することで簡略化されました。

ユーザーは2つの直交方向を持つ原点を指定するだけでよくなり、以下に示す3つのオプションで追加できます。

CofR        (0 0 0); // Centre of rotation dragDir     (1 0 0); liftDir     (0 0 1); origin (0 0 0); e1     (1 0 0); e3     (0 0 1); // combinations: (e1, e2) or (e2, e3) or (e3, e1) coordinateSystem {     origin  (0 0 0);     rotation     {         type axes;         e1 (1 0 0);         e3 (0 0 1); // combinations: (e1, e2) or (e2, e3) or (e3, e1)     } }

Source code $FOAM_SRC/functionObjects/forces/forces  $FOAM_SRC/functionObjects/forces/forceCoeffs Solver $FOAM_TUTORIALS/incompressible/simpleFoam/motorBike 新しいラムベクトル関数オブジェクト

新しいlambVector関数オブジェクトは、速度ベクトルと渦度ベクトルの外積として定義されるラムベクトルを計算します。 Ｌａｍｂベクトルの発散は、空間的に局所化された瞬間的な流体運動、例えば、１００〜１５０℃の運動量への定量的関連性を提供する。 運動量の変化率に影響を与え、抗力などの力を発生させる能力を持つ、高運動量流体小包と低運動量流体小包。

lambVectorの発散計算を含む使用法の例を以下に示します。

lambVector1 {     type        lambVector;     libs        ("libfieldFunctionObjects.so");     field       U; }div1 {     type        div;     libs        ("libfieldFunctionObjects.so");     field       lambVector; }

チャネルの場合の等値面をプロットすると、結果として生じる場は流れの乱流の内容を捉えることができることがわかります。

Source code $FOAM_SRC/functionObjects/field/lambVector Tutorials $FOAM_TUTORIALS/incompressible/pimpleFoam/LES/channel395DFSEM References Lamb vector in Wikipedia Hamman et al., (2008), On the Lamb vector divergence in NavierStokes flows 新しいサンプリング方法

新しいラインサンプリングメソッドpatchEdgeSetは、ユーザー定義の面と交差するパッチエッジの値をサンプリングします。 表面は一般的なsearchablePlane型です。 典型的な例は、平面またはtriSurfaceMesh（三角面）です。

下の図では、一番上のパッチの圧力が三角球でサンプリングされています。

使い方は通常set functionObjectを使います。

sets {     type                sets;     libs                ("libsampling.so");     writeControl        timeStep;     writeInterval       1;    fields              ( p U);     interpolationScheme cellPoint;    setFormat           vtk;    sets     (         patchEdge         {             type        patchEdge;             axis        x;

            // Selected patches             patches     (movingWall);

            // Surface type             surfaceType searchablePlane;

            // Additional info for the surface type             planeType   pointAndNormal;             pointAndNormalDict             {                 point   (1.5 1.5 1.5);                 normal  (0.1 0 1);             }

            // Reference point for ordering samples             origin      (0 1 0);         }     ); }

結果として得られる点は、提供された原点までの距離に従ってソートされることに注意してください。

Source code $FOAM_SRC/sampling/sampledSet/patchEdge 新しいランタイムトリガ

ランタイム制御関数オブジェクトはOpenFOAM-v3.0以降で導入され、一連のランタイム条件に基づいて計算を終了して書き込むメカニズムを提供します。 一連の条件は次のとおりです。

average equationInitialResidual equationMaxIter maxDuration minMax minTimeStep

v1906リリースは「トリガー」を発するオプションを追加することによって条件が満たされたときに起こることを拡張します。トリガを使用して他の機能オブジェクトを起動し、高度にカスタマイズ可能なワークフローを提供することができます。

実行するアクションはオプションのsatisfiedActionエントリによって制御されます。

終了：計算を終了します。これは後方互換性を維持するためのデフォルトのアクションです。そして setTrigger：追加のトリガーエントリによって整数値として定義されたトリガーを設定します。

関数オブジェクトの時間コントロールには、オブジェクトがいつアクティブになるかを制御するオプションのcontrolModeエントリが追加されました。

time：オブジェクトのtimeStartとtimeEndの間でアクティブ trigger：オブジェクトのtriggerStartとtriggerEndの間でアクティブ timeOrTrigger：オブジェクトのtimeStartとtimeEndの間、またはtriggerStartとtriggerEndの間でアクティブ timeAndTrigger：オブジェクトのtimeStartとtimeEndの間、およびtriggerStartとtriggerEndの間でアクティブ

一連の実行時条件を満たすことによってトリガーが起動されると、そのトリガーの「索引」に基づいて開始するように設定されているすべての機能オブジェクトが起動されます。

これをまとめると、それは可能です。すべてのフィールドの最小値と最大値のレポートを開始し、平均が力関数オブジェクトからの抗力係数が1e-3未満変化した後に100回の反復を停止するように計算を設定します。

runTimeControl1 {     type            runTimeControl;     libs            ("libutilityFunctionObjects.so");     conditions     {         condition1         {             type            average;             functionObject  forceCoeffs1;             fields          (Cd);             tolerance       1e-3;             window          20;             windowType      exact;         }     }     satisfiedAction setTrigger;     trigger         1; }runTimeControl2 {     type            runTimeControl;     libs            ("libutilityFunctionObjects.so");     controlMode     trigger;     triggerStart    1;     conditions     {         condition1         {             type            maxDuration;             duration        100;         }     }     satisfiedAction end; }fieldMinMax {     type            fieldMinMax;     libs            ("libfieldFunctionObjects.so");     fields          (".*")     controlMode     trigger;     triggerStart    1; }

Source code

$FOAM_SRC/functionObjects/utilities/runTimeControl Tutorials $FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar サーフェスサンプリングと書き込みの改善

サーフェスサンプリングと書き込みのためのインフラストラクチャは、機能性と柔軟性の向上のために大規模な見直しを受けています。以前のバージョンでは、サーフェイスライターは並列コード内で使用されると多少ぎこちなくなりましたが、最悪の部分はそれらが完全にステートレスであることでした。これは、サーフェスをサンプリングしてVTKフォーマットで書き込むときに特に顕著になります。調整されていない出力は、サンプリングされたフィールドごとに別々のファイルが生成されることを意味していました。

サーフェイスライターはタイムステップを認識できるようになり、そのタイムステップですべてのサンプルフィールドを使ってサンプルVTK出力を生成できます。

並列データ削減とそれに関連するブックキーピングは、サーフェイスライター自身の一部となり、再利用性が向上し、サンプリング段階での不要で時期尚早なデータ削減が回避されます。

サーフェスごとに異なる出力フォーマットがサポートされているほか、サンプリングされたサーフェスやフィールドをレジストリに保存して他の機能オブジェクトで再利用することもできます。したがって、サーフェスを単純にサンプルして保存し、そのサーフェスとその値を後でsurfaceFieldValue関数オブジェクトに使用して、min / maxなどの演算を計算することが可能になりました。

カラーテーブルをx3dフォーマットで書かれたサンプルサーフェスに追加することが可能になりました。これはblenderのようなレンダリングツールに直接インポートするのに便利です。

新しいサンプル表面オプション

samplesSurfaces辞書エントリは後方互換性がありますが、追加機能があります。

格納 サンプルサーフェスを再利用のためにオブジェクトレジストリに保存するように要求します。 たとえば、runTimePostProcessingのfunctionObjectSurfaceレンダリングオブジェクトによって。 sampleOnExecute 関数オブジェクトexecute（）が呼び出されたときにサンプル/ストア操作を要求します。 表面 このエントリは、リストではなくエントリの辞書になることができます。これは、changeDictionarymodificationと組み合わせて使用すると便利です。 interpolationScheme これはオプションです。 デフォルトではcellPointです。 サーフェスフォーマットとストレージ要件のサーフェスごとの仕様。 これは柔軟なユーザー要件の組み合わせをサポートします。

並列 拡張分布三角サーフェス機能

三角面は、メッシュ作成ツールへの入力に使用される形状を記述するために使用される。 snappyHexMesh、および後処理 等値面の場合 distributedTriSurfaceMeshバリアントは、各プロセッサが三角形のサブセットを保持しているだけの並列ワークフローに適しています。

このリリースでは、distributedTriSurfaceMeshは次のように拡張されました。

分解のために別のユーティリティsurfaceRedistributeParを必要としなくなりました 内側/外側のテストを許可します。 snappyHexMeshでボリューム改良を実行する方法 さまざまなクエリを高速化し、メモリ効率を向上させる

distributedTriSurfaceMeshは、snappyHexMeshDictディクショナリのgeometryセクションで指定されています。

geometry {     sphere.stl     {         type distributedTriSurfaceMesh;     } }

これは以下のどちらかになります。

すでに分解された面：processorDDD / constant / triSurface / sphere.stlおよび対応するprocessorDDD / constant / triSurface / sphere.stlDict 後者の辞書には、 ローカルサーフェスのバウンディングボックス 未分解の定数/ triSurface / sphere.stlを配布します。 これは最も頻繁に使用される操作です。

次の図は、triSurfaceMeshとdistributedTriSurfaceMeshの両方を使用した単純なテストケースの違いを示しています。

制限事項

未分解のdistributedTriSurfaceMeshでは、現在、システム内の分解方法/ decomposeParDictをhierarchyに設定する必要があります。 これは辞書の新しい条件を使って自動化できます。

1. ifeq $FOAM_APPLICATION decomposePar

    method scotch;

1. else

    method hierarchical;     coeffs     {         n  (5 2 1);     }

1. endif

Source code $FOAM_SRC/parallel/distributed/distributedTriSurfaceMesh Solver $FOAM_TUTORIALS/mesh/snappyHexMesh/distributedTriSurfaceMesh Metis分解ライブラリへのより簡単なインターフェース

OpenSUSEやRedhatなどの一部のLinuxディストリビューションには、64ビット整数でコンパイルされた可能性があるMetis 64ビットOSバージョンのプリコンパイルバージョンが付属しています。 OpenFOAMのMetisインターフェースの新しい新しい自動整数変換により、OpenFOAMはこれを直接使用できます。

システムバージョンのMetisを使用するにはconfig.sh/metisを変更します。

METIS_VERSION =メティスシステム

metisインターフェースをコンパイルします。

CDパラレル/分解 ./Allwmake

system / decomposeParDictのメソッドをmetisに設定して、任意の並列ケースでテストします。 一般的な出力は次のとおりです。

セル分布の計算 decompositionMethod metisの選択[4]

Metisは並列の文脈で使うことができます。 redistributeParとsnappyHexMeshを使用しますが、分布を決定するためにグラフをマスタープロセッサに結合します。

Source code $FOAM_SRC/parallel/decompose/metisDecomp  $FOAM_SRC/OpenFOAM/fields/Fields/Field/PrecisionAdaptor 新しいプロファイリングツール

並列実行の基本的な並列プロファイリングを行うためのオプションが追加されました。 これは現在プロファイリングフレームワークの範囲外であり、将来変更される可能性があります。 プロファイリングは、parProfiling関数オブジェクトを使用して選択されます。 典型的なセットアップは

profiling {     type  parProfiling;    libs  ("libutilityFunctionObjects.so");    // Report stats on exit only (instead of every time step)     executeControl  onEnd;     writeControl    none; }

典型的な出力：

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)

プロファイリングは2つのタイミングで構成されています。

世界規模の削減に関連するもの、すなわちすべてのプロセッサを含むもの。 そして プロセッサ間通信に関するもの。

ここでの興味深い尺度は、この計算を左右するreduceの待機に費やされた時間です。 タイミングは基本的な尺度にすぎません - どのカテゴリのためのものであるかを導き出すためのヒューリスティックは正確ではありません - タイミングの精度はかなり低いです。

Examples $FOAM_TUTORIALS/incompressible/simpleFoam/windAroundBuildings 移植性 MS-Windows®用の新しいクロスコンパイルされたOpenFOAMバージョン

OpenFOAM-v1906は、より広範囲のプラットフォームでOpenFOAMにアクセスできるようにするための努力を続けています。このバージョンでは、Symscapeが開発した多くのMS-Windows®対応策をBlueCapeのアイデアと組み合わせて、MS-Windows®用の64ビットクロスコンパイルOpenFOAMバージョンをサポートします。

移植の変更は、OpenFOAMの将来的にもっと多くの部分を手助けするであろう多くの関連コンポーネントの更新につながりました。

POSIXの正規表現の代わりにC ++ 11の正規表現を使用するためのドロップイン互換のサポート。 OS固有のpthreadへの依存性を削除しました OS固有のclockValueをstd :: chronoバージョンに置き換えた クラッタが少なくなり、より一般的なシンタックスが得られるようにエンディアン関連のマクロが更新されました（OS固有からOpenFOAM /プリミティブに移動）。 オペレーティングシステムの種類を区別するときは、標準のコンパイラマクロを使用してください。 ブートストラップのflexへの依存を削除しました。 wmakeツールチェーンはC ++コンパイラのみを必要とします。 追加の関連変更 ユーザーが選択可能なファイル名のスペースの取り扱い。 OpenFOAMのケース名自体の中のスペースは依然として非常に悪い考えですが（ケース名は他のファイル名のベースとして使われることが多く、無効な辞書エントリにつながる可能性があるため）、多くの場合親ディレクトリのスペースを受け入れることができます名。ディレクトリ名の中のスペースは、Windowsシステムで特に一般的です。慎重に使用し、予期しない問題があれば報告してください。 バックスラッシュとUNCディスクリプタのOS固有の処理を追加しました。パス内のバックスラッシュは、内部的にフォワードスラッシュに変換されます。 メイクファイル内および辞書のlibsエントリ内のlib / exeファイル拡張子の統一処理。 DarwinやWindowsなどのプラットフォームでは、拡張子.soはそれぞれ自動的に.dylibと.dllに変換されます。これにより、LinuxとWindowsで同じ辞書を使用できます。

追加の利便性として、libプレフィックスと.soサフィックスの両方がオプションになりました。これにより、辞書の入力が簡単になります。

libs    ("sampling"); // instead of libs    ("libsampling.so");

新規および更新されたコンパイラーのサポート Pgiコンパイラ用のwmakeルールを追加 ARM開発者と協力して、ClangのARMコンパイルフラグ

主な変更点は、パフォーマンスライブラリでのリンクに-armplを使用し、プロセッサターゲットに-mcpu = nativeを使用することです。 ThirdPartyによるブーストのビルドで、gccの代わりにarmclangも使用できるようになりました。

プロセッサ最適化の調整を簡単に適用できるようにする

wmakeの規則の範囲内で、cpuアーキテクチャーは現在、別個のcARCH、c ++ ARCHの内部make変数で管理されているため、コンパイラー設定からの分離が容易になります。 これにより、KNLなどのアーキテクチャーをコンパイラー・オプションではなく最適化オプションにすることができます。

以前:

WM_COMPILER=GccKNL WM_COMPILE_OPTION=Opt

-> linux64GccKNLDPInt32Opt

現在:

WM_COMPILER=Gcc  WM_COMPILE_OPTION=OptKNL

-> linux64GccDPInt32OptKN

これにより、あまりにも多くのファイルを生成しなくても、さまざまな調整を簡単に追加できます。 たとえば、ファイルcOptとc ++ Optをコピーして編集して、Broadwell固有のコンパイルを作成します。

cd wmake/rules/linux64Gcc

cp cOpt   cOptBdw cp c++Opt c++OptBdw

WM_COMPILE_OPTION = OptBdwを設定します。

コンパイラ設定への直接アクセス

キーワード：コンパイラ情報のwmake -showオプション

autoconfigまたはcmakeを使用して他のライブラリを直接構築する場合は、OpenFOAM自体で使用されているものと同じコンパイラおよびコンパイラ設定を使用することが有用または必要な場合があります。 これらは現在wmakeのshowオプションから取得されており、対応する環境変数を設定するために使用することができます。 例えば、

CC = "$（wmake -show-c）" CFLAGS = "$（wmake -show-cflags）" ./configure

これはよく使われる環境変数への対応です。

Env variable Obtaining from wmake Meaning CC wmake -show-c C compiler CFLAGS wmake -show-cflags C compiler flags CXX wmake -show-cxx C++ compiler CXXFLAGS wmake -show-cxxflags C++ compiler flags

wmake -show-cflags-arch Architecture information when linking

wmake -show-cxxflags-arch Architecture information when linking

状況によっては、コンパイラとフラグを一緒にしておくと便利なこともあります（mpicc -showおよびmpicxx -showと同様）。

wmake -show-compile-c wmake -show-compile-cxx

このシステムは、以前のバージョンで使用されていた環境変数（WM_CC、WM_CFLAGS、WM_CXX、WM_CXXFLAGS、およびWM_LDFLAGS）を、いくつかの理由で不適切であると証明したものに置き換えます。

壊れやすい 一貫性が保証されていません 完全なコンパイルフラグを提供しません 環境を煩わせる

About us

OpenFOAM is produced by the core ESI-OpenCFD team

Andrew Heather Mattijs Janssens Sergio Ferraris Mark Olesen Prashant Sonakar Pawan Ghildiyal Kutalmis Bercin Roger Almenar Matej Forman Sebastien Vilfayeau Siby Mandapathil Baby Mayur Wala Son Vo Karen Kettle Ann Ronchetti Fred Mendonca Swapnil Salokhe Jean-Michel Esclaferdelarode

With wider support from the global ESI team

ESI Group (GmbH) ESI Group (ESI Software (India) Private Limited) ESI Group (North America) ESI Group (Nihon ESI)

And contributions from

PCOpt/NTUA and FOSS GP The Environmental Hydraulics Institute IHCantabria RIST OpenFOAM.org Useful links Download OpenFOAM OpenFOAM documentation OpenFOAM services OpenFOAM repositories OpenFOAM compilation guide OpenFOAM bugs and feature requests