内存影响高斯SCF不收敛的例子

michaelm · 发表于 Post on 2017-9-20 04:52:08

本帖最后由 michaelm 于 2017-9-20 04:53 编辑

最近遇到一个有趣的例子。完全相同的输入文件，单点能DFT计算，只是一个用了24G内存，一个用了60G内存。在同一台机器上，一个SCF收敛失败，一个顺利完成。很显然，以前从来没注意过，指定的内存不一样，高斯SCF计算用的默认算法不一样！而算法不一样，就有可能导致一个收敛
失败，一个成功。

具体地说，内存少的时候，高斯默认使用Incremental Fock方式，而内存大的时候，用incore algorithm。前者在G16之前的版本里默认的格点精度和
积分精度相对较低，有时候就会导致SCF不收敛。Sobereva有非常详细的好文（http://sobereva.com/61）说明过SCF收敛的问题。作为一个应用，这
个例子里我在不收敛的指定24G内存的输入文件里，加上Int=(Acc2E=12,Grid=Ultrafine) 之后，也就能顺利收敛了。据说G16已经改进了默认的格点精度
和积分精度，可能这个问题就不存在了。哪位有G16的可以试验确认一下。

总之，作为一个懒人，如果你在G09里发现DFT计算Incremental Fock SCF不收敛，可以拼命加大内存试试。

pyrene-24gb-scf.gjf (1.35 KB, 下载次数 Times of downloads: 23)

pyrene-60gb-scf.gjf (1.35 KB, 下载次数 Times of downloads: 15)

sobereva · 发表于 Post on 2017-9-20 11:07:14

确切来说不是使用Incremental Fock方式，而是使用Direct SCF方式。Incremental Fock是用来加速SCF的技术，免得每轮迭代都较好时地去完整构建Fock矩阵。

g09默认用Direct SCF，当内存够大的时候，自动用incore方式。Direct SCF方式计算过程中由于每一轮迭代都会重新计电子积分，为了降低耗时，会根据一定条件对积分自动取舍，而不像incore那样一开始就把所有要用的积分全都算完了。Direct SCF和incore两种方式导致一个收敛一个不收敛的概率是相当低的，一般不用去考虑这个。

至于acc2e=12，除非是用诸如LPol、HYPOL、aug-pcseg-3等这种弥散函数超多的基组，用它来解决掉不收敛的可能性也很低。如果什么任务都加这个反倒会无意义地增加耗时，我对g16把这个作为默认表示不满。相对来说，ultrafine的重要性更高。

不是很小的体系，基组也不很小的话，通常的服务器的内存都不够incore用的，即曰内存设到头也用不起incore。另外值得一提的是，incore虽然原理上速度比direct SCF快得多，但我发现在Gaussian中incore时候并行效率往往很低，所以可能导致耗时严重增加。而在g16中似乎不会自动用incore，但在g09中会，为了避免因自动用incore耗时增加，在大内存的机子上（诸如256GB）用g09时我往往都刻意写上scf=noincore来避免（或者自行把%mem故意设低来避免）。

总的来说不需要刻意去靠incore来试图解决不收敛，反倒可能令耗时大大增加。只要按照博文里的方法去试图解决SCF不收敛即可。

abdoman · 发表于 Post on 2017-9-20 08:32:39

dft 计算记得好像就是建议使用Grid=Ultrafine 吗？

		自动登录 Automatic login	找回密码 Forget password
密码 Password			注册 Register

[Gaussian/gview] 内存影响高斯SCF不收敛的例子