分子軌道計算専用計算機のためのフォック行列並列計算アルゴリズムの開発

梅田 宏明, 稲富 雄一, 本田 宏明, 長嶋 雲兵


Return

1 はじめに

非経験的分子軌道計算は分子の物性等の解析に欠かせない計算手法として広く使われてきている。一方で機能性材料の設計や医薬品開発などのように巨大な系を対象とする分子軌道計算には非常に大きな計算機資源が必要となり、大学の研究室などで容易に利用できる安価なPCクラスタシステムではこのような大規模計算は大変困難であった。
研究室内外の既存の計算機を有効に活用することのできるグリッド技術は、この問題に対する一つの解決策である。グリッド技術を用いることにより、ネットワーク上にある多くの計算機資源を効果的に利用した、大規模科学技術計算が可能になると考えられる。
計算用途を限定した専用計算機の利用も、大規模計算を実現するための解決策の一つである。分子軌道計算法の一つであるHF (Hartree-Fock)法[1]ではフォック行列の生成に全計算時間の9割以上の時間を費やすことが知られている[2]。フォック行列の生成には分子サイズの4乗程度の計算が必要であるため、対象とする系が巨大になればなるほどフォック行列生成の高速化が重要であり、この部分を専用計算機で高速に実行することができれば全体の計算時間を大幅に短縮することが可能になる。
EHPC (Embedded High Performance Computing) プロジェクト[3]では、フォック行列生成において重要となる二電子積分計算専用の専用ロジックLSIを開発し、プラットフォームシステム[4]上に多数搭載することによりフォック行列を高速に生成するための分子軌道計算専用計算機システムを構築した。このプラットフォームシステムでは、一般のPCに利用されるCPUに比べ低消費電力の専用LSIを高並列で動作させることにより性能を出すアーキテクチャを採用しているため、アプリケーションプログラムの並列化効率を上げることが本質的な意味を持っている。
一般のユーザがこのシステムを手軽に利用するためには、広く利用されている分子軌道計算アプリケーションをプラットフォームシステム上で動かす必要がある。しかしながら、プラットフォームシステムではプロセッサ(PU)間の通信に強い制約が存在するため、既存の並列フォック行列生成アルゴリズムを用いた並列化では十分な効率が期待できない。
そこで本研究では、プラットフォームシステム上の多数のプロセッサを効率良く利用し、高並列計算を可能とするフォック行列生成アルゴリズムを開発するとともに、それを代表的な非経験的分子軌道計算パッケージの一つであるGAMESS[5]に組み込んだ。また専用LSIの代りに汎用のプロセッサを利用したプラットフォーム評価システム上でベンチマーク計算を行ない、並列性能を評価した。

2 プラットフォーム評価システム

2. 1 ハードウェア

本研究で利用したプラットフォーム評価システム(Figure 1)は専用LSIの代用として汎用CPUを搭載した、3ユニットからなるシステムである。各ユニットはCompact PCIバックプレーンを持ち、PC互換Compact PCIボード一枚と汎用CPUを搭載したEHPCボード(Figure 1左のボード)7枚が接続されている[4]。


Figure 1. EHPC SH4 processor board (left) and platform system (2-unit in picture).

