Kawamura1

[mitsuaki1987]

開発者、ユーザー各位

スパコン報告会でのサプライズのためにいくつかの新機能を作りました。ただし、変更点が多岐にわたるのでこれをそのままdevelopにマージしても良いかどうかの是非を問いたいと思います。

1. mltplyの複数ベクトル同時演算化

これはビット演算部分が共通であるという事を利用して演算の高速化を図ったものです。 正方格子ハバードモデル(最近接のみ)でLOBPCGで200個の固有値を求めると、サイズや並列数にもよりますが約9倍～12倍高速化されます。よりボンドの多い系や、ビット演算の使えないS>1/2のスピン系ではより顕著になると期待されます。

プログラム内部では、SIMDを効率よく使うために固有値のインデックスが一番内側になっていますv0[idim_max][k_exct]のような具合です。 ユーザーインターフェースの変更はありません。メモリ増加はLOBPCGでは約7/6≒1.166...倍です。

2. 動的相関関数(スペクトル)計算における非対角要素の計算とフーリエ変換

これはsBiCGの特徴を生かして右側の演算子一つ(正確には複数の演算子の係数付き足し算も可)に対して左側の演算子を複数使うというものです。 ブリルアン領域全体のk点で相関関数を計算する場合、サイト数倍の高速化(24サイトならば24倍)が見込まれます。 ベクトルを1本追加で保持しており、これもメモリ増加は約7/6≒1.166...倍です。 スタンダードモードでは新たにキーワードを追加し、0番目のサイトの演算子を右側、すべてのサイトの演算子を左側においてスピン―スピン動的相関などを計算できるようにしました。今まで通りq点を一点ずつ計算するキーワードも残しており、後方互換性があります。 エキスパートモードの方は、右側演算子と左側演算子の組を両方指定するようになっており。これまで通りの計算をするときには同じ演算子(若しくは演算子の線形結合)を2回書く必要があり、こちらは後方互換性はありません。ただし以前の形式で書かれた部分をコピーして2個にするだけなのですぐに移行できます。 また、固有値の計算をした後、波動関数のファイル入出力を行わず即座にスペクトル計算を開始するキーワードCalcSpec="Scratch" (CalcModではCalcSpec 6)を追加しました。波動関数が大きすぎて書き出せない時やファイルシステムが相対的にあまり速くない場合に便利です。

これらのスペクトル計算機能のサンプルは https://github.com/issp-center-dev/HPhi/tree/kawamura1/samples/Spectrum/Scratch にあります。 ぜひお試しして、マージへの議論にご参加ください。 マニュアルは日本語の方をまず更新しました。エキスパートモードについての記述はまだです。

どうぞよろしくお願いします。

河村光晶(物性研)

[mitsuaki1987]

追記 実空間表示の動的相関関数をフーリエ変換するツールの名前はdynamicalr2kで、これのマニュアルも追記しました。

[k-yoshimi]

@mitsuaki1987 機能追加ありがとうございます。いいと思います。 ただ、テストを見るとLanczosがないようですが、これは何故ですか？

[mitsuaki1987]

気づかれましたか。 Lanczosのほうは固有値計算、スペクトル計算ともにこれらの機能の恩恵を受けないので、サボりました。 Lanczosを使おうとすると、

LOBPCG is used alternative to Lanczos.

と出て、自動的にLOBPCGに切り替わります。

[k-yoshimi]

@mitsuaki1987 Lanczosは残しておいた方がいい気がするのですが、そこは他の方々の意見も聞いてみましょう。 ちなみにLanczosをそのまま使用しておくようにするのも、そこまで難しくない気がしますが、何か技術的に難しい点があったのでしょうか？

[mitsuaki1987]

いえ、単に報告会が迫っていたので実装とテストの手間を下げたためです。 Lanczosも残しておいたほうが良い部分も少しあって、たとえばスペクトル計算の振動数の上下限を見積もったりTPQの幅を見積もるために最大・最小固有値を素早く出したいという需要はあると思います。 LanczosEigenVectorと逆べき乗法は使われないと思います。

[tmisawa]

@mitsuaki1987 Lanczosを削る積極的な動機はありますか？ ないのであれば、多少労力をさいてでも残しておいたほうが いいと思います。

残しておいたほうがいいと思う理由は以下のとおりです。

• いきなり後方互換性をなくすべきでない
• LOBCG法やshifted-Krylovの優位性を示すときに 　比較対象となるLanczosがないとできない
• メモリがギリギリのときにはLanczos法を用いざるを得ないときがある
• 他の対角化のコードはすべてLanczos法なのでそれとの直接比較ができなくなる

私が一番、重要だと思うのは二番目ですね。 今までの経験からLOBCGやshifted-Krylovの 優位性を私達は知っていますが、そこまで周知されては いないと思います。優位性を示すのに一番有効なのは 既存の手法との比較ですが、それがHΦの中で閉じた形で、 できなくなるのは、これらの手法の今後の普及を 考えたときに致命的だと思います。

[k-yoshimi]

@mitsuaki1987 なるほど。特に困難がないようであれば、選択できるように残しておくというのも一手ですね。 一応、他の開発者の方々の意見も聞いて判断しましょう。 ちなみに私の意見としては、河村さんのおっしゃってる実用的なメリットに加え、伝統的な手法としてこれまで使われてきたということもあるので、教育的な側面からも残しておいた方が良いような気がしています。

@yyamaji @wistaria @tmisawa お手数ですが本件コメントいただけると助かります。よろしくお願いします。

[mitsuaki1987]

最大の理由はやはり労力ですね。

[yyamaji]

