[ORCA快速入门] ORCA -- Gaussian 命令对照

liyuanhe211 · 发表于 Post on 2015-11-4 12:35:27

Shannon 发表于 2015-11-4 09:01
一个小建议，好像表格里漏了SCF=XQC 的对应命令，这个高斯命令解决 scf不收敛超管用。 ORCA应该是对应SOSC ...

我曾经想加上这一条，但仔细一想总是不大确定：
Gaussian里的SCF=XQC是说，默认SCF失败的时候，用QC方法跑，相当于比默认情况下提前了QC的使用（默认是到结束都不使用）

而ORCA里，默认情况下就是当DIIS error<0.01时启用，SCF失败的原因是SOSCF启用的太早，偏离平衡态太远，使得SOSCF失败（而不是默认的DIIS SCF失败）。使用SOSCFStart=0.00033实际上是推迟了QC的使用

所以总觉得这二者不是等价的。不知道这个理解对不对。@sobereva

sobereva · 发表于 Post on 2015-11-4 12:59:51

liyuanhe211 发表于 2015-11-4 12:35
我曾经想加上这一条，但仔细一想总是不大确定：
Gaussian里的SCF=XQC是说，默认SCF失败的时候，用QC方法 ...

Gaussian默认是DIIS。若不收敛，可以人为尝试SCF=QC用较慢但收敛性更好的二次收敛方法。scf=xqc是当DIIS不收敛时自动切换到QC。

SOSCF并不是Gaussian里的二次收敛方法，相当于近似的SCF=QC，没有SCF=QC那么慢，同时也没那么稳健，所以默认情况下也会自动用。
SOSCF方法当SCF接近收敛的时候或者DIIS到末期难以收敛的时候效果较好，而在SCF初期没那么好，所以ORCA一开始自动用DIIS，当迭代到轨道梯度较小的时候自动切换为SOSCF以追求更好更快的收敛。SOSCFStart是控制轨道梯度小到什么时候开始用SOSCF，默认0.01，你设0.00033就是推迟了SOSCF的使用。

stecue · 发表于 Post on 2015-11-6 04:52:27

高手啊，赞一个。不知道有没有人有兴趣直接做个Gaussian-->ORCA的翻译器。这字典已经做出来了哈。

liyuanhe211 · 发表于 Post on 2015-11-6 05:02:51

stecue 发表于 2015-11-6 04:52
高手啊，赞一个。不知道有没有人有兴趣直接做个Gaussian-->ORCA的翻译器。这字典已经做出来了哈。

这没什么难度，但是人家用/学两个软件都是为了各取所长，你到好，来个就要个共有部分，除非一个软件的同一功能显著高效于另一者(这个情况几乎不可能发生)，否则这样换软件还有啥意义？

liyuanhe211 · 发表于 Post on 2015-11-6 05:06:00

sobereva 发表于 2015-11-4 12:59
Gaussian默认是DIIS。若不收敛，可以人为尝试SCF=QC用较慢但收敛性更好的二次收敛方法。scf=xqc是当DIIS ...

现在清楚了。谢谢Sob。

stecue · 发表于 Post on 2015-11-6 05:12:30

liyuanhe211 发表于 2015-11-6 05:02
这没什么难度，但是人家用/学两个软件都是为了各取所长，你到好，来个就要个共有部分，除非一个软件的同 ...

毕竟ORCA据说比Gaussian快得多啊，而且免费。

就像现代编译器都包含自动向量化部分对源代码进行优化，以充分利用新指令集；Gaussian-->ORCA翻译器足够智能的话也应该能够自动添加优化/加速选项嘛。

liyuanhe211 · 发表于 Post on 2015-11-6 10:51:57

stecue 发表于 2015-11-6 05:12
毕竟ORCA据说比Gaussian快得多啊，而且免费。

就像现代编译器都包含自动向量化部分对源代码进行优化， ...

ORCA比Gaussian快是因为RI近似支持的好，Gaussian里跑的路径一模一样的翻译到ORCA里大部分情况下反而慢。
以及，我们有钱啦啦啦

sobereva · 发表于 Post on 2015-11-6 11:35:05

stecue 发表于 2015-11-6 05:12
毕竟ORCA据说比Gaussian快得多啊，而且免费。

