s2k's eye 2nd Ed.

cygwin/g77でコンパイルした最新版GAMESSの並列化効率を、比較的短時間の計算(3分程度)を使って計測してみました。File I/O等の寄与はある程度長い計算の方が除けるかもしれませんが、そういうところはとりあえずCPU Timeを指標に。現実的な速度はWall Clock Timeを指標に。

※いずれも閉殻。2回同じ計算を実施した平均値。
※MCSCFは怪しげなエラーのため現在検討中。

CCは相変わらず伸びないっすね。。。ちなみに1 coreで30分程度かかる計算で比較しても、最大で1.4倍＠2 core。HF,DFTは優秀、MP2もまぁまぁ。
GAMESSは2並列で4プロセス発行するんで(しかもメイン以外の2プロセスもCPU使用率を食う…2並列で平均2.5 coreぐらいは使っているのでは)、その影響も結構大きそう？CCSDで2 coreのときにピークなのはその辺もあるかも。core数を増やせばいいってもんでもないのが面白いところ。ノード数が増えれば話は別ですが。

続きを読む "GAMESS 2008/04/11(R1)の並列化効率(とりあえず版)" »

投稿者: s2k 日時: 19:05 | パーマリンク | コメント (0)

GAMESSで構造最適化するとき、普通はDLCを使うのが最も高速で、たまに例外があるというのがここ最近の私の常識でした。
が、それはどうもPC GAMESSでの話で、本家GAMESSでは勝手が違うこともあるようです。

N-(n-Propyl)acetamideをRHF/STO-3Gで構造最適化する計算をしたときに、直交座標(CART)でやるかDLCでやるかを比較したときに、PC GAMESSとGAMESS(US)で大きな違いがありました。

と、PC GAMESSでは常識通りDLCによって大幅に最適化ステップ数と時間が短縮されますが、GAMESS(US)ではCartでもすでにPC GAMESSでDLCを使った場合より早く収束し、しかもDLCを使うとむしろ僅かに悪化するという結果に。
計算の内容自体は分子の構造を含めてもありふれたもので、ちょっと驚きました。
ちなみに、クロロアセトアルデヒドと塩化物イオンのSn2反応のTSを構造最適化する際も、対称性を使ったCartesian座標による計算でしたが、GAMESS(US)の収束が早いという結果でした。

こんなところでも、両プログラムが似て非なるものだなぁ…と感じました。

おまけ
PC GAMESS 7.1.0を7.1.5にアップデートするパッチが大分前から公開されてますが、このアップデートで特に計算が速くなった、という感じは今のところありません(実感できるような内容の計算を実施していないということでしょう)。ただ、両者で大きく違う点が一つだけ見えました。3/4コアを使っての計算の際、各コアの使い方が違うんです。7.1.0は4コアを広く使い、使用率が100%に達しないコアがほとんど。それに対して7.1.5は3コアを重点的に使い、2コアはいつもほぼ使用率が100%という状況。C2Qは2つのダイの張り合わせなのでダイ間の通信が遅くなりますが、その辺を少しでも回避しようという意味合いでしょうか？

投稿者: s2k 日時: 11:49 | パーマリンク | コメント (0)

まだWindows 向けバイナリのアナウンスはありませんが、自前でコンパイルして使ってみました。cygwin上でg77とgfotrran(別途導入)を使って2種類のバイナリを作ってます。TINKERのモジュールも組み込み済み。

さて、パフォーマンスですが、同じg77でコンパイルした2007/03/24(R6)に比べて若干低速化した模様。DFT Gradientの計算では10％近く計算時間が延びるケースも。gfortranでコンパイルするとかなり挽回できます。

《2,2'-Biphenyl, B3LYP1/cc-pVDZ Gradient》
○GAMESS 2008/04/11(R1)
　g77 : 353.9 sec
　gfortran : 338.2 sec
○GAMESS 2007/03/24(R1)
　g77 : 325.3 sec

