お仕事

2019年06月03日

Gaussian覚書(2)


 個人の備忘録として。
(1)分子の慣性主軸
Gaussianでは入力座標(input orientation)を適宜対称性を考慮したstandard orientationに変換しているが、必ずしも分子の慣性主軸と等しくならない。慣性主軸に沿った量にしないと不都合のあるもの(dipole derivativeなど)を計算したい場合は、予め構造最適化を済ませた後に座標を(自前のプログラムで)慣性主軸系に移しておき、standard orientationに変換しないよう
# P freq ...... nosymm
としておく。

(2)fchkのdipole derivativeとinfrared intensities
チェックポイントファイルからformchkコマンドで生成されるfchkファイルは種々の数値を含んでいて、標準出力に出てこない有益な情報が得られる。dipole derivativeもその一つで、基準振動の遷移モーメントの成分の計算が自力でできる。
単位:(∂µ/∂x)で[e][Bohr]/[Bohr]=[e]であり、Debye Å-1にするには4.8033をかければよい
配列:入力直交座標系(X,Y,Z)で
∂µ(X)/∂x1,∂µ(Y)/∂x1,∂µ(Z)/∂x1,∂µ(X)/∂y1,∂µ(Y)/∂y1,∂µ(Z)/∂y1,∂µ(X)/∂z1,∂µ(Y)/∂z1,∂µ(Z)/∂z1,…

mass-weighted cartesianで表したHessianを対角化する直交行列Cを用いると、基準振動kに対するdipole derivativeは
∂µ(X)/∂Qk=∑1/√(m(l))×(∂µ(X)/∂Xl)×Clk
このdipole derivative(単位はDebye Å-1amu-1/2)から赤外強度Ak(単位はkm mol-1)を求めるには
Ak=[(∂µ(X)/∂Qk)2+(∂µ(Y)/∂Qk)2+(∂µ(Z)/∂Qk)2]×42.25
この式はdouble harmonic近似の場合に成立するので、振動の非調和性・双極子モーメント関数の高次項を考慮する場合は別途数値積分が必要になる。



tsukimaru123 at 12:30|PermalinkComments(0)

2018年09月20日

九州出張 with ラーメン 2018


 学会参加のため、福岡に4日間滞在した。学会にフル参加するのは久しぶり。初日に関係するセッションの口頭発表があり、最終日に自分のポスターがあるので、中2日は余裕がありあちこち寄り道をした。この話は別エントリーで書くことにする。

 以前の出張の際と同様、博多ラーメンを滞在中できるだけ食することにした。北水海道のとん太を除くと、茨城県南には本格的な豚骨ラーメンを供する店が無いためだ。以下、そのリストと寸評。

(1)初日夜 金田屋
ホテルから歩いて10分ほど。チャーシュー麺をバリカタで所望。スープの濃さは文句なし。博多ラーメンにしては立派なチャーシューだったが、塩っぱいのが残念。
IMG_20180910_182021

(2)二日昼 博多ラーメンはかたや西新店
西南学院大学のご近所。チャーシュー麺をバリカタで注文。こちらのスープはサラサラ系だが、豚骨風味は十分出ていて美味。値段も安く、予想外の収穫だった。昼食時サラリーマンで混んでいたのも頷ける。
IMG_20180911_121628

(3)二日夜  元祖長浜ラーメン
ホテルから歩いて15分程度の商店街の中にある。ラーメンをバリカタで注文。店員さんが皆外国人だったのにいささか驚く。サラサラ系スープだが、今ひとつコクがないと感じた。有名店だけに少し残念。
IMG_20180911_182022

(4)四日夜  博多 一幸舎
最終日、帰路の福岡空港で夕食に味玉ラーメンをバリカタで注文。スープの濃さ・具材の味ともに申し分なし。福岡出張のシメに相応しい美味しさだった。
IMG_20180913_170754



tsukimaru123 at 12:06|PermalinkComments(0)

2017年08月31日

Ryzen7を試す


 マルチスレッド性能が高いと巷で評判のAMD Ryzen。安くて速い量子化学計算用のマシンが手に入ればこちらとしては大歓迎、という訳で今年度の予算で一台買ってみた1)。いつものSystemWorksから下記のスペックのPCを調達。
・CPU:Ryzen7 1700X(3.4GHz,8cores)
・M/B:ASUS B350-MA
・memory:8GB(4GBX2)
・HDD:1TB
P_20170901_091531

意外とこぶりな筐体だが、電源は650Wと余裕がある。1700XのTDPは95Wなので、i7に比して神経質になる必要はなかろう。
ベンダーが保証するLinuxディストリはUbuntuのみだったが、g09 ifcバイナリが走る条件を調べた結果以下のようになった。

・Ubuntu 17.04(kernel 4.10):正常インストール。g09バイナリはL1.exeでifortのSIGSEGVで死ぬ。
・CentOS 7.3(3.10):同上。
・OPEN SUSE Leap 42.3(4.4.76):正常インストール。g09バイナリ正常動作。

カーネルの新旧がg09のバイナリの正常動作を決めているのではないことがわかる。早速、OPEN SUSE上でtest397を走らせてNprocsharedに対する依存性を調べた結果が下図。
17083101

比較のため、AMDのFX-8370、Skylake(6700K)、12コアXeon(E5-2680V3)のスコアを載せている。縦軸がCPU時間、横軸がNprocsharedである。全て同じg09バイナリを走らせているが、OSはOPEN SUSEのバージョンが以下のように異なっている。
 FX-8370:12.1 (kernel 3.1.0-1.2)
 6700K, E5-2680V3:Leap 42.1 (4.1.39-56)
シングルコアのスコアを見ると、Ryzen7(1700X)はSkylakeより2割ほど遅く、ほぼクロック数2)の比になっている。一方、同じ4GHzではあるがFX-8370に対しては3割以上速くなっており、BulldozerからZenアーキテクチャへの進化が大きいことに驚く(同クロックでは6割増し)。一方、コア数に対する依存性を見ると、N=4まではSkylakeよりも並列化効率が高くXeonをも上回るスコアだが、N=4→8では伸びが2割以下と極端に効率が低下する。XeonがN=4→8で7割以上の伸びを示し、Ryzen7のスコアを上回るのとは対照的なふるまいである。マルチスレッド性能が高い、と宣伝されているRyzen7にしては、意外な結果になった。
 当初、カーネルがRyzenの性能を引き出すのに十分ではなかったのでは?と思っていたが、カーネルのバージョンアップ(4.4.76→4.13.0)を行ってもスコアが変化しなかったので、これがRyzen7の実力と考えざるを得ない。もちろん、現在のままでも十分速い(そして安い)のだが、出来うればより速くしたいと思うもの。その原因と対策については、今後検討する予定である。


1) 税抜きで15万程。昨年度の論文数に応じて配分される「インセンティブ予算」で購入した。お金持ちのラボにとっては微々たる額だろうが、大助かりであるしモチベーションアップにもなる。
2) 最近のCPUは負荷がかかるとブースト周波数に変わるので、大雑把な表現である。
続きを読む

tsukimaru123 at 17:30|PermalinkComments(0)

2016年07月27日

12コアXeon登場


 所内で共同研究を立ち上げることになり、私はDFT計算を受け持つことになった。予算が60万円ほどついたので、今まで使用していた計算機よりも速いものを購入しようと、表記の1CPUマシンをSystem Worksより購入。ここは以前Core i7マシンを買ったことがあり、信頼がおけるので選択した。スペックは
・Xeon E5-2680v3(12core)、Haswellアーキテクチャ 1)
・DDR4 ECCメモリ128GB 2)
・SSD+HDD2TB
といったもので、これが60万弱で買えるとは凄い時代になったものだ。
P_20160722_144347[1]

早速Open SUSE Leap42.1をインストールし、g09バイナリもセットアップ。正味半日ほどで使える状態になった。

早速test397を流して、計算時間のNprocshared依存性を測定。計算中topコマンドで見ると、12コアの稼働が確認できた。
capture

従来のPCと比べた結果が下図である。低クロックながら、N=4でSkylake(Core i7-6700K)と同等、N=12でSkylakeの倍以上の速度を示すことが分かる。 3)
test397

Hyper-Threadingの効果を見るべくNprocshared=24まで試したが、12コアの場合より速度が低下することが分かった。大昔のPentium4以来、HTには効果がないのを確認できた。それにしても、何のためについているのだろうか・・>HT

 今まで最速だったSkylakeマシンは夜中にハングしてることが多く、例のバグのせいかと危惧しているが、このXeonマシンにはその心配もない。スリープ復帰時の画面の乱れも皆無だし、負荷がかかった時のファンも水冷システムゆえ物静かである。UPSを付け足して、がんがん回してやろうと思う。


