Dear Marc,
Ah yes, bloody higher angular momentum Gaussian functions (
f and
g funtions for our purposes). A topic which has been very much on my mind recently.
First note that (1) they are very expensive to evaluate in QMC compared to
s,
p,
d, and (2) there isn't much evidence that they help to provide a significantly better nodal surface of the many-electron wave function, so they are of less help in QMC than they are in doing standard post-HF quantum chemistry techniques (CI, or coupled cluster, or whatever). So you may want to consider not using them, but.. OK..
Right, I realized recently (November, or something like that) that I'd been guilty of letting the interfaces with the various Gaussian codes drift a bit, and in some cases there is evidence that there are problems with
f and
g functions. Because it's very boring to maintain interfaces with other peoples' codes (particularly where the authors of said codes don't give a toss about QMC and/or there is limited or no documentation available) it's not something that I voluntarily spend much time on, but in the interests of completeness here we go.
First of all, you can see that the polynomial expressions for the
g functions and their first two analytic derivatives (in the form of gradient and Laplacian) are very complicated. Thus it is easy to bugger up the implementation. Second, the conventions for normalization, and as to whether or not you include the coefficients of the solid harmonics (is it
3(x^2 - y^2) or
(x^2-y^2)?) differ from program to program. See e.g. my discussion with reference to the CRYSTAL code here:
http://www.tcm.phy.cam.ac.uk/~mdt26/REA ... ss_dfg.txt
CASINO is able to evaluate only harmonic Gaussians, so codes which use Cartesian Gaussians have to do some sort of conversion which we haven't yet documented in the manual. This is clearly another layer of complication.
So, in order to test the current state of
f and
g function support I've set up a test suite, which you can find in
CASINO/examples/generic/gauss_dfg in the current_beta distribution of CASINO. What I've done us to take a standard methane molecule and set up three test cases with only
d functions ('d-ane'), only
f functions (f-ane), and only
g functions (g-ane) in the basis set. The idea is that a third-party Gaussian basis set code can be said to be 'supported' by CASINO, if the Hartree-Fock energy produced by the third-party code for each of these test cases, and the energy computed by CASINO in HF mode (i.e. where the wave function consists only of the determinant part without a Jastrow factor etc.) is the same.
OK, now the first problem is that that some of the third-party codes don't agree with each other independently of CASINO, and I don't understand why this is. For example, the energy for the 'f-ane' molecule is -11.3966 with CRYSTAL09 and GAUSSIAN03 and has a completely different value for GAMESS and MOLPRO (-11.2286). [CASINO produces essentially the first number if fed with a CRYSTAL or GAUSSIAN gwfn.data, but the GAMESS and MOLPRO conversion utilities for CASINO don't yet support
f or
g functions].
To actually answer your question, the energy for 'g-ane' is different with GAUSSIAN03/09 and CASINO (using a GAUSSIAN generated gwfn.data file). CASINO analytic
g orbital derivatives are numerically self-consistent (that is - the analytic formulae coded in CASINO for the orbital derivatives have been verified to be the correct derivatives of the analytic formulae coded for the values of the orbitals - so either (a) CASINO has the formulae for
g functions wrong in its orbital evaluator (and its analytic derivatives are the correct derivatives of these wrong formulae), or (b) the GAUSSIAN converter doesn't work for
g functions, or (c) there's some screwup with the harmonic/Cartesian conversion. I don't know which of these is the problem, and it's difficult for me to investigate as I don't have a license to use GAUSSIAN.
The status of GAMESS is :
Albert Defusco is implementing a CASINO converter which will be part of the GAMESS distribution, but he hasn't finished it yet. For the moment CASINO has its own converter -- a Perl script written by Alexander Badinski -- but it's a bit rubbish (Alex would agree, bless him) and it simply doesn't work for
f and
g functions.
The status of CRYSTAL is :
It has been verified to work in all cases for all angular momenta up to
f. However, CRYSTAL itself does not do
g functions, so it won't help you..
The status of MOLPRO is :
Mike Deible is implementing a CASINO converter but he hasn't finished it yet (
f and
g functions being one of the major stumbling blocks). Once this is done - since it reads the standard MOLDEN format - this should also provide support for codes like C4 and Psi-4 (and possibly stuff like ACESII, MOLCAS, DALTON, Jaguar, CADPAC, GEOMOP, and HONDO).
The status of TURBOMOLE is:
The interface provided with CASINO no longer works, because it's for a very old version of TURBOMOLE (but TURBOMOLE supports the MOLDEN format - see above).
So, the final answer to your question is that no third-party code has yet been verified to support CASINO with
g functions. This is a bit ridiculous, since I implemented the CASINO
g function orbital evaluator in something like 1998, and I hope to get this sorted soon. If you can provide any help with GAUSSIAN, that would be great (all the input files for the various cases should be in the CASINO distribution in the directory mentioned above). I intend to get in touch with Mike and Albert this week to see how they're getting on with the other interfaces.
Best wishes,
Mike
PS: there is lots more information about interfaces on the website:
http://vallico.net/casinoqmc/interfaces/
http://vallico.net/casinoqmc/interface_development/