上海绎模信息科技有限公司
eMolTech,计算科学的领航者
新闻通知
Gaussian 16 B.01 Release Notes
发布时间:2018-03-01
关键词:Gaussian 16 B.01 Release Notes
-
新功能
新模拟方法
◆ [REV B] CIS和TD方法支持激发态静态拉曼强度计算。TDFreq=Raman 使用数值微分计算电场下的极化率,所以这类方法的频率计算耗时是不计算拉曼强度耗时的7倍。
◆ TD-DFT 激发态计算支持解析频率(frequencies, IR及Raman)、过渡态优化(TS)及内禀反应坐标计算(IRC)。
◆ EOMCC 耦合簇运动方程(EOM-CC)方法支持结构优化。
◆ VCD及ROA光谱支持非谐振计算,请参考 Freq=Anharmonic。
◆ 支持电子振动光谱计算,请参考 Freq=FCHT 及相关选项。
◆ 支持共振拉曼光谱计算,请参考 Freq=ReadFCHT。
◆ 新密度泛函方法: M08 family, MN15, MN15L。
◆ 新双杂化泛函方法:DSDPBEP86, PBE0DH及PBEQIDH。
◆ PM7 半经验方法。
◆ Adamo激发态电荷转移分析,请参考 Pop=DCT。
◆ Caricato耦合簇运动方程(EOM-CC)溶剂化迭代模型,请参考 SCRF=PTED。
◆ 广义内坐标:可以任意定义内坐标用于限制性优化或者其它目的,请参考 Geom=GIC 及GIC Info。
性能提升
◆ Hartree-Fock及DFT计算在Linux系统下支持P100 (Pascal),[REV B] NVIDIA K40及K80 GPUs,上述GPUs显卡计算性能都得到了提升。具体请参考 Using GPUs。
◆ 多核芯(数量较多)处理器的并行效率已经得到提升。对于多CPUs及集群如何优化性能请参考 Parallel Performance。
◆ [REV B] Linda版本计算现已默认为动态任务分配,并行效率得到提升。
◆ Gaussian 16使用优化的内存算法来避免CCSD迭代时的磁盘读写。
◆ GEDIIS优化算法效率已得到提升。
◆ CASSCF 方法活性空间≥ (10,10) 的计算性能得到提升并可以扩展至16个轨道(取决于分子类型)。
◆ W1 组合方法的核相关能(core correlation energies)计算速度得到巨大提升。
◆ Gaussian 16 对于复合电子传播(composite electron propagator, CEP, DiazTinoco16)方法中的对角化、二阶自能量近似(second-order self-energy approximation, D2)的计算性能得到巨大提升。请参考 EPT.
用法提升
◆ [REV B] ChkChk 功能可通知作业状态,如是否正常结束、出错或者正在运行中。
◆ [REV B] 输入文件中原子半径可以在原子行定义(非点电荷原子)。使用RadNuclear=val 方式在原子行中定义(浮点型,原子单位),如:
C(RadNucl=0.001) 0.0 0.0 3.0◆ 提供其它软件的接口工具,包括汇编语言(Fortran和C)以及解释语言(Python和Perl)。具体细节请参考 Interfacing to Gaussian 16。
[REV B] 在矩阵元文件中增加了诸多物理量,如原子布居、单电子和性质算符矩阵、非绝热耦合矢量。新增表示如下: QUADRUPOLE INTEGRALS, OCTOPOLE INTEGRALS, HEXADECAPOLE INTEGRALS, [MULLIKEN,ESP,AIM,NPA,MBS] CHARGES, DIP VEL INTEGRALS, R X DEL INTEGRALS, OVERLAP DERIVATIVES, CORE HAMILTONIAN DERIVATIVES, F(X), DENSITY DERIVATIVES, FOCK DERIVATIVES, ALPHA UX, BETA UX, ALPHA MO DERIVATIVES, BETA MO DERIVATIVES, [Alpha,Beta] [SCF,MP2,MP3,MP4,CI Rho(1),CI,CC] DENSITY and TRANS MO COEFFICIENTS and the scalars 63-64◆ 输入文件Link 0 (%)中以及/或者 Default.Route 文件中的相关参数目前也能够通过命令行形式或者环境变量指定。[REV B] 可以用命令行使用chk文件或矩阵元文件来定义输入文件或具体数据。具体细节请参考 Link 0 Equivalences或 command line options。
◆ 优化过程中可以指定每N步重新计算力常数。请参考Opt=Recalc。
◆ [REV B] DFTB参数在产生基组之前的L301层读入,因此元素是否有d函数可以在参数文件中提取。
-
与Gaussian 09的区别
默认参数
下列默认参数在Gaussian 16中与Gaussian 09不同:
◆ 积分精度为10-12 而不是Gaussian 09中的10-10。
◆ DFT 默认格点为 UltraFine 而不是 G09中的FineGrid;CPHF默认格点为 SG1 而不是 CoarseGrid。具体细节请参考Integral。
◆ SCRF 默认为IEFPCM的对称形式(symmetric form of IEFPCM) [Lipparini10] (Gaussian 09中没有此功能)而不是非对称形式。
◆ 物理常数使用2010版而不是Gaussian 09中的2006版。
前两项变化是为了保证一系列新方法的精度(如TD-DFT频率, 非谐振ROA),因此使用 Integral=(UltraFine,Acc2E=12) 作为默认选项。使用这些设置一般能提高数值积分的可靠性,比如溶剂化模型下的DFT优化。相比于Gaussian 09的默认值Integral=(FineGrid,Acc2E=10),此设置对CPU的需求稍有升高。
G09Defaults 关键词能够把上述默认值重新定义为Gaussian 09 默认值。它提供了与此前计算的兼容性,但对于新的计算我们推荐使用新的默认值。
默认内存值
Gaussian 16 默认内存为 %Mem=100MW (800MB)。使用多核计算大分子体系时使用更大的内存更为适合。具体细节请参考 Parallel Jobs。
TD-DFT频率
TDDFT 频率在计算二阶导数时默认使用解析二阶导数,这比数值导数快很多(数值导数在Gaussian 09中是唯一选项)。
-
GPUs的使用
Gaussian 16 在Linux系统下支持 NVIDIA K40,K80 和P100 GPUs(P100需要B.01版本支持)。较早的GPUs不具备计算能力或者足够的内存来运行Gaussian 16。
作业内存分配
GPUs在计算时需要分配足够的内存,这比使用CPUs计算时更重要,因为高效使用GUPs时会有大量任务同时运行。K40和K80系列显卡拥有高达16 GB内存,一般情况下,大部分内存都应当用于Gaussian程序。比如每个GPU有12GB内存时,给Gaussian分配8-9 GB内存效果比较好;同理,每个GPU有16GB内存时,给Gaussian分配11-12 GB内存效果比较好。此外,每个CPU线程至少需要分配相同的内存用于控制GPU。
关于CPUs控制
当使用GUPs时,每个GPU必须由一个特定的CPU控制。该CPU应该在物理架构上更靠近所控制的GPU,并且GPUs不能共享CPUs控制。另外需要注意,用于控制GPU的CPUs 不能再用于做计算节点。
在装有GUPs的系统上查看硬件架构可以使用 nvidia-dmi 功能。例如,下面演示的是双芯片16核Haswell CPU及三芯片K80板(每个板拥有2个GPUs)的架构:
GPU0 GPU1 GPU2 GPU3 GPU4 GPU5 GPU6 GPU7 CPU Affinity
GPU0 X PIX SOC SOCSOCSOCSOCSOC0-15 第一块芯片上的核
GPU1 PIX X SOC SOCSOCSOCSOCSOC 0-15
GPU2 SOC SOC X PIX PHB PHBPHBPHB16-31 第二块芯片上的核
GPU3 SOCSOC PIX X PHB PHBPHBPHB 16-31
GPU4 SOCSOC PHB PHB X PIX PXB PXB 16-31
GPU5 SOCSOC PHB PHB PIX X PXB PXB 16-31
GPU6 SOCSOC PHB PHB PXB PXB X PIX 16-31
GPU7 SOCSOC PHB PHB PXB PXB PIX X 16-31
示例中最重要的部分是CPU亲密度(CPU affinity)。此例中显示 GPUs 0和1 (第一块K80卡) 与第一块CPUs芯片相连,而GPUs 2-7 (第二块K80卡) 与第二块CPUs芯片相连。
为Gaussian 作业指定GPUs及CPUs控制
用于计算的GPUs及用于控制的CPUs可通过Link 0 部分使用%GPUCPU 命令指定。此命令有一个参数:
%GPUCPU=gpu-list=control-cpus
其中 gpu-list 为GPU列表(用逗号隔开),也可以是数值范围(例如, 0-4,6);control-cpus 为相似格式的控制CPU列表,这两列的内容是GPU及控制CPU。
例如, 在配有6 GPUs的32核系统里,给一个作业分配所有CPUs (26 CPUs用于做部分计算) 及6CPUs用于控制GPUs可以在Link 0 部分使用如下命令:
%CPU=0-31 控制CPUs也在此列表中。
%GPUCPU=0,1,2,3,4,5=0,1,16,17,18,19 nbsp;
上述命令定义 CPUs 0-31 将用于此作业(尽管并不是所有CPUs都用于计算)。此作业将使用GPUs 0-5,并且CPU 0控制GPU0,CPU 1控制GPU1,CPU 16控制GPU2,CPU 17控制GPU3等等。注意控制CPUs也包含在%CPU列表中。
在上例中, GPU及CPU列中可以表述的更加简洁:
%CPU=0-31
%GPUCPU=0-5=0-1,16-19
一般情况下我们都使用连续编号的核,但在一些特殊情况下并非如此。例如,假设在同一台机器上已经有一个作业占用了6 CPUs,使用的是%CPU=16-21。那么,如果想要使用其它26 CPUs 并且其中6个用于控制GPUs,可以使用如下定义:
%CPU=0-15,22-31 &
%GPUCPU=0-5=0-1,22-25
这个作业将会使用26个核,其中20个核用于计算,6个核用于控制GPUs (分别为CPUs 0, 1, 22, 23, 24, 25)。
[REV B] 中将会先将列表中的的CPU和GPU归类,然后匹配。这确保了编号最低的线程在有GPUs的CPUs上执行。这样可确保如果部分计算中由于减少处理器数目(如内存限制时),将优先使用/保留GPU线程(因为它是逆向移除线程的)。
GPUs及其性能
在对大分子体系进行DFT能量、梯度及频率(适用于基态及激发态)计算时,GPUs性能才有较好体现。小分子体系计算时并不能体现GPUs性能。此外,在后自洽场(post-SCF)计算中(例如MP2或CCSD),使用GPUs效果并不明显。
单个GPU计算速度比单个CPU快许多倍。但如今的机器往往CPUs数目远超过GPUs,因此只有使用所有的CPUs及GPUs才能获得最好的性能。
在某些情况下,GUPs预期加速效果会受到抑制,因为Gaussian 16将会使用到更多的CPUs。例如,假设GPU计算速度比CPU快5倍,那么使用GPU的计算速度相比于CPU将会是5倍。但是在一台配备32CPUs及8GPUs的大型服务器下使用GPUs的预期加速效果却是2倍:
Without GPUs: 32*1 = 32
With GPUs: (24*1) + (8*5) = 64 注意控制CPU并没有参与计算
Speedup: 64/32 = 2所以你必须认真考虑你的服务器配置及环境来决定该如何使用CPUs及GPUs
集群下的GPUs
支持集群中节点上的GPUs。因为 %CPU and %GPUCPU 只是定义了每个节点中的情况,因此要求每个节点有相同的配置,不过一般情况下集群中的节点配置都是相同的,所以通常这不是问题。
-
并行性能
共享内存并行(Shared-memory parallelism)
内存分配。大分子体系使用大基组计算时,分配更多的内存计算速度将更快。对于50个或者更多原子体系及/或500个或更多基函数的体系建议每个核分配4 GB内存。freqmem 功能可以估计基态及激发态频率计算中单个线程所需要的内存大小。所需内存要按照使用的核数递增,比如单核需要4GB,则8CPUs则需要32GB。当然,有些特殊硬件在内存大小上受到限制,但是内存需求随着核数目的增长而线性增加是理想的目标。值得注意的是,在内存固定不变的情况下,随着核数目增加(较多核情况下)计算性能无法提高。
对于大体系频率计算及大体系(相对而言)CCSD和EOM-CCSD能量计算,建议有足够的内存用来缓存大的磁盘文件。因此,Gaussian作业建议使用系统总内存的50-70%。例如,在一台配有128 GB内存的服务器上,当使用所有CPUs时,一般指定64-80 GB,剩下的内存则用于系统本身的硬盘缓存。
绑定CPUs线程。当线程从一个CPU转到另一个CPU时,会造成缓存无效或者引起其它问题,因此计算效率会明显下降。在大多数服务器上,Gaussian 能够把线程绑定到特定的CPUs上,特别在使用大量核时,这是推荐模式。Link 0部分的%CPU明确定义了所使用的CPUs数目,因此在一台8核的服务器上,设定%CPU=0?7 比 %NProc=8更好,因为前者把第一个线程绑定到CPU 0上,下一个线程绑定到CPU 1,等等。
在一些老Intel处理器上(Nehalem及之前版本),因其没有足够的内存带宽而无法让所有的CPUs工作,所以推荐使用一半CPUs并分配原来两倍大小的内存。例如,在一台四芯片12核(CPUs 0-11 位于第一个芯片;12-23 位于第二个芯片,等等)和128GB内存的服务器上,推荐使用24核(每个芯片使用6核)并为每个核指定72 GB/24 procs = 3 GB内存,而不是使用全部48核(每个核只有1.5GB内存)。输入文件如下:
%Mem=72GB
%CPU=0-47/2
此处 /2 意味着将会间隔使用核芯,比如cores 0, 2, 4, 6, 8及10 (芯片0), 12, 14, 16, 18, 20及22 (芯片1),等等。
新的Intel处理器 (Haswell及此后版本)因为内存带宽有明显改进,因此使用芯片上所有核进行计算时效果较好。
只要有足够的内存以及每个线程都绑定到特定核时,使用64核甚至更多核计算时效率依然很高。
关闭超线程。超线程对于Gaussian无效,因为它把同一个物理CPU的资源(比如内存带宽)分割给不同的线程。如果超线程无法关闭,Gaussian作业应该在每个物理CPU上只使用一个超线程。对于Linux系统,不同核的超线程是编组在一起的,比如一台两芯片(8核,3路超线程)的服务器,“CPUs” 0-7 为chip 0上的8核, 8-15为chip 1上的8核,16-23 为chip 0 上8核的第二个线程,等等。因此Gaussian作业建议指定%CPU=0?15。
集群并行(Linda)
适用范围。Hartree-Fock及DFT能量、梯度、频率计算以及MP2能量和梯度计算能够在集群上有效并行,而MP2 频率、CCSD及EOM-CCSD能量和优化只支持SMP并行(单节点)。对于数值导数(Numerical derivatives),比如DFT非谐振频率和CCSD 频率,支持Linda并行计算。
与SMP组合并行。共享式并行及集群并行能够进行组合。一般来说集群中的每个节点都支持所有CPUs共享内存并行。注意 %CPU 及 %Mem 适用于集群中的每个节点。因此,如果一台服务器有3个节点,名字为apple, banana 及cherry,每个节点有两个芯片8核,此时可指定:
%Mem=64GB
%CPU=0-15
%LindaWorkers=apple,banana,cherry
# B3LYP/6-311+G(2d,p) Freq …
这样每个节点将会运行16个线程,在3个节点上每个线程都绑定到一个核上,并且48个线程中每个线程将获得4GB内存。
对于一些特殊情况(数值微分),比如 Freq=Anharm, CCSD Freq,等等—将有另外一个节点用于收集结果。因此,这些计算会在管理节点(Gaussian 16启动的节点)同时运行两个任务,例如计算非谐振频率,可指定:
%Mem=64GB
%CPU=0-15
%LindaWorkers=apple:2,banana,cherry
# B3LYP/6-311+G(2d,p) Freq=Anharm …
此处假设Gaussian 16在 apple节点启动,这里将在apple节点启动2个任务,一个仅用于收集结果,apple节点其它的核和banana及cherry将用于计算。
-
CCSD性能
CCSD, CCSD(T)及EOM-CCSD计算内存需求
如果有足够内存来存储振幅(amplitudes)及矢量积(product vectors),上述计算则可以使用内存来避免读写错误而使计算变得更加高效。如果体系有 NO 个活性占据轨道(NOA in the output)及NV 个空轨道(NVB in the output),那么所需内存则为 9NO2NV2 字节,这与所使用的核数无关。
-
Link 0中的等价定义
用于控制Gaussian 16运行的许多选项可以使用4种方法指定,其优先级从高到低如下所示:
1. Link 0 输入 (%-lines):这是一个常用方法,它可以用于控制单个作业及并且它是多步计算中控制其中一个特定作业的唯一方式。例如:
%CPU=1,2,3,4
2.&nnbsp;命令行:当我们想使用不常见方式运行程序的时候此方法比较有用。例如:
g16 -c="1,2,3,4" …
3. 环境变量:此方法对于标准脚本,例如生成和提交作业到队列系统时非常有用。例如:
export GAUSS_CDEF="1,2,3,4"
4. Default.Route文件:此方法对于我们想改变程序默认参数式非常有用。例如:
-C- 1,2,3,4
程序会首先检查当前目录下的Default.Route文件,然后 检查Gausssian 16运行程序所在目录,也就是环境变量GAUSS_EXEDIR所指定的目录,此目录一般为 $g16root/g16。
下表列出了Link 0命令中的等价定义,命令行选项,Default.Route项目,环境变量等。-h,-o选项和-i,-o选项类别为[REV B]版本中新引入的,相应的环境变量也是一样新引入的:
Default.Route
Link 0
Option
Env. Var.
Description
Gaussian 16 execution defaults
-R-
-r
GAUSS_RDEF
Route section keyword list.
-M-
%Mem
-m
GAUSS_MDEF
Memory amount for Gaussian jobs.
-C-
%CPU
-c
GAUSS_CDEF
Processor/core list for multiprocessor parallel jobs.
-G-
%GPUCPU
-g
GAUSS_GDEF
GPUs=Cores list for GPU parallel jobs.
-S-
%UseSSH
-s
GAUSS_SDEF
Program to start workers for network parallel jobs: rsh or ssh.
-W-
%LindaWorkers
-w
GAUSS_WDEF
List of hostnames for network parallel jobs.
-P-
%NProcShared
-p
GAUSS_PDEF
#processors/cores for multiprocessor parallel jobs. Deprecated; use -C-.
-L-
%NProcLinda
-l
GAUSS_LDEF
#nodes for network parallel jobs. Deprecated; use -W-.
Archive entry data
-H-
GAUSS_HDEF
Computer hostname.
-O-
GAUSS_ODEF
Organization (site) name.
Utility program defaults
-F-
GAUSS_FDEF
Options for the formchk utility.
-U-
GAUSS_UDEF
Memory amount for utilities.
Parameters for scripts and external programs
# section
-x
GAUSS_XDEF
Complete route for the job (route not read from input file).
%Chk
-y
GAUSS_YDEF
Checkpoint file
%RWF
-z
GAUSS_ZDEF
Read-write file.
注意对于命令行与及环境变量的明确数值一般需要用引号标注,以避免系统shell改变这些参数。例如:g16 -c="1,2,3,4" …
-
Rev B.01中bug修复
◆ 从RWF文件重新计算时使用 SCF=QC 遇到的问题已修复。
◆ 在 SCF=XQC 或 SCF=YQC 计算中运行常规SCF步骤时,只有当找到最低能量波函数时,轨道和密度才会被保存。如果 L502 没有收敛,且开始进行L508 (QC or steepest descent SCF)计算时,将会使用常规SCF的最优波函数。
◆ EOM-CC从RWF文件重新计算时的问题已修复。
◆ ROMP4和EOM-CC 计算时由于空β自旋空间(beta spin-space)或全α自旋空间(full alpha spin-space)产生的问题已修复。
◆ G4和G4MP2任务总结表中的错误编号已修复。
◆ NBO计算时,RWF文件物理分割时的临时文件命名问题已修复。
◆ CIS和TD方法计算大分子频率时使用很小内存的分配问题已修复。这些任务已能完成,但是如果给更多的内存,效率会更高。
◆ 使用FormCheck时产生的问题已经修复。此关键词已弃用,命令行中使用 -fchk 选项将是更好的选择。
◆ 使用formchk处理PCM溶剂化计算时的chk文件输出的不必要的警告已经移除。
◆ Opt=(TS,ReCalcFC=N) Route问题已修复。
◆ 分子力学参数已经正确储存到fchk文件中。
◆ NBO6 (Pop=NBO6Del) 中运行的问题已修复。
◆ 多步作业中在后续步骤阻止GPUs运算的问题已修复。
◆ 已弃用原子性质列表关键词QMom和Magneton 解析时的问题已修复。