ただ、なぜか理由が私にはわからないのですが、gfortranでコンパイルしたバイナリはDDIまわりに問題があるらしく、MP2のようにMEMDDIを要求される計算は軒並みアウト。2007/03/24(R6)でも、WinGAMESSとして配布されているバイナリではMP2の並列計算ができないことがあり(これもgfortranでコンパイルされている)、自分でg77でコンパイルし直したら動いたことがありました。

新たに追加された汎関数・M05/06系は、計算時間がB3LYPよりもかかるようで、上記の例では、M05で1.6倍以上の時間が費やされました。

　B3LYP1 : 353.9 sec (gfortran : 338.2 sec)
　M05 : 582.8 sec
　M06 : 574.1 sec
　M06-2X : 491.7 sec (gfortran : 469.7 sec)

ROHFを参照とする結合クラスター理論計算も可能になっていますが、こちらはまだ並列化されていません。しかしながら、ラジカル系のより精度の高い計算が可能になったと言えるでしょう。水分子のO-Hの結合エネルギーをCR-CCSD(T)/aug-cc-pVTZで計算したところ、453.6 kJ/mol (実測 463 kJ/mol)という結果が得られました(誤差 -2%)。ちなみにUMP2/cc-pVDZでは413.7 kJ/mol、CR-CCSD(T)/cc-pVTZでは444.7 kJ/molでした。
並列化されていないことやFile I/Oの時間が長いことなどで、CR-CCSD(T)/aug-cc-pVTZのエネルギー計算は30分かかりました(cpu timeは12分程度)。

※これらの計算は、Core 2 Quad Q9300 (2.5 GHz 定格)で実施しました。

投稿者: s2k 日時: 13:45 | パーマリンク | コメント (0)

メインPCの移行作業が終わりました。

さすがにBanias 1.6 GHzに比べるとサクサク動きます。OSがXP(SP2)→Vista(SP1)に変わっても。まぁ、メモリはMaxまで積んでますし、速いのは当たり前ですが…
64bitWSとGAMESSで計算速度を比較しましたが、クロック比にほぼ比例(若干64bit機が速い?)という結果でした。HDDの環境が全然違いますんで(64bit機はRAID 0)、その辺で少しリードされる程度ではないかと。

気になるのは、Core TempとSpeedFan両方で、ひとつのコアだけ温度が高く表示されるというところ。他の３つのコアより10℃高く表示されます。グリスを塗りなおしたり、CPUクーラーの向きを変えてインストールしたりしても変化なし…もしやハズレ個体なのか。まぁ、通常使用に支障は全くないので(フルに計算に使っても70℃まで行かない)、気にしないことにします。でも気になる…

これで、動画エンコードをするわけでもないのに「無駄にQuadコア×2」の生活がスタートです。

追記＠14:43
kakaku.comに、Q9300の温度表示に関する似たような体験談が。
http://bbs.kakaku.com/bbs/05100011431/SortID=7739017/
やはり個体差があるのかな？正確なことはわかりませんが。QX9650はかなりまともな温度を表示しているように思いますが、あれも実はズレてたりして？

