s2k's eye 2nd Ed.

HPもついに低価格ミニノート市場に参戦ですね。HP 2133、実に物欲をそそるデザインっす。

何かMacっぽい？
キーボードは英字onlyですが、僕は英字キーボード使いなので無問題。ていうかむしろ歓迎。液晶の解像度も高く(目が悪くなってきた自分にはちと厳しいか？)、作業領域が広く確保されているところは好印象。
問題はCPUの処理能力と筐体の排熱能力で、あちこちのレビューを見る感じ、Vistaでは若干のもたつきを感じ、またCPU使用率が高いときの筐体の発熱とファンの騒音が結構なものになるようです。やはり、この辺のサイズと価格で、いろいろと犠牲になっている感は否めません(というかしょうがない)。液晶のバックライトもLEDではなく蛍光管のようですし。
個人的には、10万を超えない領域でもうちょっと問題点が解決されたら(特にYoutubeの再生でCPU使用率が100%に到達してしまう処理能力)買いなんですが…同じVIAのプラットフォームならIsaiah待ちということになるのかもしれませんが、Isaiahになってピーク発熱は上がりそうな感じなので、その辺をどうできるか。。。

まぁ、何にせよ、今は買うつもりはありません。むしろEee PC 900の方が…うっかり買ってしまいそうでやばい。

----

前回、OSの管理外領域にRAM Diskを作成する話を書きましたが、その使い道を決めました。
ReadyBoost用に4 GB + Internet Temporary Filesに700 MBです。

RAM Diskはシャットダウンするとクリアされてしまうので、ReadyBoostの設定も起動するたびにやり直さなくてはならないわけですが、Vistaはシャットダウンせずに使うのが本道のようなので、今は休止状態を基本にしてます(低電力でメモリ領域の記憶が保持されるため、再設定が必要ない)。旅行で長期間不在のときはさすがにシャットダウンします(環境のためにも？)。

ReadyBoostによって、HDDの見かけのパフォーマンスは向上してます。システムの入っているHDDのFDBENCHの結果は以下の通り。

***** FDBENCH Ver 1.02 (C)2003-2007 ep82kazu *****
[ReadyBoostなしの場合]
Drive C:\
Drive Size 100MB

Disk Read Write RRead RWrite (KByte/s)
31629 52919 32323 18645 22629

Copy 2k 32k 256k 1MB (Operations/min)
3415 5244 4326 2172 1920

Copy 2k 32k 256k 1MB (Kbyte/Sec)
7496 117 1545 6239 22083

***** FDBENCH Ver 1.02 (C)2003-2007 ep82kazu *****
[ReadyBoostでRAMDisk4GBを指定した場合]
Drive C:\
Drive Size 100MB

Disk Read Write RRead RWrite (KByte/s)
36513 52892 46188 20508 26466

Copy 2k 32k 256k 1MB (Operations/min)
11428 8442 24678 9288 3306

Copy 2k 32k 256k 1MB (Kbyte/Sec)
18324 188 8780 26470 37858

Writeのスコアが向上してます。

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

PC Watchに特別レポートが掲載されていました。
曰く、

「32bit Windowsの管理外領域メモリでRAMディスクが作れる」

何ッ！そいつぁやるっきゃねぇ！
というわけで、PAEを有効にした後以前相性問題で丸ごとあまったメモリ2本(2GBx2)をメインPCに装着(総計8GB！)し、Gavotte RamdiskでRAMディスクを作成してみたところ、

できとる！
ちなみに、ちゃんと通常の物理メモリも認識しとります。
でも、何に使おう…いや、GAMESSのスクラッチ領域として使ってみるのが真の漢だ！というわけで、ベンゼンのRHF/aug-cc-pVDZでの1点計算をconventional SCFで実行してみました。2電子積分をスクラッチファイルに記録するので、File I/Oが激しく発生します。

見ての通り、RAMディスクではCPUとWallの時間差(≒File I/O待ち時間)が2秒足らず！通常のHDDでは1分近くかかるところですんで、まさに既報のベンチマーク結果に違わぬ爆速ぶり！

しかし…容量が5GB弱じゃぁ、ちょっと大きい計算やったらすぐオーバーフローしちゃう…(aug-cc-pVTZはアウトでした)。やっぱ使い道が難しい…IEのテンポラリフォルダぐらいかな。

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

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数を増やせばいいってもんでもないのが面白いところ。ノード数が増えれば話は別ですが。

MCSCFの怪しげなエラーとは、例えばこんなところ。2 core以上の計算だと、なぜかこんな感じに↓

