＊ここに掲載するのは、STFCデアズベリー研究所のStephen M. Pickles, Andrew R. Porter両博士によるHECToRレポート「Further Improving NEMO In Shallow Seas, Stephen M. Pickles and Andrew R. Porter, STFC Daresbury Laboratory, January 2014.」を要約したものです。
背景
NEMO(Nucleus for a European Model of the Ocean)[1]は、英国とヨーロッパにおける海洋学コミュニティにとって重要な海洋モデリングコードです。
NEMOは、全球や海洋盆地でも長年にわたり成功裏に活用されていますが、棚海モデルとしての利用に関してはそれほど開発されていません。棚海モデリング作業を外洋と連携させるのを目的に、英国気象庁と連携した外洋-棚海統合への取り組みのため、英国海洋研究プログラム(Oceans 2025; http://www.oceans2025.org)の棚海モデリング・パートナーらは、棚海モデリングに関してProudman Oceanographic Laboratory Coastal Ocean Modelling System (POLCOMS) [2, 3]の利用からNEMOの利用へ切り替えました。この決定に際して、彼らはNEMOがマルチスケール海洋学におけるグランドチャレンジを担うには膨大な作業が必要であることを認識しました。特に、棚海モデリングでのアルゴリズムや、コード性能、および近代的なアーキテクチャ上の数千コアに対するスケーラビリティが問題になります。
このプロジェクトは以前のNEMOとPOLCOMSに対する仕事を引き継いでいます。dCSEプロジェクトでは、コンパイルフラグや、netCDF4.0によるファイル圧縮、前処理による陸地のみのセルの排除が実施されました[4,5]。GNEMOプロジェクト[8]ではGPUへの移植も検討されました。
ハイブリッドOpenMP/MPI並列[10]は、マルチコアと共有メモリーノードが広く使われるようになるにつれて重要度が増しており、CMCCにおいてNEMOへの初期的な適用が実施されました[11]。この活動はPRACE-2IPのワークパッケージ8で継続されており、[11]で採用された方法の代替アプローチが検討されました。
NEMOのI/O性能問題は、NEMOのコアプログラム内での非同期並列I/O（XIOSを利用）の開発によって解決されています。これはNEMOバージョン3.6に入っています。
GSUMプロジェクト[6]の成果とGCOMSプロジェクト[3]でのPOLCOMSの領域分割法の改善により、[9]で開始された仕事の実現性が確立されたためここで継続しました。
領域分割、配列インデックス順序、マスキング
POLCOMSの3次元場はz-first順に保存されます。これは言い換えれば、a(z,x,y)といったFortran配列で宣言され、鉛直方向のインデックスzがメモリー上で連続になります。POLCOMSは、計算負荷バランスを領域分割で対処し、実行時に領域は再帰的kセクション分割法[2]により近似的に同数のwetポイントを持つように矩形領域に分割されます。分割後に残ったDryポイント上の計算は、地点(x,y)がdryなのかどうかを実際に確認して回避されます。[7]において、この方法は拡張されて、複数の領域が並列に評価されるようになりました。以降この方法を' multi-core aware partitioning'と呼びます。
これとは対照的に、NEMOの3次元場はz-last順にFortran配列a(x,y,z)といった形式で保存されます。NEMOは領域を均等なサイズの矩形領域へ分割します。ここではwetとdryポイント上で同じ計算を行い、結果に3次元マスクを乗算することで余分な結果を除外しています。このやり方は多くの冗長さによる計算負荷の分散が生じますが、ベクトルアーキテクチャには適したものです。
以前のdCSEプロジェクト[9]では、NEMOの性能とスケーラビリティ改善が図られ、特にdryポイントが全体の50%以上を占めるような浅海問題を対象にしていました。zファーストオーダーでは乾燥点の計算を避けることが実用的であることに注意すべきです。そこでは点（x、y）が陸にあるかどうかをテストするオーバーヘッドは、全体にわたって減らすことができます。作業は以下の順に行いました：
- NEMOへ'multi-core aware partitioning'およびハロ交換最適化を導入。
- 全3次元配列をz-lastからz-first順へ変更。
- ループネストを、z-first順序においてより良好なキャッシュ効率となるように入替。
- 領域分割後に残ったdryポイントを避けるように手動修正。
作業結果はNEMOソースブランチへ登録されました。元のz-lastあるいはz-firstバージョンの選択をプリプロセッサで選択が可能です。残念ながらこの作業は全ソースファイルに渡る大きな労力を必要としたため、余分なdryポイント上の計算の削除と負荷バランス化作業には、時間の都合上至りませんでした。
このプロジェクトにおいて、NEMOが海底の下にあるフィールド値についても冗長な計算と通信を実行することが判りました。これは、サポートされている垂直座標スキームのいくつかでは、各点（x、y）でのアクティブレベル数がドメイン全体で変化するために発生します。
プロジェクトの推移
プロジェクトは6人月掛かり、2013年12月に終了しました。当初の作業計画は以下の通りです：
- 海底下の場の値をハロメッセージから除去することで、3次元場のハロ交換の帯域幅を削減する。これは、z-first/z-last両方の順序で実装する。
- ファイルからパーティション情報を読み込むためのオプション機能をNEMOに追加する。これにより、オフラインで生成された「グリッド区画」マップを使用することが可能になる。このマップは手動で編集可能なので、長時間の運用でパーティションを手動でチューニングすることが可能になる。
- 各プロセッサのサブ領域の最も深いレベルを決定し、外側ループを鉛直次元に制限して、下位レベル（海底の下にある）が横切らないようにする。この変換は既存のz-last順序でも機能する。
- 各グリッド位置でアクティブレベルのみをループすることで、z-first順序により主要ルーチンの負荷バランスとキャッシュ効率を改善し、陸地および海底下の重複計算を排除する。対象のルーチンは、HECToR上でのCrayPatの結果から優先的に選択する。この作業で実行時間の50％以上を占める10-20ルーチンを変換すること。British Islesを取り巻く限られたエリアモデルであるAMM12構成を、テストとパフォーマンス測定の両方に使用する。
作業結果
海底下の場の削除
以前のプロジェクトの、NEMOの再帰的k-セクション分割バージョンでのハロ交換は、プロセス間で通信されるdryポイント数を減らすように最適化されていました。これは、各ハローを連続したwetポイントのパッチに分割し、それらのパッチのみを通信することによって達成されています。この作業では、パッチ内の水柱の最大深度の深さを含むようにこれらのパッチを拡張しました。
これをAMM12構成でテストしましたが、大きな性能向上には至りませんでした。これはプロセス間で交換されるデータポイントの数が1％程度に過ぎなかったためです。これは、この構成の垂直レベルに使用されるハイブリッドz-s座標スキームに起因します。この方式は、海洋深度に応じてグリッドの垂直解像度を調整し、海底下の垂直レベルの数を最小限に抑えます。それほど洗練されていないz座標スキームを使用すると、効果が大きくなる可能性はあるでしょう。
領域パーティションのファイルからの入力
この新しい機能は、ネームリストファイルの&nammppセクションに新しいフィールドnn_readpartを用いて、これを.TRUEに設定することで有効になります。こうすると、現在の作業ディレクトリのファイル'partition.dat'から分割情報を読み込みます。
深度ループを各サブ領域の最深レベルへ制限する
垂直モデルレベルの数を保持する変数を上書きすることで、この機能を実装しました。
各グリッドポイント上でwetレベルのみループする
我々の再帰的kセクション分割アルゴリズムでは、dryポイントには計算コストがなく、wetポイントのみがカウントされると仮定しています。Dryポイント上の計算を除外するコード修正を行いました。
結論
原理的には、乾燥ポイントに対する余分な計算を完全に排除すると、ドメイン内の乾燥ポイントの割合に等しい性能向上がもたらされます。これはグローバルモデルでは約20％、Met OfficeとNational Oceanography Centreが使用するような限定エリアモデルでは約50％程度です。実際には、完璧な負荷バランスを達成することが不可能であるため、パフォーマンスはこれよりもいくらか少なくなります。しかし、POLCOMSの経験により、90％の負荷バランスが容易に達成できると期待できます。また、領域分割の手動調整（例えば、スタンドアロンパーティショニングツール）を考慮すると、95％を期待するのは不合理ではありません。したがって、合理的なパフォーマンス目標は、AMM12（I / Oを除く）などの構成で実行時間の45％削減となります。
しかしながら、FINISS-NEMOの性能がこの目標を下回っていることは明らかです。
理由の一つは、乾燥点のループレベル除去が完全ではないという事実です。これにより、負荷バランスはルーチン（除去ループの有無）に依って異なります。
もう1つの要因は、ループ本体内のマスクへの参照を排除していないことです。この結果、FINISS-NEMOはすべてのループ内で冗長な乗算だけでなく、マスク配列の冗長なロードを実行します。
結論として、我々はドライポイントのループレベル回避の実行を完了し、FINISSの分割アルゴリズムの改良により、浅海テストケース（50％土地）で40％の実行時間の削減を達成しました。更なる改善には、三重対角ソルバーの改善、あるいはz-firstオーダーの最適化が必要と考えられます。
謝辞
このプロジェクトは、nAG Ltd.が運営するHECToRの分散計算科学および工学(CSE)サービスの基に実行されました。英国の国立スーパーコンピューティング・サービスである、HECToR：英国リサーチ・カウンシル・ハイエンド計算サービスは、リサーチ・カウンシルを代行するEPSRCが管理しています。そのミッションは英国学術界の科学および工学の研究支援です。HECToRスーパーコンピューターは、UoE HPCx Ltd.およびnAG Ltd.のCSEサポートサービスにより管理運営されています。
文献
[1] G. Madec, "NEMO ocean engine", 2008, Note du Pole de modelisation, Institut Pierre-Simon Laplace (IPSL), France, No 27 ISSN No 1288-1619.
[2] M. Ashworth, J.T. Holt and R. Proctor, "Optimization of the POLCOMS hydrodynamic code for terascale high-performance computers", Proceedings of the 18th International Parallel & Distributed Processing Symposium, Sante Fe, New Mexico, 26-30 Apr 2004.
[3] Jason Holt, James Harle, Roger Proctor, Sylvain Michel, Mike Ashworth, Crispian Batstone, Icarus Allen, Robert Holmes, Tim Smyth, Keith Haines, Dan Bretherton, Gregory Smith, "Modelling the Global Coastal-Ocean", Phil. Trans. R. Soc. A, March 13, 2009 367:939-951; doi:10.1098/rsta.2008.0210
[4] Fiona Reid, NEMO on HECToR - A dCSE Project, 4th May 2009, HECToR web site, http://www.hector.ac.uk/cse/distributedcse/reports/nemo/nemo_final_report.pdf.
[5] Fiona J. L. Reid, "The NEMO Ocean Modelling Code: A Case Study", Proceedings of the Cray User Group, Edinburgh, 2010.
[6] M. Ashworth and A. Porter, "Towards Generic Scaling of NEMO, the oceanographic component of the Unified Model", Final Report for the GSUM project, 2009.
[7] Stephen Pickles, "Multi-Core Aware Performance Optimization of Halo Exchanges in Ocean Simulations", Proceedings of the Cray User Group, Edinburgh, 2010.
[8] A. R. Porter, S. M. Pickles, M. Ashworth, "Final report for the gNEMO project: porting the oceanographic model NEMO to run on many-core devices", Daresbury Laboratory Technical Reports, DL-TR-2012-001 (2012).
[9] Stephen M. Pickles and Andrew R. Porter, "Developing NEMO for Large Multi-Core Scalar Systems: Final Report of the dCSE NEMO Project," Daresbury Laboratory Technical Reports, DL-TR-2012-002 (2012).
[10] L. Smith and M. Bull, "Development of mixed mode MPI / OpenMP applications", Scientific Programming, Vol. 9, No 2-3, 2001, 83-98.
[11] Italo Epicoco, Silvia Mocavero, and Giovanni Aloisio, "NEMO-Med: Optimization and Improvement of Scalability", CMCC Research Paper No. 96, 2011.
[12] Stephen Booth, "FTRANS User Guide", 1996.
[13] R. Ford, M.J. Glover, D.A. Ham, C.M. Maynard, S.M. Pickles, G. Riley, N. Wood, "Gung Ho: A code design for weather and climate prediction on exascale machines", Proceedings of the Exascale Applications and Software Conference, 2013, in press.
[14] "Note on possible system simplification", NEMO consortium internal memo, 2013.