2026年6月5日金曜日

SPHのGPU化

SPH(粒子法)シミュレーションコードの GPU 化に取り掛かりました。

まずは、土のみ3Dコードから。テストには 斜面崩壊(粒子数77万弱、200,00step)を使用しました。実行環境は Dtransu と同じです。
GPU: NVIDIA RTX 4000 Ada(20GB、CC 8.9)
CPU: AMD EPYC 9754(128 コア)

いくつかの試行を得て、こちらは GPU 版が CPU 版に勝てない結果となりました。
OpenMP  32 / 64 / 128 スレッド 94.4 / 60.3 / 48.0s 
OpenACC 75〜84s 
CUDA Fortran + Thrust(set_box のみ)  41.7〜55.3s  

計算コードの変数を倍精度で計算していたため、FP64律速かつメモリ帯域律速となり、搭載GPU にとって二重に不利、CPU に有利でした。特に処理時間の約45%を占める make_interaction とkernel_correction は、GPU 側で改善できませんでした。粒子のセル順ソートは GPU では悪化、コアレス化は微妙でした。
  
セル分割処理だけはGPUで効果がありました。この処理は整数演算 が主体で、FP64律速にも帯域律速にも縛られなかったのでしょう。
  • セル分割(set_box):空間を格子(セル)に区切り、「どの粒子がどのセルにいるか」の対応表(名簿)を作る処理、近傍探索の前準備です。GPU 化では内部のソートに Thrust の sort_by_key (CUB の基数ソート) を使い、インデックス(cell_id と粒子番号)だけを並べ替えて名簿を作ります(粒子データ本体は動かさない)。これが GPU で効いた処理です。
  • 粒子のセル順ソート(reorder_particles):粒子データ本体そのものを、セルの順番に並べ替えておく「席替え」(50 step 毎)。近くにある粒子をメモリ上でも近くに置き、キャッシュ効率を上げる狙い。set_box内のソートと違い、倍精度の粒子配列を丸ごと移動するため、GPU では悪化しました (CPU ではキャッシュ効果で改善)。
  • メモリアクセスのコアレス化(pair_layout):粒子ペアのデータを GPU が読みやすい並び順に変える。GPU は隣り合うスレッドが連続したメモリを読むと速い(=コアレス化)ので、その並びに合わせる。
セル分割+ソート+コアレス化は DualSPHysics の講義で教えていただいたのを覚えていました。当時はメモリ上の最適配置程度で大きな影響があるとは思わず、ちょっとしたテクニック程度の認識でした。ほかにも、DualSPHysicsでは dx/dw など過去の値に依存しない変数は FP32、累積する変数は FP64 でドリフトを避ける工夫がなされています。

土のみコードは両者を倍精度で計算しており、一部を単精度にすると過去の結果(降伏、流体化の判定)の完全再現が困難。単精度化は周囲の応力均衡を変化させ、隣接粒子の降伏タイミングを次々とずらしていく連鎖を引き起こします。これは避けたいので、今回は速度を犠牲にして見送り。 

今回はここまで。次は、残したFP32化に手を付けるか、良いGPUに入れ替えるか、でしょうか。A100 / H100 クラスの GPU であれば、CPUを超えるかもしれません。

ソフトウェアサポートのカタチ

様々なソフトウェアサポートを利用しています。

近年、電話サポートが少なくなり、メールやチャットが主流になりました。どこも人手不足、コスト改善を迫られているのでしょう。

質は様々。電話サポートは意思疎通が簡単で、短期に問題を解決できます。ユーザーの限られている国内のソフトウェアメーカーや、サポート専門会社、外資系でも特殊なソフトだから実施できるのかもしれません。

ESRI Japan さんは、昔(10年以上前)はレスポンスが早く質も高かった。が、今は AI と1日1回の壁打ちをしているような感覚に陥ります。メールでの返事は1日1回、なので意思疎通ができるまで時間がかかる、帰ってくる内容の質が悪い、問題が解決しない、しかもお高い。AI に聞く方が速くて確実になってきました。
https://phreeqc.blogspot.com/2024/03/survey123-web.html

大手さんほど AI を利用する方向に進むでしょう。が、ユーザーとしては対話がBEST。
立場が逆であればと我が身に引き比べながら、お客様と対話し問題解決を図らなくてはならないとあらためて感じています。

2026年6月1日月曜日

Dtransu のGPU化 その3

テスト環境:CPUが高性能、GPUは中(FP64は低)性能でアンバランス。
GPU: NVIDIA RTX 4000 Ada(20GB、CC 8.9)
CPU: AMD EPYC 9754(128 コア)