1) 発注時にはBroadwellアーキのXeonも選択可能だったが、見積もり請求時のスペックそのまま。
2) デフォルト8GBだったのを32GBに変更したのだが、何がどうなったのか4倍容量になっていた。
3) DFTなのでコア数に対するリニアリティが高い。



tsukimaru123 at 13:17|PermalinkComments(0)TrackBack(0)

2016年06月02日

ガスバーナーの使えない化学系研究所の謎


 A研では他の独法と同じく、年々運営交付金が減っている。その余波で、なるべく使わないものは削ろうと過去数年インフラを縮小してきた。その中には、別棟そのものを壊して更地にしたり、壊さないまでも閉鎖して電気の供給を停止したり、酸素・窒素などの集中配管を取り外したりという項目のほか、都市ガスの配管撤去・供給停止まで含まれていた。化学系研究所としてはガラス細工のために都市ガスを残すのが当然なのだが、今後はボンベで対応するか外注で済ませてくれと言う。他方、事業所当たりの高圧ガス保有数は法的上限があるため、ボンベ購入は手続きが面倒なのだ。ちょっとした装置やサンプル管の変更も、時間を要するようになった。

 かくして、私はガラス細工をしなくなって久しかったのだが、ここ数ヶ月その必要性に迫られてきた。試しに、卓上用簡易トーチ1)を買ってみたが、酸素があっという間になくなってしまった。私の実験室には酸素の配管が来ていないので、仕方なく一番小さいボンベを発注した。燃料のガスはまだ残っているが、今後は高圧ガス保安法の適用除外で安価なカセットボンベ2)のブタンを使うことにした。そのままでは使いにくいので、市販のバーナーを分解してアタッチメントをつくり、簡易トーチに接続する事にした。
P_20160602_171342

酸素もボンベから空容器に繋ぐ部分を自作して対処する事にした。
P_20160602_171353

これで、とりあえずガラス細工をする最低限の道具立てが出来た事になる。一体、この研究所は何を考えているのだろうか・・と思うことしきりである。

1) 富士バーナーのO2トーチで、元々銀ロウ付けなどに用いるため小さい。
2) 一本当たり100円以下で、何処でも入手可能というのが大きい。


tsukimaru123 at 21:30|PermalinkComments(0)TrackBack(0)

2016年04月20日

GAMESSの謎


 量子化学計算で分子の非調和振動数を計算する仕事が最近普通に成りつつある。GAUSSIANで実装されている2次摂動論以外に、GAMESSではVSCF法を実装している。どちらがより妥当な結果を出すか比較を始めたが、GAMESSのバージョン間の微妙な差が頭を悩ますようになった。ここでは、それを備忘録として書いておく。

 現在のソースビルドのバージョンは2014年版だが、 WinGAMESSの32bitバイナリは2011版のままである。一方、64bitバイナリは2014版になっており、同じWinGAMESSながらオプションの立て方などが以下のように異なるのだ。

(1)Hessianの計算法
 2011年まではDFTにおけるHessian(力の定数行列)の計算は一次の数値微分が必要(半数値法)で、デフォルトオプションは
"$FORCE METHOD=SEMINUM"
だったが、2014年から解析的微分も利用可能になったようだ。そこで、デフォルトでオプションは
"$FORCE METHOD=ANALYTIC"
となった。しかし、制限付きであり、場合によっては「半数値法」を使用しろというメッセージを出して計算が中断する。その場合は
"$FORCE METHOD=SEMINUM"
と明示的に指定する必要がある。どのような場合にエラーが出るのか、INPUT.DOCを見ただけでは判断不可能である。

(2)B3LYPの実装
 化学で最もポピュラーな汎関数B3LYPだが、GAMESSとGAUSSIANでは、以下のように中身が微妙に異なっている。

GAUSSIAN:非局所相関としてLYP表式,局所近似としてVWN汎関数III
GAMESS:非局所相関としてLYP表式,局所近似としてVWN汎関数V(2011年)

従って、整合性のある計算結果を得ようとしたら、GAMESSで
”DFTTYP=B3LYP”
はご法度である。問題は、2011年と2014年でオプションが変更されており、それがINPUT.DOCに反映されていない事である。
2011年版ではGAUSSIANと互換性があるのは
"DFTTYP=B3LYP1"
である。しかし、2014年版でOPTIMIZEの際にこの指定をすると

"GRID DFT PROGRAM CAN'T DO UNSUPPORTED DFTTYP=B3LYP1"

