２０１６年１２月１６日（金）

OpenFOAMによる流体音解析の

ボトルネックとその対応

小林泰三　帝京大学福岡医療技術学部・九州大学情報基盤研究開発センター

於　秋葉原UDX　6F CONFERENCE(A+B)

第4回OpenFOAMワークショップ ― 大規模並列実行に向けた高速化とプリ・ポスト処理への取り組み ―

本日の話題

✤ 自己紹介

✤ 研究例：流体音数値解析

✤ 問題点の整理

✤ 対策・解決策：研究段階とそれぞれの解決法

✤ 九州大学情報基盤研究開発センターでの取り組み2

自己紹介✤ 物理屋（非線形・複雑系）✤ NAREGI の統合開発に参加

✤ グリッドミドルの apt-rpm 化とインストーラ設計・開発・配布

✤ グリッド配備運用タスクフォース技術担当✤ グリッドミドルの分散インストールと更新ツールの設計・開発・配布

✤ HPCI先端ソフトウェア運用基盤、JHPCN

✤ Open Source: VineLinux (PowerPC kernel), OSXWS,..

3

研究例：流体音数値解析

研究例：流体音数値解析

エアリード楽器の発音

Jet

?????

far field

musical tone

in the resonator ～140 dB(103 Pa)!!!

Ene. of airflow = 105 Ene. of sound

～60 dB(10-2 Pa)

5

研究例：流体音数値解析 6

時間刻み幅 :Δt=1.0x10-7[s]

⾳速が約340ｍ/sと速いため細かな時間刻みが必要

計算時間 : 0~0.1[s]（２次元)      0~0.03[s] (３次元)

ノズル径 d Ⅰ mm

管長 L 90 mm

エッジ角度 θ 25°

開口部 l 5 mm

管径 h 10 mm

流速U 4 ~ 40 m/s

厚さ（３次元） 10mm

(a)圧力測定: (0~0.005, 0.0005) (b)渦度測定: (0.08, -0.005)

計算法：圧縮性LES rhoPimpleFoam

温度：T＝300[K], ⼤気圧：P0=100kPa

数値モデル

研究例：流体音数値解析 7

points cells faces2D 158,762 78,492 314,8563D 4,048,431 3,924,600 11,896,692

Wall

Wave-Transmissive（Poinsot-Lele method)

楽器

3次元：厚み方向を５０分割

500×250mm2メッシュ図

研究例：流体音数値解析 8

流速分布 圧力分布V=12 m/s

圧縮性LESを用いて エアリード楽器発音の基本的な再現に成功

エアリード楽器のシミュレーション

研究例：流体音数値解析

Howe’s Energy Corollary

9

In order to calculate ∏, it is necessary to divide sound fields from fluid

� = �0

�(� � v) · v̄ dr

<0: fluid to sound >0: sound to fluid

: fluid velocityv: vorticity� (� � v)

v̄: acoustic flow

M.S. HOWE : IMA J. APPL. MATH. 32 (1984)

+ + +

- - -

(� � v)

(� � v)

�

�

vv̄

+ + +

- - -

�

�

vv̄

Sound to Fluid

Fluid to Sound

研究例：流体音数値解析

✤ 圧縮性LESで圧力振動を再現

✤ reproduce: fluid + sound fields

✤ obtain: acoustic pressure

✤ LESでの圧力振動を入力にして音場ソルバーで音場を独立に計算

✤ reproduce: sound field

✤ obtain:

✤ HECを　　　　から求める

HEC の計算方法10

�v

v̄

� v v̄� = �0

�(� � v) · v̄ dr

Jet �v

v̄

研究例：流体音数値解析

HEC：計算結果11

(1) (2) (4)

(3)

-50

0

50

100

150

0.025 0.03 0.035 0.04 0.045 0.05

Πg

[W/m

]

Time [s]

(1)

-50

0

50

100

150

0.025 0.03 0.035 0.04 0.045 0.05

Πg

[W/m

]

Time [s]

(2)

-50

0

50

100

150

0.025 0.03 0.035 0.04 0.045 0.05

Πg

[W/m

]

Time [s]

(3)

-50

0

50

100

150

0.025 0.03 0.035 0.04 0.045 0.05