追記＠5/1 9:20
今回CPUクーラーとして選んだのはNinja miniだったのですが(同じケース&M/Bで取り付け例があったので)、プッシュピン型の固定ってちょっと怖いですね。マザーボードが反るし(汗 Noctuaのは取り付けに手数が若干かかるものの、バックプレートを使った安心仕様だったのですが…次買うときはプッシュピン型はできれば避けたい。。。

投稿者: s2k 日時: 09:26 | パーマリンク | コメント (0)

64bitWSに続き、メール等に使っているPCもこのGW中にグレードアップを計画中。
CPUがPenM(Banias) 1.6GHz(!!)からC2Q Q9300(2.5GHz)になる予定。最初はPhenom X4 9100eもいいかと思ってましたが(780Gのパフォーマンスも魅力)、消費電力と性能の比を考えると、電力のレンジが実質E8500に近いQ9300が非常に魅力的に思えてきて、こちらに決定。M/BはG33のMicroATXで十分。
これで2台がQuad coreになることに。3並列で計算をやっても他の作業をする余裕があるのがいい。

…うちのブレーカー大丈夫か? (電子レンジを使った瞬間に落ちるとかないよな…)

＋αは、pc-chem.infoの更新について。
月1回ぐらいはと言っておきながら、2008年は1回も更新してません。コンテンツ作る暇がないんです。計算は時々やっていて、Sn2の一歩進んだ内容や、Monsanto Processのエネルギープロファイルなど、ある程度まとまったものもあります。この連休中にどこまでできるか…
ただ、64bitWSは別件で埋まっているので、それが終われば進捗があるかもしれません。

投稿者: s2k 日時: 11:02 | パーマリンク | コメント (0)

備忘録です。
問題になったGAMESSのD&D実行ファイルの改造ですが、ファイル数制限解除と使用CPU数のファイル名からの判別について、以下に記載しておきます。

(1)ファイル数制限解除
目的は10個以上の入力ファイルを同時にD&Dし、順次実行させること。普通は滅多に10個以上の入力ファイルを投入することはありませんが、私が計算を使うときは、様々なパターンの相互作用解析を実施したりする時にこれくらいの数の入力ファイルを作成して一気に計算させる時があります。まぁ、別にフォルダ内の.inpを順に実行するタイプ(pc-chem.infoで以前より記載)でも良いんですけどね…batファイルが1つ減るのと、こっちの方がプログラムとしてスマートだと思うので。

「Shift」を使います。

:start
if '%1'=='' goto end
(計算実行)
shift
goto start

:end
exit

基本的にこれだけ。入力されるファイルを順に計算してはパラメータをshiftし、shiftするものが無くなったらループを抜ける。

(2)使用CPU数のファイル名からの判別
GAMESS/PC GAMESSには並列化されていない部分もまだけっこうあります。MCQDPTやNMR、SS(V)PEなどなど…複数のプロジェクトの計算を実施する際に、並列化されている計算とされていない計算を逐次処理してほしい時があるので、勝手に判断して切り替えてくれるようにするのが私には便利です。

set seqkey=seq

set fname=%~n1
set pflag=%fname:~0,3%
if %pflag% == %seqkey% (set cpu=1) else set cpu=4

seqkeyは逐次計算のトリガーとなる文字列です。pflagは入力ファイル名の先頭3文字で、これがseqkeyと一致したらcpu数を1にセットします。seqkeyの文字数に合せてpflagの抽出文字数を変える必要があります。fnameはここでは特に意味はありませんが、実際のバッチファイルでは他の目的で使われています。
上記の場合、ファイル名の最初に「seq」を付ければ、他のファイルと混じっていてもそれだけ1 CPUでの計算になります。

投稿者: s2k 日時: 23:01 | パーマリンク | コメント (0)

スタートでいきなり躓いた64bitワークステーションの構築ですが、何とか安定運用に漕ぎつけました。というわけで、現在のスクリーンショット↓

バリバリ4コアでPC GAMESSを走らせております。時間の掛かる振動計算を実施中。しかも3.00GHz→3.66GHzにOC(333x11)しての運用です。FSBと電圧をいじらずに安定運用可能な限界がここら辺でした。長時間の計算を実施しないのであれば3.83GHzまでは問題なくいけます。x12の4.00GHzはOSが立ち上がらず(コア電圧を1.33Vまで昇圧すればいけます)。
CoreTempの値が…上のSSでは見えないですね。室温20℃でピーク58℃という感じです。真夏(室温30℃)にこれをやったら70℃行っちゃう…夏は定格ですね。

投稿者: s2k 日時: 22:38 | パーマリンク | コメント (0)