1. No category

「京」でのOpenFOAM
支援内容と実績
2014.10.17
RIST神戸センター
産業利用推進室.ＡＰ東京
井上 義昭
1
コンテンツ
 支援課題状況
インストール支援
実行環境支援（ステージング方式）
性能分析・評価支援
• プロファイラ (基本fipp/詳細fapp)
• RIST最適版(通信処理、C++最適化フラグ）
• 支援課題での実例トピック
 可視化プリポスト支援
 AP東京ファシリティ
2
OpenFOAM支援状況
＃ 課
題
※
支援
状況
支援期間
（延べ月）
ミーティング実施回数
報告
レポー
RIST
RIST神戸 利用者
ト数
office
AP東京 センタ
5ヶ月
3
1
1
3
1
備考
1
T
完了済み
2
E
継続(2回目） 10ヶ月
3
3
J
継続(2回目） 12ヶ月
4
5
1
4
K
実施中
4ヶ月
2
2
1
今年度
開始
5
S
実施中
3ヶ月
2
2
1
同上
※「高度化支援依頼」の申請手続きの課題のみであり、京のヘルプデスク窓口において
実施されたOpenFOAMに関しての対応課題は含まれていない. 尚、課題名としては、課
題IDではなく、ユニークな任意の１文字で代用.
ヘルプデスク
高度化支援
https://www.hpci-office.jp/pages/support
https://www.hpci-office.jp/pages/k_koudoka
OpenFOAM支援状況
# 課題
Version Solver
サイズ
※1
並列
数
分割
支援内容
※2
1
T
2.1.0
chanelDNS
6710万2.68億
2000~
4000
Simple/ インストール支援、
Scotch 実行環境支援(STG方法),
性能評価（fipp/fapp分
析）、性能改善
2
E
2.1.0
2.2.0
interFoam
4000万
768
Simple
インストール/実行支援
プリポスト処理支援
性能評価/改善(2.7倍）
3
J
2.1.0
2.2.1
interFoam
9700万
~1280
Scotch
/Metis
インストール/実行支援、
可視化支援
(ParaView,EnSight)
性能改善（1.4倍）
4
K
2.2.1
pisoFoam
3550万,
1.4億
1536~
6144
hierarc
hical
インストール/実行支援
性能評価/改善(1.3倍）
5
S
2.2.1
pisoFoam
(pcg,amg)
9800万,
6億
1536~
12288
hierarc
hical
性能分析（メモリサイズ)、
評価支援/改善(1.3倍）
※1：性能評価用データのサイズ/並列数
※2:STG:ステージング方法、 fipp/fapp:基本/詳細プロファイラ
4
対象：全課題
インストール支援
•
神戸センターで発行のパッチをベースに、「京」初心者のOpenFOAM利用者向けに、
東京RISTで「OpenFOAMインストールとテスト実行」のドキュメントを発行
•
内容は、１章ダウンロードとビルド、２章テスト実行、2.1共用ディレクトリでの実行、
2.2ランクディレクトリでの実行をサンプルシェルを用いて具体的に説明
•
ソルバーの実行方法だけでなく、ステージングやデータ分割、リスタートファイルの作
成など実践での実行サイクルをフルカバー
(ランクディレクトリ使用の場合)
OpenFOAM実行ファイルのtar圧縮
並列実行数に合わせたdecompose
分割processorフォルダーのtar圧縮
サイクル
OpenFOAM 並列実行（最長24H)
結果ファイルから次のソルバ実行の入
力となる最終Timeスタンプ抽出
5
実行環境支援(STG方式)
対象：全課題
•
•
•
※STG:ステージング
「京」では、大規模実行向けに、他のJOBのIO負荷の影響を軽減させるべく、
グローバルFSとローカルFS （計算ノード専用）間のステージング機能を提供
大規模構成での実行の場合、STGの設定が性能に大きく影響するが、「京」
独自機能のため、不慣れな利用者は当初戸惑いがち.
RISTでは、サンプルシェルや性能分析で作成したシェルを提供
計算ノード群
（ジョブ実行）
ログインノード
（プログラム開発、ジョブ操作）
入力データ
データ領域
グローバル FS
/data
ファイルコピー
入力データ
出力データ ※
プログラム編集
ソースプログラム
ステージイン／アウト
ホーム領域
グローバル FS
/home
一時保存領域
ローカル FS
/work
入力データ
出力データ
コンパイル／リンク
ロードモジュール
ロードモジュール
ロードモジュール
ファイルコピー
ジョブスクリプト
ジョブスクリプト
ジョブ投入
※ ホーム領域へのステージングも可能
ジョブ実行
6
STGのためのtar処理時間
※
• STG方式ではプログラムの実行の前後にTar処理が必要となり、このtarを効率的
（並列等）に実行することは、ジョブの経過時間の軽減に貢献する場合がある.
（グローバルFS）
Tarball
圧縮
STGIN
Tar処理※
（計算node/ローカルFS）
Tarball解凍
(入力data
+ 実行file)
OpenFOAM実行
（MPI並列）
ジョブ経過時間
Tar処理※
（グローバルFS）
Tarball圧縮
(計算結果）
STGOUT Tarball
解凍
※STG:ステージング
• 一方、計算nodeのローカルFS側では、２つのDIR(directory)方式が有り.
DIR方式
内容（留意点）
用途
共有DIR
全MPIランク共通データ
（ランク間のIO競合発生）
OpenFOAM実行ファイル、
共通dataのsystemフォル
ダー等
ランク専用（他ランクとのIO
競合が軽微）
MPIプロセス毎に分散さ
れたProcessorフォルダー
ランクDIR
Tar圧縮・解凍の並列化
通常、不可×
並列処理が可能◎
(MPI
プロセスでの並列tar処理）
7
STG方式とtar時間比較
対象：課題E
※STG:ステージング
[実例１]
対象：課題K
192 mpi
6144 mpi
[実例2]
共通dataもランクDIR化
して並列tarでランク数
分展開、ランク数巨大化
でIO競合発生
結果dataのtar圧縮時間（共有DIR
のため並列処理不可）
ランクDIR化、
並列tarで大幅
時間短縮
共通dataは共有DIR上
に1つだけ高速展開、ア
クセス用にシンボリック
linkをランクDIRに作成
④
⑤
case
DIR方式
Tar形式
Tar実行
性能
①
共有DIR
bz2
シングル実行
×
tgz
シングル実行
△
tgz
並列実行
◎
②
③
ランクDIR
case
Processor
フォルダ
共通データ
system,constants
性能
④
ランクDIR
ランクDIR
IO競合発生 ×
⑤
ランクDIR
共有DIR（file) &
ランクDIR (ln –s )
軽速tar,IO競合
微小
◎
*1
＊1 Tar形式：tgz, tar実行: 並列実行（⑤は一部シングル）
8
対象：全課題
性能分析、評価支援
• ユーザから実データ（中規模.短時間モデル）を提供して
頂き、実際の特性・傾向に近いもので分析.評価
• 「京」での実データでの実行、プロファイラ データを採取
し、ボトルネックなどを調査分析、性能評価結果を報告
• 実際のプロダクション ランでの改善策を提言
• 課題共通の改善については、RIST提供の次期の京用
ビルドのパッチや実行手順のドキュメント等に反映
9
性能分析
基本プロファイラ(fipp分析）
（fipp採取データをIDE/profilerで表示)
コスト大の関数名
インバランス表示
pisoFoam 3027mpi 表示サンプル
>
(赤：MAX,緑：AVG,青：MIN)
コスト大の関数を調査、このデータでは、DICPreconditioner,lduMatrix,PCGや、MPI通信主体
のallReduce等が重く、これらの詳細プロファイラ(fapp)の採取を行い分析を続けます
又、BarChartの色の長さからMPIランクのインバランスの概要を把握し、必要に応じて特
定関数のランク詳細(右図）
を表示し、分散の仕方など
の改善なども検討します.
DICPrecond
rank
10
性能分析
詳細プロファイラfapp分析
Time(s)
interFoam
このデータでは、並列数が
640を超えた辺りから、実行
時間が急増!!
演算系処理
pEqn時間は
並列数にス
ケールし減少
データ交換 (MPI通信）
AlphaEqn
時間の急増
が原因
ここでは、fippで調査し
たコスト大の関数に対
して詳細プロファイラ
(fapp)を採取し、各関数
の実行時間をグラフ化
このデータでは、MPI通
信関連の関数
(AlphaEqn>exc3)がボト
ルネック化していること
が判明、ソースコードを
詳細に調査し、改善策
を検討した.
（ソースコード）
exchange.C
>combineGatherScatter.C
MPI並列数
fappでは指定した採取区間の実行回数/経過時間/UserTimeに加えて、HWモニター情報(Mflops,Mips,
メモリスループット,SIMD率、キャッシュヒット率等）、MPI特性情報(MPI命令別の経過時間/回数/MSG長、
その分布）などの詳細情報が採取できる
11
RIST.opt版
Time(s)
通信処理の最適化
実行時間内訳(fapp分析）
大幅性能改善
Alpha時間
(通信）
大幅削減
1280mpi
①標準のOpenFOAMでは、
gather/scatterの集団通信
をsend/recvの一対一通
信で実装、その通信処理
を並列動作するため、
通信順序/通信先を、Tree
構造(binary tree)に設定
②しかし、その処理の一部
(scatter)に性能面での不
具合（通信順序に、並列性
が乏しい）がある事が判明、
③それを是正※する様に、
RISTでプログラムを改善
※改善ソースは、近々に標準パッチとして、「京」利用者に提供予定. 尚、当該の性能面での不具合は、
MPI通信の基本性能に依存するが、1000mpi並列以上でないと顕著化しない、と推測される
12
RIST.opt版
C++最適化Flag(-Kfast)適応
コスト大の演算関数に限定して、「京」での最速・最適化flagの-Kfastでコンパイルする.
code
修正前
最適化flags
DICPreconditioner.C
-O3
-Kfast
lduMatrixATmul.C
-O3
同上
PCG.C
-O3
-Kfast -DvectorMachine(*1)
*1:sumProd,sumMagの
マクロ展開をvecter型に
変更
scalarField.C
-O3
-Kfast, nofp_relaxed
-DvectorMachine
-Kfastだけでは異常終了
PBiCG.C
-O3
-Kfast, -DvectorMachine
sumProd,sumMagを
include(*2)
smoothSolver.C
-O3
-Kfast, -DvectorMachine
同上
備考
(*2）sumProd/sumMagを使用するため、/fields/Fields/Field/FieldFunctions.Cをincludeしているので、親ごと最適化
flagでコンパイルする
13
実例：課題J データの大規模(「京」に相応しく）
実行効率％
③RISTopt版採用
②大規模化
①中規模化
Mpi並列数
順次、データ規模を「京」に相応しく、大規模化していき、RISTopt（最適バージョン）で実測、
結果検証にも協力頂きました！性能も640並列で効率1.8%(1.4倍）を発揮
14
実例：課題E
インバランスの改善（診断）
詳細プロファイラで
コスト大関数Surface
に、異常なimbalance
が存在している事が
判明、詳細を調査.
①Elapsed time
ランク144から以降のrankでElapsed時間
が大幅に増加
ランク144~192
rank
一部の特定rankの
System-timeが異常値
を示しており、これが
Imbalance発生の原因.
②system time
こちらもランク144から以降のrankで
大幅に増加、これが原因で①が発生
rank
ランク144~192
System-timeを増加させる事象には、IO処理などの他に、演算例外(underFlow,ゼロ割)
等があり、今回の関数ではIOは発生しないため、演算例外の可能性を調査した.
Sys-time
15
実例：課題E
ExecTime(SEC)
インバランス改善(-Kns option指定)
UP比
コンパイルオプション-Kns
を追加してビルドした.
（Kns:non-standard
floating point mode）
System-timeが大幅減少、
異常なimbalanceが解消し、
大幅な性能ＵＰを得ること
に成功、192mpiでは実行
時間(logのExecTime)で、
2.7倍の高速化となった.
mpi数(分割形状)
-Knsは、FPUをnon-standard floating point modeで初期化するもので段階的
underflowの処理を無効にしての実行となり、指摘の特定rankで発生しているsystimeの増加によるimbalanceを押さえるものである. 尚、underflow発生時、ＨＷで
即ゼロをセットするため、IEEEの規格外となるため、結果検証が必要となる.
16
実例：課題K
IO改善(Sampling採取の削減)
35Mcell
Time(sec)
1000回目
20回おき
イタレーション回数、20回周期や
1000回目で急増の階段有り！
6144mpiは段差拡大し、実行時間が
3072mpiより遅くなってしまっている.
性能逆転
35Mcell
Time(sec)
イタレーションloop時間
初期処理(初回exec.Time)
Loop時間比
①
イタレーション
②
RISTopt版で２割程度性能UPするも、
高並列(6144mpi)でスケールが飽和、
③
原因は頻繁に採取していたsampling
と判明、Samplingの採取Intervalを長
くして高スケール化(②>③）に成功!
尚、FX-10よりも３割高速の性能①と
なっている.
K_RISTopt with Sampling
※base:標準ビルド版
17
実例：課題S
MB
高並列でのメモリサイズ問題（調査中）
98Mcell
MAX MEMORY SIZE
（.iファイル情報）
MAX_MEMORY SIZE(USE)を調査、3072mpi以降、
急増. 京ではnode当たり14GB以内の制限のため、
メモリ不足で実行不可！
Memory不足
でエラー
KB
98Mcell
MEMORY SIZE内訳
Proc.0
Mpi数
Mpi数
12288MPIを超える実行には、
この問題の解決が不可欠
現在、詳細を調査、改善を検討中.
（有志の皆様のご支援、協力を！）
処理別にメモリ使用量を調査、イタレーション
loop処理での量はmpi数にscalして減少する
が、初期処理(setRoot,createMesh)での量が、
3072mpiから急増！
18
実例：課題S
Time(sec)
大規模データ＆高並列スケール
endT=2.01
98Mcell
ratio
大規模(98M)及び、超大規模(600M)での高並
列(1536~6144MPI)実行.
並列化率：99.99897%
98Mデータでは、RISTopt版は２割高速であり、
初期処理は並列数増加で急増するが、Loop処
理性能はMPI数に対し健全にスケールしている.
Time(sec)
ユーザビルド.1536mpi
RISTopt.1536
600Mcell
endT=2.01
ratio
Mpi数
600Mデータでは、演算処理のコストが増えたため
か、更にRISTopt版は３割程度、高速となり、
12288mpi並列での性能が期待される.
標準ビルド版
ユーザビルド版
19
実行効率とデータサイズ
実行効率%
97M
600M
98M
140M
実行効率(MFLPS%peak)をグラフ化
した. (※RISTopt版イタレーションloop性能）
当然、データやSolverの種類に大きく
依存するが、同じ種類の場合、
データサイズが大で、並列数が
少ない時が高効率となる事が判る.
35M
mpi数
MPIプロセス当たりのデータサイズ
で、ノーマライズしてみた.
実行効率%
MPIプロセス当たり,20Kcel程度以上
で1-1.5%規模であり、
dataSize[Kcel]/proc
逆に、2%を超えるには50-100Kcel
程度が必要と推測される.
20
対象：課題J/E
可視化プリポスト支援
「京」の大規模計算のプリポスト処理用にサーバが提供され、
計算結果の可視化に活用
プリポスト処理サーバ（2014年7月時点）
「京」システム（一部）
プリポスト処理
サーバ
フロントエンド
サーバ
インターネット
ssh
内部ネットワーク
計算結果データ
ユーザ
saver
利用形態
pps1
バッチ
pps2
バッチ
pps3
インタラクティブ
pps4
インタラクティブ
OS/SW
Red Hat Enterprise
Linux 6.5/
Intelコンパイラ,
GCC,
OpenMPI,
MPICH2,
RHEL6.5の標準パッ
ケージに含まれるソ
フトウェア
HW構成（CPU,メモリ）
Xeon X7560x8cpu ,1TB
(8core/2.26GHz/24MB)
Xeon X7560x8cpu ,512GB
(8core/2.26GHz/24MB)
Xeon X7560x8cpu ： 2TB
(8core/2.26GHz/24MB)
Xeon E5-2637x2cpu,512GB
(2core/3GHz/5MB)
https://www.hpci-office.jp/pages/aics_riken
 プリポスト処理サーバを利用したリモートインタラクティブ可視化
及びバッチ可視化を支援（手順書の提供、技術打ち合わせ）
 リモートインタラクティブ可視化（ParaView, EnSight※)：
「京」システム内のデータを直接読み込み、ローカルマシンのGUIでインタラクティブ
に可視化.
※EnSightはAP東京で利用可能
 バッチ可視化(ParaView)：可視化画像を連続作成.
 ユーザデータを使用して可視化を試行し、可視化ソフト利用の立
ち上がりを支援
21
対象：課題J/K/S
AP東京ファシリティ
 場所：東京都品川区北品川2-32-3 六行会総合ビル7階
RIST東京（京急 新馬場から徒歩２分） http://tokyo.rist.jp/ap-tokyo/
 提供サービス：コンシェルジュ的相談窓口、技術相談窓口
 利用設備：個別作業室（PC1台）、高速FTP環境、可視化サーバ
– AP東京と「京」コンピュータ間を専用１０Gbps回線で接続
AP東京
10Gbps
SINET4
・実効100~150MB/sec
（従来1Gbpsの2~3倍高速）
・OpenFOAMデータ実績:
600Mcel/6144分割データ
(約30GB)の転送に約40分
• 可視化サーバ Xeon 2.5GHz/16core/512GB、CentOS6.5
 利用可視化ソフト
 OpenFOAMでの使用実績
ParaView での小規模データを可視化試行
データ分割(decompose)実行（140Mcel/12,288分割）＋「京」への高速転送
22
まとめ
• ご清聴ありがとうございました.
• 今回は、RISTで支援した課題に関し、RIST最適化版の性能
や実際に遭遇した性能問題とその対策等を主体に紹介さ
せて頂きました.
• RISTには、「京」でのOpenFOAMの実行環境支援、性能評
価について、それなりに経験を積んできているのがご理解
頂けたら幸いです.
• 今後も、引き続き、「京」でのOpenFOAMを利用する課題に
関して、微力ながら支援を続けて行きたい、と思います
23
End
24