渡邉先生
お世話になっております。
こちらにつきましては、Abinit-MPではなくGamessを使って無理やり解決してしまったので、ある意味解決はしているのですが、
今後のために、状況を共有いたします。
元の計算ファイルはごちゃごちゃしているので、サンプルファイルのgly5で問題となっている個所を提示します。
/home/u10997/u10997/3rh8-fmo/share/samples
こちらのフォルダに、
1. まず、一度リスタートファイルを書き出す設定にし、計算がすべて終了したあと(input.write.log)
2. monomer SCCとMP2を読み出すように設定し、dimerから再度計算するように設定して走らせた結果(input.read.log)があります。
問題となるのは、input.read.logにおいて、READ MONOMER SCC RESULTとなったあとに、SCCが2サイクル走っているというところです。
このケースでは、2サイクルで収束しているのでいいのですが、以前のケースでは、リスタート前の計算でSCCまで収束してMP2まで走っていたにもかかわらず、リスタート計算でSCCが再び振動し始め、結局MP2に入るまでにかなりの時間を要してしまうという現象が発生していました。
今回、gly5で検証したことで、SCCファイルを読み込んだ際は、それを初期値としてSCCが再度走るという仕様がわかったため、原因は明確になり、
SCCが以前の計算で収束していても、再度そこから再開するとすぐに収束しないことがあるというのが原因だとわかりました。
これを解決するためには、SCCの読み込み時には収束判定をスキップする処理を追加するくらいしか、思いつかないですが、以前収束していたSCCがリスタートすると振動するということ自体、なにかおかしなことが起きているという考え方もできるかと思っています。（その時扱っていたのが、鉄をclosed shellで扱うという今思えば無理のある設定でしたので、そういうこともあるということで捨て置いてよいのかもしれません）
煮え切らない感じにはなりましたが、現状はこのような感じです。
吉村匡隆
