関連情報
ホーム > 製品&サービス > コンサルティングサービス > HPCチューニングサービス > 事例一覧 > HECToRプロジェクト - CASTEP/ONETEPのパフォーマンス改善

HPCチューニングサービスの事例

HECToRプロジェクト
CASTEP/ONETEPのパフォーマンス改善

対象プログラム 電子構造計算
アプリケーション名 CASTEP/ONETEP
チューニング方法 limited-memory版BFGSアルゴリズム(L-BFGS)への切り替え
成果 座標最適化機能(BFGS法)のパフォーマンス向上。原子数に対するメモリー増加が線形にスケールした。
[2014年5月掲載]

HECToR dCSE Team による材料科学コード(CASTEP, ONETEP)のパフォーマンス改善

Matt Probert, University of York
Jolyon Aarons, University of York
HECToR CSE Team, Numerical Algorithms Group Ltd (NAG)

CASTEP/ONETEP

英国の国立学術スーパーコンピューティング設備であるHECToR 向けのNAGの計算科学技術(CSE)サポートサービスのもとで業務を行っているヨーク大学のHPC開発者は、材料科学コードCASTEPとONETEPの構造最適化についてパフォーマンスの改善(所要時間と使用メモリ両方に関して)を行いました。この改善により科学者は予算内でより大きく複雑な系を研究することが可能になります。

研究できる系のサイズは2倍に増加しました。これにより、これらのコードで対処できる新しい問題領域が広がりました。

dCSE プロジェクトに言及して、ヨーク大学の物理学部のMatt Probert 博士は次のように述べています。「CASTEPとONETEPの新しい構造最適化ツールの開発はすばらしい成功を収めました。必要なメモリ量が大幅に削減されるとともに、『科学に要する時間』、すなわちどちらかのコードで完全な構造最適化を行うための時間が、維持あるいは特定の状況下で削減されました。マルチコアへの移行と同様に、この後者が重要なポイントです。コアあたりのメモリ量は減少しており、古い構造最適化ツールは大量の非分散型メモリを消費し、対処可能な問題サイズを制限し始めていました。結果として、現在はCASTEPとONETEP両方のユーザは非常に大きな系に対処できます。古いコードではHECToR Phase 3 上で約3,000原子が有効な最大サイズでしたが、現在は100,000原子までに増加しました。これによりCASTEPのユーザは粒界といったより大きな系を研究することができます。またONETEPのユーザはタンパク質やDNA断片といったより大きな分子を扱うことができます。 もちろんすべてのCASTEPやONETEPユーザがこのようなサイズの系を研究できるわけではありませんが、新しい最小化ツールに対してマイナス面はありません。全ての計算は以前と比べて同じか少ないメモリを使用します。(例外として非常に小さい系ではHECToR上で有効に実行できません。)また以前と比べて同じか少ない時間で収束します。新しい最小化ツールはCASTEPとONETEP両者の次期バージョンではデフォルトのアルゴリズムとなります。」

HECToR
HECToR はResearch Councils を代行する EPSRC により管理されており、英国学術界の科学と工学をサポートする任務を負っています。エジンバラ大学にある Cray XT スーパーコンピュータはUoE HPCx 社によって管理されています。 CSE サポートサービスはNAG 社によって提供されており、高度なスーパーコンピュータの効率的な活用のために、ユーザは確実に適切なHPC専門家にコンタクトできます。CSEサポートサービスの重要な特徴は分散型CSE(dCSE)プログラムです。これは簡潔なピアレビューを経てユーザからの提案に応える、特定のコードのパフォーマンスとスケーラビリティに対処するプロジェクトです。dCSE プログラムは、伝統的なHPCユーザアプリケーションサポートとNAG によるトレーニングで補われる、約 50 の集中的プロジェクトから成り立っています。

これまでに完了した dCSE プロジェクトは、CSEの尽力により可能なコスト削減と新しい科学の優れた適用例をもたらしました。ここで報告されているCASTEP/ONESTEPプロジェクトは成功を収めたパフォーマンス改善であり、新たなサクセスストーリーとなっています。

プロジェクトの背景

CASTEP と ONETEP は第一原理の電子的材料特性を計算するための密度関数理論(DFT)を使用するコードです。これらはHECToRで最も使用されるアプリケーションの一つです。これらのアプリケーションの多くの時間が構造最適化に費やされました。それは原子配置に関する系のエントロピー最小化です。 元々この最適化は、計算量が研究対象の系の原子数をNとした場合のO(N2)に比例して増加するBroyden-Fletcher-Goldfarb Shanno (BFGS)非線形最適化アルゴリズムを用いて行われました。
このdCSEプロジェクトの目標は、limited-memory版BFGSアルゴリズム(L-BFGS)に切り替えることで両方のコードのスケーラビリティを改善することでした。 ヨーク大学のMatt Probert はプロジェクトの主任研究員でした。ヨーク大学の Jolyon Aarons はNAG CSE チームと密接に協力して12人月のプロジェクトを実行しました。 CASTEP, ONETEP そして他のDFT コードを用いてHECToR上で1年間につき約 200,000 kAUs (千アロケーションユニット) (注)が使用されました。

プロジェクトの結果

元のBFGSアルゴリズムはヘッシアン行列の明示的構成を含んでいました。それは必要なメモリが系のサイズに応じ二次的に増す演算です。一方、L-BFGSは行列を計算、格納することなく更新履歴からヘッシアンを構築します。これにより必要なメモリの増加が線形的になります (図を参照)。L-BFGS はCASTEPに問題なく実装されました(そして構造最適化コードがONETEPと共有していたため、改善されたアルゴリズムがそのアプリケーションにも実装されました)。また、BFGSを用いた場合は 構造最適化コードに関連するメモリがすべてのMPIイメージに複製されていました。L-BFGSへ切り替えることにより、これはもはや異なり、残りのコードが使用するためのハードウェアノードのメモリを解放します。プロジェクトの間、機会あるごとに既存のコードを最適化しました。(例えば、Fortran 90 固有の行列関数をBLASの同等関数と置き換えるということが行われ、これによりパフォーマンスが若干増加しました。)

所要時間と使用されるメモリの両方に関するパフォーマンス改善が大規模システムで実証されました。


(注)アロケーションユニット(allocation unit, AU)はHECToRにおけるノード課金単位です。大まかに言えばLinpackベンチマーク(Rmax)を基にした1時間当たり1Tflopsの実行量がkAUに相当します。例えば60Tflopsのプロセッサ群は60kAU/時間に相当します。

詳細なテクニカルレポートは以下で参照いただけます。
http://www.hector.ac.uk/cse/distributedcse/reports/

さらに詳しくお知りになりたい場合は、日本NAG株式会社 コンサルティンググループご相談窓口 http://www.nag-j.co.jp/nagconsul/toiawase.htm (あるいはメール:consul@nag-j.co.jp)までお問い合わせください。

Results matter. Trust NAG.

Privacy Policy | Trademarks