# 格子ボルツマン法 ## 定義 格子ボルツマン法(Lattice Boltzmann Method、LBM)は、規則格子上で流体粒子の速度分布を更新し、流れをシミュレーションする計算流体力学の手法である。 格子点ごとに速度方向別の分布関数を持ち、近傍への streaming と、局所的な collision を反復する。 [[@2004__SC__GPU Cluster for High Performance Computing|Fan ほかの SC'04 論文]]は D3Q19 格子と BGK 衝突モデルを GPU クラスタへ写像し、都市形状を含む空気中汚染物質の拡散を計算した。 ## 計算構造 - **格子**: D3Q19 では 3 次元格子点ごとに 19 の速度方向を持つ。 - **状態**: 速度方向ごとの分布関数 `f_i`、速度リンク `c_i`、密度、流速を保持する。 - **更新**: streaming で隣接格子点へ分布を移し、collision で局所平衡へ緩和する。 - **境界**: 境界面と格子リンクの交差情報を使い、曲面や複雑形状を表現する。 - **精度**: Fan ほかは時間・空間について 2 次精度で、非圧縮 Navier–Stokes 方程式へつながる手法として説明する。 ## GPU・クラスタへの写像 LBM の状態は速度方向ごとのボリュームへ分け、4 ボリュームを 1 スタックの 2D テクスチャへ詰められる。 各 GPU ノードが 3D サブドメインを担当し、境界サイトの分布関数を最近傍ノードへ交換する。 規則格子上の局所更新は GPU の大量並列処理と相性がよい一方、サブドメイン境界の通信、GPU–CPU 転送、複雑な境界情報の保存がクラスタ性能を制限する。 ## 横断的知見 - **LBM は GPU の計算性能だけでなくデータ移動の設計を評価する代表的な規則格子アプリケーションである**: Fan ほかはテクスチャへの状態配置、GPU–CPU 転送、MPI 通信、通信と計算のオーバーラップを一体として実装した。[[@2023__CSUR__Optimization Techniques for GPU Programming]] は GPU 最適化をメモリアクセス・不規則性・バランシング・ホストインタラクションの 4 テーマに整理しており、LBM のボトルネックはそのうちメモリアクセスとホストインタラクションが結びつく例として読める。(Source: [[@2004__SC__GPU Cluster for High Performance Computing]], [[@2023__CSUR__Optimization Techniques for GPU Programming]]) - **境界面積と体積の比は、GPU クラスタの問題サイズと通信効率を同時に決める**: Fan ほかはサブドメインを立方体に近づけると境界面積/体積比を小さくできるとし、固定問題サイズではノードを増やすほどサブドメインが小さくなり計算/通信比が低下すると示した。これは現代の LLM 訓練で並列化次数と物理トポロジを協調設計する議論と同じく、計算分割の粒度が通信コストを決めるという構造である。(Source: [[@2004__SC__GPU Cluster for High Performance Computing]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **通信と計算のオーバーラップは、通信が消えることではなく非重複部分を遅延へ残す**: Fan ほかでは 28 ノードまではネットワーク通信を計算に重ね合わせられたが、28 ノード以上で非重複通信が増え、32 ノードの効率は 66.8% へ低下した。後続の GPU クラスタ研究でも、通信を隠蔽できる範囲と、トポロジや並列化配置によって残る通信クリティカルパスを分けて測る必要がある。(Source: [[@2004__SC__GPU Cluster for High Performance Computing]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **物理トポロジの最適化以前に、アプリケーションの通信相手を減らすアルゴリズム設計が効く**: Fan ほかは D3Q19 の第二近傍データを直接交換せず最近傍ノードで中継し、通信パターンを単純化した。後年のトポロジ考慮型 GPU スケジューリングは通信要求グラフを GPU 間リンクへ写像するため、通信パターンの単純化と配置最適化は別層だが連続した設計対象である。(Source: [[@2004__SC__GPU Cluster for High Performance Computing]], [[@2017__SC__Topology-Aware GPU Scheduling for Learning Workloads in Cloud Environments]]) - [GPU・クラスタへの写像] multiphase LBM(Free-energyモデル)は、D3Q19(運動量分布)とD3Q7(相の分布、D3Q19の部分集合)という2種類の離散化を併用し、各反復でrho/velocity更新→φ交換→collision→f交換→streaming→f/g交換の6ステップを踏む。f/gの近傍交換はMPI subarray/vector/struct datatypeで表現でき、非連続GPUデータ通信の評価に適した典型例になっている(Source: [[@2014__TPDS__GPU-Aware MPI on RDMA-Enabled Clusters - Design, Implementation and Evaluation]])。 ## 未解決の問い - LBM の境界通信を、現代の GPU 起動型ネットワーキングや GPU-aware MPI でどこまで GPU–CPU 転送なしに実行できるか。 - 非圧縮流体以外の反応輸送・熱流体・多相流で、D3Q19 と BGK の単純な写像が精度・安定性・メモリ量の面で成立するか。 - 固定問題サイズでノードを増やしたときの通信効率低下を、サブドメイン形状、通信スケジュール、ネットワークトポロジのどの層で最も費用対効果よく抑えられるか。 - 現代 GPU の HBM、共有メモリ、非同期コピー、複数 GPU ノードを使う場合、速度分布のテクスチャ配置はどのメモリ階層設計へ置き換わるか。 ## 関連 - ソース: [[@2004__SC__GPU Cluster for High Performance Computing]] - 概念: [[GPU最適化]] / [[GPUクラスタ運用]] / [[HPCインターコネクトベンチマーク]] / [[並列化戦略]] - エンティティ: [[Zhe Fan]] / [[Feng Qiu]] / [[Arie Kaufman]] / [[Suzanne Yoakum-Stover]] / [[Stony Brook Visual Computing Cluster]] - 関連 MOC: [[HPC - MOC]] ## 出典 - [[@2004__SC__GPU Cluster for High Performance Computing]](§4 LBM の流体モデル・単一 GPU 写像・クラスタ分割・通信スケジュール・性能評価) - [[@2023__CSUR__Optimization Techniques for GPU Programming]](GPU 最適化の 4 テーマ) - [[@2017__SC__Topology-Aware GPU Scheduling for Learning Workloads in Cloud Environments]](通信要求グラフと GPU トポロジの写像) - [[@2014__TPDS__GPU-Aware MPI on RDMA-Enabled Clusters - Design, Implementation and Evaluation]](multiphase 3D LBM(Free-energyモデル)をGPU-Aware MPIで最適化し、64GPUで最大19.9%のアプリケーションレベル性能改善)