Πg

[W/m

]

Time [s]

(4)

(2)で流体から音にエネルギーが変換されている

T. Kobayashi, et al, “Interaction between compressible fluid and sound in a flue instrument”, Fluid Dyn. Res. 46 061411, 2014

問題点の整理

問題点

過渡現象数値解析の特徴

✤ 現象が始まる前から終わるまで計算✤ 計算ステップ数が大きい：106ステップ

✤ 一本の軌跡（計算）では統計的議論が困難（な場合が多い）✤ アンサンブルが必要：×10

✤ 現象を俯瞰的に議論する✤ パラメータサーベイ：×100~1000

✤ 多段階プレ・ポスト処理

13

このような数値計算の現場では…？

加えて・・・流体音では： 最小メッシュ間隔＝0.1mm ⇔メッシュサイズ＝106~8

問題点

計算サイクルとボトルネック14

OpenFOAMの総出力ファイル数・容量

2 TB! / day with gzip

９割以上ポスト処理：うちストレージI/Oが８割

analysis 1

Super Computer

PC Cluster

Local PC

sim.

day0 1 2 3 4 5 6 7 8 9 10

tarftp

untar merge analysis 1visualization

11

ftpdiscussionポスト処

総ファイル数 =物理量�並列数� ステップ数出力インターバル � (Para. Surv.)

= 17 � 736 � 2 � 106

200� 4 � 5.0 � 108

総データ量 =総ファイル数� 1ファイル容量� 5.0 � 108 � 50kB � 25TB

問題点

ユーザーの研究サイクルとボトルネック

✤ これまで：数値計算✤ 通信、データ構造、計算アルゴリズム、並列化効率の改善

✤ 生成データ量が飛躍的に増加

✤ いま：tar, ftp, data merge

15

HPC研究対象を拡大： pre, postを含む計算サイクル全体へ

start

programing,building mesh,

etc.

pre process(setup initial conditions,

etc.)

simulation

post process(visualization, etc.)

discussion

研究者の計算サイクル

re-calculation?Yes

stop

No

過渡現象数値計算研究の PDCA* サイクル * PDCA cycle: Plan-Do-Check-Act cycle

問題点

大規模計算研究者の意識

✤ ３５課題中１０課題

✤ 研究主体はユーザーが多い

✤ 論文投稿先はユーザーの専門分野（流体・土木・建築…）

✤ フレームワーク化・一般利用は研究段階

16

情報処理学会研究報告IPSJ SIG Technical Report

start

stop

pre process(setup initial conditions,

etc.)

re-calculation?

simulation

post process(visualization, etc.)

discussion

Yes

No

研究者の計算サイクル

programing,building mesh,

etc.

図 1 数値計算を用いた研究の流れ．赤破線で囲まれた部分が研究者が計算機上で行う作業であり，これまでは緑の数値シミュレーション部分が計算時間の大半を占めており，計算機科学分野での研究対象ももっぱらこの数値シミュレーションになっている．しかし，大規模計算が可能になった現在では，ポスト処理に多大な時間が掛かる様になり，新たなボトルネックになってきている．

その一方で，計算に必要な入力データを整備するプレ処理や，数値計算結果を議論するために必要な可視化やデータ解析等のポスト処理にかかる手間と時間が膨大になり，新たなボトルネックになってきている．数値計算を行う研究者が計算機上で行う作業である計算全体を，図 1 に赤い破線で示した．緑の数値シミュレーションが最も計算リソースが必要であり，これまでは計算時間も計算全体の大半を占めており，計算機科学（HPC）でももっぱらこの数値シミュレーションを研究対象にしてきた．しかし，大規模計算が可能になった現在では，ポスト処理に多大な時間が掛かる様になり，新たなボトルネックになってきている．今後は図 1 に赤い破線で示したプレ・ポスト処理を含めた計算全体の状況も研究対象にする必要がある．実際に，この計算全体としての環境を整える事が重要であるとの議論が「学際大規模情報基盤共同利用・共同研究拠点 (JHPCN)」[5]にて行われており，さまざまな研究開発が進められている．この JHPCNでの 2012年度採択課題の中で，プレ・ポスト処理を含む計算全体の環境を整える必要性を述べているものを表 1に列挙する．全 35課題中 10課題が計算全体の環境整備の必要性を明記している．加えて，「移動境界問題及び連成計算の大規模流体シミュレーションと動的負荷分散の評価（12-NA09）」のように，ポスト処理がネックになっていながらそれらが研究者の興味を惹かなかったり，計算科学での成果が上がったためにあえて報告に明記していない研究課題も存在