とエラー表示され、計算が中断する。にもかかわらず、TD-DFTではB3LYP1がいまだ使用可能である。
・・(ー_ー#)
代わりのオプションとして2014年のINPUT.DOCを参照すると
B3LYPV3:use VWN3 in place of B3LYP's VWN5
と記述があり、
"DFTTYP=B3LYPV3"
が正しいかと思いきや、実際に計算結果を見るともう一つのオプション
"DFTTYP=B3LYPV1R"
が正解である事がわかった。最初は我が目を疑った。
・・(ー_ー#)(ー_ー#)

 はっきり言って「混乱のきわみ」である。これでは、とても普通の実験屋がツールとして安心して用いる事は出来ない。フロントエンドの定番だったWinmostarがライセンス変更でアカデミックフリーでなくなり、Facioも何故か使いにくいままの現状では、多くのリソースを費やす意味はない。


tsukimaru123 at 00:27|PermalinkComments(0)TrackBack(0)

2016年04月08日

悪質査読者を打ち返せ


 1月に某誌に論文を投稿したところ、二人の査読者の意見が割れてエディター判断でリジェクトになった。評価の悪いレフェリーは具体的な指摘も無く、自分の思い込みをただ書き連ねたレビューだったが、エディターが鵜呑みにしたらしい。今後、このようなエディターからの査読依頼は一切受け付けないことにし、当該アドレスからのメールは全てスパム指定した。

 2月に別誌に同論文を投稿。英語にけちがつけられないよう、事前に英文校閲に出しcertificateももらっていた。今度は大丈夫だろうと思ったが、一月後に戻ってきたレビューに驚いた。3人のうち2人は好意的で、具体的な指摘に溢れていたが、一人のレビューはたった一文で
"I am sorry to say that this is a really poor work, badly written and presented. I do not recommend
it for a publication in ****[雑誌名].
"

という取り付く島の無いものだった。そもそも、これが査読結果と云えるのか。単なる感想文以下、言いがかりではないか。具体的で科学的・技術的な指摘は皆無。英文校閲に出した原稿を「酷い書き方」とは・・これまで言いがかりをつけられた例について書いた事があったが、あの時よりも酷い。怒りのあまり眩暈と吐き気がしたほどだ。エディターと残りの2人の査読者がまともでよかった。

 とはいえ、このまま通常の対応をしても腹の虫が収まらない。多くの場合、レフェリーは同業者であり、数十年に渡ってinteractionを持つこともあるので、喧嘩をしないのが基本である。しかし、今回のような案件を看過すると、次回査読者になった際も同じような対応をしてくるような人間だろう。single-blind review systemでは、身元がわからない事をいい事に、酷いコメントを送りつける低劣な人間もいるのだ。また、それをコントロールできないエディターも。そこで、以下のような対応を取った。

(1)雑誌のGuide for reviwersに反した行為かどうか検証
(2)"The Committee on Publication Ethics"の"Ethical Guidelines for Peer Reviewers"に反した行為か検証

(1)については、電子投稿システム上での確認が出来なかった。そもそも、常識的なことを書く必要はないからかもしれない。一方、(2)については丁度合う記述を見つける事が出来た。
"Peer reviewers should be objective and constructive in their reviews, refraining from being hostile or inflammatory and from making libelous or derogatory personal comments"
この事を踏まえ、以下のようなrebuttalを書いて送った。

" First of all, the author would like to point out that the comment from the reviewer#1 is NOT compliant to "COPE Ethical Guidelines for Peer Reviewers" (http://publicationethics.org/resources/guidelines) announced by The Committee on Publication Ethics, where the ****[出版社名] company participates. It says that "Peer reviewers should be objective and constructive in their reviews, refraining from being hostile or inflammatory and from making libelous or derogatory personal comments". On the contrary, the comment does not include any scientific, technical point of view. Furthermore, the author must stress that the expression in the comment is not appropriate. The manuscript has been subjected to a professional proof-reading consultant prior to the first submission, and been given with a certificate for its English writing quality.
These points are problematic enough to raise the concern if the comment of the reviewer#1 is harassment in the name of referee's comment, by abusing the single-blind review system. If so, the author would request the **** company to improve this situation as soon as possible."


適切な対応をしないと、出版倫理問題で出版社に対応を要請する、と言うことだ。残り2人のレビューには最大限の謝辞とともに対応した改訂を施し原稿を送ったところ、その日のうちにアクセプト通知が来た。当該査読者の身元はわからないままだが、今後同じような対応はしにくくなるだろう。
「やられたら、黙っていないでやり返せ、但し紳士的に」
をモットーに、今後も粛々と対応して行きたい。


tsukimaru123 at 12:05|PermalinkComments(1)

2016年03月30日

学会出張 in 奈良


 春の学会は同志社大京田辺キャンパスで行われた。京都と奈良の中間に位置し、付近に宿泊施設が無い山の中である。京都は近年増加中の観光客であふれ、宿が取れなかったので、奈良に投宿する事にした。JR奈良駅から会場までは一時間弱である。せっかく奈良に泊まるのだからと、あちこち見て回った。中三の修学旅行以来だから、36年ぶりの奈良観光である。
(0)ホテル
 JR奈良駅から徒歩20分ほどのリガーレ春日野。駅から遠く、周りにコンビニなどがないので不便では有るが、静かで落ち着いた雰囲気であった。部屋も綺麗で十分広い。朝食は湯豆腐+和洋バイキングと豪華。東大寺転害門まで徒歩15分程で行ける。
IMG_20160324_160119510
(1)東大寺
 云わずと知れた観光地で、外国人が非常に多かった(主に中国・韓国人団体)。鹿が観光客に大人気で、一緒にセルフィーに納める人多数。
 巨大な大仏殿には圧倒される。
IMG_20160325_083123478
IMG_20160324_170936822
IMG_20160325_08493557
IMG_20160325_085500915
IMG_20160325_090141768
IMG_20160325_093914988

(2)興福寺
 ここも外国人観光客多数。有名な五重塔・三重塔以外に、天竜八部衆像を収めた国宝館が見物だった。
IMG_20160325_105221109
IMG_20160325_101105269
IMG_20160325_101138236
IMG_20160325_11003337

(3)古墳群
 ホテルから西に30分ほど歩くと、佐紀盾列古墳群という大型の前方後円墳群に着く。
IMG_20160326_093410863
IMG_20160326_094529540
IMG_20160326_095249979

(4)平城京
 古墳群の南西に平城京跡がある。
IMG_20160326_102139675
IMG_20160326_103027715
IMG_20160326_103501203

(5)薬師寺
 平城京から近鉄西大寺駅に向かい、樫原線で二駅乗ると薬師寺に着く。丁度お稚児さんの格好をした子供たちの厄払いをやっていたようで、華やかな雰囲気だった。あちこち見て回ると別料金を取られまくるので、早々に退散。
IMG_20160326_125153425
IMG_20160326_130030177
IMG_20160326_130228675



tsukimaru123 at 12:36|PermalinkComments(0)TrackBack(0)

2016年02月05日

Skylakeがやって来た


 9年来動いていたQX6700マシンが死亡した。オンボードSATAの故障らしく、Linuxの再インストールをしても起動に異様に時間がかかるようになった。最近では重いジョブを投げず使用頻度が減っていたが、ある程度の数の計算機は確保しておく必要がある。そこで、FX-8120以来のPC購入を行った。パソコン工房のSkylake(Core i7 6700-K)搭載マシンを交付金で購入。11万円程だった。

 届いて早々Linuxのインストールを始めたが、Linuxとの相性が悪いらしく、CentOS7はインストール完了するもGUI起動せず。OPEN SUSE 13.2はインストーラがハングして先に進めなかった。OPEN SUSE Leap 42.1は正常にインストール終了し起動もできたが、スリープからの復帰時マウスの動きで画面が上下移動するというトラブルが発生1)。どうせsshでログインしジョブを放り込んではftpで取り出すだけなので、無視する事にした。

 以前コンパイルしたGaussian09(A2)のifcバイナリで、test397のベンチマークを行った結果が下図である。縦軸はCPU時間(s)で、低いほど速い。
scores for test397

気が着く事:
(1)Nproc=1のスコアでは、Core i7 965やFX-8120の倍程度の速度である。
(2)CPU数を増やしても、あまりスコアは改善されない(Nproc=4で2.2倍程度)。
コア当たりの性能は十分高いが、並列化効率のリニアリティが低いという印象である。とはいえ、十分に速い。

後、気がかりなのは、高負荷の条件でハングするマイクロコードのバグがあるという事だ。発生条件が一定しないので、Gaussianで出るか確証も無い。とりあえず、マザーボードのBIOSを小まめに更新する事にしよう。

1)CentOSインストール時のトラブルといい、どうもオンボードビデオのドライバに問題がありそう。BIOSでオンボードVGAを殺して、枯れたビデオボードを挿せばよいのかもしれない。


tsukimaru123 at 18:07|PermalinkComments(0)TrackBack(0)

2013年02月19日

Gaussian覚書


 量子化学計算ソフトGaussianで振動計算をすると、自動的に各基準振動の波数などを出力してくれるので、中で何が行われているのか知らずに使えてしまう。GaussView(GV)等のフロントエンドでジョブを投入し、出力もGVで行っているとアニメーションで可視化までしてくれるので、ブラックボックス化の傾向は更に顕著になる。下手をすると、完全に「マウスをクリックするだけの猿」と化してしまうのだ。いくら実験屋とはいえ、何も知らずに道具を使うのは憚られるものだ。そこで、いくつか気が付いたことを備忘録の形で書き留めて置こう。

(1)Gaussianは計算過程をCheckpoint fileというバイナリファイルに書き込んでいる。この中にはcartesianでのHessian(力の定数行列)などの情報がパンチされており、formchkコマンドでASCIIファイルに落とすことができる。
cartesianでのHessianは振動計算の際Iop(7/33=1)を指定すると標準出力にパンチされる。

(2)上記のHessianと分子の原子質量から基準振動数を以下のように求めることが出来る。

・cartesianでのHessian→mass-weighted cartesianでのHessian→対角化**
・ωk=√λk
λkはk番目の固有値である。
λkを原子単位で表すと、(Hartree)(a.m.u)-1(Bohr)-2であり、上式からcm-1での基準振動数にするには換算係数として5140.5をかけると良い。

一度やり方を憶えると、mass-weighted cartesian→基準座標の直交変換行列(行列)を用い、Coriolis定数やRaman散乱で重要な∂α/∂Qkなどを自分で計算できるようになる。

(3)Gaussianの振動計算の出力の最後にこんな部分がある。(H2OのRHF/6-31Gレベルの場合)
------------------------------------------------------------------------------------
GradGradGradGradGradGradGradGradGradGradGradGradGradGradGradGradGradGrad

1|1|UNPC-E1400BBQ|Freq|RHF|6-31G|H2O1|FITO|18-Feb-2013|0||#N Geom=AllC
heck Guess=TCheck SCRF=Check GenChk RHF/6-31G Freq||H2O test||0,1|O,-0
.0188774341,-0.0244713386,0.|H,0.9290620083,-0.0810959382,0.|H,-0.3143
476107,0.8780212779,0.||Version=IA32W-G09RevA.02|State=1-A'|HF=-75.985
3592|RMSD=3.326e-010|RMSF=1.696e-006|ZeroPoint=0.0224877|Thermal=0.025
3221|Dipole=0.6008698,0.778974,0.|DipoleDeriv=-0.5105623,0.0508084,0.,
------------------------------------------------------------------------------------
ここに書かれている”Dipole Deriv”を見て、GVは基準振動の可視化の際に遷移モーメントを矢印表示している。ちなみに、このDipole Derivativeはinput orientationかつ原子単位で表示されている(Checkpoint fileにもパンチ)。上記のIop(7/33=1)をつけると、標準出力中にStandard orientationでパンチされるようになる。

(4)Standard orientationは必ずしも分子の重心系・慣性主軸系と一致しないので、目視で確認することが必要。

**厳密には、並進・回転の自由度を取り除いた後に対角化するが、値自体は殆ど変わらない。GAMESSの振動計算でも同様な処理を”PURIFY=.t."で行えるが、やはり結果に差が出ない。


tsukimaru123 at 17:42|PermalinkComments(0)TrackBack(0)

2012年05月28日

英語論文の悩み


 英語で論文を書くようになってから四半世紀。昔よりはましになったが、いまだに査読者から「英語をnativeに見てもらえ」と指摘される身である。

A. 参考書など
 マーク・ピーターセンの「日本人の英語」を読んだりした時期もあったが、今の所論文書きで使っているものは下記のものだけである。

(1)「理系のための論文執筆ガイド」(ブルーバックス)
  買った当初は辞書代わりに使っていたが、日本語から逐語訳で英語を書いているわけではないので、余り役に立たなくなった。最近は本棚の肥やしとなりつつある。
