 |
SEARCH
TOOLBOX
LANGUAGES
Forum Menu
Gaussian-N composite thermochemical methods
From NWChem
Viewed 3555 times, With a total of 4 Posts
|
|
|
Clicked A Few Times
Threads 10
Posts 24
|
|
| 5:24:20 AM PDT - Sat, May 9th 2015 |
|
As I read the NWChem 6.5 release, the Curtiss, Redfern,et.al. G3, G3(MP2,QCISD), and and GAMESS G3(MP2,CCSDT) variants could be easily implemented in Python2.7 if the following changes were in place:
1. G3large basis set, preferably including 3rd row elements
2. RTDB variables for zero point energy in Hartrees ("vib:zpe")
3. RTDB variables for number of alpha and beta electrons (if only after MP2 tasks)
I mention the G3(MP2,CCSDT) variant since it is faster and more accurate than the original, particularly for problematic organo-fluorides. A full G3/99 test suite was not possible, but mean absolute deviations (MAD) for G3(MP2,CCSDT), G4(MP2), and CBS-QB3 were 1.8, 1.7, and 1.6 kcal/mol for my particular ~36 compound group.
The later G4 and G4(MP2) methods require the G3largeXP basis set. Both basis sets are available in Gaussian(tm) format at Curtiss' old ANL website [1].
Link is: http://www.cse.anl.gov/OldCHMwebsiteContent/compmat/comptherm.htm
I've crufted a translator to render these basis sets (which are in Gaussian (tm) data format) as NWCHEM files and would like to discuss this with interested parties.
|
|
|
|
|
|
Gets Around
Threads 18
Posts 133
|
|
| 10:27:37 AM PDT - Sat, May 9th 2015 |
|
EDIT: Oh, wait, it's YOU! I don't need to try to teach you anything about GAMESS. PM me :-)
This is one of my long-term interests with NWChem and other quantum chemistry packages that I am writing a job driver for. I did some preliminary tests last year. It is tricky to reproduce the Gn methods exactly in packages other than Gaussian because there is an implicit dependency on Gaussian's orbital freezing conventions for post-HF calculations. I suspect that mean unsigned error across the full test set will not be significantly different using non-Gaussian packages, but I couldn't get the exact same numbers as published when I tried assembling a composite calculation by hand for hydrogen sulfide.
It would be best if you could get the special basis sets submitted to the EMSL Basis Set Exchange. I already have a Python API to get basis sets out of the BSE, store them in a SQLite database, and offer programmable access to them in NWChem, GAMESS-US, and Gaussian94 formats.
After a long period of idling I have returned to the project, but I am working first on automating the individual steps I will need to perform composite calculations. Once that infrastructure is in place I can try whole test sets much faster, and hopefully identify sources/significance of deviations from published results.
I don't have access to Gaussian. I have been calibrating my work from the original publications, the occasional Gaussian log file that you can find on the web, and the composite thermochemical methods implemented in GAMESS-US and Psi4. The GAMESS implementations are quirky. You should search the GAMESS user group archives before diving in with them.
Psi4 has only G2MP2: http://sirius.chem.vt.edu/psi4manual/master/_modules/gaussian_n.html
It's a bit quirky also. It doesn't seem to work beyond first-row elements, and its output is different both because of orbital freezing conventions and because of other speed-for-accuracy tradeoffs used in Psi4 by default (e.g. density fitting for SCF). I have not tried Psi4's implementation across all the test set molecules where it can complete jobs. I should, though, to see how it compares with the published version.
Since I don't use HPC facilities any more and I want to keep my options open, I am writing my code to parse log files instead of use the RTDB, and run separate calculations for different phases of the composite approach. The RTDB approach is cleaner if you stick with NWChem, and of course it is advantageous to be able to submit a single job containing all the phases if you go through a job queue.
Both my basis set data API and the work-in-progress job driver code are on github. I don't want to self-promote here, so send me a PM if you are interested in the code.
|
|
Edited On 10:28:53 AM PDT - Sat, May 9th 2015 by Mernst
|
|
|
|
|
|
Clicked A Few Times
Threads 10
Posts 24
|
|
| 2:40:57 PM PDT - Sat, May 9th 2015 |
|
Quote:Mernst May 9th 11:27 amThis is one of my long-term interests with NWChem and other quantum chemistry packages that I am writing a job driver for. I did some preliminary tests last year. It is tricky to reproduce the Gn methods exactly in packages other than Gaussian because there is an implicit dependency on Gaussian's orbital freezing conventions for post-HF calculations.
I got a <100 microHartree (~1/16 kcal) agreement between NWChem, GAMESS, and Gaussian for single point energies on identical geometries last time I checked, but it took attention to the cartesian vs. spherical handling of basis sets. Of DFTs, B3LYP is a term of art, implementation dependent, and best avoided for reproducibility. wB97X-D, however, is your friend.
Quote: It would be best if you could get the special basis sets submitted to the EMSL Basis Set Exchange. I already have a Python API to get basis sets out of the BSE, store them in a SQLite database, and offer programmable access to them in NWChem, GAMESS-US, and Gaussian94 formats.
Will do. Curtiss delivered them as complete through the third row, so any G3(etc) using them can deliver accordingly.
Quote: I don't have access to Gaussian.
Ditto. No great loss, although the completeness and ease of use are impressive, if only in comparison to GAMESS.
Quote: I have been calibrating my work from the original publications, the occasional Gaussian log file that you can find on the web, and the composite thermochemical methods implemented in GAMESS-US and Psi4. The GAMESS implementations are quirky. You should search the GAMESS user group archives before diving in with them.
The GAMESS G3(MP2) implementation is good in its delta-Hf values but particular data sets in the source code are irreproducible. Lacking RO-CCSD(T), GAMESS could not have generated the necessary total energies for non-singlet atomic species and the author is not forthcoming about their origin. I'd hoped to extend it to 3rd row elements as per Curtiss, Redfern,et.al., but decided it would be like passing a twisted sardine can lid wasn't worth the trouble. GAMESS has incompletenesses and defects which have lain unaddressed for a decade and will probably never be fixed.
So here I am.
Quote: The RTDB approach is cleaner if you stick with NWChem, and of course it is advantageous to be able to submit a single job containing all the phases if you go through a job queue.
I want RTDB support that allows me to specify a geometry normally and write little beyond this:
print none
python
import g3mp2
(E0, H0, H298, G0, dHf0, dHf298) = g3mp2()
print "Energy(0K) = ", E0
print "Enthalpy(0K) = ", H0
print "Enthalpy(298K) = ", H298
print "Gibbs Free Energy= ", G0
print "Heat of Formation(0K) = ",dHf0
print "Heat of Formation(298K)= ",dHf298
end
task python
That, IMHO, would utterly rock! lead to clean implementations of G4(mumble) and assorted ccCA-? composite methods, perhaps even a CBS-QB3 which is often cited in the same paper as G4 results.
|
|
|
-
Edoapra Forum:Admin, Forum:Mod, bureaucrat, sysop
|
|
|
Forum Vet
Threads 9
Posts 1571
|
|
| 5:19:59 PM PDT - Thu, May 14th 2015 |
|
| Just checked into the svn repository a new version of routine vib_wrtfreq.F containing rtdb_put of vib:zpe, vib:ethermal, vib:htermal
|
|
|
|
|
|
Gets Around
Threads 18
Posts 133
|
|
| 2:33:22 PM PDT - Sun, May 31st 2015 |
|
TCE missing rtdb entry for "number frozen core" (patch supplied)
|
When you use 'freeze atomic' in a CCSD calculation, the rtdb values "ccsd:number frozen core" and "ccsd:frozen core:freeze by atoms" are available.
If you need to use the TCE implementation for CCSD, e.g. for open shell calculations, "tce:frozen core:freeze by atoms" is available but not "tce:number frozen core." This makes it hard to implement composite methods that incorporate the frozen core count (or derived values) as part of the high level correction.
This patch to tce_init.F adds "tce:number frozen core" to the rtdb. I note that in tce_init.F there are separate counts reserved for alpha and beta frozen cores, nfc(1) and nfc(2), but in practice it appears that the beta count is always set equal to the alpha count.
--- tce_init.F.bak 2015-05-31 10:39:45.869247867 -0700
+++ tce_init.F 2015-05-31 15:02:18.912596802 -0700
@@ -478,6 +478,10 @@
if (.not.rtdb_put(rtdb,'tce:ampnorms',mt_log,1,ampnorms))
1 call errquit('tce_init: failed to write ampnorms',0,RTDB_ERR)
endif
+c Frozen core counts to match non-TCE MP2/CCSD modules
+ if (.not.rtdb_put(rtdb,'tce:number frozen core',mt_int,1,nfc(1)))
+ 1 call errquit('tce_init: failed to write number frozen core',0,
+ 2 RTDB_ERR)
c
c Beginning of response property input section
c
|
|
|
AWC's:
2.5.10 MediaWiki - Stand Alone Forum Extension
Forum theme style by: AWC
| |