表 1 計算全体の環境整備に言及している JHPCN 採択課題課題番号 課題名12-DA03 生体分子の大規模分子動力学計算に対する時系列

解析とその応用12-MD02 次世代ジオスペースシミュレーション拠点の構築12-MD03 高分子系粗視化シミュレーション基盤の計算機科

学的高度化検討12-MD04 壁乱流の大規模組織構造の解明がもたらすエネル

ギー高効率化への貢献12-MD05 グリッドデータファームによる大規模分散スト

レージの構築とサイエンスクラウド技術の研究12-MD06 マルチパラメータサーベイ型シミュレーションを

支えるシステム化技術に関する研究12-NA05 分野横断型ハイパフォーマンス計算力学の新展開12-NA10 超多自由度複雑流動現象解明のための計算科学12-NA11 GPGPU による地震ハザード評価12-NA16 災害影響評価のための大規模マルチフィジックス・

シミュレータの高度・高性能化

するであろう．いずれにしても，課題番号 12-MD06 のように，マルチパラメータサーベイを行うためのプレ・ポスト処理を含めた環境の構築そのものを研究する課題が存在する．これは，実際の大規模計算環境を利用して研究を行っている現場の研究者には，主たる数値計算の高速化だけではなく，図 1に赤い破線で示したプレ・ポスト処理を含む計算全体の高速化が重要であるとの認識が共有されてきていることを示している．しかしながら，これらの知見を計算機科学の研究対象にするには若干の距離がある．例えば，表 1に上げた課題には以下の特徴がある．• 研究主体が HPCを利用する計算科学者である• 論文投稿先が流体や土木・建築といった分野が多く，情報系が少ない

• フレームワーク化・一般利用化は研究段階であるものが多い

JHPCN の様な学際的な共同研究の場で明らかになってきたポスト処理を含む総合的な計算環境の問題は，この先のエクサスケール以降ますます重要になる．この認識を計算機科学の研究者間で共有するのが，本稿の大きな目的の一つである．本稿の構成は，続く 2節でポスト処理がボトルネックになっている数値計算の研究を事例として取り上げて，ボトルネックの詳細を議論する．つづく節にてボトルネックを解消するために進めている研究開発の進捗を報告する．

2. 流体音研究における事例ここでは，著者が研究に参加している流体音研究 [6] [7]

を題材にして，ポスト処理がボトルネックになっている状況を議論する．

c⃝ 2013 Information Processing Society of Japan 2

JHPCN: 学際大規模情報基盤共同利用・共同研究拠点

計算全体の環境整備に言及している2012年度JHPCN採択課題

ポスト処理の問題は、ほぼ共通認識

対策・解決策（基本方針）

対策・解決策

計算サイクル：I/Oベース

✤ 数値計算と各ポスト処理のすべてが独立してI/O

✤ ストレージの高速化に頼るのは筋違い！

18

physical quantities

simulation

conditions, mesh, etc.

start

stop

t <= T_end

simulation

Yes

No

Strage I/O

submit job

Super Computer PC Cluster for Post Processing Local PC

conditions, mesh, etc.

physical quantities

start

stop

merge

ftp

local

visualizationanalysis 1analysis 2

start

ftp

localdiscussion

stop5TB

5TB

5TB

5TB / 300GB

1TB

1TB

tar

5TB

Kyushu Univ. R.I.I.T. Resources

Local Lab. Resources

untar5TB

無駄なI/Oが多すぎる

対策・解決策

計算サイクル：ポスト処理連携

✤ OpenFOAM に

Nstream クラスとネットワーク関連クラスを実装して実現

19

GbEでも効果あり

Kyushu Univ. R.I.I.T. Resources

Local Lab. Resources

ftp

physical quantities

simulation

conditions, mesh, etc.

start

stop

t <= T_end

