Hi all,
Furthermore, the d-orbitals (l = 2) are treated specially and have their own, nonstandard,
additional normalization factor in CASINO. The additional normalization..
I'm not sure I would describe this as an 'additional normalization factor' as Katharina does. This makes it sound like something mathematically profound is being done, whereas it's in reality just an efficiency issue.
Just to be clear and simple, let's say we have a single orbital expanded in a Gaussian basis consisting of a single uncontracted
d shell with exponent
a. For the harmonic case this shell defines 5 separate basis functions
g_i * exp(-a|r|^2) where the
g_i are polynomials in
x,y,z. The orbital is then given by
Phi(r)=(sum_i c_i g_i ) * exp(-a|r|^2) where the
c_i are the suitably normalized orbital coefficients..
For a
d shell, as Vladimir has correctly divined, the real solid harmonics
g_i that we use are:
Code: Select all
g_1 = 0.5 * (3z^2 - r^2)
g_2 = 3xz
g_3 = 3yz
g_4 = 3(x^2-y^2)
g_5 = 6xy
Looking at e.g.
g_5 = 6xy we see there is a constant factor
6 and since the expression for the orbital involves products
c_i * g_i this factor can either (1) be premultiplied into the orbital coefficients
c_i, or (2) multiplied into each new value of
xy 'on the fly. Option (1) would be done by the Gaussian/GAMESS/Orca/MOLDEN (or whatever..) converter, Option (2) by CASINO itself. From the point of view of 'tidiness' (2) is preferable since we maintain a nice separation between the basis functions as defined in our standard reference, and the orbital coefficients as generated by the external program. However if we look at efficiency we see that (1) requires a single multiplication, and (2) requires several billion repetitions of the same multiplication over the course of a long simulation, so (1) is clearly preferable and that's the convention I chose when I originally developed this.
To understand where we are today, let's just look at the historical development:
I wrote the first version of the CASINO Gaussian orbital evaluator long ago in 1997. At that time the only Gaussian basis set code I had access to was the CRYSTAL program (which - despite the name - does atoms and molecules as well as periodic systems and so it was all I needed). However, CRYSTAL only implemented
s,
p,
d and so that's what I did originally for CASINO. At that time, the convention above was clear: '
all constant numerical factors in the Gaussian basis functions must be premultiplied into the orbital coefficients by the converter program'. The
s and
p functions have no such numerical factors - only the
d - and so everything was consistent at that point.
Several years later the CRYSTAL people implemented
f functions, and consequently I did the same in CASINO. They had told me they were in the process of doing
g functions, and so I coded that up in CASINO too. However the CRYSTAL
g functions never appeared (and still haven't even today) and so the
g part of the code was left unused and untested for many years. My original
g implementation in CASINO in fact, somewhat miraculously, turned out to be correct - but as Katharina showed relatively recently the only converter ever to try to deal with
g functions - Andrew Porter's
gaussian2qmc - was not implemented correctly. We think it now is.
Now the main point is - when I did the
f and
g implementation I abandoned the convention about constant numerical factors being premultiplied into the orbital coefficients by the converter. In retrospect this was probably a mistake, and I can't quite remember why I did that. It was probably a mixture of (1) not caring about efficiency thinking no-one would ever use
f and
g, the implementation only being for 'completeness', (2) the numerical factors being much more 'messy' than in the
d case, (3) the complication of the expressions particularly when you get to the analytic second derivatives meaning the premultiplication gives less of a saving - not that it buys you all that much even in the
d case, but this is QMC and every little helps, (4) being very young, and (5) I may even have forgotten about this convention given the several years gap between
s,
p,
d and
f,
g.
Now once we've adopted a convention for this it becomes very difficult to change it without breaking all pre-existing
gwfn.data files, and that probably wouldn't be a very good idea. Once I became aware of the issue I took the view that in the documentation we should just write down the solid harmonics as defined in the original standard reference that I used (the 'Orange book' referred to in Vladimir's post - see the relevant pages at
http://www.tcm.phy.cam.ac.uk/~mdt26/cry ... monics.pdf ) along with the formulae for the normalization coefficients and then accompany them with a statement of the convention: '
all constant factors in our real solid harmonics up to L=2 (effectively d only) must be premultiplied into the orbital coefficients, but not for L>2.' I appreciate this is a little inelegant, but it's clear and it shouldn't cause any problems for the writers of CASINO interfaces to external programs.
Never having had to deal with a Cartesian to spherical conversion myself (CRYSTAL uses
5d7f spherical solid harmonics natively..) I allowed converter authors to have their own adventures doing this for their own codes, and hoped they would be able to work it out...
I've been threatening for several weeks to synthesize all relevant information on this in a new appendix to the CASINO manual. All the stuff currently in the
gauss_dfg/REAME file will be put in there, and hopefully some example Cartesian --> spherical stuff of the kind that Kevin and our Pittsburgh friends have been working on. However, as so often this year, life keeps intruding. Hopefully soon.
Mike