Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

2026-08-09 議事録

実施日時

  • 2026-08-09（日）Teams（オンライン）

目的

  • 2026 HPC課題の確定ルールと評価方法（FVOPS）を共有する。
  • 競技マシン（NCI Gadi、NSCC ASPIRE-2A）へのアクセス環境（VPN・アカウント）を整える。
  • OpenFOAMのベースライン測定の進め方と玄界での実測結果を確認する。
  • チーム内の情報共有方法として「分報（Times）」の導入を決める。

決定事項

  • HPC側は主にGadiを使う方針とする。ASPIRE-2Aは結果のばらつき（spread）が大きく、ルール上「改善率がspreadを下回るとscore評価されない」可能性があるため（要確認）、安定して結果が出るGadiを優先する。
  • 大きな高速化はdata layout／cache locality／memory trafficの削減方向で狙う。compiler／MPI設定・process bindingは重要だが改善幅は数%程度と割り切る。source modificationはルール上許可されている。
  • ベースラインは同一条件で4〜5回実行してばらつきを把握する。process bindingが正常に動作していることを必ず確認する（解除すると約3.7倍遅くなる）。
  • 情報共有用に「分報（Times）」チャンネルをTeams上に作る。各自が思ったこと・悩みどころ・判断・決定をその場で書き溜めていく。通知で全員が疲れないよう、非表示（ミュート）チャンネルとして作る。
  • 環境構築の手順（VPN接続、アカウント作成、ログイン方法）を、画像付きで後からまとめてWiki化する。九州大学側の知見も参照する。
  • Iris（講習会で使ったスパコン）は練習用として使う。本番では使わない旨をルール・手順に明記する。

共有内容

2026 HPC課題の確定ルール（小林）

  • 固定されているもの（変更不可）。

    • OpenFOAM v2506以降を使用する。
    • 計算量、出力結果の精度。
    • 使用ノード数は1, 2, 4。

  • 評価指標FVOPS（高いほどよい）。

    FVOPS_trim = (64,000,000 × 4) / (ExecutionTime_step5 − ExecutionTime_step1)
    • solverが出力するExecutionTimeを結果として使う。
    • Step1〜5を実行し、Step1の結果は除外する（ウォームアップ相当）。

  • 評価対象は「4ノードでベースラインからどれだけ高速化したか」。

報告・提出するもの（小林）

  • 1/2/4ノードそれぞれの結果（Log.icoFoam と parse_result.sh の RESULT）。
  • 最適化内容（何を変更したか。1つの変更につき1行）。
  • 最適化の仮説（なぜ高速化すると考えたか）とボトルネックの根拠（なぜボトルネックと判断したか）。この2つは重要な評価項目。
  • FVOPS before / after / Delta（変化量）。
  • MPI rank数（ranks per node）、Decomposition（分割法）、Subdomain数（rank数との関係も明示）、Ordering/renumbering（未実施ならその旨）。
  • 総run数（実験期間中の全run）と総core-hours / SU（消費した計算資源）。

競技マシン：Gadi と ASPIRE-2A（小林）

  • 昨年の資料を見た限り、HPC部門ではGadiを選ぶチームが多い。

  • gitで公開されていたベースラインログでは、ASPIRE-2Aは結果のばらつきが大きい。ルール上、改善率がspreadを下回るとscore評価されない可能性がある（要確認）。

  • 公開ベースラインログの要約（Best FVOPSは高いほど良い）。

    ClusterNodesRuns平均 [s/step]SpreadBest FVOPS
    Gadi1331.8811.22%2.0161 M
    Gadi2315.4670.29%4.1457 M
    Gadi486.5921.87%9.7785 M
    ASPIRE-2A1355.2864.03%1.1793 M
    ASPIRE-2A2827.26123.91%2.6003 M
    ASPIRE-2A4812.00113.73%5.7168 M

  • ポイント（core-hours / SU）には上限があり、消費量は報告義務がある（報告項目に含まれる）。

