MPI通信最適化

このページは、2026-06-05の勉強会でチームが共有したMPI通信最適化の基礎をまとめたものです。担当: 松村。OpenFOAM最適化の中心テーマです。

これは何か

MPI（Message Passing Interface）は、複数プロセス間でデータをやり取りするプロセス間通信ライブラリです。例: MPI_Send()、MPI_Recv()。

HPCクラスタでは、Node1〜Node4のように数百〜数万のCPUコアが協調して計算します。そのため、プロセス間の通信が性能を大きく左右します。

なぜMPI通信が必要か

100万セルの流体解析を例にすると、1つのCPUで全部解く代わりに、領域を複数のrank（Rank0〜Rank3）に分割して並列計算します。

分割すると、各rankの**境界セル(Boundary Cells)**の情報を隣のrankと交換する必要があります。
この交換（通信）がないと計算を進められません。

なぜMPI通信が「遅い」か

処理	おおよその時間スケール
CPU演算	ns（ナノ秒）
通信	μs〜ms（マイクロ〜ミリ秒）

その差は1000倍以上です。人間サイズに換算すると「1秒 vs 約11日」というイメージです。だからこそ、通信削減 = 高速化になります。

富岳で見るべき典型的ボトルネック

注: チームは富岳(A64FX)を前提に調査しています。2026年大会の実機は未確定です（富岳アーキテクチャ、調査ステータス）。

① MPI通信

「ノード数を増やしたのに速くならない」典型です。

対策:

通信回数の削減
通信と計算のオーバーラップ（重ね合わせ）
MPIランク配置の改善

② メモリ帯域律速

富岳のCPUはA64FX。メモリ帯域がボトルネックになりやすいです。詳細は富岳アーキテクチャを参照。

Load Imbalance（最重要ボトルネック）

rank間で計算量が偏ると、全体は最も遅いrankに引っ張られます。

rank	計算時間
Rank0	10秒
Rank1〜3	5秒（残り5秒は待機/idle）

→ 全体 = 10秒。速いrankが遊んでいる分、追加した計算資源が無駄になります。対策は領域分割の改善です（領域分割）。

OpenFOAMの典型的ボトルネック

OpenFOAMはCFD（速度・圧力・温度を解く）で、最終的に巨大な連立一次方程式 Ax = b を解きます。

計算の流れ:

メッシュ生成 → 行列構築 → Pressure Solver → 結果出力

実行時間の多くはPressure Solver（圧力ソルバ）が占めます。

反復法とMPI_Allreduce

Pressure SolverはCG系の反復法（CG、PCG、BiCGStab、GAMGなど）で、正解に少しずつ近づきます。各反復で残差を計算し、全rankで合わせるためにMPI_Allreduceを使います。

MPI_Allreduceとは: 各rankの値（局所誤差）を集約して全体の値（全体誤差）を計算し、全rankへ配り直す collective通信です（Gather → 合算 → Broadcast）。

Pressure Solver → 残差計算 → MPI_Allreduce → 全員同期 → Pressure Solver → ...

このループが本当のボトルネックになりがちです。

なぜAllreduceが大量発生するのか

CG反復は、反復ごとにMPI_Allreduceを繰り返します。例えば300 iterationなら、300回以上の通信が発生します。

Pressure Solver 起動 → MPI_Allreduce 頻発 → 通信待ち(Idle) → （繰り返し）

→ 結論: 通信最適化が重要。研究者は次を頑張ります。

ソルバ変更（PCG → GAMG）
通信回数の削減
rank数の調整
メッシュ分割の改善（領域分割）

最初に見るべき指標・設定

観点	見るもの	なぜ重要か
通信時間	`MPI_Allreduce`・`MPI_Wait`の時間	通信・同期待ちが律速か
負荷の偏り	rankごとの計算時間のばらつき	load imbalanceの有無
ソルバ	`fvSolution`のsolver/precondition設定	PCG/GAMGの選択で通信特性が変わる
分割	`decomposeParDict`のmethod	通信量・負荷分散に直結

注意点

ソルバや収束条件（tolerance/relTol）の変更は、物理結果や収束性に影響します。大会で変更可能か要確認です。
富岳前提の議論です。実機の通信特性（InfiniBand/Tofu等）は環境依存です。

APAC-HPC-AI