CCL:G: GAUSSIAN/GAMESS/MOLPRO/CRYSTAL differences - summary + QMC request

 Sent to CCL by: "Mike  Towler" [mdt26_-_cam.ac.uk]
 Dear all,
 About a week ago I asked a question about why GAUSSIAN, GAMESS, MOLPRO,
 and CRYSTAL were giving very different answers in test calculations for a
 methane molecule, using basis sets consisting only of functions of a
 particular high angular momentum (f functions only, in the example I
 presented). I just wanted to summarize the responses, and to make an
 additional request.
 Many thanks for all the replies, especially to Susi Lehtola, Mikael
 Johansson, William McDonald, Raghu, and in particular to Wenli (Zork
 Zou?), who all gave helpful responses leading to the right answer, which
 was that GAUSSIAN and CRYSTAL manage to produce lower-energy
 symmetry-broken solutions all by themselves, whereas GAMESS and MOLPRO
 require specific keyword incantations to kick them off a saddle point into
 the broken-symmetry state:
 MOLPRO: {hf;noenest;occ,1,2,1,1}
 GAMESS: $GUESS ORDER=1 IORDER(2)=6,3,4,5,2 $END
 Some people also suggested that I was using a poor quality basis set, and
 I needed to include s,p,d functions etc.. As any fule kno, this is quite
 true, and would be a concern if my aim were to calculate some property of
 the methane molecule. However, as I said in my original mail, these
 calculations are being done to check the correctness of the interface
 between our quantum Monte Carlo code 'CASINO' and various other quantum
 chemistry codes such as the four mentioned here. For a number of reasons,
 these interfaces are very easy to screw up for higher angular momentum
 Gaussians, and it's very helpful to check each value of L individually
 (and also to have all the MO coefficients having non-zero values, which is
 why I chose the tetrahedral symmetry..).
 Even though it's helpful for comparison purposes that GAUSSIAN, GAMESS
 etc. all end up in same state, it doesn't matter overall what state we end
 up in (e.g. the broken symmetry state, or the symmetric one); any state
 represents some many-body wave function which can be communicated to
 CASINO. The formula for the expectation value of the energy can then be
 numerically integrated by evaluating the wave function at random points in
 the configuration space (Monte Carlo integration). Hopefully this will
 give the same answer as the initial code running in HF mode. (Once that is
 verified, propagation in imaginary time will 'improve' the wave function
 and massage it towards the true ground state, but that's another story).
 Speaking of interfaces, here's my additional request, which concerns the
 new public release of CASINO which we're hoping will appear in a few weeks
 time.
 We're hoping to offer support for a wider range of quantum chemistry
 codes, and to this end Mike Deible of the University of Pittsburgh has very
 kindly written a conversion utility which converts output in the standard
 MOLDEN format (produced by many different quantum chemistry codes..) into
 the trial many-body wave function format required by CASINO.  Using our
 standard tests, Mike is currently verifying that this works for the
 MOLPRO, CFOUR, PSI4, and TURBOMOLE packages (NB: certain issues can arise,
 depending on how the code chooses to write the MOLDEN FILE - and so e.g.
 it doesn't work for CFOUR - see the PS below my signature for the boring
 reasons why).
 Now, according to this page:
 http://www.cmbi.ru.nl/molden/others.html
 many other codes such as ACESII, MOLCAS, DALTON, Jaguar, CADPAC, GEOMOP,
 ORCA, and HONDO have some kind of support for the MOLDEN format. If any
 people with a professional interest in these or other MOLDEN-supporting
 codes would like to do QMC calculations, it should be possible quite
 quickly to verify that this general interface to CASINO works, and to add
 the code in question to the list of 'supported software' that we maintain
 here:
 http://vallico.net/casinoqmc/interfaces/
 So if you would like to do that, please let me know. A good start would be
 for you to produce input files for the d-ane, f-ane, and g-ane molecules
 in a format suitable for your code (you may base these on the GAUSSIAN,
 GAMESS, MOLPRO, CRYSTAL examples for f-ane given in the links below;
 similar d-ane and g-ane files with suitable Gaussian exponents can be
 supplied on request). You should then send me those inputs plus the
 corresponding Hartree-Fock outputs with the wave function in MOLDEN
 format. We can then run Mike's converter on the MOLDEN file, and I can
 then do quick QMC Hartree-Fock calculations with CASINO; if it produces
 the same answer as you to within statistical error bars for all three
 cases (and for any one standard molecule with a 'normal basis' including s and p
 functions), then your code will be 'officially supported'.
 http://www.tcm.phy.cam.ac.uk/~mdt26/g/crystal.txt
 http://www.tcm.phy.cam.ac.uk/~mdt26/g/gamess_new.txt
 http://www.tcm.phy.cam.ac.uk/~mdt26/g/gaussian.txt
 http://www.tcm.phy.cam.ac.uk/~mdt26/g/molpro_new.txt
 Please address any general queries to me (mdt26 at cam.ac.uk) and specific
 technical queries about the MOLDEN interface to Mike Deible (mjd87 at
 pitt.edu).
 Best wishes,
 Mike
 PS: Just to give you an idea of the kind of problem that can arise - the
 problem with CFOUR according to Mike D. appears to be as follows. It
 normalizes the basis set before the calculation (like most codes), then
 does the HF calculation.  It prints the orbitals to the MOLDEN file, but
 the basis set that it prints is not the normalized basis set that it used
 for the calculation, it is the basis set from the initial input.  The
 CFOUR output prints the normalization constant it uses for each
 contraction for each atom, but because these aren't in the MOLDEN file and
 are different for each atom, there is no straightforward way to
 renormalize the contraction coefficients. MOLPRO prints to the MOLDEN file
 the normalized basis set that it uses, so it only needs to multiplied by
 some factor to be accepted by CASINO - hopefully this issue can therefore
 be fixed..