(2)英英辞典(OXFORD MODERN ENGLISH DICTIONARY)
(3)英和辞典(研究社リーダーズ電子ブックをDDWinで運用)
(4)オンライン検索
  これが一番使い勝手が良い。
(5)生の英語の論文
  定型句・気になった表現を拾い上げたりしている。コピペするとplagiarismに問われるので、注意が必要である。

B. 書き進め方
 私の論文の書き方は、

  まずデータをまとめて図表にする。参考文献ピックアップ ⇒ 日本語で粗筋を書く ⇒ 英語書き

といった感じである。学会発表の際、図表を見ながら説明するように心がけているので、それを論文にも応用した形である。英語の口頭発表でも原稿を作って予め暗記したりしないので、論文も自然な流れで文章を書くようにしている。Wordで書いて、スペルチェッカをかけてtrivialな間違いは訂正するが、校正は印刷して目で追う方が自分に合っていると思う。適宜図表や参考文献を追加・修正し、番号付けをしていく。

 自分でも意外だが、論文を書いている最中に結論を徐々に煮詰めていくことが最近多くなった。昔は実験結果の記述に重きを置いていたので、上司に「論文と研究報告は違う」と指摘されたこともあったので、スタイルに変化が生じたのだろう。某先生に「推理小説を読むように読めるのが良い論文。結論は、読者への種明かしに相当するので、要旨と同じ事を書いてはいけない」と教えられ、そんな論文が書ければよいなぁと思いつつ日々格闘している。

 論文では、冠詞の使い方が頭痛の種である。ネイティブであるカナダ人に以前proofreadingを頼んだとき「冠詞は感覚だ。」と言っていたので、とにかく場数を踏んで慣れるしかないらしい。OJTというやつである。英語の論文は総数で60になったが、いつになったら「十分な場数」になるのやら・・日暮れて道遠しの感が強い。


tsukimaru123 at 16:32|PermalinkComments(0)TrackBack(0)

2012年05月16日

WinGAMESSとFireflyの比較


 先日インストールしたWinGAMESSだが、予想以上にFireflyとの速度差が大きいので驚愕した。自宅のAthlon64X2 +5000で実行したいくつかのベンチマークの結果を下に示す(NCPU=1)。

・(CH3I)3 MP2/general basis setでのエネルギー計算(C1)
Firefly:451s
WinGAMESS:635s

・CH3I MP2/general basis setでの構造最適化(C3v)
Firefly:11s
WinGAMESS:94s

・C6H6 B3LYP/6-311Gでの構造最適化(D6h)
Firefly:23s
WinGAMESS:85s

エネルギー一点計算より構造最適化で差が大きく出たのは、gradientの計算アルゴリズムに差があるためだろうか。いずれにしろ、数倍の速度差が出てしまうと大きな規模の計算にWinGAMESSは使えない。
ちなみに、こちらのサイトを見ると、更に大きな速度差がつくものがある様子(バージョン、コンパイラに依存するが)。


tsukimaru123 at 23:29|PermalinkComments(0)TrackBack(0)

2012年05月15日

英語・英語・英語・・


 某誌に3/30に投稿した論文の査読結果が先日返ってきた。珍しく二人のレフェリーの意見が載っており、二人とも”改訂後に受理可能”とのことで一安心である。とはいえ、改訂は相変わらず胃が重たくなる作業だ。文章の変更・参考文献の追加・図表の改訂、全てcoherentに行わなければならない。

 今回はそれに加え、「英語に磨きをかけろ」との助言を頂いた。毎日英語の論文を読み、英語でメールを書いていても、相も変わらず英語ができない。単純なスペルチェッカーならWordの機能でできるが、韜晦な言い回しを簡潔に言い直すなどは不可能だ。かくして、今回は専門の会社にproof readingに出すことにした。5500words程度で3〜4万円なので、十分だろう。

 それと同時に、英文校正ソフトを調べてみた。今の所Windows版で評価が高いのは
・Writer's Workbench
・Style Writer
辺りらしい。試用版が落とせる後者を早速使ってみた。改訂した原稿を食わせて、スコアを出してみたのが下図である。
Image1
文章の分類で、"Academic"+"special"を選ばないと、専門用語・略語が多すぎてBog Indexが"poor"になるので注意。この設定をするととりあえず"average"に落ち着くが、Style Indexが"poor"の評価であった。さて、どうやってスタイルの改善をして行こうか・・


tsukimaru123 at 12:30|PermalinkComments(0)TrackBack(0)

2012年03月21日

More on Firefly


この前に引き続き、Fireflyに関する備忘録をば。OSはWinXP32bit(SP3)である。

(1)MP2一点計算の並列化効率
以前DELL Precision 390(QX6700)でGaussian03のMP2一点計算を行った、並列化効率はN=2で頭打ちになった。今回はFireflyをCore2Quad Q6600に換装したPrecision 390で走らせ、比べてみたのが下の結果である。
 ”MW=16"(128MB)の際のMP2一点計算
 ----------------------------
 NCPU CPUtime(s)
 ----------------------------
  1    283
  2    156
  4     82
 ----------------------------
 Fireflyの$CONTRLで”MW=”で指定するのは1CPUあたりのメモリで、Windowsのタスクマネージャで見ると、NCPUとともにメモリ使用量が増えていくのが確認できた。つまり、NCPUとともに増やす必要がないことがわかる。
結果の解釈:GaussianではN=2で頭打ちになっていた計算速度が、FireflyではN=4まで順調に伸びていく。Gaussianとの実装方法の差が出たということだろう。

(2)MP2エネルギー勾配計算の並列化
MP2でgradientの並列計算を行うには、別途下記のオプションを指定する必要がある。
$P2P P2P=.t. $END
ロードバランスを最適化するのに、更に"DLB=.t."を付けるとパフォーマンスが向上するらしい。
 ”MW=16"(128MB)の際のMP2 gradient計算
 ----------------------------
 NCPU Wall time(s)
 ----------------------------
  1    954
  2    215
  4    136
 ----------------------------
gradientも並列化の効果が出る。QX67上でLinux版G09を用いて同様な計算を行うと、
N=1: 581s
N=4: 342
となり、やはり効率がFireflyより小さく時間もかかる。

(3)MP2でのHessian計算
MP2でのHessian計算については、Gaussianは解析的に行うことが出来るが、Fireflyでは数値的に求めることしか出来ない(Gaussianのfreq=numerに相当)。したがって、時間がかかる。Linux上のG09(A2)と比べると3倍近くの時間がかかるのだ!MP2での振動計算はFireflyでやらないほうが良い。

また、計算の際
$FORCE NVIB=2 $END
と指定しないと低振動モードの値が変になる。"PURIFY=.t."を付け加えても改善されなかったので、この点要注意である。

以上のことから、MP2での計算は
構造最適化まで:Firefly
振動計算:Gaussian
と使い分けるのが良いと思われる。

(4)FireflyでのDFTの並列化
 Fireflyの公式サイトには以下のように書かれている。

"Limitations. The present implementation does not support multithreading. Analytical energy and energy gradients (and hence numerical hessians) are supported for both R-DFT and RO/U-DFT. Parallel mode is supported both for DFT energy and gradients."

これは、SMPには対応しないがネットワークを介した並列計算には対応するということだろう。実際、Core2Quad上でNCPUを変えても計算時間に差が出なかった。いずれにしろ、汎関数も少ないのでDFTをFireflyで行うメリットは無さそうである。

NWChemは汎関数を豊富にリストしているので、DFTだけこちらにしてもよいかという気になってきた。パフォーマンスはこれから見ていきたい。
続きを読む

tsukimaru123 at 17:49|PermalinkComments(0)TrackBack(0)

2012年03月15日

Bridging the gap between Gaussian and Firefly


やっと動き始めたFireflyだが、色々使い込むために試行錯誤しているとGaussian(具体的にはG03W)との差を感じるようになった。デフォルトの設定などに結構な差があるのだ。以下、備忘録的に書き留めておく。

