s2k's eye 2nd Ed.

とりあえずの報告。
Fedora 9 (x86-64)を以前使っていたAthlon 64 X2機にインストールしました。いやぁインストーラも昔に比べて洗練されて、非常に楽です。Windowsとぱっと見難易度は変わりません。
無事インストールが終わり、GAMESSのソースを展開してコンパイル開始。が、cshがないと。とりあえず現在のメインPC経由でネットにつなぎ、tcshをインストール。ふぅ。コンパイル自体は正常に進行し、あとはリンクするだけというところで今度は線形代数ライブラリがないと。ATLASをインストールし、今度こそ完了。無事並列で計算できました。

3GBのメモリを積んでいますが、$SYSTEMでMWORDS=1100程度まで指定可能に(↑)。x64のcygwinがあれば、Windowsでも同じようにメモリを使えるんだろうが…まぁ、これでメモリを大量消費するNMRの計算なんかもかなり大きな分子まで実行可能になったんではなかろうか。

----

余談ですが、Fedora 9を使っていて、時々タイミング不明でUSBがきかなくなる現象がありました。マウス・キーボード・USBメモリが認識されなくなり、フリーズ状態。今後はとりあえずPS/2のマウスとキーボードでしのぐかなぁ…

【追記@15:30】
上記のUSBの問題は、キーボード/マウスについてはPS/2接続で安定。
「続きを読む」に、WineでWinmostarとFacioを動かした話を追記しました。

続きを読む "Fedora 9 (x64)でGAMESSを使ってみるテスト。" »

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

備忘録。
PC GAMESSのWebサイトで公開されている、GAMESS入出力加工専用マクロ『JOB』を使って、何気に面倒な$VECと$HESSのPUNCHファイルからの抽出を、.inpファイルと.punファイルのD&Dで実現するバッチファイルを作成しました。イマイチ美しくないコードですが。

-----------------

@echo off

set job_dir=D:\JOB
set f_inp=inp
set f_pun=pun

if "%~x1"==".inp" set f_inp=%1
if "%~x1"==".pun" set f_pun=%1

if "%~x2"==".inp" set f_inp=%2
if "%~x2"==".pun" set f_pun=%2

if %f_inp%==inp goto exterr
if %f_pun%==pun goto exterr

move %f_inp% %job_dir%\temp.inp

echo #copy_vec %f_pun% %job_dir%\temp.inp > %job_dir%\temp.job
%job_dir%\job.exe %job_dir%\temp.job

move %job_dir%\TEMP.INP %f_inp%

pause
exit

:exterr
echo 拡張子に誤りがあります
pause
exit

-----------------

ドロップされた2つのファイルの拡張子からどちらがinputでどちらがpunchかを判別し、JOB用のファイル(temp.job)を作成して実行。このとき、一回temp.inpに書き込んだ後元の.inpファイルにリネームしてますが、これはJOBがなぜか書き込み先の.inpファイルのファイル名を全て大文字にしてしまう(だからmove行でTEMP.INPと書いている)からです。
#copy_vecを#copy_hessに変えるだけで、$HESSの読み込みに対応します。

本当は、.outも読み込めばNORBを自動で入れてくれたりするので、その辺を実装したバージョンも書いていますが、GAMESS(US)の.outファイルには対応していないようなので(実際NORBは入らない)、それを省いたバージョンを使ってます。

この辺のは、JOBじゃなくてもperlでできたりしますが(最近GAMESS MLにポストされてましたね)、プログラム慣れしてない私にゃJOBが便利です。

投稿者: s2k 日時: 21:48 | パーマリンク | コメント (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数を増やせばいいってもんでもないのが面白いところ。ノード数が増えれば話は別ですが。

続きを読む "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)

備忘録です。
問題になった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)

備忘録です。
前回まではこちら↓
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)。

続きを読む "続・WinGAMESSの割り当てメモリ量の増量" »

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

備忘録。
最近、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を使うと構造の収束に時間が掛かることが多いです。非常にリジッドな分子ではその差が縮まってきます。(一般論かどうかはわかりませんが…私の経験上では)

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

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)を用いています。

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

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

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

