« 2008年02月 | メイン | 2008年04月 »

2008年03月30日

新しいPCって大変…

喜び勇んでx64ワークステーションを組んだわけですが、これがおそらくはメモリの相性(&グラフィックカードのドライバ?)に起因すると思われるブルースクリーンに悩まされております。
PC GAMESSの計算は基本的に問題が起こらないのですが、WinGAMESSの方はMP2なんかでメモリ領域を大量に使うときに突然砂嵐に巻き込まれたり真っ青になったりと…しかもエラーの出るタイミングやメッセージはばらばら。
メモリモジュールの挿し方によって変わる(2Gx4ではなくx3とし、3枚の挿し方のパターンによって安定したりしなかったり)。落ち方を見ると、DDIがメモリ領域を展開(この言い方が正しいのかどうかはわかりませんが)するタイミングです。WinGAMESSのバイナリにも依存していないように思うので(コンパイル済みvs自分でCygwinでコンパイル、LAAのon/off)、おそらくメモリではないかと。。。ちなみにMEMTEST86+ではエラー出ません。
似たようなケースでメモリのメーカーを変えたら嘘のように安定したという報告もちらほらあるので、P5K PROで動作確認が取られているメーカーのものにしたいと思います。メモリ安くて助かった…
(→CFDのW2U800CQ-2GL5J(CFD-elixir, P5K PROで動作確認済み)で無事安定動作となりました。一安心。[08/04/01追記])

PC GAMESSが普通に動かせるので、MP4(SDTQ)でベンチマークを取ってみました。

Xeon E5150 (2.66 GHz) x 2 : 1701.5 sec (28.4 min) (From PC GAMESS Performance page)
C2E QX9650 (3.00 GHz) : 1593.3 sec (26.6 min)

1.068倍高速ですが、クロック比では1.128倍ですから、伸びは悪いです。ま、OSやらチップセットやらが違いますし、細かいオプションの指定も違いますんで、その辺が影響しているかも知れませんが。

----
とりあえず、倍率変更のみですがOCしてみました。デフォルトは333x9で3.00GHzですが、これをx10.5に変更して3.50GHzにしてみました。x11はOSが立ち上がっても計算しようとすると即落ちでした。

C2E QX9650@3.50GHz : 1419.0 sec (23.7 min)

速くなっとります。ただ、発熱は結構馬鹿になりません。ピークで65℃前後。定格より10℃上がってます。室温が16℃ぐらいなので、夏場は無理ですね。定格運用なら、室温20℃でピーク55℃前後ですので、夏場も無問題でしょう。今の季節なら、x10で3.33GHzが落としどころでしょうか。

2008年03月28日

64bitワークステーションを組んでみました。

ちょっとお金が貯まったので、Core MAの計算速度を体感しようと一台PCを組みました。
こいつ何するんだ?とショップ店員に訝しく思われるかもしれない構成。電力効率と静音性に配慮しつつ計算速度は高めたい、という意図でパーツを選びました。

64ws1.jpg64ws2.jpg

ケースはCooler MasterのCOSMOS。E-ATXのマザーにも対応する、作業性の良い大型ケースです。音と冷却のバランスも良いのでは。中のパーツは以下の通り。

64ws3.jpg

CPUはQX9650。Q9000シリーズが発売になっていますが、入手性がかなり悪そうということと、QX9650はしばらく値段が下がらなそうだったので選択。TDPの印象以上に発熱が小さく、OCも楽しめそう。
HDDは発熱の小さいWD製ドライブをRAID 0で構成(計算ノードのみ)。5台積んでいますが、HDDの騒音はほぼ皆無です。
CPU coolerはNoctuaのNH-U12P。ヒートシンクがあまり重くなく、しかし冷却性能はすばらしいです。
4コアフル稼働で分子軌道計算を数時間行いましたが、CPU温度(CoreTemp読み)は50℃前後でした(室温20℃、アイドル時35℃)。

Athlon 64 X2 4400+ (OC@2.42GHz)の2コアフル稼働に対して、C2E QX9650の4コアフル稼働は3.3~4倍高速に計算を行うことができるようです。3.3GHzにOCすると、3.6~倍なので、4倍越えも出来そうな感じです。

続・WinGAMESSの割り当てメモリ量の増量

備忘録です。
前回まではこちら↓
WinGAMESSの割り当てメモリ量の増量