(1)General Basisの指定
ヨウ素原子の基底として、LanL2DZに2df分極関数とs・p型diffuse関数を加えたものを用いる場合、$DATAには下記のように書けばよいことがわかった。$CONTRLでは”ECP=HW”と書くのを忘れないようにする。(3s3p)/[2s2p]の部分はBasis Set ExchangeからGAMESS-US形式で頂いてきた。平尾・武次両先生の「すぐできる量子化学計算」がGAMESSの入力ファイルについて解説してあり、大変参考になった。
---------------------------------------------------------
I 53.0 -2.949465 -0.552293 -0.940121    ←  座標
S 2
1 0.7242000 -2.9731048
2 0.4653000 3.4827643
S 1
1 0.1336000 1.0000000
P 2
1 1.2900000 -0.2092377
2 0.3180000 1.1035347
P 1
1 0.1053000 1.0000000
D 1                          ← d型分極関数
1 0.161 1.0000000
D 1                          ← d型分極関数
1 0.483 1.0000000
F 1                          ← f型分極関数
1 0.441 1.0000000
S 1                          ← s型diffuse関数
1 0.0569 1.0000000
P 1                          ← p型diffuse関数
1 0.0330 1.0000000
---------------------------------------------------------
(2)組み込み済み基底関数の指数因子
 Gaussianに組み込み済みのD95++(d,p)と、Basis Set Exchange で得られるDunning DZP+diffuseでは、diffuse関数だけが微妙に異なっていた。GAMESSでこれに相当する計算をする際は注意が必要かと思う。炭素原子Cの場合は下記のとおり。
------------------------------------------------------------------------------------
         D95++(d,p)    Dunning DZP+diffuse
------------------------------------------------------------------------------------
type         SP             P
exp        0.0438          0.034
------------------------------------------------------------------------------------
SP型関数の表記にも2つのソフトで差があることもわかった。たとえば、指数因子0.0438のSP型diffuse関数の記述は下記のとおり。
Gaussian:
------------------------------------------------------------------------------------
SP 1 1.00
0.0438000 1.0000000 1.0000000
------------------------------------------------------------------------------------
GAMESS:
------------------------------------------------------------------------------------
L 1
1 0.0438000 1.0000000 1.0000000
------------------------------------------------------------------------------------

(3)カーテシアン?球面調和?
General BasisでGAMESSの計算を行ってみたが、同様な計算をG03Wで行ったときとは微妙に基底関数の数が違う。前者ではカーテシアンのd,f関数を使うために、分極・diffuse関数を入れた場合差が出たのだ。これを避けるため、以下のオプションが必要になった。
------------------------------------------------------------------------------------
Gaussian: 5d 7f
GAMESS: $CONTRLで"ISPHER=1"または"D5=.t." (Firefly)
------------------------------------------------------------------------------------
FireflyIの$CONTRLでISPHERを指定するとエラーで終了するが、添付のinput.txtには何も書いていない。謎である。

(4)MP2計算のメモリー依存性
使用メモリ量を変えながらMP2一点計算を行った結果、下のように顕著な差が見られた。
------------------------------------------------------------------------------------
       NCPU       CPUtime(s,E1400)
------------------------------------------------------------------------------------
Firefly     1    896(10MW),399(16MW),300(32MW)
Firefly     2    496(10MW),252(16MW),181(32MW)

G03W     1    650(default),622(128MB),607(256MB)
------------------------------------------------------------------------------------
G03Wは殆どメモリ量に依存しないが、Fireflyは10MW→16MWの変更で速度が倍近くになる。G03Wでもメモリを増やすとsemi-directからFull directに計算法が切り換わっているので、速度がメモリ量にもう少し依存してもよいのだが。
一方、GaussianのWindowsバージョンには使用可能メモリに上限(256MB)があるとの情報もあり(未確認)。

(5)計算結果の比較−G03WとFirefly
(4)の結果を見るとおり、メモリ量を増やして並列化を行うとFireflyの圧勝である。並列版のG03W(現行はG09W)がお高いことを考えると、Fireflyの利用価値は高い。無論、大規模計算ではLinux上でG09を使用するので、あくまで予備的計算等に留めるつもりであるが。Quad Core以上でFireflyを試してみたいものである。


tsukimaru123 at 08:30|PermalinkComments(0)

2012年03月08日

Firefly(旧PC-GAMESS)で遊ぶ


 10年以上前、Kondara MNU Linux上でg77を用いてビルドして以来、量子化学計算ソフトGAMESSとはご無沙汰していた。Win32上のPC-GAMESSバイナリも触ったが、今ひとつ使いにくかった。特に、座標・基底関数入力が面倒くさく、Genaral basisで入力することの多かった当時としては食指が動かなかったのだ。

 あれから随分経ち、厳しくなる一方の予算状況を鑑みて少しでもGaussian以外のソフトに慣れておくことにした。この分野のフリーソフトとしては、GAMESSのほかにORCA、NWChem(Windows上のCygwinバイナリならここ)などがあるが、Windows上のバイナリで動作実績の多いPC-GAMESS(現在のFirefly)をインストールして使ってみた。ここでは備忘録として覚えたことをGaussianとの比較で書きとめておく。

(1)入力ファイルはオプション満載
 Gaussianでもオプションは色々あるが、細かい制御はOverlayオプションに隠されている。GAMESSではキーワードを指定することで色々指定できそうだ。

(2)対称性の拘束をかけた分子座標の入力が面倒
 Gaussianではカーテシアンで座標を入力しても、自動的に点群を判断して計算量を減らしてくれる。GAMESSではその点に工夫が要る。点群指定+Z-matrix(COORD=ZMT)ならちゃんとジョブが走るが、点群指定+カーテシアン(COORD=CART)では軸の向きを指定しないと駄目。指定しない場合は"master frame"の存在を仮定するので、この座標系に合致した座標を入力しないとエラーが出る。具体的には、主軸はZ方向・σ面はXZ平面になるようにすればOK。点群指定+ユニークな座標(COORD=UNIQUE)でも、同様な座標系の存在を意識する必要有。

(3)Winmostarをプリプロセッサ(ランチャー)に使用可能
 GaussianにおけるGaussViewのように、アカデミックフリーのWinmostarをプリプロセッサに使用できる。Winmostarは入力ファイルを上書きするので注意が必要。同様なソフトではFacioがあり、グラフィックス的にはこちらの方がきれい。

(4)計算速度は結構いい
 RHF/6-31GでH2O分子の構造最適化・振動計算を行ってみたが、G03Wより速いことがすぐわかった。これでは実行時間が短すぎるので、もう少し重い計算(B3LYP/6-311Gレベルでベンゼンの構造最適化)をしてみたのが下記の結果である(CPU時間)。initial guessは同じD6h構造である。
-------------------------------------------------
 Firefly 19s(NCPU=2では15s)
 G03W 27s
-------------------------------------------------
 並列計算も簡単に出来るが、上で見るとおり並列化効率はまだ良くない。スクラッチディスクを分けた方が速くなるらしい。

(5)GPGPUの機能が使える(らしい)
 NvidiaのGeForceを装着してCUDAライブラリをインストールすると、MP4計算が速くなるらしい。そのうち試してみたい。

(6)DFTの汎関数が少ない
 欠点であるが、DFT計算で利用可能な組み込み済みの汎関数が少ない。特に、近年重要性を増している分散力を評価できるもの(B971、M05系など)が使えないのが痛い。

(7)基底関数の指定が煩雑
 CH3Iの計算を考える。CとHにD95(d,p)、ヨウ素原子の基底としてLanL2DZにd型分極関数(指数因子0.16)を加えたものを使用する場合、入力ファイルでGeneral Basisを指定することで
C H 0
D95**
****
I 0
LanL2DZ
d 1 1.00
0.161d0 1.00d0
****
 のように柔軟な指定が出来た。GAMESS系のソフトでは面倒である。通常の$BASISキーワードでは指定できず、$DATAの一部として各原子について座標データと一緒に入力する必要がある。外部ファイルで別途指定する方が簡単かもしれない。何れの場合も、Gaussianとは書式が異なるのでBasis Set Exchangeなどを用いたほうがよい。


tsukimaru123 at 17:51|PermalinkComments(0)TrackBack(0)

2012年02月24日

AMD FX-8120を試す


 年度末、予算が少し残ったのでPCパーツを買ってGaussian用計算機を新しく組むことにした。かねてより興味のあったBulldozerを試すべく、FX-8120+A5M87のセットをツクモで購入。パソコン工房で別途購入した電源・メモリ・HDDと一緒に組み上げた。ケースは10年前のフルタワー(奇しくもAMD AthlonMPの2CPU構成マシンのもの)を”居抜き”で使用、ビデオカードはA研のゴミ捨て場で拾ってきたPCIのGeForceを使うことでとにかく経費を浮かせることに成功。計算サーバーで、SSHやtelnetでログインしてジョブを放り込むだけなので本当はキーボード・マウスも不要なのだが・・
 OPENSUSE12.1をインストール。最初試したCentOS6.2はオンボードのデバイスを悉く認識しなかったので捨てることにした。以前mahoさんのパッチを当ててビルドしたGaussian09(Rev.A2)のifcバイナリをインストールした。topコマンドで見ると8個のCPUが見える。
