「京」での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
© Copyright 2024 ExpyDoc