--------------------------------------------------
AMES LABORATORY DETERMINANTAL FULL CI
PROGRAM WRITTEN BY JOE IVANIC AND KLAUS RUEDENBERG
--------------------------------------------------

THE NUMBER OF DETERMINANTS HAVING SPACE SYMMETRY A
IN POINT GROUP C1 WITH SZ= 0.0 IS 400
WHICH INCLUDES 175 CSFS WITH S= 0.0
WHICH INCLUDES 189 CSFS WITH S= 1.0
WHICH INCLUDES 35 CSFS WITH S= 2.0
WHICH INCLUDES 1 CSFS WITH S= 3.0
THE DETERMINANT FULL CI REQUIRES 148137 WORDS
INITIAL CI VECTORS READ FROM DISK, NSTATE= 1
INITIAL FULL CI ITERATION TIME: 0.0

ITERATION ENERGY GRADIENT
0 -224.2437411993 0.00000000　　　←？？？

CONVERGED STATE 1 ENERGY= -224.2437411993 IN 0 ITERS

ALL STATES CONVERGED.

CI EIGENVECTORS WILL BE LABELED IN GROUP=C1
PRINTING CI COEFFICIENTS LARGER THAN 0.050000

STATE 1 ENERGY= -224.2437411993 S= 1.30 SZ= 0.00 SPACE SYM=A

ALPHA | BETA | COEFFICIENT
--------|--------|------------
..... DONE WITH DETERMINANT CI COMPUTATION .....
ON NODE 0 STEP CPU TIME= 0.00 TOTAL CPU TIME= 7.5 ( 0.1 MIN)

同じ入力を使っても、1 coreの計算(つまりMEMDDIなし)だとこんな感じ↓で正常終了に至る。

--------------------------------------------------
AMES LABORATORY DETERMINANTAL FULL CI
PROGRAM WRITTEN BY JOE IVANIC AND KLAUS RUEDENBERG
--------------------------------------------------

THE NUMBER OF DETERMINANTS HAVING SPACE SYMMETRY A
IN POINT GROUP C1 WITH SZ= 0.0 IS 400
WHICH INCLUDES 175 CSFS WITH S= 0.0
WHICH INCLUDES 189 CSFS WITH S= 1.0
WHICH INCLUDES 35 CSFS WITH S= 2.0
WHICH INCLUDES 1 CSFS WITH S= 3.0
THE DETERMINANT FULL CI REQUIRES 177837 WORDS
INITIAL CI VECTORS READ FROM DISK, NSTATE= 1
INITIAL FULL CI ITERATION TIME: 0.0

ITERATION ENERGY GRADIENT
0 -230.7249876870 0.10262436
1 -230.7338189446 0.04201266
2 -230.7359344336 0.00991418
3 -230.7360345648 0.00081996
4 -230.7360351996 0.00016938
5 -230.7360352446 0.00005406
6 -230.7360352483 0.00001119
7 -230.7360352485 0.00000130
8 -230.7360352485 0.00000024

CONVERGED STATE 1 ENERGY= -230.7360352485 IN 8 ITERS

ALL STATES CONVERGED.

CI EIGENVECTORS WILL BE LABELED IN GROUP=C1
PRINTING CI COEFFICIENTS LARGER THAN 0.050000

STATE 1 ENERGY= -230.7360352485 S= 0.00 SZ= 0.00 SPACE SYM=A

ALPHA | BETA | COEFFICIENT
--------|--------|------------
111000 | 111000 | 0.9720686
101100 | 101100 | -0.1040727
110010 | 110010 | -0.1040573
110100 | 110100 | -0.0712754
101010 | 101010 | -0.0712717
111000 | 100110 | 0.0711535
100110 | 111000 | 0.0711535
110100 | 101010 | 0.0519747
101010 | 110100 | 0.0519747
..... DONE WITH DETERMINANT CI COMPUTATION .....
STEP CPU TIME = 0.08 TOTAL CPU TIME = 10.7 ( 0.2 MIN)

1 core向け入力ファイル(mcscftest1.zip)
2 core 以上の入力ファイルは$SYSTEMがMWORDS=1 MEMDDI=6 PARALL=.T.になっているだけ。
これはバグなんでしょうか？？

【自己解決】
入力ファイルと同名のスクラッチファイル(scratch内)が存在していたことに起因するようで、そこを空にしたら正常終了しました。
んが、FULLNRは並列計算で何でこんなに遅いんだ…4並列で、やっとMEMDDIなしの逐次計算と同じ時間とは…逐次計算でもMEMDDIを使うと激遅になるから、メモリ周りに原因がありそうだ。

投稿者: 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)