美國Gaussian公司于2019年7月24日發(fā)布了Gaussian16 Revision C.01; GaussView6.1.1; TCP-Linda9.2; GMMX3.1版本。

Gaussian16 C.01版本的Linda版需要將Linda 升級至 TCP-Linda 9.2。

根據(jù)美國Gaussian公司的規(guī)定：2019年4月1日之后購買 Gaussian 16 Revision B.01, TCP-Linda 9.1,GMMX 3.0, GaussView 6.0.16 軟件的用戶，將在幾周內(nèi)收到美國Gaussian公司寄出的免費升級軟件。

以下是Gaussian 16 Revision C.01 Release Notes，方便大家了解。

新模擬方法

·        [REV C] 支持NBO 7軟件接口。此版本有許多新的選項：Keyword: Pop=NPA7, Pop=NBO7, Pop=NBO7Read 及 Pop=NBO7Delete。分別代表需要計算自然布居分析(Natural Population Analysis)，全自然鍵軌道分析(full Natural Bond Orbital Analysis)，從輸入文件讀取信息的全NBO分析以及考慮剔除某些作用影響之后的NBO分析。此外，Pop=NEDA 可用于分析自然能量分解分析(Natural Energy Decomposition Analysis)。此功能所使用的分子碎片輸入文件信息與計算BSSE校正時一樣.

·        [REV C] The RESP (restrained electrostatic potential) 電荷可以在計算potential-derived charges時使用。例如, Pop=(MK,Resp=N) 將 N x 10^-6 Hartrees電荷施加于平方電荷. 其它靜電勢導出的電荷方法都可以使用此選項。(如 CHelp, HLY). N 默認值為2.

·        [REV C] Pop=SaveHirshfeld 及 Pop=SaveCM5 可以保存特定形式的電荷到MM電荷中，以便于接下來的計算。

性能提升

·        Hartree-Fock及DFT計算在Linux系統(tǒng)下支持V100(Volta, [REV C]), P100 (Pascal, [REV B]), NVIDIA K40及K80 GPUs，上述GPUs顯卡計算性能都得到了提升。具體請參考 Using GPUs

用法提升

·        [REV C] 每個振動模式的ROA不變量現(xiàn)在只由G16或freqchk輸出(如果指定了正常模式），而不是默認輸出。

·        [REV C] Utilities 模塊中現(xiàn)在能使用 -m 參數(shù)指定所使用內(nèi)存大小。例如:

formchk -m=1gb myfile -m 選項必須寫在文件名或者其它參數(shù)前。

·        [REV C]  Link 0命令中%SSH 及其等效命令可用于啟動Linda workers, 而不是用rsh 或 ssh。

·        [REV C] 當指定 Geom=AllCheck時一些默認項可以重新設(shè)置:

·        Field=NoChk 可用于禁止從chk文件讀取外場系數(shù)。

·        Geom=GenConnectivity 強制重新計算原子連接關(guān)系，而不是使用chk文件中的信息。

·        Geom=UseStandardOrientation 使用chk文件中的標準坐標作為新作業(yè)的坐標

·        [REV C] 穩(wěn)態(tài)結(jié)構(gòu)優(yōu)化中的一些默認項可以重新設(shè)置:

·        Opt=NGoUp=N 在只進行線性搜索之前，允許能量增加N倍。默認值為1（在第二次能量增加后只執(zhí)行線性搜索）；n=-1表示在能量增加時強制執(zhí)行線性搜索。

·        當接近鞍點時，Opt=NGoDown=N使程序?qū)?/span>Hessian的最多N個特征向量與負特征值混合，形成遠離鞍點的一步。默認值為3；N=-1表示關(guān)閉此功能，并且算法只執(zhí)行常規(guī)的RFO步驟。

·        Opt=MaxEStep=N 表示從鞍點離開時，下一步要移動的長度為N/1000 (Bohr or radians)。對于常規(guī)優(yōu)化，默認值為N=600 (0.6)，對于ONIOMOpt=Quadmac 計算，默認值為N=100 (0.1)。

·        [REV C] 多維勢能面掃描的信息現(xiàn)在存儲在fchk文件中，其中包含有關(guān)軸的詳細信息，因此這些信息可以顯示在GaussView和其他程序中。