fx8120-top
test397を実行した結果が下図である。横軸はスレッド数、縦軸はCPU-timeである。比較のため、手持ちのPhenom-IIとCore i7の結果も載せた。
test397
N=1から4まではリニアに実行時間が短縮されているが、N=4でplateauに達しN=4->8で若干の向上が見られるのみである。これは、Bulldozerが2コアでFPUを共有しているためで、8コアといってもHPC用途上4コアと同じと考えると辻褄が合う。
 Phenom-II 965より3割以上速いことから、同クロックのPhenom-IIより4割以上高速化していると考えられる。ネット上で散々な言われようのFXだが、実数計算に関する限り十分速い。スコア上は3年前のCore i7 965 extremeとほぼ同等であることもわかる。スレッド数に対する依存性もほぼ同等である。価格性能比は高い。


tsukimaru123 at 23:31|PermalinkComments(0)TrackBack(0)

2011年05月24日

広島出張始末記


 恒例の学会出席のため、広島まで出張することになった。今年度は震災後のA研の復旧のため、交付金が大幅に減額された。現時点で昨年度のほぼ1/5、10万円である。遠隔地であれば出張2回分で終わり、雑誌によっては別刷り代も払えない赤貧状態である。7月に国際会議に出る予定なので本当は国内出張を控えたかったが、一応運営委員ということもあり下記のようなケチケチ作戦で広島に行くことにした。
 往路:格安夜行バス6700円(一泊分宿泊費が浮く)
 宿泊:5000円のビジネスホテル
 復路:新幹線のぞみ(18000円ほど)

5/19 丸の内北口の集合場所に8時ごろ到着。街灯を減らしてあるとはいえ、東京は明るい。
img127
8時半ごろにバスに乗り込む。思ったよりも座席の間隔が狭く、窮屈である。夜行バス内では禁酒、とアナウンスされ吃驚。どうやって寝るのだ??と思った。缶ビール・ウイスキーの水割り缶を持ち込んでいた私は、こっそり隠れて寝酒として飲むことに(笑)。
img128
バスは横浜から高速に乗りっぱなしなので、Willcomもb-mobileも繋がった。少しだけ車内ツイートしたが、昼間の自転車漕ぎで疲れたせいかすぐに眠りに落ちた。ただ、スペースが狭く膝が伸ばせないので、段々足が痛くなり眠りが深くなる前に目が覚める。うーん、やっぱり6700円は”伊達”ではないのだなw。

5/20 朝8時ごろ広島駅に到着・降車。駅前のカフェで行きかう人を見ながら軽い朝食を取る。
img129
学会会場まではJR山陽本線で一駅隣の横川まで行き、そこからバスに乗ることにした。学会会場はバスでずんずん山の中に入っていったところにある。広島は何故か市内に国公立大学がなく、辺境に追い出されている。確かにキャンパスは広く取れるが、アクセスが悪いのは困り者である。
img131
学会は相変わらず学生さんの”錬度”が足りない。質問されて壇上でモジ(((´ω` *)(* ´ω`)))モジしているのを見ると、加齢で怒りっぽくなっている私は苛立ちを感じるほどだ。「わかりません」とか「今後調べます」くらい言えないとは・・先生方はどんな指導をしているのやら。これじゃ就活で苦戦してもおかしくないぞ(怒)。

懇親会は楽しく終わり、路面電車で広島駅まで帰ることにした。
img132

ホテルは思っていたよりきれいで、喫煙可の部屋にしては臭いも少ない。シャワーを浴びた後、寝酒で買ったウイスキーでちびちびやる。

5/21 学会二日目。昨日と同じようにバスに乗るが、土曜日で休校のためバスは大学を通りすぎた。気づいたところで降車し、仕方なく徒歩で行く。1km近く蒸し暑い中歩いて会場に到着。
 山の中の学会会場でもwillcom・b-mobileは繋がるので、携行していったMI-13で内職。やはり400gを切るミニノートは軽くて楽だわ。office使うのはしんどいが、メールとweb程度ならさして苦にならない。
 あんまり長居していると帰宅が遅くなるので、お昼になる前に引き揚げ。午後一時前ののぞみで帰路に着いた。


tsukimaru123 at 21:49|PermalinkComments(0)TrackBack(0)

2010年09月30日

論文の行方


 8月〜9月はじめにかけて主著の論文3報(投稿順にA,B,C)を投稿した。論文Aは8月半ばにリジェクト通知を受け、修正のうえ別雑誌(”落人の里”)に再投稿。現在査読中である。twitterでつぶやいたとおり、一回目は詰めが余りに甘かったのが敗因だったので、査読結果が戻るまで想定質問に対する答えを用意して今回は臨んでいる(最初っからそれをしていればOKだったような気もするw)。
 Cは先日アクセプトされ、現在ゲラ刷り中である。来週中にはProof correctionが終わり、10月中にはweb上で見られることだろう。

 論文Bは一番リスキーな論文で、まず一発アクセプトはないだろうと思っていた。そのため、”2段落ち”も覚悟して最終的な落人の里も想定していた。この論文に対するコメントが今週はじめに返ってきた。夏休みの旅行中だったので、休み明けの今日からコメントを読んで対応を検討している。とりあえずmajor revisionで通してくれそうなのが望外の幸せ、といったところか。でも、一見型破りに見える事でも世界の人は同じような事を考えて仕事をしているのだと実感した。私は日本では「傍流」の研究者だが、それをいいことにこれからも「変なこと」をやり続けていこう。今年は生物多様性条約COP10の年でもあるしw。

 それにしても、この改訂作業。何度やっても胃が重くなってつらいんだよなぁ。査読者たちとの真剣勝負だから緊張するのは当たり前なのだが、エネルギーが体から吸い出されていくような感じがして終わるとガックリとくるのだ(↓のような感じ)。
真っ白に燃え尽きた
これに長年耐えられる先生方はやっぱり偉い。そういえば、多比良さんも最盛期は一年に90報論文を書いていたらしいが、4日に1報だと私は確実に死ぬw。


tsukimaru123 at 12:01|PermalinkComments(0)TrackBack(0)

2010年09月21日

Unfinished business


 8月後半〜9月始めにかけて主著の論文をいくつか投稿し、そのうちの一つに対してコメントが返ってきた。とりあえず小変更で受理してくれそうなので、一安心である。残りの論文はどうなるのかなぁ〜(汗)。

 この論文、元になるデータを採ってから20年になるものだ。あまりの複雑さにお蔵入りを考えずっと放置していたが、今年になって形に残すことに決めた。解析が完璧でなくても、公表すればいつかどこかの誰かが解決してくれるかもしれない、私がこの世を去っても論文は形に残るのだから。そう考えてのことだ。もうひとつの理由は、20年経ってもこの系に関する実験データがほとんど出ていないことだ。今出しても、今更感がないというのは私にとっては結構なことだが、分野が停滞しているといえなくもない。

 論文として形にするには、現時点でどこまで詰められるかを定量的に記述する必要があり、実験をサポートする計算をいくつか行った。この20年間の間の計算速度の進歩は凄まじく、昔ならできないような大きな計算をPC上で簡単にできるようになった。おかげで、摂動の起源をかなり特定できた。後は、実験データを再現するようなモデルを立ててフィッティングをする仕事が残っているが、まずは適切なモデルを作るのが難しい。この業界、簡単な系については理論・実験ともに精密さを競いやり尽された感があるが、ちょっと大きな系・対称性の低い系は放置されていると思う。上で述べた「停滞」感もそこに起因しているのだ。

続きを読む

tsukimaru123 at 11:50|PermalinkComments(0)TrackBack(0)

2010年08月18日

長いつぶやき on 文献整理


 Nature Newsの記事「被引用回数を上げたかったら引用文献を増やせ」を読んで、「ああ、こうして研究者コミュニティができていくのか」と思った。確かに、私もISIやScopusで自分の論文の被引用回数を定期的にチェックしているし、引用してくれた著者にメールを送ったこともある。同様な分野で仕事をしていれば、自然と気に留まり引用もするようになるのだ。

 とはいえ、論文を書いていて大変なのもこの引用だ。引用する前に文献整理が必要だし、本文とReferencesの対応付けは書き進めるうちに動いていく。投稿後も「こんなのを引用しろ」と査読者から注文が付けば、追加してreference numberも変更しなければならない。まさに、moving targetである。

 特に、北欧人・東欧人のやたらと子音が多かったりアクセント記号の付いたややこしい著者名の手入力はミスを誘発する。最近では急増する中国人の名前の著者も頭痛の種だ。今まではこんなのを50〜60も手入力していたが、間違いが起こるのはある意味当たり前である。

 基本的に、論文のreferenceは著者の責任で正しい引用をしなければならない。最近のオンライン出版のおかげで、間違った著者名を入れた参考論文はちゃんとしたリンクが張られないので、Citationをカウントしないのだ。私が2007年に書いた論文も、referencesにぽつんとリンクが張られないまま残っている引用文献がある。ああ、恥ずかしい。

 やっぱり、手入力を止めてDOIから書誌情報を抽出するソフト(EndNoteなど)を買うしかないのだろう。Mendeley Desktopはまだ頼りないし..貧乏人の私にとって安くない買い物だが、回りまわって自分の論文の引用回数を増やしてくれるのならもはや必需品だ。


