http://blog.3016.net/ s2kの雑考記録。でも少し計算化学備忘録風味。 ja Copyright 2008 Fri, 27 Jun 2008 01:40:47 +0900 http://www.sixapart.com/movabletype/?v=3.2-ja-2 http://blogs.law.harvard.edu/tech/rss 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を動かした話を追記しました。]]> http://blog.3016.net/2008/06/fedora_9_x64gamess_1.html http://blog.3016.net/2008/06/fedora_9_x64gamess_1.html Chemistry Fri, 27 Jun 2008 01:40:47 +0900 備忘録。 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が便利です。 http://blog.3016.net/2008/06/jobvechess.html http://blog.3016.net/2008/06/jobvechess.html Chemistry Mon, 02 Jun 2008 21:48:29 +0900 何かMacっぽい？ キーボードは英字onlyですが、僕は英字キーボード使いなので無問題。ていうかむしろ歓迎。液晶の解像度も高く(目が悪くなってきた自分にはちと厳しいか？)、作業領域が広く確保されているところは好印象。 問題はCPUの処理能力と筐体の排熱能力で、あちこちのレビューを見る感じ、Vistaでは若干のもたつきを感じ、またCPU使用率が高いときの筐体の発熱とファンの騒音が結構なものになるようです。やはり、この辺のサイズと価格で、いろいろと犠牲になっている感は否めません(というかしょうがない)。液晶のバックライトもLEDではなく蛍光管のようですし。 個人的には、10万を超えない領域でもうちょっと問題点が解決されたら(特にYoutubeの再生でCPU使用率が100%に到達してしまう処理能力)買いなんですが…同じVIAのプラットフォームならIsaiah待ちということになるのかもしれませんが、Isaiahになってピーク発熱は上がりそうな感じなので、その辺をどうできるか。。。 まぁ、何にせよ、今は買うつもりはありません。むしろEee PC 900の方が…うっかり買ってしまいそうでやばい。 ]]> http://blog.3016.net/2008/05/hp_2133ram_disk.html http://blog.3016.net/2008/05/hp_2133ram_disk.html Web Sun, 25 May 2008 17:18:54 +0900 特別レポートが掲載されていました。 曰く、 「32bit Windowsの管理外領域メモリでRAMディスクが作れる」 何ッ！そいつぁやるっきゃねぇ！ というわけで、PAEを有効にした後以前相性問題で丸ごとあまったメモリ2本(2GBx2)をメインPCに装着(総計8GB！)し、Gavotte RamdiskでRAMディスクを作成してみたところ、 できとる！ ちなみに、ちゃんと通常の物理メモリも認識しとります。 でも、何に使おう…いや、GAMESSのスクラッチ領域として使ってみるのが真の漢だ！というわけで、ベンゼンのRHF/aug-cc-pVDZでの1点計算をconventional SCFで実行してみました。2電子積分をスクラッチファイルに記録するので、File I/Oが激しく発生します。

	CPU	Wall
HDD (SATA, 500GB, 7200rpm)	44.1	101.9
HDD (RAID0, SATA, 300GB, 7200rpm)	38.5	74.0
RAM Disk (DDR2-800, 4.74GB)	41.0	42.7