Figure 2にプラットフォームシステムの概念図を示す。各ユニットを統轄するホストPC(PC互換ボード上のPC, Figure 2の緑色で示したPU [PC-#])にはPentium3ボード (Pentium3 400MHz CPU, 256MB メモリ, 20GB HDD)とPentium2ボード(Pentium2 266MHz, 64MBメモリ, 20GB HDD)の2種類があり、今回利用したシステムはPentium3ボードを搭載したユニット2台とPentium2ボードのユニット1台の3ユニット構成となっている。これらのホストPCにはLinux OS (kernel 2.4)が搭載されており、通常のLinuxマシンとして利用できる。またホストPCでは100Base-TXのNICが利用でき、LANを通してTCP/IP等による通信が可能である。


Figure 2. EHPC platform architecture. T-COM library is adopted for intra-unit communication, and DDI library in the GAMESS package for inter-unit communication.

各ユニットのCompact PCIスロットに挿入されたEHPCボードには4個の汎用 CPU(日立製 SH4, 200MHz)が搭載されており、そのうちの一つは制御用PU (Figure 2の黄色で示されたPU [S-#]) 、残りの3個は専用LSIに代わって二電子積分を実行する計算用PU (Figure 2の赤色で示されたPU [E-#]) である。これらのSH4 CPUはμITRON OSにより駆動され、それぞれ64MBのメモリを利用可能となっている。SH4プロセッサの倍精度浮動小数点演算はPentium等に比べて非常に遅く、乗算(6サイクル)でせいぜい33MHz程度の演算性能しかない。またボードにはハードディスク等の記憶デバイスは搭載されていない。システム全体としては63個(3ユニット×7ボード×3PU)もの計算用PUが存在することになり、プラットフォームシステム上での並列実行性能を評価するには十分な数のプロセッサであると言える。

2. 2 プロセッサ間通信

ホストPC―制御用SH4―計算用SH4の通信はEHPCプロジェクトで開発されたプラットフォームシステム用通信ライブラリTree-Comm (T-COM) [4]を用いて行なわれる。T-COMでは同期的なsend/recvやwait_anyといったMPI類似の機能が実装されているが、階層構造を持つプラットフォームシステムのアーキテクチャ(Figure 2)を反映して、木構造を前提としたAPIになっている(Figure 3)。T-COM APIにおける階層構造のもとでは、計算用SH4同士の直接通信はできず、そのボード上の制御用SH4に対してのみ通信が可能である。制御用SH4もそれら同士の通信はできず、その筐体のPC又は自らの管理する計算用SH4とのみ通信が可能となっている。


Figure 3. Tree-COM (T-COM) layered architecture. PUs can communicate only with their parent and child PU in a tree.

Figure 3に示されるような階層構造を持つシステムではPCと末端の計算用SH4, または計算用SH4同士のデータのやりとりに中間の制御用SH4を経由する必要があるため、小さなデータの転送でも非常に大きなコストが必要になる。特にT-COM APIは同期通信を行なうため、中間階層を経由するような通信を効果的に制御するのは容易ではない。このため計算を局所化し、広範囲に影響を与える通信を可能な限り減らすことが求められる。
ユニット内の通信については階層構造による強い制約があるのに対し、ユニット間はTCP/IPネットワークにより接続されているためMPI[6]等を用いた自由な通信が可能である。実際Figure 2で示されるプラットフォームシステムのホストPCは広く利用されているLinuxシステムであり、専用プロセッサを利用しない単なるPCクラスタとしての実行形態であれば、公式に配布されているGAMESS[5]を修正することなく並列計算が可能である。
本研究のターゲットであるGAMESS[5]ではプロセッサ間の通信APIにDDI (distributed data interface)ライブラリ[7]を採用している。DDIライブラリはsend/recvやbroadcast/global sumといった同期通信関数に加えて、get/putなどの非同期通信による分散メモリ機構やこれを利用したグローバルカウンタの機構が実装されており、比較的簡単に動的負荷分散による効率の良い並列計算を実現することが可能である。グローバルカウンタ用の関数としてはカウンタを初期化するreset()関数とカウンタの値を取り出しインクリメントするnextval()関数が用意されており(Figure 4)、これを用いて動的負荷分散は次のように実現される。単一のタスクIDのみで指定される多数の独立したタスクを考える。この時グローバルカウンタからタスクIDが得られるようプログラムを設計すると、nextval()関数によりプロセッサは遅延なく次に実行するべきタスクのタスクIDを取得することができる。これによって、プロセッサそれぞれの計算量に応じてタスクIDを取得する回数が動的に変化することとなり、比較的負荷が均一に分散した効率の良い並列計算が可能となる。


Figure 4. Global counter in DDI library for dynamic load balance. Each PC can access global counter allocated on PC-0 asynchronously through nextval() function.

3 フォック行列生成のアルゴリズム

最終的なプラットフォームに搭載される専用LSIは、プログラミングが可能な汎用プロセッサコアと二電子積分専用演算コアを持つマルチコアPUであるため[8]、柔軟なフォック行列生成のアルゴリズムの実装が可能になっている。そこでプラットフォームシステム上においても効率良く実行可能な並列計算アルゴリズムの開発および汎用PUを用いたプラットフォーム評価システム上での実装を行なった。以下ではフォック行列の計算式および高速化手法である二電子積分のスクリーニングについて解説した後、本研究で開発した行列生成のアルゴリズムについて説明する。

3. 1 フォック行列

非経験的分子軌道計算の一つであるHF法においてフォック行列Fは以下の式で与えられる[1]。

ここでi, j, k, lは縮約シェル(contracted shell, CS)のインデックスであり、タンパクなどの大規模分子ではその数Nが数万程度になることもある。D, Hcoreはそれぞれ密度行列および核-電子ハミルトニアン行列であり、 (ij|kl) は4中心の二電子積分である。式1に見られるようにN4個の二電子積分を計算する必要があるため、大規模HF計算においてはフォック行列の生成がほとんどの計算時間を占めることとなる。特に二電子積分の計算はコストが大きい計算であり、これを高速に実行するための専用LSIを作成する意味は大きい。

3. 2 スクリーニングによる高速化

フォック行列を高速に計算するために一般的に使われる手法として、二電子積分のスクリーニングがある[1]。これは計算コストの大きい二電子積分の計算をできるだけ減らすために、事前に概算値を算出して不要と判断できる二電子積分の計算を省略する方法であり、本研究では代表的な3つの手法を採用した。
(a) 重なり積分によるスクリーニング
4中心の積分のうちの二つのガウス型関数の重なりがほとんどない場合、その関数ペアを含む二電子積分は非常に小さい値しか持たなくなるため、フォック行列への影響も無視できる程小さくなる。このような場合にはその二電子積分の計算を省略することができ、フォック行列の生成を高速化することが可能になる。例えばN=1000程度の場合、このスクリーニングにより生き残るCSペアの数は元々のCSペア数の半分程度になるため[2, 9]、CSペアの二重ループで構成される全体の計算量としては1/4に削減できることになる。分子サイズが大きくなればスクリーニングの効果は一層大きくなり、さらに効率の良い計算が可能である。
(b) シュワルツの不等式によるスクリーニング
二電子積分 (ij|kl)は、シュワルツの不等式

によって上限を決定できるため、これによるスクリーニングも可能である。特にCSペアi jに対する の値を事前に一度計算して保存しておけば、HF法のSCF (self-consistent field, 自己無撞着場)計算で発生する繰り返しごとの式2の評価を高速に実行できる。
(c) 密度行列によるスクリーニング
フォック行列は二電子積分と密度行列の積により求められるため(式1)、式2で求められた二電子積分の上限とそれに対応する密度行列との積が十分小さい値であれば、やはりその二電子積分の計算を省略することができる。このスクリーニング手法は差密度行列によるフォック行列生成アルゴリズムを利用した場合には特に大きな効果を発揮する。SCFの収束につれ差密度が小さくなっていくため閾値以下の要素が急速に増加し、スクリーニングの効果が大きくなるからである。

3. 3 生成アルゴリズム

Figure 5にフォック行列生成の擬似コードを示す。ここで式1の核-電子ハミルトニアン行列HcoreはSCFの繰り返しに関わらず一定であり、また計算量もO(N2)と小さいため、事前に計算した行列をホストPCで加算するものとする。スクリーニングの特徴からCSペアi, j を一つのCSペアインデックスIJで表わすと都合が良い。CSペアインデックスはCS ijの重なりの条件を使ったスクリーニング(a)により生き残ったものだけに対し用意すればよいので、これを構造体の配列cs_idx[]に格納する。またcs_idx[]にはシュワルツの不等式によるスクリーニング(b)に必要な も格納しておき、check_schwarz()関数においてスクリーニングを実行する。make_fock()は与えられたCSペア対IJKLに対するフォック行列を計算し配列F[]に加えていく関数であり、密度行列によるスクリーニングもこの関数内で実装する。


Figure 5. Pseudocode of Fock matrix construction. NIJ is the number of screened contracted-shell-pair (CS-pair) index, and an array of structure cs_idx[IJ] stores pre-screened CS-pair indices and value corresponding to screened index IJ. A Boolean function check_schwarz() examines Schwarz' inequality screening, and a function make_fock() constructs partial Fock matrix for CS-pair ij and kl onto an array F[]. D[] is an array of density matrix.

ホストPCから計算用PUへの通信量を減らすため、密度行列と結果のフォック行列はそれぞれSCF繰り返し部分の最初 (Figure 5, line 1) と最後 (Figure 5, line 8) でまとめて転送する。これはプラットフォームシステムの最終的なターゲットである専用LSIが比較的大きなメモリ領域(256M-512Mバイト)を確保できる設計であり、EHPCプロジェクトでターゲットにしている数千基底程度の分子であれば密度行列及びフォック行列が十分保存できることを前提としている。それに対し本研究で利用した評価システムでは各計算用PUに64MB程度のメモリしか搭載していないこと、ホストPCのメモリも64MBと少ないこと、計算用PUであるSH4プロセッサの浮動小数点演算速度が遅いことなどの問題があり、数百基底の比較的小さな分子を扱うのが現実的である。
数万基底を超えるような超巨大分子を扱う場合には、個々のプロセッサにメモリをあまり必要としない分散メモリ用のアルゴリズム[9, 10]が必須となる。通信のオーバーヘッドが大きい本プラットフォームシステムのような階層構造を持つシステムには不向きであると思われるが、プログラマブルな専用LSIを利用しているのでそのようなアルゴリズムの採用も十分に可能である。

4 並列化と負荷分散

Figure 5の擬似コードを並列化するために、本研究では二種類のタスク分割(TASK_IJKL, TASK_IJ)に対する静的負荷分散(SLB-IJ, SLB-IJKL)、およびタスク分割TASK_IJに対する動的負荷分散(DLB)の3つのコードをプラットフォーム評価システム上のGAMESSに実装した。

4. 1 タスクの分割

並列計算のためにはFigure 5のコードを多数のタスクに分割する必要がある。本研究では二種類のタスク分割(TASK_IJKL, TASK_IJ)を採用した。
CSペア対IJKLをタスクIDとしたタスク分割(TASK_IJKL)では比較的粒度の小さいタスクが非常に多く発生する。この時シュワルツの不等式によるスクリーニングで生き残ったIJKLに対するフォック行列の計算(make_fock())を一つのタスクとして考えると、タスクごとの負荷のばらつきを減らすことができる。一方でタスクの粒度が小さ過ぎるため、タスク分割処理自体のオーバーヘッドが見えてしまう可能性がある。
もう一つのタスク分割(TASK_IJ)はCSペアIJをタスクIDとしたタスク分割である。タスクの数は数万程度にはなるため並列化するのに十分なタスク数と考えられる。一方、TASK_IJKLに比べ平均的なタスクの粒度は大きいものの、計算量がklループのループ長ijに依存してしまうためタスクの粒度が不均一になってしまう。

4. 2 負荷分散

並列性能を向上させるためには、これらのタスクを各プロセッサに均一に分散させる必要がある。本研究ではタスクIDを均一に分配する形の静的負荷分散とグローバルカウンタを利用した動的負荷分散をそれぞれ採用した。
静的負荷分散(static load balance, SLB)は並列化において通信回数を最も削減するタスクの分配方法である。各PUで計算するタスクを事前に割り振るため、最初と最後の密度行列およびフォック行列の転送以外に通信の必要はない。一方で静的負荷分散では、計算量に合わせてタスクを均等に分配するために多くの労力が必要となる。シュワルツの不等式によるスクリーニングの影響を事前に考慮するのは非常に困難であるため、本研究ではタスクIDを均等に分配する単純な静的負荷分散を採用した。このような単純な負荷分散では、タスク粒度のばらつきが大きいタスク分割TASK_IJで計算量の不均一が発生する可能性が高いと思われる。
動的負荷分散(dynamic load balance)はタスクの分配を動的に行なう方法である。各PUの負荷状況により動的にタスクを分配するため、PU間の負荷の偏りを防ぐことができ効果的に並列計算を実行することができる。一方でタスクID転送のため通信の頻度が増加し、環境によっては通信のオーバーヘッドが並列性能を阻害する可能性がある。また動的負荷分散のためにはタスクの実行状況を管理する必要があり、T-COM APIのように木構造を持っている場合には実装が困難であった。
階層構造を持つプラットフォームシステムで動的負荷分散を実現するために、多段動的負荷分散機構を実装した(Figure 6)。ホストPC間の動的負荷分散はGAMESSのDDIライブラリが持つnextval()関数によるグローバルカウンタ機構により実現している。ホストPC及び制御用SH4には、より下位のPUにタスクを分配するためのタスクマネージャの機構を実装し、各ツリー内に局在した動的負荷分散を実現した。各タスクマネージャでのタスクの分配は、下位のPUからの要求を受けてタスクを分配するデマンド駆動方式を採用し、負荷の分散を計っている。階層ごとにタスクの粒度(=分配するタスクIDの数)を変えることで上位層へのタスク要求の頻度を抑え、動的負荷分散による通信オーバーヘッドの影響を最小にした。


Figure 6. Multi-level dynamic load balance scheme. PC-0 has global counter for task ID, and other host PCs and controller SH4s have task manager with local task counter. TaskIDs IJn are allocated to processors in a demand-driven manner.

動的負荷分散を行なうための通信負荷を考えると、タスクの分割TASK_IJKLでは計算時間が短かすぎるため適当ではない。そこでタスク分割TASK_IJに対してのみ動的負荷分散機構を実装した。TASK_IJでは、先に述べたようにIJが大きい程KLループのループ長が長くなる傾向がある。そこで計算量の大きい(=IJの大きい)タスクから先に分配するようタスクIDを設定した。今回のようなデマンド駆動方式の動的負荷分散の場合には、計算量の大きいタスクを分配することで生まれる負荷の不均衡を計算量の小さいタスクで平均化する効果が期待できる。
動的負荷分散を実行する場合、CSペアの段階で可能な限りスクリーニングすることが重要である。計算用PUで全てのスクリーニングを実行した場合、割り当てられたタスクの半分以上についての計算がスクリーニングによって省略されることになってしまい、タスク要求にかかる通信負荷が非常に高くなってしまうからである。CSペアに対して可能なスクリーニングをIJループの段階で行なうFigure 5のアルゴリズムは、この点において動的負荷分散に適したアルゴリズムである。

5 ベンチマーク計算

対象とした計算はC末端をOHキャップしたグリシンの15量体(Gly)15 (Figure 7)のHF/STO-3G計算である。この分子は108個の原子からなり、STO-3Gレベルの計算ではガウス型基底の数N=352となっている。スクリーニングの条件などについてはGAMESSのデフォルトの値を用いた。スクリーニング後のCSペアの数はNIJ=14698であり、CSペアの数26565個と比較すると半分程度に減少する。


Figure 7. (Glycine)15.

プラットフォームシステムのホストPC上で動くGAMESSを含むプログラムは全てGNU g77を利用してコンパイルした。計算時間の大部分を占めるフォック行列の生成部分は計算ボード上で実行されるため、これによる影響はごく小さいものと思われる。ボード上のSH4用プログラムのコンパイルには日立製コンパイラを利用している。SH4プロセッサで動作する二電子積分演算ルーチンは、専用LSIのロジック作成用に用意された小原積分ルーチン[11]であり、汎用プロセッサにとって最適なプログラムとはなっていない。
比較のため、2.8GHzのPentium4 PC上でインテルコンパイラによりコンパイルされた公式配付版GAMESSを実行するベンチマークも行なった。なおこの時の二電子積分の計算には精度を上げるためにGAMESSのHONDOオプションを利用している。これは本システムのターゲットとなる巨大分子では精度の高い二電子積分が必要になると考えられるからである。
Table 1に3ユニット(=63PU)のプラットフォーム評価システムおよびPentium4 PCを利用したベンチマーク計算の結果を示す。DLBはTASK_IJに対する動的負荷分散、SLB-IJ, SLB-IJKLはそれぞれTASK_IJおよびTASK_IJKLに対する静的負荷分散の結果である。WfockはFock行列の生成に対する経過時間であり、Wtotalは計算全体に対するものである。Pentium4 PCの結果から13回のSCFサイクルの合計でフォック行列の生成に2500秒程度かかっており、計算全体の99%以上の時間をフォック行列の生成に費やしていることがわかる。Speedupはそれぞれの負荷分散アルゴリズムで1つのボード(またはチップ)のみを利用した場合と比較した時の性能向上である。またRatioは並列化効率であり、リニアな性能向上であれば1となる。

Table 1. Benchmark results on the EHPC platform system with 63 SH4 CPUs. Wfock is the total elapsed time of Fock matrix constructions for 13 SCF cycles, and Wtotal is the total elapsed time of benchmark calculation.
Platform system (SH4, 200MHz)PC(Pentium4, 2.8GHz)
DLBSLB-IJSLB-IJKL
Wfock /sec4486.75595.34837.52517.5
Speedups /board20.72416.85419.244
Speedups /chip62.56250.14357.909
Ratio0.9930.7960.919
Wtotal /sec4659.55775.44995.62526.4
Speedups /board19.98716.35318.664
Speedups /chip60.15248.53056.105
Ratio0.9550.7700.891

3つの負荷分散の手法を比較すると、動的負荷分散の手法が際だって優れていることがわかる。速度の向上はボード数・PU数の増加に対してほぼ線形(並列化効率99.3%)であり、今後さらにボード数を増加させた場合でも高い性能を与えることが十分期待できる。計算全体でみた場合についても、速度が遅いホストPCが含まれているにも関わらず高い並列性能を示している。
並列化効率をPUの数に対してプロットしたのがFigure 8である。動的負荷分散の並列化効率が非常に高いことがよりはっきりと示されている。 SLB-IJではシュワルツの不等式等によるスクリーニングの影響でタスクの粒度にばらつきが大きく、そのためボードの数によって並列化効率に大きな変動が表われる。一方でSLB-IJKLではそのような変動は見られていない。これはシュワルツの不等式によるスクリーニング後のIJKLをプロセッサに分配しているため、計算すべき二電子積分が均等に分配されたからである。しかしながら二電子積分計算自体はその積分タイプにより計算量が異なるため、十分な負荷分散は得られていない。Figure 8において54および63プロセッサ時に並列性能が悪くなる傾向が負荷分散の方法に関わらず見られているが、これは遅いホストPC(Pentium2, 266MHz, 64MBメモリ)が利用されたことによる影響と思われる。


Figure 8. Parallelization Efficiency of three different load-balance schemes on the EHPC platform system with 63 SH4 CPUs. Wfock is the total elapsed time of Fock matrix constructions for 13 SCF cycles, and Wtotal is the total elapsed time of the benchmark calculation.

今回並列性能の評価に用いたSH4プロセッサの倍精度浮動小数点演算速度は33MHz程度であり、また二電子積分計算アルゴリズムの違いもあって、2.8GHzのPentium4に比べ1/100程度の速度しかない。これを反映しプラットフォーム評価システム(63PUシステム)全体で、Pentium4 PCの半分程度の性能に留まる結果となってしまっている。200MHzで動作する予定の専用LSIでは、専用ロジックを用いることで最終的にSH4プロセッサの十倍以上の性能が予想されており、1ユニットでPentium4 PCの数倍の速度が期待できる。計算PUの性能が向上すると、タスクひとつの計算時間が減少し、相対的に通信等が並列性能を阻害する可能性も考えられる。しかしながら本研究で開発した多段階の動的負荷分散機構ではその各段階でタスクの粒度を調整することが可能であり、本ベンチマークと同等の並列性能が容易に実現できる。通信環境の変化についても同様の議論が可能であり、多数ユニットを用いたスケーラブルな高速高並列分子軌道計算が実現可能である。

6 おわりに

大規模分子軌道計算においてフォック行列の生成は計算量の多い計算であり、この部分を専用計算機により高速化する意味は非常に大きい。EHPCプロジェクトにより開発された二電子積分計算専用LSIが組み込まれるプラットフォームシステムは階層的構造を持つアーキテクチャであり、これを考慮した並列化技法の開発が必要であった。本研究ではプラットフォームアーキテクチャの評価システム上にフォック行列生成ルーチンを実装し、並列性能を評価した。我々の開発した多段の動的負荷分散を利用することで、通信頻度を抑制しつつ負荷を均一に分散させることに成功し、63PUを利用した場合に99%以上の非常に高い並列性能を得ることができた。これは、数百以上の専用LSIを用いた高速高並列分子軌道計算が可能であることを示している。
このような階層的なネットワーク構造を持つ分散処理システムとしてグリッドRPCモデル[12]がある。本研究で開発された多段動的負荷分散はグリッドRPCモデルにも同様に適用可能であるばかりか、グリッドRPCモデルの中に専用計算機システムを組込むことも可能である。これにより利用者は専用計算機の存在を意識する必要がなくなり、専用計算機の稼働率の向上などの効果も期待できる。

本研究の一部は科学技術振興調整費 総合研究「科学技術計算専用ロジック組込み型プラットフォーム・アーキテクチャに関する研究」(代表 村上和彰 九州大学教授)によるものである。

参考文献

[ 1] T. Helgaker, P. Jorgensen, and J. Olsen, Molecular Electronic-Structure Theory, Wiley (2000).
[ 2] 長嶋雲兵, 計算化学<<空間系V>>, 岩波講座 現代工学の基礎, 岩波出版 (2002).
[ 3] Embedded High Performance Computing (EHPC) Project, http://www.ehpc.jp
村上和彰, 稲垣祐一郎, 上原正光, 大谷康昭, 小原繁, 小関史朗, 佐々木徹, 棚橋隆彦, 中馬寛, 塚田捷, 長嶋雲兵, 中野達也, 情報処理学会研究報告, 2000-HPC-82, 1 (2000).
長嶋雲兵, 佐々木徹, 大谷泰昭, 上原正光, 塚田捷, 村上和彰, J. Comput. Chem. Jpn., 4, 131 (2005).
[ 4] T. Sasaki, U. Nagashima, J. Comput. Chem. Jpn., 2, 111 (2003).
佐々木徹, 村上和彰,
J. Comput. Chem. Jpn., 4, 139 (2005).
[ 5] M. W. Schmidt, K. K. Baldridge, J. A. Boatz, S. T. Elbert, M. S. Gordon, J. H. Jensen, S. Koseki, N. Matsunaga, K. A. Nguyen, S. J. Su, T. L. Windus, M. Dupuis, and J. A. Montgomery, J. Comput. Chem., 14, 1347 (1993).
http://www.msg.ameslab.gov/GAMESS/GAMESS.html
[ 6] The Message Passing Interface (MPI), http://www-unix.mcs.anl.gov/mpi/.
[ 7] G. D. Fletcher, M. W. Schmidt, B. M. Bode, M. S. Gordon, Comput. Phys. Commun., 128, 190 (2000).
[ 8] 原田宗幸, 中村健太, 桑山庸史, 上原正光, 佐藤比佐夫, 小原繁, 本田宏明, 長嶋雲兵, 稲富雄一, 村上和彰, 情報処理学会研究報告, 2002-ARC-152, 133 (2003).
中村健太, 本田宏明, 梅田宏明, 小松晴信, 村上和彰,
J. Comput. Chem. Jpn., 4,155 (2005).
[ 9] H. Takashima, S. Yamada, S. Obara, K. Kitamura, S. Inabata, N. Miyakawa, K. Tanabe, and U. Nagashima, J. Comput. Chem., 23, 1337 (2002).
[10] I. T. Foster, J. L. Tilson, A. F. Wagner, R. L. Shepard, R. J. Harrision, R. A. Kendall, and R. J. Littlefield, J. Comput. Chem., 17, 109 (1996).
[11] S. Obara, A. Saika, J. Chem. Phys., 84, 3963 (1986).
H. Honda, T. Yamaki, S. Obara, J. Chem. Phys., 117, 1457 (2002).
小原繁, 本田宏明, IPSJ Symposium Series High Performance Computing Symposium 2003, 2003(4), 71 (2003).
本田宏明, 小原繁, IPSJ Symposium Series High Performance Computing Symposium 2003, 2003(4), 121 (2003).
[12] Ninf-G, http://ninf.apgrid.org/.


Return