tsukimaru123 at 23:20|PermalinkComments(0)TrackBack(0)

2010年07月27日

その後のG09−表示編−


Gaussian09(G09)で計算するようになって早数ヶ月。速度が上がったのは良いが、計算結果の可視化に手間取っていた。従来使っていたGaussview3では出力ファイルの読み込み時にエラーが出るようになったのだ。WebMO(ver8.0)ではファイル読み込みが終了せず、ハングする。どうも微妙に出力形式が変わったらしい。新しいGaussviewを買えと言うことなのだろうが、この金も馬鹿にならない。エネルギー・最適化構造程度ならこれらのソフトを使う必要もないが、大きな分子の基準振動の特徴をつかむには必須である。
 困っていたところでググッて見ると、このサイトに解決法が載っていた。早速使わせていただく。コメントに書き込めないようなので、この場を借りてお礼申し上げます。どうもありがとう。ちなみに、WebMOではファイル読み込みは進行するが、分子の表示・振動の可視化が一切できなかった。ほかにもトラップを仕掛けてあるのか..Gaussian inc.、お主も悪よの〜。


tsukimaru123 at 12:15|PermalinkComments(0)TrackBack(0)

2010年06月16日

その後のG09


 PhenomIIマシンにインストールしたGaussian09(G09)だったが、先日PGIコンパイラ(8.0)の評価版ライセンスが切れると同時に使用できなくなった。PGI6.1では、ビルドしたバイナリはexpireされたあとも利用できたのだが..Intel fortran compiler(IFC)との競争もあり、使用条件が変わったのだろうか。世知辛いなぁ。

 G09をちゃんと仕事に使うにはPGI8以上を正規購入すればよいが、最小構成でも8万円前後。予算状況の逼迫した今年度は厳しい。となれば、取りうるオプションは以下の2つ。

(1)正規購入してあるPGI6.1でG09をビルド
(2)g77、IFC非商用版などの無料コンパイラでG09をビルド

(2)はかなりi386.makeとmdutil.cをいじらないといけなそうなので、まずは(1)を試してみた。結果としては、i386.makeを2箇所変更するだけで無事G09をビルドでき、流したジョブも正常に終了した。

せっかくビルドしたバイナリ、他のマシンでも使用できるようにバックアップをDVD-Rに取り、インストール用スクリプトを作った。元は昔mahoさんがGaussian98のために作って公開してくれたものであり、それをG09用に改変したものである。
--------------------------------------------------------
#!/bin/sh