見ての通り、RAMディスクではCPUとWallの時間差(≒File I/O待ち時間)が2秒足らず！通常のHDDでは1分近くかかるところですんで、まさに既報のベンチマーク結果に違わぬ爆速ぶり！ しかし…容量が5GB弱じゃぁ、ちょっと大きい計算やったらすぐオーバーフローしちゃう…(aug-cc-pVTZはアウトでした)。やっぱ使い道が難しい…IEのテンポラリフォルダぐらいかな。]]> http://blog.3016.net/2008/05/ram_disk.html http://blog.3016.net/2008/05/ram_disk.html PC Mon, 12 May 2008 23:08:43 +0900 ※いずれも閉殻。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数を増やせばいいってもんでもないのが面白いところ。ノード数が増えれば話は別ですが。]]> http://blog.3016.net/2008/05/gamess_20080411r1.html http://blog.3016.net/2008/05/gamess_20080411r1.html Chemistry Tue, 06 May 2008 19:05:15 +0900 GAMESS(US)
08/04/11(R1)PC GAMESS
7.1.5Test 1
CartSteps3976Time41.6(32.9)74.0(75.7)Test 2
DLCSteps4140Time43.2(33.8)40.5(41.4) ※TimeはWall(CPU) と、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つのダイの張り合わせなのでダイ間の通信が遅くなりますが、その辺を少しでも回避しようという意味合いでしょうか？]]> http://blog.3016.net/2008/05/post_52.html http://blog.3016.net/2008/05/post_52.html Chemistry Sat, 03 May 2008 11:49:18 +0900 まだ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 定格)で実施しました。 http://blog.3016.net/2008/05/gamess_20080411r1_1.html http://blog.3016.net/2008/05/gamess_20080411r1_1.html Chemistry Fri, 02 May 2008 13:45:54 +0900 さすがに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のは取り付けに手数が若干かかるものの、バックプレートを使った安心仕様だったのですが…次買うときはプッシュピン型はできれば避けたい。。。]]> http://blog.3016.net/2008/04/q9300_1.html http://blog.3016.net/2008/04/q9300_1.html PC Wed, 30 Apr 2008 09:26:05 +0900 2008年は1回も更新してません。コンテンツ作る暇がないんです。計算は時々やっていて、Sn2の一歩進んだ内容や、Monsanto Processのエネルギープロファイルなど、ある程度まとまったものもあります。この連休中にどこまでできるか… ただ、64bitWSは別件で埋まっているので、それが終われば進捗があるかもしれません。 ]]> http://blog.3016.net/2008/04/pc_4.html http://blog.3016.net/2008/04/pc_4.html 雑記 Sat, 26 Apr 2008 11:02:42 +0900 備忘録です。 問題になった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での計算になります。 http://blog.3016.net/2008/04/gamessdd.html http://blog.3016.net/2008/04/gamessdd.html Chemistry Sat, 19 Apr 2008 23:01:12 +0900 バリバリ4コアでPC GAMESSを走らせております。時間の掛かる振動計算を実施中。しかも3.00GHz→3.66GHzにOC(333x11)しての運用です。FSBと電圧をいじらずに安定運用可能な限界がここら辺でした。長時間の計算を実施しないのであれば3.83GHzまでは問題なくいけます。x12の4.00GHzはOSが立ち上がらず(コア電圧を1.33Vまで昇圧すればいけます)。 CoreTempの値が…上のSSでは見えないですね。室温20℃でピーク58℃という感じです。真夏(室温30℃)にこれをやったら70℃行っちゃう…夏は定格ですね。]]> http://blog.3016.net/2008/04/64bitws.html http://blog.3016.net/2008/04/64bitws.html PC Mon, 14 Apr 2008 22:38:50 +0900 喜び勇んで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追記]) http://blog.3016.net/2008/03/pc_3.html http://blog.3016.net/2008/03/pc_3.html PC Sun, 30 Mar 2008 20:14:52 +0900 ケースはCooler MasterのCOSMOS。E-ATXのマザーにも対応する、作業性の良い大型ケースです。音と冷却のバランスも良いのでは。中のパーツは以下の通り。 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倍越えも出来そうな感じです。 ]]> http://blog.3016.net/2008/03/64bit.html http://blog.3016.net/2008/03/64bit.html PC Fri, 28 Mar 2008 23:19:03 +0900 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)。 ]]> http://blog.3016.net/2008/03/wingamess_1.html http://blog.3016.net/2008/03/wingamess_1.html Chemistry Fri, 28 Mar 2008 18:28:50 +0900 備忘録。 最近、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を使うと構造の収束に時間が掛かることが多いです。非常にリジッドな分子ではその差が縮まってきます。(一般論かどうかはわかりませんが…私の経験上では) http://blog.3016.net/2008/03/post_50.html http://blog.3016.net/2008/03/post_50.html Chemistry Sun, 09 Mar 2008 21:40:09 +0900