1. 密度流 (v2 sample3.dtr, KAN3=2 密度連成) 

流れ:GPU + 粒子追跡:OpenMP  のハイブリッドとしました。
流れ系 (setelm ~48% + solpcg ~28%の self-time) が構造的に並列で GPU 理想形。ここを GPU カーネル化して大幅短縮です。

粒子追跡 MOVE1 連鎖 (~20%) はバケット探索の IF/GOTO  分岐が多く、GPU だと並列効率が落ちました。これは OpenMP スレッドに流す形が BESTでした。

2. 表面流+移流分散 

 一番速かったのは ompacc で、密度流と同じ戦略(流れ:GPU + 粒子:OMP)。全構成中で最大のを記録しました。
surface_flow.f90 (D8 地表水ルーティング) の self-time が ~2.3% しかないため、にここは GPU 化不要、host 常駐で問題なし。残りは密度流と同じハイブリッドという構成でした。


当初、なぜ FP64 が弱い GPU でも速くなったのか不思議でした。AIに聞くと、「典型的な arithmetic intensity(バイトあたりFLOP数)が低い 処理だったから」+「16tだから」とのこと。この辺りをAIに頼るようではまだまだかな。

  • 1要素読むごとの計算量はわずか。演算器はメモリ待ちで遊んでいるので足を引っ張らない。
  • GPUは数千〜数万スレッドを同時に走らせ、メモリレイテンシをスレッド切替で隠蔽。結果、自分の~360 GB/sをほぼ飽和できた。
  • CPU 側の並列効率が悪く、460 GB/sを使い切れず~16t相当で頭打ち。

純 GPU (acc)  が負けるのは、ハードの性能差が大きなこともありますが、分岐の多い粒子追跡が GPU の thread divergence に弱いのも一因。ここをテコ入れするとGPUの方が速くなるかもしれません。なお、途中でSPH の Box Search 手法を取り入れてみましたが、劇的な効果は見られませんでした。
このような計算をしていると、FP64に強いGPUだとどうなるのか、試してみたくなります。

改変コードの公開は配布元が許可されていません。時代の流れでコーディング問題はほぼ解決したので、いずれ配布元でもGPU対応版やMPI版、表流水連携版を公開されると思います。比較は出るまで待ちましょう。

2026年5月22日金曜日

Dtransu のGPU化 その2

Dtransu Ver.2 が手元にあったので、こちらもGPU化に着手。

テストは付属の密度流です。
もともと、OMP対応済みだったので、GPU化のみでした。が、何度かテストするうちに、再現性に劣ることがわかりました。

128tまで実施しましたが、16tで頭打ち。

v1 でも密度流をかけると、同じように再現性を確保できませんでした。テストするモノです。
密度流で PCG の流れが変わるのと、粒子追跡の OMP 化部分が引っかかっているようでした。最終的には v1 で固定しましたが、OMP+GPU の速度は v2 よりやや低下しました。
最初は v2 GPU+OMP でパラスタし、最後に v1 で提出、でしょうか。


2026年5月18日月曜日

Dtransu のGPU化

Dtransu のGPU化を実施。

AIさんがプロファイルをとってくれるので、非常に効率的でした。

RTX4000を使っていたのでFP64性能はイマイチ。それでも、2.5倍速くなりました。次は計算用途も考慮して選択しましょう。

ずっと優先度低で眠らせていた課題。今年の頭に外した途端、解決しました。残りは不連続体+連続体ですが、SPHのGPU化が先ですね。

優先度中:機械学習のスキル増強
優先度低:流体+個体(不連続体+連続体)+振動
優先度低:Dtransu の MPI/GPU 対応
優先度低:地表流+地下水+移流拡散


2026年5月10日日曜日

文献:High-resolution raindrop counting via instantaneous frequency sensing

High-resolution raindrop counting via instantaneous frequency sensing on hydrophobic elastic membranes | PLOS One

AI要約

1. 背景
雨粒の数やサイズを測定する装置であるディスドロメータは、気象観測において重要ですが、従来の装置には課題がありました。高精度な標準機器(JWDなど)は高価で、交流電源や専門知識を必要とするため、広範囲な設置が困難です。
一方で、安価な圧電素子を用いたセンサーは「振幅閾値方式」を採用しており、一度衝撃を検知すると一定時間計算を停止(ロックアウト)するため、時間解像度が低く、連続して衝突する雨粒を見逃したり、小さな雨粒を過小評価したりするという欠点がありました。
本研究は、市販のマイクと疎水性弾性膜を組み合わせ、低コストながらこれらの限界を克服する新しい検知手法を提案しています。

