生コミュニケータ版 allreduce ラッパーを MPI_IN_PLACE 化し自動配列バッファを廃止する

Kazuya Gotorequested to merge
kgoto/FrontISTR:feature/allreduce-in-place into master

Close #895 (closed)

解決策

hecmw_allreduce_R_comm / hecmw_allreduce_I_comm を MPI_IN_PLACE 化し、 一時バッファ自体を廃止する（1 ファイル・+12/−17 行）。

  • 受けバッファ VALM(n)・ゼロ埋め・書き戻しコピーを削除し、 MPI_allreduce(MPI_IN_PLACE, val, ...) に置き換え
  • スタック配置のバッファが消えるため、自動配列をスタックに置く処理系 （ifx、-Mstack_arrays）でも問題規模に依存せず動作する（ulimit 不要）
  • 送受とも呼び出し元の val 1 本になるため、コード内コメント（および cb1e7dc8）が 対処した CUDA-aware MPI のメモリ種別制約（集団通信の src/dst に host と managed を 混在させない）は構造的に成立する（managed でも host でも src=dst）
  • MPI_Allreduce は要素ごとの縮約であり、in-place でもランク間の縮約順序は 変わらない（下記のとおりビット同一性を確認済み）
  • 同一パターン（automatic VALM）を持つ 2 ラッパーを対で修正（I 版の現行呼び出しは 全て n=1 でスタック溢れは起きないが、同じ理由コメントを持つ対を揃えて直す）。 hecMESH 版の旧来ラッパー hecmw_allreduce_R/_I は allocatable+sbuf 方式で スタック問題を持たないため対象外

検証

  • ifx（oneAPI 2026.1.1 + Intel MPI）: 300 万自由度の全長ベクトル allreduce を含む 分散求解が、既定スタック上限（16 MB）のまま 4 ランクで正常終了。残差は ulimit -s unlimited 回避時の実行とビット一致
  • gfortran + OpenMPI: 開発中の分散ソルバの MPI 回帰スイート（np=1,2,3,4,8）で 50 PASS・縮約結果が逐次実行とビット同一のまま維持されることを確認 （IN_PLACE 化が縮約のビット同一性を変えないことの確認）
  • SA-AMG の GPU 挙動不変: NVHPC 26.5 + HPC-X（CUDA-aware UCX、 -gpu=ccnative,mem:managed）の 2 ランク実行で、修正前後の CG 反復履歴が 完全一致・メモリ種別エラーなし（自動配列が回避していたメモリ種別検出系への回帰確認。 最終残差の再計算値の末位は同一バイナリの再実行でも揺れる GPU 求解の 非決定性の範囲内）
  • 回帰（gfortran、origin/master 5b3a9beb + 本コミット）: ctest -L serial 120/120、 -L mpi -R solver/ 3/3、-L hybrid -R solver/ 3/3 全 PASS

補足

  • スタック溢れの実測は開発中の分散直接法ソルバ（別途 MR 予定）で顕在化したものだが、 ラッパー自体は SA-AMG 前処理（PRECOND=22）等の既存経路からも呼ばれており、 修正は本体に対して独立
  • MPI_IN_PLACE の使用はコードベース初出
Edited by Kazuya Goto

Merge request reports