@mitsuaki1987 乗り遅れましたが、Lanczosを削るというのは、どこまでの範囲ですか？ 対角化だけですか？ ちなみに、あまり指摘されませんが、LanczosとLOBCG及びshifted Krylovは 得られる情報に違いがあるので、三澤さんの論点以外の観点からも削らない 方が良いと思います。

[mitsuaki1987]

三重対角行列を出すところまでは残すのが良いのではないでしょうか。

[k-yoshimi]

@mitsuaki1987 ちなみに、今回の機能導入にあたり、Lanczos意外にも削った機能はありますか？

[mitsuaki1987]

CMAです。

[k-yoshimi]

@mitsuaki1987 了解です(なかなか豪快ですね)。CMAもLanczosと同様に対応するのに手間がかかるため、削除したという理解でしょうか？

[k-yoshimi]

@tmisawa @yyamaji
せっかくの良い機能を河村さんが労力をかけて追加していただいたので、LanczosやCMAを残す場合には我々で対応するのがいいかもしれませんね。

[yyamaji]

@mitsuaki1987 CMAはPDのprojectで使っていて10倍早いんで 勘弁してください。 @k-yoshimi @tmisawa 削らないで追加する実装は可能なはずです。 河村さんが時間節約しただけでしょう。

[yyamaji]

@mitsuaki1987 m本求める場合、一般化固有値問題を 作る際の内積計算がnaiveにはm^2ですよね？ CMAだとmultiplyよりそっちが大きくなるんですが、 河村さんの場合は何故見えてないのか教えてください。

[mitsuaki1987]

モデルとかサイズとか並列数とかでケースバイケースなのでしょう。 山地さんのやつとコレで、それぞれハバードやスピン系、近藤系、保存/非保存等色々試してみたらわかるのではないですか。

[yyamaji]

@mitsuaki1987 scalingなので詳細によらず、サイズが小さくない限りは m^2が聞くと思いますよ。

[mitsuaki1987]

mltplyの方の時間がモデル等で変わるのではないでしょうか。

[yyamaji]

@mitsuaki1987 繰り返しですが、

1. 厳密なscalingなので、mが十分大きければ必ず逆転する。
2. 論文レベルの応用ではmが数十で逆転する例がある。 サイズはメモリーで規定され計算量もほぼメモリサイズにスケール するので、詳細によらず、できる範囲の計算を頑張れば逆転がおこる。 ということです。

[mitsuaki1987]

承知しました。ではそのうち調べておきます。

[yyamaji]

@mitsuaki1987 もしm^2でない方法があれば、もちろんうれしいので、私の書いていることが間違っている方がありがたいです。

[tmisawa]

@k-yoshimi @yyamaji @mitsuaki1987 とりあえず、まとめとしては、 削った部分は河村さん以外で対応するということで いいですか？

もとのコードを書いた経緯もあるので、 Lanczosは私 or 吉見さんが対応しておきます。

@yyamaji CMAの対応は山地さんにお願いしていいですか？

[k-yoshimi]

@tmisawa はい、それでいいと思います。 それぞれテストコードを書いて、それが通るようになった段階でmergeしましょう。

[yyamaji]

@tmisawa@k-yoshimi お二人はコードの中身検討しましたか？ CMAはinput周り以外は自明な書き換えになります。

[yyamaji]

あるいはinputから機能ごとのbranchingのところが一番作業量が多そうなのですが... 個別にやるとエライことに

[mitsuaki1987]

cmaだけ前のルーチン（1本ずつ演算）を使うのであれば簡単に対応できるので私がやっておきましょう。

[yyamaji]

@k-yoshimi そうしていただけると多数まとめての演算への切り替えが簡単で助かります。 ところで、河村さんのテストでの計算時間の変化に興味が あります。加速ではない方のデータについて、 お手数ですが、log-logでplotしていただけますでしょうか。

[mitsuaki1987]

上記の方法でCMAの実装をしました。

[mitsuaki1987]

LOBPCGに関しては山地さんの言うようにmltplyの複ベクトル化よりも部分空間ハミルトニアン計算でzgemmを使ったのが効いているのかもしれませんね。 興味がおありでしたら調べてみてください。

[k-yoshimi]

@tmisawa @mitsuaki1987 @yyamaji 諸々機能を復活させるのに、少し時間がかかると思うので一旦PRは取り下げ、改めて機能が復活させた状態でPRを出すのがよいと思うのですが、それでよいですか？

[k-yoshimi]

@mitsuaki1987 @tmisawa @yyamaji 特に反対意見がないようですので、一旦PRをcloseします。諸機能が復活したら、またPRを出しましょう。

[hphi-user]

吉見さん，河村さん

日頃よりお世話になっています． 兵庫県立大学の鈴木です．

HPhiに関して質問があるのですがここで良いのでしょうか？

鈴木

Takafumi Suzuki Graduate School of Engineering, University of Hyogo takafumi-s@eng.u-hyogo.ac.jp

2019/04/12 12:36、Yoshimi notifications@github.comのメール:

@tmisawa https://github.com/tmisawa @mitsuaki1987 https://github.com/mitsuaki1987 @yyamaji https://github.com/yyamaji 諸々機能を復活させるのに、少し時間がかかると思うので一旦PRは取り下げ、改めて機能が復活させた状態でPRを出すのがよいと思うのですが、それでよいですか？

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/issp-center-dev/HPhi/pull/66#issuecomment-482424869, or mute the thread https://github.com/notifications/unsubscribe-auth/AdXUN0MpwsKX3CpmhvT934E7YwB9NU5eks5vf_9VgaJpZM4cpGHt.

[k-yoshimi]

鈴木さん

吉見です。返信遅れてすみません。 issueを新規に立てていただくとアナウンスされますので、 そちらで質問していただく形式でお願いできればと思います。 研究に関連してpublicにしたくない場合には、メールでもOKです。 今後ともよろしくお願いします。

吉見