OpenFOAM最適化の考え方

最適化の単位

OpenFOAMの高速化は、少なくとも次の層に分けて考えます。

層	例	リスク
実行設定	rank数、ノード数、binding、I/O設定	低い
分割設定	`simple`、`hierarchical`、`scotch`、分割方向	低から中
ソルバ設定	tolerance、relTol、preconditioner、反復上限	中。精度や収束性が変わる
コンパイル設定	compiler、MPI、最適化フラグ	中。環境差が出る
コード変更	ソルバ改変、行列計算、通信削減	高い。ルール確認が必須

大会では「どこまで変更してよいか」が最重要です。最終ルールが出るまでは、設定変更と計測基盤の準備に寄せるのが安全です。

ボトルネックの探し方

最初に見るべき症状と対応です。

症状	疑う場所	次に見るログ・指標
rank数を増やしても速くならない	MPI通信、分割不均衡	各rankのセル数、境界数、MPI時間
solver反復が多い	線形ソルバ設定、メッシュ品質	residual、iteration count
計算開始前後が遅い	I/O、decompose、reconstruct	ログの時刻、ファイル数、scratch配置
ノードを増やすと不安定	network、MPI、filesystem	PBS/Slurmログ、MPIエラー
一部rankだけ遅い	load imbalance、NUMA、binding	rank別時間、CPU affinity

OpenFOAMで特に注意すること

I/O

OpenFOAMの並列実行では、rankごとにprocessor*ディレクトリが作られます。大規模並列ではファイル数が増え、I/Oが詰まることがあります。

OpenFOAM user guideでは、collated file handlerにより、分割されたfieldやmeshをまとめた形式で扱えると説明されています。ただしMPIのthreading supportなど環境条件があります。

領域分割

分割は「セル数を均等にする」だけでは不十分です。境界面が増えると通信が増えます。乱暴にrankを増やすと、計算より通信の割合が増えて遅くなることがあります。

収束条件

toleranceやrelTolを緩めると速くなる場合がありますが、結果の正当性が変わります。大会で許されるか、評価がwall timeだけか、物理結果の検証があるかを確認する必要があります。

実験ログの最小項目

experiment_id:
date:
author:
case:
openfoam_version:
git_commit:
nodes:
ranks:
threads:
decomposition:
solver_settings_changed:
io_settings_changed:
command:
wall_time:
iteration_count:
residual_summary:
stdout_log:
stderr_log:
notes:
next_action:

APAC-HPC-AI