@Misc{NagoyaITC_202007-imano, author="今野 雅", title={{名古屋大学スーパーコンピュータ不老のOpenFOAMベンチマークテスト}}, booktitle={第1回 スーパーコンピュータ「不老」ユーザ会}, organization={名古屋大学情報基盤センター}, year="2020", month="Jul", url = {http://www.icts.nagoya-u.ac.jp/ja/sc/overview.html}, }

1. 2020年8月31日 (WEB公開版: 2020年9月11日)
第1回 スーパーコンピュータ「不老」ユーザ会
「名古屋大学スーパーコンピュータ不老のOpenFOAMベンチマークテスト」
今野 雅 / IMANO Masashi
(株式会社OCAEL・東京大学情報基盤センター客員研究員)

2. 1 はじめに
• 学際大規模情報基盤共同利用・共同研究拠点(JHPCN)の2020年度一般共同研究課題
「機械学習を用いた風環境予測精度の向上と防災技術への応用」(課題代表者:高木洋平氏)
での共同研究では，以下の計算機資源が供与されている．
– 名古屋大学情報基盤センター 不老
– 東京大学情報基盤センター Oakbridge-CX (以下，OBCX)
• 本課題では，建物設計時の支援となるよう，機械学習を用いて，建物表面のピーク風圧や
歩行者高さでの風環境解析を短時間で予測するための基礎検討を行なっている．
• この機械学習を行うには，多数の建物形状に対して，教師データとなる非定常LES解析
(格子数3〜24M程度)と，入力データとなる定常RAS解析(格子数1〜3M程度)を行う必
要がある．
• 効率的な計算機資源の利用のため，不老Type I，Type II，CloudとOBCXでOpenFOAM
ベンチマークテストを行い，多数のLES，RAS解析を効率的に行うことができるシステム
や計算条件を検討した．
1

3. 2 オープンCAE学会チャネル流ベンチマーク
Lx × Ly × Lz = 5π × 2 × 2π
Reτ = uτ δ/ μ = 110 [-]
ここで
Lx , Ly , Lz : 各方向のチャネル幅 [m]
uτ : 壁面摩擦速度 [m/s]
δ : チャネル半幅 [m] ( =Ly / 2 )
μ : 動粘性係数 [m2/s2]
主流方向(x): 一定の圧力勾配
主流方向(x), スパン方向(z): 周期境界
ソルバ: pimpleFoam
乱流モデル: 無し(laminar)
領域分割手法：周期境界面は同領域
速度線型ソルバ: BiCG (前処理DILU)
圧力線型ソルバ: PCG (前処理DIC)
解析条件
✓メッシュ生成に時間を要しない
✓構造格子のため，格子数変更が容易
✓圧力と速度のみ解くので，「圧力線形ソ
ルバの解析時間が支配的」という非圧縮性
流体解析の特性を素直に示す
レイノルズ数Reτ 110
主流方向 一定の圧力勾配
主流・スパン方向 周期境界
ソルバ pimpleFoam
乱流モデル 無し(laminar)
領域分割手法 scotch(周期境界面は同領域)
速度線型ソルバ BiCG (前処理DILU)
圧力線型ソルバ PCG (前処理DIC)
• 多くのスパコンやクラウドで計測結果があり，他のシステムとの比較が可能なオープン
CAE学会のチャネル流ベンチマークで計測．
• 計測結果やジョブスクリプトは，チャネル流ベンチマークのレポジトリ[3]参照．
• 0.37M，3M，24Mの格子数で検討．
• 0.37M，3Mの格子数は1〜51ステップ，24Mは1〜9ステップの解析時間(Execution
Time)の平均値を算出し，さらに使用ノード数を掛けて，ノード時間[s]とした．
• PPN: Type I=48，Cloud=80, OBCX=56とフルコア，Type II=使用GPU数．
2

4. 3 Type Iの実行ケース
ケース名 OpenFOAM コンパイラ 主なオプション
v1912-module v1912 Fcc 4.2.0 -Nclang -O3(*1)
v1612-trad-O3 v1612+ “ -Ntrad -O3
v1612-trad-Kfast v1612+ “ -Ntrad -Kfastから-Kfp_relaxedを除外(*2)
v1612-clang-O3 v1612+ “ -Nclang -O3 -march=armv8.2-a+fp16+nosve(*3)
v1612-clang-fast v1612+ “ -Nclang -Ofast -march=armv8.2-a+fp16+nosve
v2006-clang-O3 v2006 “ -Nclang -O3 -march=armv8.2-a+fp16+nosve
v2006-clang-fast v2006 “ -Nclang -Ofast -march=armv8.2-a+fp16+nosve
v2006-Gcc-O3 v2006 Gcc 10.2.0 -O3(*4)
• (*1) spackでビルドされたType Iのopenfoam/1912_200506 module．ただし，sigFpe が
発生する場合があるため，moduleの設定でtrapFpe を無効化．
• (*2) -Kfp_relaxedを指定するとソルバが実行不可のため．
• (*3) sveを有効するとソルバ並列実行時にsigFpeが発生するため．
• (*4) Gccでは-march=armv8-aや，fp，simd，lse，rdma，dotprodの有効化で，有意に高
速化されることは無かった．またsveの有効化で並列計算不可．
3

5. 4 0.37M格子での1ノード解析時のノード時間の比較
v1912-module
v1612-trad-O3
v1612-trad-Kfast
v1612-clang-O3
v1612-clang-Ofast
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
0.00
0.05
0.10
0.15
0.20
0.25
0.30
0.35
0.40
Nodetime[s](<Lowerisbetter)
0.2s(0%)
0.2s(+17.7%)
0.2s(-7.9%)
0.2s(+2.7%)
0.2s(-10.3%)
0.2s(+2.4%)
0.2s(-12.4%)
0.2s(-1.3%)
• -O3よりfastレベルの最
適化のほうが高速．
• Fccのtradモ ー ド よ り，
clandモードのほうが高
速．
• Gccはclangモードの-O3
最適化と同程度．
4

6. 5 3M格子の1ノード解析時のノード時間の比較
v1912-module
v1612-trad-O3
v1612-trad-Kfast
v1612-clang-O3
v1612-clang-Ofast
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
Nodetime[s](<Lowerisbetter)
1.8s(0%)
2.1s(+13.1%)
1.5s(-20.6%)
1.7s(-6.5%)
1.5s(-20.5%)
1.8s(+0.4%)
1.6s(-13.3%)
1.7s(-4.5%)
• 0.37M格 子 と 同 様 の 傾
向．
5

7. 6 24M格子の1ノード解析時のノード時間の比較
v1912-module
v1612-trad-O3
v1612-trad-Kfast
v1612-clang-O3
v1612-clang-Ofast
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
0
10
20
30
40
50
60
70
Nodetime[s](<Lowerisbetter)
30.2s(0%)
40.0s(+24.4%)
27.8s(-8.8%)
32.9s(+8.1%)
29.1s(-4.0%)
30.3s(+0.3%)
26.6s(-13.7%)
28.7s(-5.4%)
• 0.37M格 子 と 同 様 の 傾
向．
6

8. 7 0.37M格子でのノード時間の比較
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
0.0
0.1
0.2
0.3
0.4
0.5
0.6
Nodetime[s](<Lowerisbetter)
01node
0.2s(0%)
0.2s(+2.4%)
0.2s(-12.4%)
0.2s(-1.3%)
02node
0.2s(0%)
0.2s(+1.2%)
0.2s(-10.3%)
0.2s(-1.2%)
04node
0.3s(0%)
0.3s(+0.7%)
0.3s(-10.6%)
0.3s(+0.2%)
• 新 し い バ ー ジ ョ ン の
v1912とv2006の み で 比
較．
• 多ノードでもFccのclang
モード-O3最適化はGcc
と同程度．
• Fcc clangモードのfast最
適化が最速で，moduleよ
り10%程度速い．
• nodeのshapeは 無 指 定
だ が，default allocation
modeはtorus．
7

9. 8 3M格子でのノード時間の比較
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
0
1
2
3
4
5
6
Nodetime[s](<Lowerisbetter)
01node
1.8s(0%)
1.8s(+0.4%)
1.6s(-13.3%)
1.7s(-4.5%)
02node
1.7s(0%)
1.7s(+0.1%)
1.5s(-14.6%)
1.7s(-4.1%)
04node
2.9s(0%)
3.0s(+2.2%)
2.6s(-11.4%)
2.9s(-1.9%)
08node
3.4s(0%)
3.4s(+2.0%)
3.0s(-11.4%)
3.3s(-2.9%)
12node
2.4s(0%)
2.4s(+0.5%)
2.1s(-11.1%)
2.3s(-4.8%)
24node
3.4s(0%)
3.5s(+2.8%)
3.4s(+0.9%)
3.2s(-4.0%)
• 0.37M格 子 と 同 様 の 傾
向．
8

10. 9 24M格子でのノード時間の比較
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
v1912-module
v2006-clang-O3
v2006-clang-Ofast
v2006-Gcc-O3
0
10
20
30
40
50
60
70
Nodetime[s](<Lowerisbetter)
02node
30.2s(0%)
30.3s(+0.3%)
26.6s(-13.7%)
28.7s(-5.4%)
04node
26.5s(0%)
26.7s(+1.0%)
23.5s(-12.6%)
25.1s(-5.2%)
08node
41.6s(0%)
41.6s(+0.1%)
36.8s(-13.2%)
39.6s(-5.0%)
12node
25.7s(0%)
26.3s(+2.5%)
23.4s(-9.5%)
24.7s(-4.1%)
24node
25.1s(0%)
25.8s(+2.7%)
22.8s(-10.1%)
24.0s(-4.6%)
• 0.37M格 子 と 同 様 の 傾
向．
• Type Iについては，今後
は最速のFcc clangモー
ド のfast最 適 化 さ れ た
OpenFOAM v2006の 結
果のみを示す．
9

11. 10 Type IIの実行ケース
ケース名 OpenFOAM コンパイラ 主なオプション
Volta rapidCFD-dev Nvcc 10.1.243 -O3 -gencode=arch=compute_70,code=sm_70
Pascal “ “ -O3 -gencode=arch=compute_60,code=sm_70
• Type IIはGPU機なので，OpenFOAM-2.3.1のThrustライブラリによるGPU実装である
RapidCFDを用いた．
• PCGの前処理は，DICではなく，AINVが用いられる[2]．
• Volta向けビルドとPascal向けビルドの比較も行なった．
• MPIライブラリは全てのmoduleのOpenMPI 4.0.3を使用．
• しかし，moduleのOpenMPI 4.0.3では，今回ビルドしたrapidCFD-dev(コミッ
ト:0fc3af285e3551234ffff9f9402c4c42f088af66)において，GPUDirect RDMAの機能を有
効にするとソルバが実行できなかったので無効とした．
• なお ，RISTの山岸らの既往の研究[4, 5]では，TSUBAME 3.0においてOpenMPI 2.1.1
を用い，rapidCFDのGPUDirect RDMAの有無を比較しているが，1〜64GPUの範囲では
特に有意な差が無い結果であった．
10

12. 11 0.37M格子のノード時間の比較
Volta
Pascal
Volta
Pascal
Volta
Pascal
0.0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
Nodetime[s](<Lowerisbetter)
01GPU
0.1s(0%)
0.1s(+0.2%)
02GPU
0.2s(0%)
0.2s(-0.1%)
04GPU
0.4s(0%)
0.4s(-3.3%)
1ノードでGPU数を変更
Volta
Pascal
Volta
Pascal
0.0
0.2
0.4
0.6
0.8
1.0
1.2
1.4
Nodetime[s](<Lowerisbetter)
01node
0.4s(0%)
0.4s(-3.3%)
02node
0.8s(0%)
0.8s(+0.2%)
1ノードで4GPUでノード数を変更
• 1GPUのジョブはノードを共有するcx-shareリソースグループで実行し，その他のジョブ
はノードを占有．
• Volta向けとPascal向けビルドで有意な差は無い．
• ノード内でGPUを増した場合でも計算時間が概ね一定で，ノード時間がGPU数に比例．
• ノード数が増えると，ノード時間が大きく増加し，スケールしない．
• 格子数が少ないため，ほぼ通信に費されている．
11

13. 12 3M格子のノード時間の比較
Volta
Pascal
Volta
Pascal
Volta
Pascal
0.0
0.5
1.0
1.5
2.0
2.5
3.0
Nodetime[s](<Lowerisbetter)
01GPU
0.5s(0%)
0.5s(-0.1%)
02GPU
0.8s(0%)
0.8s(+0.1%)
04GPU
1.3s(0%)
1.3s(+0.9%)1ノードでGPU数を変更
Volta
Pascal
Volta
Pascal
Volta
Pascal
0
1
2
3
4
5
6
Nodetime[s](<Lowerisbetter)
01node
1.3s(0%)
1.3s(+0.9%)
02node
2.2s(0%)
2.2s(+0.2%)
04node
3.3s(0%)
3.3s(+0.4%)
1ノードで4GPUでノード数を変更
• 0.37M格子と概ね同様の傾向．
• まだ格子数が少なく，概ね通信に費されている．
12

14. 13 24M格子のノード時間の比較
Volta
Pascal
Volta
Pascal
Volta
Pascal
0
2
4
6
8
10
12
14
16
Nodetime[s](<Lowerisbetter)
01GPU
6.9s(0%)
6.9s(+0.1%)
02GPU
8.8s(0%)
8.8s(+0.2%)
04GPU
9.6s(0%)
9.7s(+0.9%)1ノードでGPU数を変更
Volta
Pascal
Volta
Pascal
Volta
Pascal
0
5
10
15
20
25
30
Nodetime[s](<Lowerisbetter)
01node
9.6s(0%)
9.7s(+0.9%)
02node
8.1s(0%)
8.0s(-1.2%)
04node
15.5s(0%)
15.5s(-0.0%)
1ノードで4GPUでノード数を変更
• ノード内でGPUを増した場合，1GPUベースでの並列化効率は，2GPUで約77%，4GPU
で約70% であり，ある程度スケール．
• 1ノードより2ノードのほうがノード時間が減少しスーパースケールするが，4ノードでは
ノード時間が大幅に増加．
• Votlta向けとPascal向けビルドで有意な性能差が無いので，今後はVotlta向けビルドの結
果のみを示す．
13

15. 14 CloudおよびOBCXの実行ケース
ケース名 OpenFOAM コンパイラ 主なオプション システム
Flow Cloud v2006 Gcc 10.2.0 -O3 Cloud
OBCX “ “ “ OBCX
• CloudやOBCXでは，Gcc 10.2を用いてビルドしたv2006を用いたが，Gccの最適化オプ
ションについても，デフォルトの最適化オプションである-O3を用いた．
• CloudのシステムコンパイラであるGcc 4.8.5でもビルドを行なったが，以下のCloudでの
結果の通り，概ね10.2のほうが高速だったので，今後は10.2の結果のみ示す．
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
0.00
0.05
0.10
0.15
0.20
0.25
0.30
Nodetime[s](<Lowerisbetter)
01node
0.0s(0%)
0.0s(-4.9%)
02node
0.1s(0%)
0.1s(-12.0%)
04node
0.1s(0%)
0.1s(-21.4%)
08node
0.2s(0%)
0.2s(-20.8%)
0.37M格子
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
0.00
0.25
0.50
0.75
1.00
1.25
1.50
1.75
2.00
Nodetime[s](<Lowerisbetter)
01node
1.3s(0%)
1.3s(-1.5%)
02node
0.6s(0%)
0.6s(-1.4%)
04node
0.8s(0%)
0.8s(-2.6%)
08node
1.0s(0%)
0.9s(-13.8%)
16node
1.1s(0%)
1.0s(-9.4%)
3M格子
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
Gcc4.8.5
Gcc10.2.0
0
10
20
30
40
50
Nodetime[s](<Lowerisbetter)
01node
27.5s(0%)
28.0s(+1.7%)
02node
14.4s(0%)
14.7s(+2.2%)
04node
12.8s(0%)
12.4s(-3.3%)
08node
10.7s(0%)
10.3s(-4.3%)
16node
8.4s(0%)
8.4s(-0.7%)
24M格子
14

16. 15 各システムでの0.37M格子のノード時間の比較
0
0.1
0.2
0.3
0.4
0.5
0.25
(1GPU)
0.5
(2GPU)
1
(4GPU)
2
(8GPU)
4 8
Nodetime[s](<Lowerinbetter)
Number of nodes
Flow Type I
Flow Type II
Flow Cloud
OBCX
• Type I，Cloud，OBCXともに，2ノードまでノード時間がほぼ一定でスケール．
• Cloud, OBCX, Type IIの1GPU，Type Iの順にノード時間が増加．
• Type IIの1GPU，または，Cloud・OBCXの1ノードが効率的．
• 定常解析では領域分割のコストが高いので，領域分割が不要な1GPUが最も効率的．
15

17. 16 各システムでの3M格子のノード時間の比較
0
0.5
1
1.5
2
2.5
3
3.5
4
0.25
(1GPU)
0.5
(2GPU)
1
(4GPU)
2
(8GPU)
4
(16GPU)
8 12 16 24
Nodetime[s](<Lowerinbetter)
Number of nodes
Flow Type I
Flow Type II
Flow Cloud
OBCX
• Type Iは，2ノードまでスケール．1Tofu単位の12ノードで一旦減少．
• CloudとOBCXは，2〜8ノードまで概ねスケール．
• Type IIの1GPUは，Cloud 2ノードと同程度の最小値．
• 定常解析ならType IIの1GPU，非定常LES解析ならCloud・OBCXの2〜8ノードが効
率的．
16

18. 17 各システムでの24M格子のノード時間の比較
0
10
20
30
40
50
0.25
(1GPU)
0.5
(2GPU)
1
(4GPU)
2
(8GPU)
4
(16GPU)
8 12 16 24 32 48 64
Nodetime[s](<Lowerinbetter)
Number of nodes
Flow Type I
Flow Type II
Flow Cloud
OBCX
• CloudとOBCXは，16ノードまでノード時間が減少し，スーパースケール．
• Type Iは8ノードを除き，24ノードまでスケールするが，CloudやOBCXより遅い．
• Type IIは2ノードまではスケールし，Cloudよりもノード時間が大幅に小さい．
• 定常解析はType IIの1GPUまたは2ノード，非定常LES解析はCloud 16ノード，OBCX
16〜24ノードが効率的．Cloud(100ノード)とOBCX(1368ノード)の混雑も要考慮．
17

19. 18 各システムでの3M格子の解析スピードの比較
1 2 4 8 16 32 64 128
Number of nodes
103
104
105
Speed[Steps/h](>Higherisbetter)
Flow Type I
Flow Type II
Flow Cloud
OakBridge-CX
ITO
OCTPUS
Oakforest-PACS
FOCUS F
Linear
• Cloudが最速
• Type IIは1ノードで
はCloudと 同 程 度 だ
が，多ノードでは遅く
なる．
• Type Iは，概ね大阪
大学OCTOPUS(Intel
Xeon 6126[Skylake]
24コア/ノード)と同
程度．
18

20. 19 各システムでの24M格子の解析スピードの比較
1 2 4 8 16 32 64 128 256
Number of nodes
101
102
103
104
105
Speed[Steps/h](>Higherisbetter)
Flow Type I
Flow Type II
Flow Cloud
OakBridge-CX
ITO
OCTPUS
Oakforest-PACS
FOCUS F
Linear
• 1，2ノードを除けば
Cloudが最速．
• Type IIは1，2ノード
で最速だが，4ノード
で はCloudよ り 少 し
劣る．
• Type Iは，概ね大阪
大学OCTOPUS(Intel
Xeon 6126[Skylake]
24コア/ノード)と同
程度．
19

21. 20 まとめ
• JHPCN課題で供与されている計算資源の不老のType I，II，Cloud，および，東京大学
OBCXについて，オープンCAE学会のチャネル流ベンチマークを行なった．
• 機械学習のために実行する必要がある多数の建物形状に対する非定常LES解析や定常
RAS解析に対して，効率的なシステムやノード数等を選定した．
• 今後はより大きな格子数でチャネル流ベンチマークを行い，Type I，II，Cloud，OBCXの
特性を検討したい．
20

22. 謝辞
• FccのtradモードによるOpenFOAMのビルドは非常に時間がかかる上，tradモードでの
コンパイルはメモリ使用量が多いため，Type Iの計算ノード1台を用いてビルドした場
合，メモリ不足で異常終了しない並列数の上限は3並列であった．そこで，本研究では，
多数のビルドオプションを変更したベンチマークテストを効率良く行うため，
auto_wmake[1]を用いて，ベンチマークテストで用いるソルバと関数，および，その依存
ライブラリのみをビルドした．ここにauto_wmakeの作者のkurenaif氏に感謝する．
• 本研究は，学際大規模情報基盤共同利用・共同研究拠点の支援による(課題番号:
jh200064-NAH)．
Copyright
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike
4.0 International License(CC BY-NC-SA 4.0).
21

23. 参考文献
[1] auto_wmake. Accessed: 2020-09-11. URL:
https://github.com/kurenaif/auto_wmake/.
[2] Ilya B Labutin and Irina V Surodina. Algorithm for sparse approximate inverse
preconditioners in the conjugate gradient method. Reliable Computing, 19:121, 2013.
URL: https://hgpu.org/?p=11066.
[3] オープンCAE学会OpenFOAMベンチマーク. Accessed: 2020-09-11. URL:
https://gitlab.com/OpenCAE/OpenFOAM-BenchmarkTest/.
[4] 山岸孝輝, 井上義昭, 青柳哲雄, and 浅見曉. GPU・メニーコアにおけるOpenFOAMの
高度化支援紹介. In 第1回CAEワークショップ〜流体・構造解析アプリケーションを中
心に〜. 高度情報科学技術研究機構, Dec 2017. URL:
https://www.hpci-office.jp/pages/ws_cae_171206.
[5] 山岸孝輝, 井上義昭, 青柳哲雄, and 浅見曉. OpenFOAMの GPUによる高速化事例紹介.
In 平成29年度 高速化ワークショップ〜「京」を中核とするHPCIにおけるメニーコア
の活用を目指して〜. 高度情報科学技術研究機構, Mar 2018. URL:
https://www.hpci-office.jp/pages/ws_hpc_180323.
22