仕事にも役に立つかもしれないので、ABINIT-MPを一通り使えるように勉強開始。
とりあえず、自分でフラグメントを設定して1点計算でIFIEを求められるようにはなりました(多分)。それにしても、計算速いですね。
MPICH使った並列化は初めてだったのですが、ユーザを新たに作成しなくてはならなかったり、パスが上手く通らなかったりでちょっと苦戦。でも、15分くらいでbatファイルを使って並列計算を流すことはできました。かなりメモリを食うプログラムのようですので、64bit環境が必須かも知れませんね。

----

64bit PCをツクモで売り始めましたが、何か高いですね。自分で組んだらずっと安く上がりそう。保証とかサポートとかOSインストールの手間とか組み上げるときの人為的ミスのリスクとか考えると、5～6万ぐらいは高くても目をつぶるか…

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

『Pauling's mystery molecule』は、化学マニアの間では良く知られている分子の一つでしょう。佐藤健太郎さんの著書「有機化学美術館へようこそ」にも、最後のコラムに採り上げられています。この分子は、20世紀の天才Linus Carl Paulingが氏のオフィスの黒板に書き残した意図不明の分子で、Heptazine骨格にアジド基と2つのヒドロキシル基が結合しています。

ACSのC&ENで、2000年に「この分子の意味するところは何か？」という懸賞が企画されました。その結果については今更なので書きませんが、私の第一感をここに書き残しておきたいと思います。

続きを読む "Paulingのミステリー分子" »

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

今年に入って、Sn2反応の再評価をやってます。
単純な反応でも、計算で再現するのは大変だということが良く分かります。いろいろなモデル化学を試してみて、結局HF/6-31G(d)が一番再現しているのがまた…(MP2は活性化障壁を高く、DFTの多くは低く見積もってしまう)。
Hofmann転位についてもMOPACとGAMESSの両方で再計算中。来月の更新となる予定。

WinGAMESS 08(実際には2007.03 R6)がリリースされましたが、末永先生のD&DジョブポスティングBATファイル(お、何かかっこいいな)が同梱されました。pc-chem.infoでは古典的なやり方を書いてますが、これが同梱されたことで改訂が必要でしょう。もともとFacioには同梱されていて、私も使ってました。
このWinGAMESS 08ですが、私の環境ではいくつかのjobで並列計算がエラー終了します。具体的にはMP2絡みの計算で、MEMDDIが必要になる計算で起こっているよう。DDIに問題があるとしか考えられません(追記に出力例を書きました)。