·        [REV C] 本版本將在chk文件中存儲和檢查版本號。這可以避免由于不同版本chk文件導致的各種復雜問題。c8616程序可用于更新chk文件。并且-fixver選項可以 unfchk，即使輸入格式的chk文件中沒有版本，它也會自動創(chuàng)建一個當前版本。

·        [REV C] 支持使用4字節(jié)或8字節(jié)整數(shù)的原始二進制文件。默認為4字節(jié)(NEC系統(tǒng)除外)。此功能支持包括Output 關(guān)鍵詞和formchk程序的新選項、新的Link 0命令以及新的命令行選項和環(huán)境變量。

·        [REV C] 本版本將向矩陣元素文件中添加有關(guān)ONIOM層、優(yōu)化和軌跡結(jié)果的信息。它還為Output 關(guān)鍵詞增加了新的選項，包括AO雙電子積分、重疊導數(shù)、核心哈密頓量和其他矩陣和/或AO 雙電子積分導數(shù)。

·        [REV C] 腳本功能增強：

·        ONIOM方法中當使用外部程序/腳本時，外部關(guān)鍵字(External keyword)的AllAtoms 及 ActiveAtoms用于提供所有原子的信息，或僅提供模型（高層）中的原子的信息。

·        $g16root/g16/bsd/inp2mat腳本接受Gaussian輸入文件并生成一個矩陣元素文件，其中包含輸入文件（坐標、基組等）所隱含的信息，而不進行完整的計算。這是由GauOpen中的python接口用來將這些信息導入到矩陣元文件中，但也可以在其他腳本中使用，以避免需要解析Gaussian輸入文件。

·        testrt 工具現(xiàn)在輸出G16使用的整數(shù)大小，以便腳本可以檢查在矩陣元文件中默認使用的整數(shù)大小。

Bug修復

以下內(nèi)容在C.01版本中得到修復:

·        在計算多個入射頻率的Raman 或 ROA時，使用Freq=Anharmonic產(chǎn)生的問題已修復。

·        高角動量和純DFT泛函計算時的內(nèi)存調(diào)用問題得到修復。

·        合理地跳過了DFTB參數(shù)文件中的內(nèi)容。

·        早期中止的任務chk文件使用chkchk遇到的問題已解決。

·        大分子體系中使用PM7R6方法的雜化項問題已經(jīng)得到解決。

·        將GVB代碼中被占軌道數(shù)的限制提高到1000，解決了大分子FMM和GVB的一些問題。

·        Grimme (D2或D3)色散校正與鬼原子(ghost atoms)的問題得到解決。

·        Punch=MO 及chkchk -p輸出的軌道能量問題已經(jīng)得到解決。

·        擴展名 -fck= (/fck= on Windows systems) 命令行參數(shù)問題已經(jīng)修復，默認為.fck ，但 .fchk 仍然有用。

·        在一般基組輸入中指定命名基組時，以前未檢測到的一些錯誤現(xiàn)在可以被識別出來。

·        解決了在ONIOM模型計算時在文件上運行 formchk的問題，或在計算期間停止的ONIOM作業(yè)的chk文件上運行formchk的問題。

·        修復了.fchk (或.fch)文件中MM參數(shù)值不完整或錯誤的問題。

·        Field=Read在使用密度擬合時，不再嘗試讀取兩次外場值。

·        CIS方法中的 SCF=Conventional 選項產(chǎn)生的錯誤默認值已經(jīng)得到修復。

·        鬼原子(ghost atoms)存在時使用Guess=Read產(chǎn)生的問題已經(jīng)得到修復。

·        Punch=GAMESS 現(xiàn)在支持 H 及更高的函數(shù)。

·        在輸入文件中的原子說明部分，又可以使用-2代表Tv 平移矢量。

·        解決了原子長鏈分子生成內(nèi)坐標的一些問題。

·        當雙電子積分閾值很小時，計算單電子導數(shù)的問題已修復。

·        當使用非默認后自洽場方法(如 MP2=FreezeG2)進行Opt+Freq計算時，不能進行頻率計算的問題已經(jīng)得到解決。

·        對incore內(nèi)存需求的低估問題（這可能導致作業(yè)默認為incore，然后導致內(nèi)存耗盡）被修復。