就像现代编译器都包含自动向量化部分对源代码进行优化， ...

不开RI的时候并不比高斯快。尤其体系对称性越高，ORCA吃亏越大

stecue · 发表于 Post on 2015-11-6 12:35:23

liyuanhe211 发表于 2015-11-6 10:51
ORCA比Gaussian快是因为RI近似支持的好，Gaussian里跑的路径一模一样的翻译到ORCA里大部分情况下反而慢。 ...

原来这样子哈。那真要有人写的话就应该把RI近似作为默认优化选项，如果RI不能作为黑箱可以通过简单添加关键词开启的话，那正好可以体现翻译器的水平哈。

liyuanhe211 · 发表于 Post on 2015-11-6 17:04:55

stecue 发表于 2015-11-6 12:35
原来这样子哈。那真要有人写的话就应该把RI近似作为默认优化选项，如果RI不能作为黑箱可以通过简单添加关 ...

我曾经写过Gaussian的黑箱，比GV方便多了，比如点一下“Optimized Energy”，就自动按照原子种类、个数、电荷加基组和方法，能保存输入文件，遇到诸如9999之类的常见错误还能给出带解决方法的输入文件，自动判断能量是不是震荡了。但是后来发现并没有什么卵用。计算显然不像做实验那样，写输入文件的时间能把你的日程排的满满的，且当需要计算的体系越来越多，遇到的情况越来越多，使得到最后终究会变成一个可以点击的Gaussian手册而已。

顶多写一个能够根据一条关键词输入，填充多个结构，生成多个输入文件就完了。

以及自己去查查ORCA里面的自动opt选项，比如GoodOpt，DFT_Energy 之类的，方法基组自动选，带RI，这已经就是个黑箱。还要怎么样？

planet5460 · 发表于 Post on 2015-11-6 23:59:06

这个有点给力哦，可以快速切入ORCA

stecue · 发表于 Post on 2015-11-7 01:14:28

liyuanhe211 发表于 2015-11-6 17:04
我曾经写过Gaussian的黑箱，比GV方便多了，比如点一下“Optimized Energy”，就自动按照原子种类、个数、 ...

我不是说从头开始的黑箱。只是为了充分利用一个软件的优势（比如ORCA的RI）在进行文件输入格式转换的时候自动添加合适的加速选项的黑箱。

举个例子，namd可以直接利用amber的力场。在多节点的计算上namd比amber有优势。但是1) amber那一套建模工具很方便，直接在本地的机器上调试amber各种参数，再到超算上做production run也比直接在超算上排队节省很多时间。2) 以前有好多legacy的输入文件都是amber格式的。3)不同的合作者有的喜欢用amber，有的喜欢用namd。4)说实在话amber的namelist输入格式是在反人类。很难从变量名猜到确切意义。

所以我一直在想应该弄个amber<-->namd的双向兼容工具。手写两遍输入文件实在是容易出错。bash脚本当然也能部分解决问题，但是通用性略弱。可惜通用性强的话得两个软件都相当精通，各种corner case得考虑到，一般人怕是没那么闲。

songsong · 发表于 Post on 2015-11-7 01:20:26

有心人，学习了

liyuanhe211 · 发表于 Post on 2015-11-7 03:35:37

stecue 发表于 2015-11-7 01:14
我不是说从头开始的黑箱。只是为了充分利用一个软件的优势（比如ORCA的RI）在进行文件输入格式转换的时候 ...

大概知道什么意思了，感觉对ORCA和Gaussian来说，写个东西自己用应该还是很容易的（我已经开始修改我用来生成Gaussian输入文件的东西让它帮忙做ORCA了），但是写一个能发布给其他人用的感觉难度还是挺大的。

stecue · 发表于 Post on 2015-11-7 05:44:16

liyuanhe211 发表于 2015-11-7 03:35
大概知道什么意思了，感觉对ORCA和Gaussian来说，写个东西自己用应该还是很容易的（我已经开始修改我用来 ...

是的啊。自己写写用到的选项总是有限的，但是发布的话就得尽量穷举所有选项……

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

[ORCA] [ORCA快速入门] ORCA -- Gaussian 命令对照

评分 Rate