simulation

Yes

NoStrage I/O

submit job

Super Computer

conditions, mesh, etc.

physical quantities

start

stop

localvisualizationanalysis 1analysis 2

Network

1GB

30MB/sec

300GB

1TB

Local PC

start

localdiscussion

stop

1TB

PC Cluster for Post Processing

IOstream

Istream Ostream

ITstream ISstreamUIPstream

IFstream INstream

OSstream

ONstream

対策・解決策

analysis 1

Super Computer

PC Cluster

Local PC

sim.

day0 1 2 3 4 5 6 7 8 9 10

tarftp

untar merge analysis 1visualization

11

ftpdiscussion

計算サイクル：改善効果20

九大センターでサービス開始を目指して…

I/O処理

I/Oをストリームで置き換え

１計算サイクルを1/10

に削減

analysis 2

Super Computer

PC Cluster

Local PC

simulation

day0 1

analysis 1visualization

ftpdiscussion

2

Next Calc Cycle.

stream

対策・解決策

OpenFOAM が使われる理由

✤ 望むソルバーを簡単に作れる

✤ 計算法もパラメータと同様に設定

✤ 柔軟なプリ・ポスト処理窓口がある

✤ ボトルネックが数値計算からプレ・ポスト処理へ

21

対策・解決策

OpenFOAM の構造：ソルバー

✤ 偏微分方程式をそのまま記述

✤ ソルバーのコード自体はわずか数十行

22

望むソルバーを簡単に作れる#include "fvCFD.H"

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

int main(int argc, char *argv[]) { #include "setRootCase.H"

#include "createTime.H" #include "createMesh.H" #include "createFields.H"

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

Info<< "\nStarting iteration loop\n" << endl;

while (runTime.loop()) { Info<< "Iteration = " << runTime.timeName() << nl << endl;

solve ( fvm::laplacian(phi) + rho/epsilon0 );

rhoFlux = -k*mesh.magSf()*fvc::snGrad(phi);

solve ( fvm::ddt(rho) + fvm::div(rhoFlux, rho) );

runTime.write();

Info<< "ExecutionTime = " << runTime.elapsedCpuTime() << " s" << " ClockTime = " << runTime.elapsedClockTime() << " s" << nl << endl; }

Info<< "End\n" << endl;

return 0; }

物理さえ理解していれば

ソルバーを作れる！！

対策・解決策

OpenFOAM の構造：設定

✤ 物理はC++コードで実装

✤ 離散化法などの計算モデルやパラメータは設定項目

23

計算法もパラメータと同様に設定ddtSchemes { default Euler; }

gradSchemes { default leastSquares; }

divSchemes { default none; div(rhoFlux,rho) Gauss upwind; }

laplacianSchemes { default none; laplacian(phi) Gauss linear corrected; }

interpolationSchemes { default linear; }

snGradSchemes { default corrected; }

fluxRequired { default no; phi ; }

不確定要素を明確にコードから分離している！！

solvers { phi { solver PCG; preconditioner DIC; tolerance 1e-08; relTol 0.2; }

rho { solver PBiCG; preconditioner DILU; tolerance 1e-08; relTol 0.2; } }

fvSchemes

fvSolution

対策・解決策

OpenFOAM の構造：ポスト処理

✤ “run-time”アクセスが可能： 数値計算の時間発展ループ内に処理を追加可能

✤ OpenFOAM 内のクラスを利用可能： 目的の物理量への加工を OpenFOAM にさせてから使える

24

functionObjects

連成計算の窓口として

利用されている！！Function Objects を利用した連成計算実行デザイン例

simulation

conditions, mesh, etc.

start

stop

t <= T_end

simulation

Yes

No

OpenFOAM Solver

conditions, mesh, etc.

start

simulation

Post-Processing Server

EGCPOPSfunction Object

outlet

receiveValue()

sendValue()TCP/IP,EGCPOPS,.........

inlet

physical quantitiesphysical quantities

http://cfd.direct/openfoam/user-guide/post-processing-cli/

OpenFOAM の Post-Processing アクセスの framework

対策・解決策

研究段階と解決法25

OpenFOAM流儀 個別対応

方法 Class の改良・新設 functionObjects