今現在、重原子が70弱(total basis functions = 1185)という結構大きなMP2 single point計算をしてます。気が付いたらDASORTファイルが100GB到達目前！いや、そのHDD、150GBしか容量ないんですが…(汗　別に必須の計算でもないんで、止めて別の計算を流した方が今は効率がいいかも…

◆1/20 14:00に追記あり

続きを読む "近況とかいろいろ" »

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

こちらに書くのは久しぶりです。

最近、ForumにMRMP2計算のスレッドが立ちました。これまでMRMP2を含む励起状態の計算はほとんどやったことが無かったので、いい機会だと思っていろいろやってみてます。
実は、励起状態に限らず多参照理論を使ったことがなかったので、出力の見方だったり入力の癖だったり、いろいろと分からないことが多く、最初はかなり苦戦しました。でも、一回慣れてしまうと目的の励起状態の計算は結構すんなり行えるようになりました(多分)。今でも活性軌道の取り方はなかなか難しいとは思いますね。
Winmostarの同梱のCNDO/Sによって簡単な励起エネルギー計算はできますが、より進んだ計算ならGAMESSでいろいろできます。上で書いたMRMP2はある意味一番面倒な(一番高価ではない)方法です。他に、CIS, TD-DFT, EOM-CCSDが使えます。この連休中に、これらの計算について入力作成から結果の比較までをまとめてコンテンツ化したいと。その前に、この記事の追記でプレビューしますので、少しお待ちを。

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

ちょっと前に、GAMESS MLでORCAという名前のプログラムが出てきました。聞いたことがなかったので調べてみたら、ドイツ・ボン大のグループによって開発されているab initio計算プログラムで、アカデミックに限り無償で配布されています。ユーザー登録で"個人的な学習"とし、プログラムを使ってみました。

RI-MP2やSCS-MP2， DFT/MP2ハイブリッド法であるB2PLYP, mPW2PLYPが利用できます。HFの計算スピードはGAMESSに比べて低速ながらMP2とDFTの効率は高く、PC GAMESSほどではありませんが結構高速で計算できます(RI-MP2ならGAMESSのMP2より速いかも？)。Windowsでも並列できればいいですが、バイナリは1CPUのみです。

続きを読む "ORCA使ってる人オルカ？" »

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

GAMESS (2007.03 R3)のWindows上でのコンパイルについて。
すでに、cygwin/g77でのコンパイルについては正常に行えることを確認済みですが、それからgfortran 4.3によるコンパイルとCygwin/MinGWを使ったcygwin非依存バイナリ生成を試みてました。どちらも実行速度向上の可能性を考えてのトライです。

現状、上手くいってません。
gfortran on Cygwinでは、nmrとあともう一つ(何だったか忘れてしまった…)でコンパイル時にエラーを吐いて終了。ただ、それ以外は正常にコンパイルできているんで、リンク時にそれら2つのオブジェクトファイルを除けば、NMR計算は機能しないものの他の計算はできるかも。近々やってみます。ちなみにエラーについてはgfortranのバグだとlogには記録されてますが…どうなんでしょ？
MinGWのg77によるコンパイルでは、ddi以外はすべて正常にコンパイルできます(-mno-cygwinオプション追加で)。ddiはソースがcですが、MinGWのヘッダファイル(include以下)が足りないので、コンパイルができませんでした。cygwinのincludeにパスを通しても、それは所詮cygwinのヘッダファイルなので、コンパイルが上手くいかなかったりリンクでエラー吐くんで意味なし。

個人的には、MinGWでのcygwin非依存バイナリに興味津々ですが、すぐにはできなそう(涙
この辺について詳しい方 or やってみた方情報募集中。あ、MLに流してみよか…まずはエラー内容をきっちり押さえてからですが。

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

なかなか重い腰が上がらなかった、GAMESSのソースコードからのコンパイル。やっと実施してみることにしました。
細かい内容には触れませんが、cygwinは1.5.19(gcc-3.4.4.1)を使いました。ソースコードに同梱のマニュアル通りにコンパイルができます。但しcompallとcompddi，lkedは「./」を頭につけて実行する必要がありました。ddiのsysVはoffです(cygwinでのコンパイルでは必須？)。あと、tinkerモジュールを組み込みました。QM/MMは興味ありますし。

コンパイルにかかった時間はトータルで20分ほど。特につまずくこともなく、あっという間に終了しました(ちょっと拍子抜け？)。
生成した実行ファイルでベンチマークしてみました。例によって有機ラジカルのUMP2 Gradientです。但し、基底関数にaug-cc-pVDZを使って計算時間を延長してます。
NUMBER OF CARTESIAN GAUSSIAN BASIS FUNCTIONS = 154です。

1 CPUでの計算効率は、Webリリースのprecompiled binaryが有利(自分でコンパイルしたbinaryは0.966倍の効率)ですが、並列化効率は自分でコンパイルしたbinaryの方が有利(Wall clock timeで1.1倍)という結果でした。ちなみに並列計算の入力ではMWORDS=1, MEMDDI=22ですが、シングルスレッドの入力ではMWORDS=120(実際には96で足ります)ということで、メモリ効率も良いです。

今回の比較は、ソースのリビジョンが違う(R1とR3)ので単純に比較できないのですが(もしかしたらUMP2 Gradientに関わる最適化がされているかも？)、並列計算では自分のところでコンパイルしたものを使った方が効率が上がるかもしれません。

コンパイル&並列化については、pc-chem.infoで近くコンテンツ化予定です。乞うご期待。

【追記】
最新の(正確には2006.09～)GAMESSではCCSD(T)のエネルギー計算が並列でできることになっていますが、WinGAMESS 07.03では1 CPUと2 CPUで計算時間に変わりなし(むしろ2 CPUが遅いぐらい)。もちろん、タスクマネージャー上では2つのコアが両方動いていますが…何してるん？
(※各ステップごとのCPU時間を見る限り、SCFは短縮されていますがCCで時間がかかってる)
また、上で紹介した私がコンパイルしたバイナリでは、precompiledのものに比べ倍時間がかかります。どうもCCのルーチンだけ特殊？

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

最近Forumで投稿があった、WinGAMESSでの並列計算について。
wingamに同梱のwingam.cshを使うことで、1年前のバージョンである2006.02なら並列化できることはわかりました。方法についてはForumに投稿していますが、ここでは計算速度についてわかったことを書き留めておきます。
ジメチルアミノキシルラジカルの6-31G(d)基底によるGradient計算を例に、並列化効率を計って見ました。なぜこんな分子を選んだかは自分でも謎ですが、PC GAMESSでは現状できないUMP2 Gradientをやりたかったからではないかと。

結果は上記の通り。並列化効率以外の数値の単位は秒です。短時間の計算なのであまり現実的ではないような気もしますが、まぁまぁの効率であることは分かると思います。UMP2もちゃんと並列化できてます(そりゃそうだろう)。
ちなみに、スチレンの構造最適化(MP2/3-21G)も並列化効率を見てみましたが、凡そ1.7倍。上記Gradient計算の結果を反映した結果になってます。こちらは1 CPUで2000秒弱かかりましたので、現実的な比較ではないでしょうか。もっと大きな系やConventional SCFだとどうかはこれから時間が有るときに見て見ます。

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

タイトルは↑ですが、カテゴリはChemistryでお送りします。

7/22(日)、IntelがCore 2 DuoのFSB 1333MHz版[E6x50]シリーズをリリースします。同時に大幅な価格改定も行われ、新シリーズも含めてかなり攻撃的な価格設定が為されるようです。E6850(3.0GHz)はX6800より性能upしながら40,000円強ぐらいで出始める雰囲気。かなりコストパフォーマンス高そうです。45nMは待つ必要が無さそう？

さて、7月といえばボーナス商戦ですね。かく言う私もそれなりにボーナスを貰い、それにプラスして隠れ財産(「隠し」ではない：出張旅費清算の口座を先日初めて覗いてみてびっくり！)ができていたので、1台ワークステーションを組めそうな感じです。Max30万ぐらいまで可。
そこで、PC GAMESSの計算能力を加味した形でコストパフォーマンスを調べてみました。価格は7/22時点での予測ですので、正確さはかなり？？ですが。

続きを読む "7/22、Intelの価格改定＆新CPU登場で…" »

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

Winmostarのアイコンを作ってみました。

これ、未踏事業の特設サイトの画像のリファインです。菱形のデザインだったので、アイコンにするとこじんまりとしてしまってちょっと失敗かも。でも、個人的にはこのデザインが気に入っているので、デスクトップのショートカットとかこのアイコンに置き換えてます。

このアイコンを使ってもいいと思う奇特な方はこちらから。

これから旧掲示板の(仮の)ロックかけます。。。実は忘れてました。

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

PC GAMESSのサイトにnew mp2 gradient code documentationが公開されています。これを参考に入力ファイルを調整し、実用的なベンチマークという意味で、電子数208の有機分子(第1～第3周期の元素を含む)を種々のモデル化学でGradient計算してみました。Gradient計算で、最適化1サイクルあたりの時間が大体分かるので、実験計画を立てやすいというのが理由です。

HF, B3LYPについては
$p2p p2p=.t. dlb=.t. $end
$smp csmtx=.t. $end

MP2については
$p2p p2p=.t. dlb=.t. xdlb=.t. $end
$smp csmtx=.t. $end
$mp2 method=1 $end

のオプションにて計算を実施(HF,DFTはp2pでなくても並列計算できますが、MP2に合わせるということと、p2pを使った方が少し計算が速いため)。
MP2も結構健闘していて、基底関数が大きくなるとHFに接近する傾向があります(DFTほどではないですが)。メモリの消費量は他の二つに比べて増えますが、上記オプションを使うことでエネルギー計算の際の(異常なメモリ消費による)ロスはなくなります(400 Basis Functionsの系で700秒短縮(2000→1300)されました！)。
前回のグラフでも分かるように、小さい系(<200 Basis Functions)ならMP2はDFTよりも高速ですので、その辺ではかなり使えそう。そしてある程度大きい系でもDFTでは扱えない相互作用を扱うのにMP2は必要ですから、これぐらいのスケールで収まったのは実務上大きいですね。

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

本日、PC GAMESSの最新版7.1.0RCが公開されました。
ついにMP2 Gradientの並列化が実装され、本当の意味での高速MP2計算が実行できるようになりました。ちなみにP2P shared memoryで実行する仕様です。

この最新版で、HF,MP2,B3LYPのスケーリングを比較してみました。炭化水素の1点計算で、Basis Functionの数が42～396までの4種類(基底関数は6-31G(d)で、分子の大きさを変えたもの)について実施し、グラフ化したのがこれ↓

小さい分子ではMP2が優秀、大きい分子ではB3LYPが優秀というセオリー通りの結果です。MP2は396 Basis Functionの系でメモリが飽和してしまい、エネルギー計算を5 passに分割しているため、メモリ量さえ十分確保できればB3LYPの曲線に近づくと思われます。ただ、現実的にはメモリ量に限りがありますので、少ないメモリ量で高速に計算できるDFTはやはり優秀ですね。

話は変わりますが、個人的には折角並列PCMを実装しているので、もうちょっとPCM計算のチューニングをできるように機能拡張してほしいですね(原子あたりのセグメント数の指定とかできない感じ)。PCMでの構造最適化の収束が非常に悪いので…

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

話題1つ目。
本を2冊買いました。アドバンスソフト刊行の「フラグメント分子軌道法入門」と「タンパク質量子化学計算」です。生体高分子であるタンパク質の量子化学計算は膨大な計算資源(ハードウェア・時間)が要求されますが、二冊ともそれを現実的なタイムスケールに引き寄せる革新的なアルゴリズムに関する「超」入門書です。

GAMESSを使っている人間として、FMO法を正しく理解し、計算を実行できるようになることは重要だと思いますし、タンパク質を相手にしている人間として、タンパクの全電子計算を学ぶことは将来的役に立つとも思います。
2冊の本でそれぞれ紹介されている方法論は、それぞれABINIT MPやProtein DFとしてRSS21からプログラムがダウンロード可能です。興味のある方は是非。

続きを読む "最近の話題３つ" »

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

連荘で化学ネタです。今度は計算の備忘録。
GAMESSにFMOが実装されていることは、計算をやっている人なら周知の事実ですが、WinGAMESSに収録されている入出力例(manualsフォルダ内のtests.pdf)のexam37はそのまま実行してもエラーが出ます。
まぁ、とりあえずFMOってどないやねん、とpdfファイルからコピペして実行すると、

**** THERE ARE ATOMS LESS THAN 0.100 APART, QUITTING... ****
EXECUTION OF GAMESS TERMINATED -ABNORMALLY- AT Sat Jun 16 22:13:30 2007

てな感じでエラー終了します。

続きを読む "GAMESS/FMOに落とし穴あり。" »

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

有機化学実験をやったことのある人なら、必ず１回は分液操作をしたことがあると思います。
普通、分液というと水―有機溶媒系がほとんどで、よく有機溶媒としてエーテル(ジエチルエーテル)，クロロホルム，酢酸エチルなどが使われます。

が、

有機溶媒―有機溶媒の分液もごく稀に行われることがあります。ペンタン―アセトニトリルやヘキサン―メタノールがそんな一例です。
不思議な2層の1つに、エーテル―DMSOがあります。ヘキサン―メタノールは直感的に2層になることが理解できるのですが、エーテルとDMSOにそんなに違いが有るとは思えません。エーテルとDMFは混和しますし…

続きを読む "有機化学者にとって身近な謎？" »

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

計算をただ使うだけの立場だと、「え、DFT？じゃぁB3LYP使っとけば？」なんていう風潮がありませんか？B3LYP使っておけば、とりあえず論文に書いても蹴られないだろうみたいな。
でも、本当はいくつか汎関数を比較してみて、目的とする系に適したものを選択する必要があるはずですよね？そういう情報は専門家が握っていて、素人の目にはなかなか留まらないものかも知れませんが。
Casida先生のページには、今までに開発されてきた様々な汎関数が紹介されていて、その元文献やそのabstractなんかが書かれていますので、非常に参考になります。

GAMESSでは色々な汎関数が利用できますが、その中のいくつかを、最適化構造が実験値にどれくらい合っているか比較してみました。

続きを読む "DFT Functionalにも個性がありますよね？" »

投稿者: s2k 日時: 21:14 | パーマリンク | コメント (1)

最近、ねじれ歪みの計算を合間を見てやっています。
意外と奥が深いもので、分子によっては非常に高価なモデル化学が要求されるものもあります。そんな難易度の高い分子に「過酸化水素」があります。O-O結合の回転障壁が曲者で、DFT如きでは正確な障壁は求められません。CCSD(T)でやっと満足いく値に。計算時間も馬鹿になりません(といってもせいぜい1時間ですが…PCも速くなったもんだ)。

実は、この回転障壁を求めるのにPC GAMESSのRSURFACE計算を使っているのですが、この挙動が非常に怪しいのです。

続きを読む "RSURFACEの怪" »

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

MO計算データの可視化ソフトは、計算を利用するものにとって大変有り難い存在です。何しろ、元となる計算の出力データは数字の羅列で、直感的に理解しにくいものです。それを目で見て分かる形に変換してくれるのですから、説得力も増しますし、計算自体の魅力も増すのだと思います。

しかし、この「可視化」というものはその威力の反面、ブラックボックス的に使っていると痛い目にあうことになりかねません。
下の画像を見てください。これはPC GAMESSで計算したメタノールとエチレンのESP(静電ポテンシャル)を等電子密度面にマッピングした画像です(Winmostarで作成しました)。

これを見ると、エチレンとメタノールは同じぐらい分極しているように見えますね。

続きを読む "「可視化」の威力と怖さ" »

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

以前に、WinGAMESSで指定できるメモリ量の妙な制限の話を書きました。これについて、ちょっとだけ解決したので覚書を。

WinGAMESSはCygwin/gccでコンパイルされていますので、cygwinのメモリ制限に引っかかるそうです。で、以下のレジストリキーを追加することで、その最大割り当てメモリ量を拡張することができます。
HKEY_LOCAL_MACHINE/SOFTWARE/Cygnus Solutions/Cygwin/heap_chunk_in_mb
このキーのDWORD値に適当なメモリ量をMB単位で入れます。私のワークステーションは現在3072MBのメモリが積まれていますので、(全部使えるわけではありませんが)3072(10進数で)と指定してみました。すると、今まではMWORDS=122が限界値でしたが、これが172まで行けるようになりました。

続きを読む "WinGAMESSの割り当てメモリ量の増量" »

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

最近、PC GAMESSのページのNewsで「JOB」という入出力ファイル操作用マクロが公開されました。これ、なかなか楽しいです。いくつかの実例が同梱されてますが、G2に代表される高精度エネルギー法が簡単に実行できるようになります。

続きを読む ""JOB"って何か知ってます？" »

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

PC GAMESSでは結構前のバージョンからGaussian Cubeデータの生成に対応していました。基本は$CUBE CUBE=.T. $ENDで、Cubeデータ化したいものに応じて他の入力を追加します。電子密度なら$ELDENS IEDEN=1 $END，静電ポテンシャルなら$ELPOT IEPOT=1 $ENDを追加すればとりあえず計算できます。

このPC GAMESSのCubeデータはマニュアルでは「Gaussian形式準拠」となっていますが、実は微妙に曲者で、数字を区切るスペースの数が部分的に異なるために、そのままだと読み込めないことがあります。

続きを読む "GAMESSでGaussian Cubeファイルの生成" »

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

随分前に、対称性を利用して計算を行う話をしました。対称性の高い分子は、点群を利用して計算を低コスト化することが可能です。
美しい対称性の一つに、Td(正四面体形)があります。メタンが代表例ですが、こういった分子をうまく計算するのがなかなか…
GAMESSのマニュアルの記述がわかりにくいので、備忘録的にここにメモしておきます。

続きを読む "Td対称の計算に苦戦。" »

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

以前にS-O相互作用(硫黄原子と酸素原子のattractiveな相互作用)の計算についていくつか書きました。

S-O相互作用の計算に必要なモデル化学とは。
続・S-O相互作用の計算に必要なモデル化学とは。
続々・S-O相互作用の計算に必要なモデル化学とは。

最近、会社でS-O相互作用の話が出たので、以前やりかけていた諸熊分割についてまとめてみました。

続きを読む "諸熊分割によるS-O相互作用の解析" »

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

昨日、PC GAMESSの新しいテスト版7.0.4が登録ユーザー向けにリリースされました。7.0.3から組み込まれた並列化PCMとO汎関数に興味があるところで、まずはPCM計算の並列化について早速簡単なテストをしてみました。

計算内容は、フルフラール(フラン-2-カルボアルデヒド)のs-trans配座をPCM法(THF中)を用いて計算するもので、HF/6-31G(d)による構造最適化とB3LYP1/6-31G(d)によるシングルポイント。

続きを読む "PC GAMESS 7.0.4 の並列PCMテスト" »

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

PC GAMESSのオフィシャルページで、WinGAMESSと共通のinputを使ったベンチマークテストが公開されてました。
ハードウェアが二昔前ですが…
ちなみに、僕がやった短時間のベンチマークの結果はこちら。

こうやってみると、PC GAMESSは多くのケースで一桁速いことがわかります。実際の構造最適化計算では逐次処理で1.5倍～2倍，二並列処理で3倍～4倍速いです(計算環境：Athlon X2 4400+(2.2GHz), 1GB RAM(DDR400), 160GB HDD(SATA150, 7200rpm))。特殊な計算以外は、PC GAMESSで行うほうが時間は節約できますね。最も、GAMESSをLinux上でコンパイル，並列化するとそれなりに速いようですので、一度それもやっておきたいところです。

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

TINKERでUFFが使えればいいのに…とずっと考えているのですが、UFFを使って遷移金属錯体の構造最適化を行うことができるフリーソフトがありました。ArgusLabです(↓スクリーンショット)。

以前から名前は知っていましたが、トップページに「A molecular modeling, graphics, and drug design program」と書かれていて、実際ドッキングとかができるのでそういう方向性のプログラムだと思っていました。ところが、今日会社でUFFのことを調べていたら(おいおい)、Scirusの検索でArgusLabのヘルプファイルの内容がヒットして、そこにUFFが使えると書かれていてビックリ。

続きを読む "UFFを使えるフリーソフト・ArgusLab" »

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

新年早々、プログラムネタ(?)です。

FacioからTINKERを利用できますが、FFEパッケージをインストールした場合と、コマンドライン実行ファイルを単体でダウンロードした場合のどちらの実行ファイルを用いても、protein.exeとnucleic.exeからペプチドや核酸を生成することができません。前はできたような気がするんですが…
(ちなみにTINKERはver.4.2(2004.06), Facioはver.10.6.2)

それぞれの実行ファイルをFacioとは関係なく立ち上げてみても、パラメータ等の入力は正常に行うことができ、DOS窓が閉じられた後に生成しているxyzファイルを開いてみると、タイトル以外は空。
もしかして、何か足りない？

続きを読む "TINKERのprotein/nucleicで…" »

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

前々から公言していましたが、Facioの記事の準備を始めました。Gaussian, UTChem以外の環境は自前で整えられますので、自分でできる範囲の内容で取りまとめる予定です。実はWinmostarも大分メニューの内容とかが変わっていて更新しなくてはならないのですが、それはFacioの記事の後になる予定です。

▲現在の最新バージョン10.6.1。同梱のGrubbs Cat. 2Gを表示してます。

公開は12月最終週を予定しています。現在の最新バージョン10.6.1で書く予定ですので、重大なバグが無い限り、12月中に新バージョンが公開されても記事にはすぐに反映させないつもりです。いやぁ、Facioといい、Winmostarといい、フリー計算環境はここ5年ほどで劇的に進化しましたねぇ…

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

先日、GAMESSでのEFP読み込みが変という話を書きましたが、単純にマニュアルの読み込みが甘いだけという結果でした(恥ずかしい)。

前回の記事でIRON28さんに貴重な助言を頂きまして、それを参考に考えていたところ、「$EFRAG内のEFP座標指定は、最初の3行だけあればよいのではないか？」と思いつき、

$EFRAG
COORD=CART
FRAGNAME=MEOHEF
H1 0.041076 0.427531 -0.166429
O2 -0.892956 0.548707 -0.075101
C3 -1.464756 -0.615528 0.450662
$END

で実行してみたところ、あっさり計算できました。つまり、最初から3行だけしか必要ないのですから、プログラムが3行しか読まないのは道理です。そこまで来てから、「あれ、マニュアルに書いてあったっけ？」と思って読み返すと、2-140($EFRAGの最後のページ)に、

Line -3- must be given a total of three times to define this fragment's position.

書いてあるやんかーΣ(゜Д゜；

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

EFP(Effective Fragment Potential)は溶媒効果をより短時間で効果的に見積もる良い方法です。GAMESSでは任意の分子についてEFPを生成することができ(RUNTYP=MAKEFP@$CONTRL)、これを使ったエネルギー計算ができる…はずです。

が、しかし。なぜかうまくいかない。

続きを読む "GAMESSのEFP読み込みは変？" »

投稿者: s2k 日時: 00:12 | パーマリンク | コメント (4)

しばらくご無沙汰で申し訳ありません。(見てる人いるんか？)
なんとなくプライベートに余裕が無い状態が続いていまして、PCに向かわない日が何日も。やっと一心地着いて、この記事を書いております。はい。

タイトルにあるように、Winmostar絡みでRM1法を知ったわけですが、そこからの流れでOpenMOPACを知りました(情報が遅くてすみません)。現在テスト公開中のPM6が面白いですね。遷移金属のパラメータが導入され、第3から第5周期の遷移金属のほとんど(ランタニドは一部のみ)をカバーしています。まだテスト運用中ですが、いくつか計算してみたところ、得られた構造はそこそこ妥当なものが多そうです。エネルギーとかはどうかわかりませんが。そのうち計算でこんな構造になりましたよ的なものを公開したいなと思ってます。

投稿者: s2k 日時: 00:40 | パーマリンク | コメント (1)

久々の投稿、そして久々の計算化学の記事。
以前、GAMESSではMOPACのMEP計算のような計算ができないということを書きました。実は、今日CC-BBSで同じことが質問に出ていました。そこで再度挑戦したところ、なんとできてしまったわけです。
ちょっと裏技じみた(と思っているのは私だけ？)やり方ですが、こういうのを発見するのも、開発する立場ではなく使う立場の楽しみで…

続きを読む "GAMESSでMEP計算。" »

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

昨日のGAMESS MLで、Conroe(Core 2 Duo)のベンチマーク結果が流れていました。
http://classic.chem.msu.su/gran/gamess/PC%20GAMESS%20Conroe%20performance.html
私のWSとの比較は以下の通り。(数値はCPU Time，Sequential Execution．カッコ内はConroeを1とした相対値)

Test 2 (single-point semiempirical (PM3) energy plus gradient for large system (540 atoms, 2160 basis functions))
Athlon 64 X2 4400+ (2.2GHz,L2=1MB) 338.7 sec (1.78)
Core 2 Duo E6700 (2.66GHz,L2=4MB[share]) 190.1 sec (1.00)

Test 4, (single-point two-state MCQDPT2 energy with ISA energy denominators shift for small model system)
Athlon 64 X2 4400+ (2.2GHz,L2=1MB) 1258.7 sec (1.76)
Core 2 Duo E6700 (2.66GHz,L2=4MB[share]) 716.5 sec (1.00)

Athlon 64 X2がおよそ1.8倍かかる結果。クロック比が1.21ですから、凡そ1.4～1.5倍Conroeの方が高速と考えられます。もしXeon5160で4並列やったらどんだけ速いことやら…

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

分子内でも、何とか純粋なS-O相互作用の寄与がどれほどかを推定する手段が無いものでしょうか。Royらは、ホモデスミック反応やオルト-パラ法でSeとO及びSの相互作用の計算を行っています(JPC.A, 2006, 110, 5942-5947.)。このアプローチもありですが、完全にSe-X相互作用のみを切り出すことはできません。

実際問題、通常のエネルギー比較法ではS-O相互作用を純粋に切り出すのは不可能だと思いますが、それなりに見れそうな例として、チオフェン-2-カルバルデヒドの配座間エネルギー差を考えてみました。

続きを読む "続々・S-O相互作用の計算に必要なモデル化学とは。" »

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