主催者が推奨していること（小林）

  • ベースラインを再現する。同一条件で4〜5回実行し、結果のばらつきを把握する。
  • process bindingが正常に動作することを確認する（解除すると約3.7倍遅くなる）。
  • compiler／MPI設定の変更は試して記録する価値はあるが、大幅な高速化は期待しない。主催者の測定ではMVAPICH/UCX設定・binding・compiler flagsはいずれも改善幅が数%程度だった。
  • 大きな改善を狙うならdata layout・cache locality・memory traffic。solverはachievable memory bandwidthのかなり高い割合をすでに使っており、命令の高速化よりDRAMとのデータ移動量そのものを減らす方に余地が大きい。source modificationも許可されており、公式ルールは許可例としてcache blocking、SpMV vectorization、通信と計算のoverlap、PCG global reductionsの融合などを挙げている。

玄界上でのベースライン（小林）

  • 条件：OpenFOAM-v2606、MPIはMVAPICH 3.0-gcc8.5.0、decompositionはscotch、各ノード数3回ずつ実行。

    ノード数平均実行時間 [s/step]Best実行時間ばらつきBest FVOPS
    132.38431.8694.84%2.0082 M
    217.92917.3129.42%3.6968 M
    46.8166.6783.18%9.5844 M

  • Gadiの公開ベースライン（4ノードBest FVOPS 9.7785 M）と近い水準まで再現できている。2ノードのばらつき（9.42%）はやや大きく、測定回数を増やす余地がある。

アカウント・VPN・環境構築

  • NSCCのアカウントは各メンバーに1つずつ付与される（ASPIRE内では個人アカウント）。
  • 接続にはEndpoint Security VPNのソフトをインストールする。ユーザー名APACSC15でログインに失敗する事例があったが、原因はI（大文字アイ）とl（小文字エル）の取り違え。画像共有で解決した。VPN接続時は毎回、端末側で認証（QRコード等の二段階認証）が必要。
  • NCI（Gadi）はASPIREとは別のマシン。利用にはプロジェクトのメンバーシップ申請（join）が必要で、プロジェクトコードで検索して参加リクエストを送る。各自のアカウント名でログインする。
  • 接続手順は各自で一度確認し、後で画像付きにまとめてWiki（限定公開の想定）に残す。

情報共有：分報（Times）の導入

  • リーダーの提案。会社で導入している経験から、効率的だったとのこと（経験談）。
  • 「思ったこと・気づき・判断・決定」を時系列で書き溜め、チームで共有する。ドキュメントに残すほどでもないが後から見返したい内容の受け皿にする。
  • リアルタイム性と相性が良い。夏休み期間は出社・発表がまばらになるため、記録として特に有用。
  • チャンネルの粒度（個人ごと／チームごと／全体）は今後調整する。まずはTeamsに作成し、HPC／AIそれぞれの気づきを記録として残す。通知は非表示（ミュート）運用にする。

TODO

項目内容目的
提出物テンプレの整備報告項目（仮説・ボトルネック根拠・FVOPS before/after・decomposition・総SU等）を実験ログに組み込む提出要件を満たしつつ最適化を記録する
ベースライン測定Gadi（本番）で同一条件4〜5回実行し、spreadとprocess binding（解除で約3.7倍遅）を確認する4ノードの評価基準（baseline）を固める
data layout最適化の検討cache blocking・SpMV vectorization・通信計算overlap等、許可されたsource modificationを洗い出す数%止まりでなく大きな改善余地を狙う
環境構築手順のWiki化VPN接続・アカウント作成・ログイン手順を画像付きでまとめる全員が同じ手順で競技マシンへアクセスできるようにする
分報チャンネル作成Teamsに分報（Times）チャンネルを非表示で作る判断・気づきを記録して共有する
spread評価ルールの確認「改善率がspreadを下回るとscore対象外」の可否を公式ルールで確認するGadi優先の判断根拠を確定する

次回方針

  • HPCはGadiを主軸に、4ノードのベースラインを固めてから最適化に入る。まずはdata layout／cache locality方向の候補を検討する。
  • VPN・アカウントの環境が整い次第、各自が小林の測定を後追いで再現し、spreadを確認する。
  • 分報を実際に運用し始め、判断や気づきを蓄積する。

参考リンク