研究開始時・計算結果のチェック

解析箇所を特定

既存ソースコード資産の活用

融通生・フレームワーク

全データが必要

必要データは限定

対策・解決策（九大での取り組み）

対策・解決策

九大基盤センターでの取り組み✤ OpenFOAM

✤ Sn で “routing” ポスト処理サーバへ直接データ転送✤ “NSTDIO”

✤ {FPN}stream 間連携

✤ MW: functionObject + P.P.

✤ 連成・連携計算管理機構✤ EGCPOPS の活用

27

ポスト処理問題解決から、他拠点間連成・連携計算に向けて

S1 …S2 Sn

スパコン

Network

研究者のPC

九大センター global

“NSTDIO” : stdio の様にネットワークを利用できる通信ライブラリ https://github.com/y-morie/nstdio

“EGCPOPS” : ユーザー権限のみで多拠点連携するフレームワーク https://github.com/RyzeVia/exgcoup

フロント

エンド

MWSINET

他センター

MWP.P.S.

“NSTDIO”

京コンピューター 商用版

通常の大規模 PCクラスタ構成 ＋GPU

通常の大規模 PCクラスタ構成 ＋Xeon Phi

大規模共有 メモリサーバ

Fujitsu PRIMEHPC FX10

Fujitsu PRIMERGY CX400

Hitachi HA8000tc/HT210

Hitachi SR16000 VM1

768 ノード 12,288コア

1476 ノード 23,616コア

965 ノード 23,160コア

1 ノード 256コア

SPARC64 IX fx

GAUSSIAN, GAMESS, 等々

GAUSSIAN, GAMESS, 等々

GAUSSIAN, GAMESS

Xeon E5-2680 + GPU

Xeon E5-2697 v2 + Xeon Phi

Power7

ソフトウエア インストールは 比較的容易

32GiB/node 128GiB/node 256Gib/node 16TiB

Fujitsu PRIMEHPC FX10

FujitsuPRIMERGY CX400

HitachiHA8000-tc/HT210

HitachiSR16000 VM1

大学等

12ノード

48ノード

96ノード

48,000円

192,000円

384,000円

4ノード

16ノード

64ノード

128ノード

16,000円

64,000円

256,000円

512,000円

4ノード

16ノード

64ノード

128ノード

19,200円

76,800円

307,200円

614,400円

1 CPU

8 CPU

16 CPU

10,000円

80,000円

160,000円

民間等

12ノード

48ノード

74,400円

297,600円

4ノード

16ノード

64ノード

28,800円

115,200円

460,800円

4ノード

16ノード

64ノード

32,400円

129,600円

518,400円

年間ご利用価格：共有タイプの場合

• ３ヶ月間単位での細かな利用期間での利用も可能です！

(2016年10月現在）

※この他，占有タイプもございます

利用形態のご紹介

共有利用 申請受付中！

申請受付中！

・・・通年で申請受付

占有利用 ・・・例年３月上旬が申請締め切り

・・・無償で利用可能

・・・今年度６課題採択

先進的計算科学研究プロジェクト

民間利用

バックエンドサブシステム B

次期スーパーコンピュータシステム概要

通常FEノード大容量メモリFEノード

インターコネクト

フロントエンドサブシステム

NFSサーバ

Web/NAT サーバ

インターネット

ストレージサブシステム

Ethernet

ログインノード

プライベートクラウドシステム

AzureAmazon Web Service

パブリッククラウド連携

バックエンドサブシステム A

GPUGPU GPU GPU GPU GPU

・アクセラレータ無し ・4.6PF～

・ アクセラレータ有り ・2.7PF～

・通常FE (384GBメモリ): 64ノード～ ・大容量メモリFE (4TB～メモリ）: 　　4ノード～ ・用途： 対話型処理（プリ・ポスト処理等)

・容量 20PB程度

九大情報基盤センターと OpenFOAM

✤ RIST 様・東京大学情報基盤センター様をはじめ、 OpenCAE 学会・HPCIなどにて情報共有・連携

✤ 個別要望に可能な限り対応

✤ FX10 では「京」で実行するジョブのテストとしても利用可能

32

皆様のご利用・ご提案・ご指摘をお願い申し上げます