「京」での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