2. 手法
本手法は、振幅ではなく「瞬時周波数」の変化に着目している点が革新的です。

  • ハードウェア構成: 一般的なPVCパイプの片端に、安価なプラスチック膜(PETやHDPEなど)を張り、ドラムのような構造にしています。この膜に雨粒が衝突した際の音をマイクで集音します。
  • 物理的原理: 雨粒が疎水性弾性膜に衝突すると、膜の固有振動(低周波)とは別に、12–18 kHzの非常に短い高周波過渡振動が発生することを発見しました。この高周波信号は雨粒の衝突に特有のものであり、低周波の背景ノイズと分離しやすい特性があります。
  • Acoustic Feature Model (AFM): 音声データから、信号の局所的なピーク(山)と谷の位置を抽出し、ノイズを除去した上で「局所的な周波数推定値」へと変換します。
  • 機械学習 (1D-CNN): AFMで得られた特徴量を、1次元畳み込みニューラルネットワーク(CNN)に入力します。このネットワークは、風などのノイズと雨粒の衝突を判別し、衝突の確率を算出します。
  • 軽量設計: リソースの限られたマイコンやスマートフォンで動作(TinyML)させることを目的としており、モデルのパラメータ数は1000個未満と極めて軽量です。

3. 結果

  • 高い時間解像度: 従来の手法が30ms程度の解像度だったのに対し、本手法は約10ミリ秒の時間解像度を達成しました。
  • 精度: 評価実験において、予測されたイベントの80%~90%が実際の衝突時刻から10ms以内に収まっており、高い精度で雨粒を数えられることが示されました。
  • ノイズ耐性: 振幅を計算に使用しないため、低周波の振幅ノイズ(風など)に対して頑健であり、高い感度を維持したまま背景ノイズの影響を抑えることに成功しました。
  • モデルの有効性: DensenetやResidualブロックを用いたCNNモデルは、基本的なモデルよりもノイズ抑制能力が高いことが確認されました。

4. 考察
本研究の最大の特徴は、材料の物理的な減衰に頼るのではなく、信号処理と機械学習によって時間解像度を向上させた点にあります。

  • 利点と応用: 非常に低コストな材料で構築できるため、教育現場や発展途上国での気象観測ネットワーク、短期間のキャンペーン調査などに適しています。
  • 現在の課題: 強風による高周波ノイズが誤検知の原因となることがあり、さらなるノイズ除去技術や風防の検討が必要です。また、一度の衝突を二重に数えてしまうアルゴリズム上の課題も指摘されています。
  • 今後の展望: 今回は雨粒の「カウント」に焦点を当てていますが、将来的には個々の雨粒の運動エネルギーの推定や、平均的な粒径分布に基づいた降雨強度の算出へと拡張することが期待されています。
  • 未解明の物理: なぜ軟らかな疎水性膜への衝突で高周波振動が発生するのかという微視的な物理メカニズムは完全には解明されておらず、さらなる研究の余地を残しています。

塩ビパイプに膜を張って雨音を計測するだけという、これ以上ない実用的なアイデアです。
パイプのサイズや膜の張力は低周波の共振には影響しますが、検知に用いる高周波過渡振動(12–18kHz)には影響しないとのこと。また、 PETやHDPEといった異なる材質でも同様の信号が観察されています。身近な材料かつDIYによる物理的な製作誤差に対しても極めて高い堅牢性を持っている点が素晴らしい。
機械学習モデルも最初からエッジAI向きに作られています。今後の雨量推定がどうなるか、期待を込めて待ちましょう。


コード整備 その3

おまけです。

 ・振動計
200Hzサンプリング以上にするとデータ保存時にバグっていたのですが、AIに見せると問題点を指摘してくれました。浅いコピーをやめて深いコピー&数を増やすことで問題を回避。500Hzサンプリングでも問題なく保存できるようになりました。

・3次元安定解析
これもAIがバグを発見してくれました。学習量の多いであろうPythonで書いていたためか、割と早く修正が完了しました。正しい部分も怪しそうなところは指摘することもありましたが、そこに注意しておけば、コードの照査にかなり有効です。

・RegionGrow3D
MATLABコードをPythonに変換。近い将来できるようになると思っていましたが、もう既に可能だったとは。
1回目の変換で結果はピクセルベースで86%合致。もう少し詰める必要はありそうですが、なかなか賢い。

全体を通してみると以下のような感触。
◎既存コードを他の言語に変換したり修正したりする。
◎コードの照査
◎WEBサイトの解析
〇新たな実装
〇機械学習の自動化

まだまだ性能が上がっていくのでしょう。楽しみです。