install -d -o root -g wheel -m 0750 /usr/local/bin/g09
install -d -o root -g wheel -m 0750 /usr/local/bin/g09/bsd
cp *.exe /usr/local/bin/g09
cp c8609 chkchk copychk cubegen cubman demofc /usr/local/bin/g09
cp formchk freqchk freqmem g09 /usr/local/bin/g09
cp gau-machine gauopt gauoptl gautraj ghelp ham506 /usr/local/bin/g09
cp mm newzmat rwfdump testrt unfchk /usr/local/bin/g09
chown root.wheel /usr/local/bin/g09/*
chmod 750 /usr/local/bin/g09/*
cp bsd/g09.login bsd/gau-arflags bsd/gau-get bsd/gau-hname bsd/gau-ranlib bsd/gau-unlimit bsd/set-mflags /usr/local/bin/g09/bsd/
chown root.wheel /usr/local/bin/g09/bsd/*
chmod 750 /usr/local/bin/g09/bsd/*
cp util.a /usr/lib/
chown root.wheel /usr/lib/util.a
chmod 755 /usr/lib/util.a
/sbin/ldconfig -v
--------------------------------------------------------
後は/usr/local/binに下記のスクリプトをコピーして実行可能な形にchmodすればよい。スクラッチディレクトリは/workにしてある。これもmahoさんの改変版である。
--------------------------------------------------------
#!/bin/csh -f
# usage: gaussian09 InputFile
#
setenv g09root /usr/local/bin
setenv GAUSS_SCRDIR /work
source $g09root/g09/bsd/g09.login
setenv GAUSS_EXEDIR $g09root/g09
if ($#argv == 0 ) then
echo "Usage: gaussian09 < input file >"
echo " or gaussian09 < input file > < output file >"
else if ($#argv == 1 ) then
cat $1 | $g09root/g09/g09
else
cat $1 | $g09root/g09/g09 >& $2
endif
--------------------------------------------------------

 IFC非商用版は仕事に使ってはいけないので、ビルドに成功することがわかったら正規版を買わねばいけないのが悲しいところ。IFCのLinux正規版は10万以上とPGIより高いので、IFCによるG09ビルドを試すことは余程暇にならない限りなさそうである。


tsukimaru123 at 17:41|PermalinkComments(4)TrackBack(0)

2010年06月04日

G09を使い始めた


 Gaussian09(G09)を先日組み立てたPhenom-IIマシンにインストールして使い始めた。いつものようにMP一点計算のベンチマークをとってみると、G03より速い。2−3割増しの感じである。プロセッサ数を変えながら並列化効率を見てみると、N=4で3.5程度と上々である。まあ、G98からG03になったとき速度が低下したので、その分を取り戻したのだろうというのが第一印象だった。

 少し大きめの分子について、DFTで構造最適化をしてみるとその考えは変わった。G03よりもはるかに早く計算が収束したのだ。エネルギーの落ち方を見ると傾向に大きな違いはないが、G03では最後の一押しで振動していることがわかる(下図)。
エネルギー低下
構造の収束を最大変位で見るとその差ははっきりする。G09では速やかに収束したのに対して、G03ではかなり激しく振動している(下図)。
最大変位の収束
2つの計算とも全く同じ初期構造・オプション設定で走らせているので、違いは最適化のアルゴリズムにあると考えられる。G09ではGEDIISという新たに実装されたアルゴリズムがデフォルトになっているので、この効果だろう。自由度の大きい系や低振動数モードの多い系ではこの差はより顕著に表れそうである。


tsukimaru123 at 22:19|PermalinkComments(0)TrackBack(0)

2010年05月24日

研究所の管理職とは

 毎年この時期になると、上司との面接が行われ昨年度の仕事の評価と今年度の計画についてインタビューが行われる。研究所に評価が導入されると同時に始まったこの制度だが、私の個人的印象ではまったく機能していない。それは以下のような理由による。

 管理職の仕事として考えられるのは、
(1)リソース配分
(2)テーマ設定
(3)所外との交渉
(4)雑用(人事評価など)
(5)上とのやり取り
(6)メンタルな管理
であるが、A研における上司は”雑用おじさん”(orおばさん)である。お金をとってきて配るわけでもなく、テーマ設定について具体的な助言ができるわけでもない。関連研究の紹介はできないし、外部の研究者・関連学会への橋渡しができるわけでもないのだ。ダメ出しはできても、「ではどうすればよいのか」という提案ができない。成果の評価にしても、論文を何報書こうがまったくfeedbackがない。中身を読んでいないことは確実であり、そもそも部下がどんな場所でどんな装置・手法で仕事をしているのかすら把握していないと思われる。現に、研究現場に様子を見に来たこともないのだ。

 つまり、上記(1)〜(6)のうち(1)と(4)を除いて全滅である。”雑用おじさん”とされる所以である。このような状況では、個々の強みを組み合わせて組織の特徴を出していくなどという、MOTは夢のまた夢だ。仕事の良し悪しについてのfeedbackがないのだから、部下は「自分の仕事が理解されない」「頑張ってもencourageされない」と考え込むことになり、
・段々無気力になっていく
・見切りをつけて転出する
の何れかを選択するようになる。数から言えば、前者が圧倒的だろう。ある仕事をしなくなった人間に対して、別の仕事を割り振るシステムは会社なら当たり前に存在するだろうが、A研には存在しない。「**は仕事をしなくて困る」などと平気でいうのだ。仕事を(むちや飴で)させるのが管理職の仕事とは思っていないらしい。かくして、長期的に見ると研究所としてのアクティビティは落ちていく。

 斯く言う私も、段々うんざりしてきた。圧倒的に「組織が機能していない」と感じるのだ。職場の性格として、「個人事業主の集まり」というカラーが強いのは仕方ないにしてもだ。

tsukimaru123 at 18:46|PermalinkComments(5)TrackBack(0)

2010年05月21日

Mendeley Desktopの使用感


 Stochinaiさんのサイトで、文献整理用のフリーソフトMendeley desktopが紹介されていた。私は恥ずかしながらこの手のものを使ったことがなかったので、早速インストールして使用した印象を書いておこう。
Mendeley desktop とりあえず常用しているPC上の650程度のpdfを登録したが、書誌情報の自動抽出は雑誌によりかなりバラつきがあった。ちょっと古くなると自分で雑誌名・巻数・ページ数を入れてGoogle Scholarで補完しないとエントリーは空白のままである。特に、1995年以前のpdfだと画像としてpdfに取り込まれる場合が多く、文字列抽出がうまくいかないらしい。おかげで、殆ど全てのpdfの登録には単調な手作業が必要になった。

 また、無事書誌情報をそろえることができても、今度は抄訳の抽出がうまくいかない。
AIPの雑誌はアブスト表示可
AIPの雑誌はOKだが、ACSとElsevierの雑誌は抄訳を手入力する必要がある。
Elsevierの雑誌はアブストも表示しない
 また、参考文献については、AIPを含めてほぼ全滅である。AcknowledgementやFigure captionsなどを誤って抽出したり、まったく空白のままだったりした。
AIPの雑誌はreference抽出不可
 唯一全ての書誌情報の抽出に成功したのはNature Materialsの論文一報のみ。Nature本誌のLetterでさえ不具合があった。
Nature Materials

一旦登録が済んでしまうと、確かに所有している文献の見通しが良くなるので便利さを感じる。これなら、お金を払っても良いと思える。だが、そこまでに至るのが大変である。たかだか数百のpdfでこれだから、千を超えたら苦行である。功徳を積むつもりで虫のように黙々と手入力を繰り返すか、アルバイトを雇ってやらせたほうが良いだろう。おそらく、ターゲットにしている分野が物理・化学ではないことに依るのだろう。今後の進歩に期待しよう。


tsukimaru123 at 12:35|PermalinkComments(2)TrackBack(0)

2010年05月19日

今年度の初学会が終わった(参加しただけ)


 先週の後半、東京某所で学会に参加した。我が家からは電車で1時間45分程度かかるので、一日目は通って朝一の座長をすることになっている二日目のため東京で一泊することにした。

img053 学会は以前に書いたとおり、学生さんの発表に若干の不安(不満)がないわけではないが、粛々と進行。私は聴いているだけなのでとにかく眠くならないよう、目覚ましサプリをキメて臨むことに。しかし、時間の経過とともに意識の途絶が頻発する。体も目も疲れていないが、退屈な(=脳を刺激しない)話だと脳がスリープモードに入ってしまうらしい。特に、「これだけお金をかけてこんな装置を作りました」「新規なデータはまだです」的な発表に対しては、貧乏暮らしの私のルサンチマンが刺激されるらしく、脳が強制スルーモードになって爆睡した。
 持って行ったパソコンで内職すると、さくさく進んで眠気も飛んでいく。やっぱり、最近この学会に対する興味が失せてきたのだなぁ。運営委員会に入っているので、足抜けするのも現状難しいが。機会を伺うことにしようか(苦笑)。

 懇親会が終わり、ホテルに行く。
img055
ホテルはできたてらしく、東京にしては広々していた。ベッドに見慣れないものがあったが、どうも抱き枕らしい。最近腰痛に悩む人が多いせいだろうか。img054

 2日目の朝9時から、座長をする。何故か最近、朝一の座長・講演者が回ってくることが多い。何かの罰ゲームだろうか(身に覚えはないのだが)。この学会は話は十年一日のことが多くて退屈さを感じる場合が多いが、議論が活発なところが美点である。結構厳しいつっこみもあり、質問が出ない場合に備えて用意していた質問集は使わずじまいだった。


tsukimaru123 at 21:14|PermalinkComments(0)TrackBack(0)

2010年05月07日

(ある意味)宝の持ち腐れ


 仕事でG03を回しているPCのうち、socket939のAthlon64 X2が載っているものをPhenomII X4に先日置き換えることにし、CPUとマザーボード・DDR3DIMMを購入した。〆て4万円弱。換装してベンチマークをとると、一昨年購入したCore i7と同等の性能で、価格性能比の高さにびっくりする。6コアのPhenomIIも出たが、コンパイラの制限もあるので当分このまま使うことになるだろう。早速、大きなジョブをゴールデンウイーク中流しっぱなしにした。

 これで4コアマシンが3台になったのだが、中々フルコアで計算を回す機会はない。その理由は、計算の並列化効率の問題である。下図はネットで手に入れた分子研での2004年における発表資料だが、DFTの場合はCPU数に対して高い並列化効率を示すことがわかる。HF計算の場合も同様な傾向である。
DFT-並列化
ところが、post-SCFになると並列化効率は一気に悪くなる。下図はMP2計算に対するものだが、プロセッサ数8以上はほぼ横ばいである。
MP2-並列化
CCSDになるとN=2で横ばいになり、G03の場合N=4で速度の低下すら見える。
postSCF-並列化
いずれも縦軸はCPU時間だが、ディスクI/Oの多くなるpost-SCFでは実際のelapsed-timeはさらに遅くなる。いくらコア数が多くてもその恩恵に与れないわけで、実際CCSD計算をここ2週間ばかりしてみてそのことを実感するようになった。その結果、4コアマシンも常時動いているのは半分だけというもったいない状況が続いている。G09では状況が少し変わっているといいのだが..
続きを読む

tsukimaru123 at 22:21|PermalinkComments(0)TrackBack(0)

2010年02月24日

祝アクセプト

 先日リバイズして送り返した論文の受理通知がエディタからやって来た。投稿してから三ヶ月、フルペーパーだから時間がかかるのは仕方ないところか。三月第一週にはゲラが上がってくるとのことなので、四月にはオンラインで読めるようになるだろう。ひとまずは良かった。
 
 次は何を仕込もうか、思案中。

tsukimaru123 at 22:35|PermalinkComments(0)TrackBack(0)

2010年02月03日

学術雑誌の購読料高騰について


 やや旧聞に属するが、学術雑誌の購読料高騰で購読をあきらめる大学の話が新聞に載っていた。Stochinaiさんのサイトでも取り上げられていたので、少し感想を書いてみよう。

 これら学術雑誌の出版元がどういうビジネスモデルを使っているのか、私は詳しくは知らない。おそらく、投稿料をとらない場合(Elsevierなど)は購読料と広告収入のみではないか。学術雑誌・教科書の出版はそもそも儲からない仕事で、ElsevierもAcademic Pressなどを吸収して大きくなっていった経緯がある。寡占状態になれば価格は上昇するのがある意味理にはかなっており、ようやく「おいしい仕事」になったともいえそうである。とすれば、購読料の高騰は不可避といえるだろう。たまたま、今回世界的な景気の冷え込み・日本における科学技術予算の見直しと重なってしまったので、我々にとっては災難なのだが(´;ω;`)。

 また、価格高騰の原因であるが、今の学術雑誌はほとんどオンライン投稿・出版になり、お金がかからないように思われるが、実際のところサーバーの維持・整備に金がかかっているのではないかと推察する。現に、Elsevierの電子投稿システムやScience Directは割りと頻繁にメンテナンスしている。また、これらのサイトは他のデータベース(ISI Web of ScienceやScopus)とも出版日時や引用文献に関してデータのやり取りをしている様子で、サイトが以前より重くなっていることを最近実感する。昔は質実剛健のイメージがあったこれら学術雑誌のサイトも、graphical abstractなどを載せて見栄えのよさを競うところもあり、さらにサイトのトップページの読み込みに重さが加わっている。とすると、出版社が言うように、
投稿量の増大⇒ミドルウェアの整備やサーバーの増強・回線の増強⇒購読料の高騰
とつながっていてもおかしくはない。また、投稿された原稿の査読者への割り振り・交渉は人力でやらねばならず、その事務手続きの手間も無視できないと思われ、それが
人員増強⇒人件費上昇⇒購読料高騰
というイベントツリーをたどっている可能性もある。

 我々が個々に取りうる自衛策は、金額の大きさからいってなさそうである。投稿料の問題なら別の雑誌(国内欧文誌を含む)を見つけることで対応可能だが、雑誌を購読できないとなるとお手上げだ。出版社との価格交渉・他の機関との共同購入といった地道な方策以外には、またノーベル賞受賞者を使って関係省庁に陳情にいくのがよいのかもしれない(笑)。


tsukimaru123 at 12:30|PermalinkComments(2)TrackBack(0)
Archives