gamess.xx.exe(xxはバージョン番号)とddikick.exeにLargeAddressAwareのフラグを立てる、という方法。
LaaTiDo (http://www.musikbanken.se/laatidosetup.exe)をDL&インストールし、GUIの指示に従ってgamess.xx.exeとddikick.exeをLAA activeに変換し、変換前のものと置き換えて実行するだけです。
runscript.cshで両ファイルの存在を確認する辺りでなぜか引っかかるので、その辺はすべてコメントアウトor削除すると、無事メモリ量の制限が大分緩められます。
Windows Vista Business x64 では、MWORDS=268まで指定可能でした(搭載物理メモリは8GB)。

ちなみに前回は172でしたが、x64ではデフォルトではその半分しか指定できません。word単位は64bitOSと32bitOSでは倍サイズが違いますので、実に理論的に当たり前の結果。
ちなみに、PC GAMESSでは32bitでも64bitでもMWORDS=267が最大でした。これが一般向けWindowsを使う限りの限界でしょうか。

2008年03月09日

直交座標が活きるとき

備忘録。
最近、PCM(IEFPCM, CPCM)で溶媒和を考慮する計算をやってるんですが、構造最適化のカットオフがOPTTOL=0.0001(default)の設定で、0.0008ぐらいのところで振動というかぴくりとも構造とエネルギーが動かなくなる状態に鉢合わせました。まぁ、よくある話だよなと思いつつ、$STATPT辺りのパラメータをいじりながら詰められるかなと思っていたところ、これが思わぬ苦戦。

MOPACのCOSMOなんかでDDMIN=0.0が効くので(出力中にも「DDMIN=0.0 LETを追加してみろ」って出たりしますよね)、TRMIN=0.00なんぞにしてみたりすると、上手くいくときもたまにあるが、全く改善しない場合も多い。で、STSTEPやUPHESSを変えてみたりして何の解決にもならんので(注:あまり意味を考えずにいじってます)、そういえば、と思って最適化に使う座標系をDLCからCART(正確にはNZVAR=0にしただけ)にしたところ、あっさり解決。

座標系の選択は最適化に最も大きな影響を及ぼす因子だというのは知っていたものの、分子の構造からして直交座標が有利になることはないと思っていたんですが(※)、こういうこともあるんだと認識を新たにしました。

※GAMESSでいろいろな分子の構造最適化をしてみる限り、DLCを使って損をすることは滅多になく、普通はCARTを使うと構造の収束に時間が掛かることが多いです。非常にリジッドな分子ではその差が縮まってきます。(一般論かどうかはわかりませんが…私の経験上では)

2008年03月03日

長距離補正DFTの良い一面

DFT計算では反応障壁を低く見積もったり、系が大きくなるにつれて反応熱の見積もり誤差が大きくなるなどのいくつかの問題が指摘されていて、世の理論化学者たちはその解決に躍起になっているようです。
GAMESSには、そのような問題(の一部)を解決できるような補正法が搭載されています。東大の平尾研で開発されたLC(長距離相互作用補正)DFTで、現在のところGAMESSではBOP,BLYPについてLC補正を加えることができます(キーワード: LCBOP, LCBLYP. BVWNにもLCを加えられるが、$DFTでLC=.T.を指定する必要あり)。

LCによりどんな効果があるのか、それは平尾先生らの発表でも明らかではありますが、自分で計算してみないと気がすまないのが私なので、昨年発表されたMichael付加反応の反応熱に関する論文(OL, 2007, 9, 4279-4282. DOI:10.1021/ol701872z)のFigure 2をネタに、LC-BOPとBOPの比較をしてみました。計算時間の都合上、基底関数はDZVP(DFT orbital)を用いています。

ol701872z_plus.jpg

参考に、文献のSupporting InfoよりSCS-MP2/cc-pVTZ(本系でのG3MP2B3との最大絶対誤差が1-2 kcal/mol)の値を引用してグラフ化してあります。
結果は一目瞭然で、元文献に記載のB3LYPの結果とほぼ同じ挙動を示すBOPに対して、LC-BOPはSCS-MP2に非常に近いグラフとなっていて、トータルの反応熱も大きく改善されています。

ちなみに、LC-BOPの計算はBOPに比べておよそ1.3倍の計算時間がかかります(一点計算での比較)。
また、LCで何でも解決できる、というわけではないので注意が必要ですね。