CASINO works as stand-alone software only for certain model systems like the homogeneous electron gas. For real systems containing atoms it requires input from another program – such as a Hartree-Fock, DFT, or quantum chemistry program – to define a ‘trial wave function’ which the DMC process is then supposed to improve. Hence QMC ‘makes the answer better’.  Unluckily for the CASINO developers, quantum Monte Carlo codes therefore require the development and long-term support of  standard interfaces with multiple external programs.

For the case of CASINO, an external code needs to write an ‘xwfn.data‘ file, where x is a letter indicating the kind of basis set (p=plane-wave, b=blip, g=gaussian, sto=slater, a=numerical atomic orbitals on a grid, d=numerical molecular orbitals on a grid for diatomics, lapw=LAPW orbitals, with pwfn.data for the plane waves between the spheres, nao=numeric atom-centred orbitals). These files contain (1) some basic information about the system and the generating program, (2) the geometry, (3) the basis set, (4) any multideterminant information, and (5) the orbital coefficients (the numbers that multiply the basis functions when you’re linearly combining them to represent an orbital). For the awfn.data and dwfn.data cases, (3) and (5) are not present, and the value of the orbital is given directly on some kind of grid. The exact format of these files is defined in a formal specification in Section 7 of the CASINO user manual. Anyone who has some knowledge of the internal workings of a third-party code, or is in possession of a proper definition of the output of such a code, should find it easy enough to develop a simple converter program to write a CASINO xwfn.data file and thus construct a formally defined interface. This can take the form of an external utility which reads the output of the third-party code, or one can modify the third-party code to write the CASINO file directly. Potential QMC users are warmly encouraged to do so! More advice is given on this site here.

This page provides a list of third-party codes that – at least in principle – have support for producing  CASINO trial wave function xwfn.data files. The exact degree of support will depend on time; in particular the interfaces may stop working if the developers release a new version of their code without bothering to check that CASINO support still works. If you find this is the case, please let us know. All voluntary contributions to maintaining these interfaces is gratefully accepted, since doing so is very boring indeed.  Our personal support for the codes can be greatly enhanced if we have someone working in Cambridge who is a dedicated user of the code in question. When they leave, our group knowledge may become non-existent (e.g., currently, none of us know anything about the popular GAUSSIAN code).

Example input files for some of the codes below can be found in the distribution directory CASINO/examples/wfn_generation and in CASINO/examples/generic/gauss_dfg. Instructions are in accompanying READMEs.

Inside each of the basis set headers, the codes are given in a rough order of preference. The codes near the top of each list are likely to be widely used with a properly supported and maintained interface, and/or support more features.

Plane-wave/blip basis set

Although CASINO is capable of directly evaluating orbitals expanded in plane-waves (in its initial version, that was all it could do) this is now considered extremely inadvisable, as it adds an extra power of N to the scaling  of the required computer time with system size. This is because every plane-wave potentially contributes at every point in space, and the number of necessary plane-waves increases with system size. It is far better to expand the orbitals in a localized basis set; then only a fixed number of basis functions  can potentially contribute at any random point, and this number does not increase with system size. For users of plane-wave codes, the plane-wave orbitals can be re-expanded in a localized basis of blip functions using a well-defined mathematical transformation. PWSCF is currently the only code that can do this natively; the pwfn.data output of all other plane-wave codes should be turned into a bwfn.data blip file by a CASINO run with runtype : gen_blip, which replaced the separate utility blip in v2.13.753.

(1) PWSCF (part of the Quantum Espresso package)

This is the best-supported plane-wave DFT package with native CASINO support and it’s free (amongst the developers and their friends it is used by Mike Towler and Dario Alfè). The CASINO support has three unique features: (1) PWSCF can do blip transformations natively and write out either pwfn.data or bwfn.data files (the latter, by default, in a binary format), (2) the CASINO distribution contains a runpwscf run script that supports the CASINO architecture system, and (3) it supports DFT-DMC molecular dynamics calculations. CASINO also supplies a twistav_pwscf script which automates the process of performing twist-averaged QMC calculations.

Assuming you use the supplied runpwscf script, then one can generate an xwfn.data file simply by typing runpwscf --qmc (with --ehome naming your Quantum Espresso directory if it isn’t ~/espresso). The runpwscf script also supports all the usual runqmc command-line arguments specifying e.g. the number of cores etc. on any machine supported by CASINO, that is, one that has a defined CASINO_ARCH file.

Two things to know with Quantum Espresso 7.6. First, pw.x reads pw2casino.dat only from the directory named by outdir in its input, not from the directory you run it in, and it ignores a misplaced file, or anything after a keyword it doesn’t recognise, without a word. It also writes the CASINO file into outdir with your prefix in front, so copy, say, tmp/si.bwfn.data.b1 to bwfn.data.b1. Any outdir but ./out will do: CASINO writes its output to a file called out in the run directory, and won’t run if a directory has taken that name. Second, the blip grid is set by blip_multiplicity, not xmul, and its default of 1.0 is coarser than it should be: use blip_multiplicity=2.d0, which on silicon cut the error in the density of the blip orbitals twentyfold for six and a half times the file size. pw.x prints the grid it actually used as Blip grid: ..., so check it. From v3.1.300 the README in CASINO/utils/wfn_converters/pwscf and the manual say all this, with a worked example, which from v3.1.335 runs through CASINO as printed (before, it used ./out). And also from v3.1.300 CASINO reads a pwfn.data made with K_POINTS gamma, which holds only one of each pair of plane waves G and –G, correctly, adding the missing half itself; earlier versions evaluate the wrong orbitals from such a file, so with them use K_POINTS automatic with 1 1 1 0 0 0 for a pwfn.data at Gamma.

A few more things to know. Like CASTEP and ABINIT, PWSCF applies the pseudopotential in Kleinman-Bylander form, so CASINO’s nonlocal energy of the same orbitals is not PWSCF’s: for silicon they differ by about 2 mHa per cell. From v3.1.341 a multideterminant calculation, or one that is not a ground state, can use the binary bwfn.data.b1 file PWSCF writes by default (earlier versions stop, so give them the formatted bwfn.data), and runqmcmd runs DFT-DMC molecular dynamics with the files Quantum Espresso 7.6 writes, which it could not before, since it expected them to be numbered differently. And from v3.1.371 CASINO falls back to a formatted bwfn.data beside a binary blip file it cannot read, where it used to stop.

Quantum Espresso supplies casino2upf.x, which turns a CASINO x_pp.data pseudopotential into a UPF file. The file says it was made by Hartree-Fock, so set input_dft in the PWSCF input, or PWSCF will try to do a Hartree-Fock calculation. Its converter the other way, upfconv.x -c, says itself that it probably doesn’t work, and I haven’t tried it.

For more detailed information, see Section 8.17 of the CASINO manual.

(2) CASTEP

CASTEP is a powerful plane-wave DFT package that, like CASINO, was originally developed in the Cavendish Laboratory’s Theory of Condensed Matter Group (see castep.org). Academics anywhere in the world can now have the source code free of charge, under a licence issued to a research group: apply through STFC’s licensing site, which handles it for Cambridge Enterprise and the CASTEP Developers’ Group. Commercial users get CASTEP as part of BIOVIA Materials Studio. Of the main CASINO developers, Neil Drummond is the one who uses CASTEP as his principal DFT code.

You make a CASINO pwfn.data file with castep2casino, which comes with CASTEP (it is one of the tools a plain serial make builds). After a single-point run, type castep2casino seedname in the same directory, on one process: it reads seedname.check, and you no longer need to add a continuation line to the .param file first. Rename the seedname.casino it writes as pwfn.data, and turn it into blips with a CASINO run with runtype : gen_blip. CASTEP reads CASINO’s x_pp.data pseudopotentials natively: put the pseudopotential and the awfn.data file for the atom’s ground state, renamed x_pp.awfn, in the run directory, and name the first in the species_pot block of the .cell file. Give the k points explicitly in a kpoints_list block, without symmetry_generate, and set fix_occupancy : true, finite_basis_corr : 0 and a tight elec_energy_tol. For an exact density on CASTEP’s grid, also set grid_scale : 2.0 and fine_grid_scale : 2.0.

Two things to know. First, CASTEP applies the pseudopotential in Kleinman-Bylander form, like PWSCF and ABINIT and unlike CASINO, which applies it semilocally, so CASINO’s nonlocal energy of the same orbitals is not CASTEP’s: for silicon it is about 2 mHa per cell higher. For the same reason, with first-row transition metals watch out for ghost states (see CASINO/utils/pseudo_converters/NOTES). CASTEP takes the local channel from the x_pp.data file and has no option to change it. Second, the header of the file castep2casino writes CASTEP’s kinetic, ion-ion and total energies but zero for the local and nonlocal ones, so if you want to compare those with CASINO’s, take them from seedname.castep with iprint : 3. MDT tested CASTEP 26.1.1 (September 2026) with CASINO v3.1.334 on silicon, at the Gamma point, on a 2x2x2 grid of k points and for a spin-polarised atom. CASINO evaluates the converted orbitals to the density CASTEP writes, to the six decimal places it writes it with. A VMC run with no Jastrow factor reproduces CASTEP’s kinetic and local energies within the statistical error, on plane waves and on blips. And CASTEP, given the same pseudopotential and cutoff, gets the same answer as PWSCF to better than a microhartree per cell. From v3.1.349 the README in CASINO/utils/wfn_converters/castep and Section 8.4 of the CASINO manual say all this, and CASINO/examples/wfn_generation/CASTEP/neon is an example of the whole route.

(3) ABINIT

Official ABINIT blurb:

“ABINIT is a package whose main program allows one to find the total energy, charge density and electronic structure of systems made of electrons and nuclei (molecules and periodic solids) within Density Functional Theory (DFT), using pseudopotentials and a planewave or wavelet basis. ABINIT also includes options to optimize the geometry according to the DFT forces and stresses, or to perform molecular dynamics simulations using these forces, or to generate dynamical matrices, Born effective charges, and dielectric tensors, based on Density-Functional Perturbation Theory, and many more properties. Excited states can be computed within the Many-Body Perturbation Theory (the GW approximation and the Bethe-Salpeter equation), and Time-Dependent Density Functional Theory (for molecules).“

ABINIT has native CASINO support. To tell ABINIT to write the wave function in CASINO format, set prtwf to 2 in the ABINIT input file. Some other input parameters must also be set appropriately.

Appropriate pseudopotential converters are provided in the CASINO distribution.

Two things to know with ABINIT 10.8.3. First, run the ABINIT job that writes pwfn.data on one process: run in parallel over k points, ABINIT’s CASINO writer doesn’t stop with an error, as our documentation used to say, but writes a file full of garbage and then crashes. Second, the way to give ABINIT the same pseudopotential as CASINO is CASINO’s own ppconvert utility with its --tm option. Run it in a directory that also holds the summary.txt file our pseudopotential library supplies with each pseudopotential, and give it an awfn.data file for every angular-momentum channel, the local one included. The file it writes names no exchange-correlation functional, and ABINIT then uses none unless you set ixc in its input, so always set it. ABINIT can’t read the UPF files that Quantum Espresso’s casino2upf writes, and with first-row transition metals watch out for ghost states (see CASINO/utils/pseudo_converters/NOTES). From v3.1.300 the README in CASINO/utils/wfn_converters/abinit and the manual say all this, with a worked example.

For more detailed information, see Section 8.1 of the CASINO manual.

(4) MCEXX

MCEXX is a plane-wave electronic structure code written by A. Görling, S. Rohra, P. Carrier, A. Hesselmann, H. Schulz and E. Trushin at the University of Erlangen-Nuremberg in Germany. It does conventional Kohn-Sham calculations (LDA/GGAs), Hartree-Fock calculations, DFT calculations with hybrid functionals, exact-exchange (EXX) Kohn-Sham calculations by the optimised effective potential method, and calculations treating electron correlation within the random phase approximation. Spin-orbit interactions, non-collinear spin and the accompanying magnetisation currents can be treated, and with explicitly temperature-dependent functionals it can do calculations at the very high temperatures of warm dense matter (in nuclear fusion, or in stars). What it offers QMC is the EXX Kohn-Sham orbitals of a solid, from a local potential free of self-interaction, and a library of pseudopotentials generated with exact exchange.

An interface that wrote CASINO’s pwfn.data was made in November 2013, in collaboration with Andreas Görling and Andreas Hesselmann, but when it was asked for again its authors could not find it, and a new one has been written by MDT, which CASINO supports from v3.1.1102. With l_casino = .true. in the &basic namelist of its input, MCEXX writes a pwfn.data file itself, together with the pseudopotential it used in CASINO’s format, and the k-point grid of the MCEXX calculation becomes the CASINO simulation cell (npcell equal to MCEXX’s nklmn). It writes the orbitals of any calculation that gives one closed-shell determinant (exact exchange, the Libxc functionals, and Hartree-Fock and hybrids with the iterative solver) and refuses, with a message, those that do not. If you compare energies with MCEXX’s, remember that CASINO’s Jastrow-free VMC energy uses the Ewald interaction for the exchange energy, not MCEXX’s exchange kernel (for silicon on a 2x2x2 grid that alone lowers it by 0.030 Ha per primitive cell), and applies the pseudopotential semilocally, where MCEXX uses Kleinman-Bylander projectors. For silicon’s 64-electron cell, MCEXX’s PBE orbitals and Quantum Espresso’s, with the same pseudopotential, give the same DMC energy within the statistical error of about 0.1 mHa per primitive cell.

MCEXX is not formally publicly available; interested parties may contact Prof. Görling at andreas.goerling at fau.de. The part of it that writes the files for CASINO is available from the CASINO developers on request, until MCEXX includes it. A worked example is in CASINO/examples/wfn_generation/MCEXX, and the MCEXX section of the CASINO manual’s chapter on other programs has the details.

(5) QBOX (and GP / JEEP)

QBOX is a plane-wave DFT and Hartree-Fock code written by François Gygi (website here). It grew out of an old Lawrence Livermore code which, when we played with it years ago, was called GP and then JEEP, and our converter for that, jeep_to_pwfn, reads files that no version of QBOX has ever written, so for a long time there was no working route from QBOX to CASINO at all. From v3.1.315 there is one, written by Mike Towler (hello!). Run QBOX with set wf_diag T (it only prints eigenvalues when it diagonalises), give it every k point of the grid that matches your CASINO simulation cell, each with the same weight, and finish with save file.xml; then qbox2pwfn file.xml qbox.out turns the sample and the output of the same run into a pwfn.data file, at any number of k points and with or without spin polarisation, with the energies CASINO’s kinetic-energy check needs in its header. It refuses, with a message, anything it can’t convert faithfully: fractional occupations, k-point weights that are not those of a whole grid, or a sample and an output that don’t belong together. A grid halved by time reversal, k and -k represented by one of them at twice the weight, is fine; from v3.1.344 one halved without doubling the weights is refused, where before it was converted and CASINO then stopped at its kinetic-energy check. Type the components of the k points to more than eight decimals (0.333333333333), since QBOX prints them to eight only. QBOX’s Hartree-Fock works at the Gamma point only.

To give QBOX the same pseudopotential as CASINO, casino2qso x_pp.data -o species.xml writes a species file that QBOX applies semilocally, exactly as CASINO does, rather than in the Kleinman-Bylander form every other plane-wave code uses. The nonlocal energy in the pwfn.data header is then the one CASINO computes for the same orbitals (with a Kleinman-Bylander pseudopotential the two differ, by about 2 mHa per cell for silicon), and at the Gamma point the Jastrow-free VMC energy of a QBOX Hartree-Fock determinant is QBOX’s Hartree-Fock energy. On silicon, at Gamma and on a 2x2x2 grid, and for a spin-polarised silicon atom, CASINO evaluates the converted orbitals to the density QBOX itself writes, to the six figures it writes it, and its VMC reproduces QBOX’s kinetic, local and nonlocal energies within the statistical error. The README in CASINO/utils/wfn_converters/qbox and Section 8.18 of the manual say all this, with a worked example in examples/wfn_generation/QBOX. The old jeep_to_pwfn is still there for anyone with output from GP or JEEP.

Gaussian basis set

(6) CRYSTAL (03/06/09/14/17/23)

CRYSTAL is a commercially available Hartree-Fock/DFT Gaussian basis set package which is able to treat  both molecules and systems with periodic boundary conditions in 1, 2 or 3 dimensions (polymers, slabs or crystals). Licences come from CRYSTAL Solutions: academics at UK institutions can have the basic licence free, and a free evaluation version is limited to ten atoms in the primitive cell. It originated at the University of Torino in Italy, with considerable collaboration from Daresbury Laboratory and other institutions in the UK. The author list of the latest version of the program is Roberto Dovesi, Vic Saunders, Carla Roetti, Roberto Orlando, Claudio Zicovich-Wilson, F. Pascale, Bartolomeo Civalleri, Klaus Doll, Nic Harrison, Ian Bush, Philippe D’Arco, Miquel Llunell, Mauro Causa, Y. Noel, L. Maschio, A. Erba, M. Rerat and Silvia Casassa.

CRYSTAL has the best CASINO support of all the available Gaussian basis codes (because Mike’s first job after getting his Ph.D. was working for its developers in Torino and he retains a sneaking fondness for it..) and has the unique advantage of treating periodic systems (which is done either badly or, more usually, not at all in other Gaussian codes that we know about). Our run script supports versions back to CRYSTAL03 (from v3.1.329 it refuses CRYSTAL95 and 98, which it could no longer run), but we strongly recommend that you use the latest CRYSTAL23 edition, which CASINO reads from v3.1.178 through the converter crysgen23. CRYSTAL03 writes gwfn.data only with routines added to its properties program, written by MDT to a specification agreed with its Daresbury authors, which the Torino group did not take into CRYSTAL: anyone holding a CRYSTAL03 licence may have them from us on request, and runcrystal -03 -qmc writes the properties input that such a build reads.

The CASINO distribution includes a runcrystal script which, given the -qmc option, runs CRYSTAL and then everything needed to turn its wave function into a gwfn.data file. From v3.1.188 it runs the newest CRYSTAL you have installed unless a flag such as -17 or -23 names another, and from v3.1.190 it finds the converter through CASINO’s architecture system; otherwise it is still an old csh script with a setup of its own, which may need some manual work. Section 8.6 of the CASINO manual gives the details, and the procedure without the script. If you go without it, run crysgen23 in the directory where properties has just run with CRYAPI_OUT, before any other properties run there: it takes the eigenvectors from fort.8, and a fort.8 kept from the SCF, or written by a later run on another k net, gave the wrong determinant without a word until v3.1.258, from which crysgen23 refuses it (at every k point and spin from v3.1.275).

With CRYSTAL23 (version 1.0.1), CASINO’s density from the converted orbitals is CRYSTAL’s own to about one part in 10¹², for water, for methane with only d, only f and only g functions, and for MgO at the Gamma point and on a 2x2x2 grid of k points, and a VMC run with no Jastrow factor gives CRYSTAL’s Hartree-Fock energy within statistical error for the helium atom, H2, LiH, MgO and the methanes. CRYSTAL23 has g functions, in a build compiled for them (the ordinary one stops, saying G-ORBITALS NOT COMPILED), and from v3.1.193 CASINO accepts them in molecules; it has no g functions for periodic systems, and says so. Use crysgen23 for CRYSTAL23’s files, as runcrystal does: crysgen17 writes zeros for g coefficients without a word. And if you compare orbitals or densities with another code’s, note that crysgen23‘s orbitals are about 2.432 times CRYSTAL’s, a factor that cancels in every energy.

Trail-Needs pseudopotentials (and some corresponding Gaussian basis sets) are provided in our pseudopotential library in CRYSTAL format. Other basis sets and various other somewhat out-of-date material can be found on Mike Towler’s old CRYSTAL website – which he made because his first job after getting his Ph.D. involved spending two years in Torino in Roberto Dovesi’s group (Mike should therefore be the first person you ask about any issues about the CASINO-CRYSTAL interface).

(7) TREXIO (PySCF, Quantum Package)

TREXIO is the common file format for wave functions that came out of the European TREX project, one file through which quantum chemistry codes and QMC codes can hand each other orbitals and determinant expansions, and its own documentation lists the codes that write it. From v3.1.342 CASINO reads it too, through MDT’s utility trexio2qmc: type trexio2qmc file.h5 and you get a gwfn.data file and, if the file holds a CASSCF or CI expansion, the MDET block of correlation.data as well, with the signs of the determinant coefficients sorted out for the order in which CASINO builds its determinants. So multideterminant wave functions from PySCF, and Quantum Package’s CIPSI expansions (below), can now get into CASINO without anyone having to type an MDET block by hand.

Spherical s to g functions and Cartesian d and f functions are converted exactly, and anything we can’t represent faithfully (periodic systems, complex orbitals and the like) is refused with a message rather than converted quietly. So far I have checked it with the files PySCF writes, on water, the lithium and nitrogen atoms, our old test of methane with only d, only f and only g functions, and water and hydrogen fluoride in Cartesian basis sets: CASINO’s values of the converted orbitals agree with PySCF’s own to nine figures or better at every point we tried, its VMC energy without a Jastrow factor agrees with PySCF’s Hartree-Fock energy to within about three error bars, each under 10 mHa, which is as well as such a noisy calculation resolves it, and the same orbitals sent through MOLDEN and molden2qmc give the same file to thirteen figures.

For CASSCF expansions of the beryllium and boron atoms, and one of a chain of six hydrogen atoms with 400 determinants, CASINO’s value of the whole wave function is PySCF’s to nine figures, and the VMC energy agrees with the CASSCF energy to a few mHa.

Quantum Package, the open-source determinant-driven code from Toulouse best known for its CIPSI selected configuration interaction, writes TREXIO files as well, single determinants and CIPSI expansions alike. Its releases are too old for this: the last, 2.1.2 of 2020, has no TREXIO export, so build it from its master branch on GitHub (I used that of 25 September 2026). After its scf or fci run, type qp set trexio backend 1 (TREXIO’s text format, which needs no HDF5), qp set trexio trexio_file mol.trexio and qp run export_trexio, then trexio2qmc mol.trexio. Keep QP’s default export, with Cartesian functions: its spherical one (export_cartesian false) is wrong in the version I used, its d and f coefficients scaled and mixed, which cost water 53 mHa. QP does its calculations in the space of spherical functions all the same, so trexio2qmc leaves out the almost empty non-spherical parts of its Cartesian shells and CASINO gets ordinary spherical shells, g included, with a note giving the largest weight left out (up to about 8E-4 of an orbital’s largest coefficient in the files tried). If a file carries more than the default limit of 1E-3, trexio2qmc refuses it and says so: set --cartesian-tol above the weight it reports. trexio2qmc has read QP’s files with d and f functions since it first shipped, in v3.1.342, but before v3.1.412 it refused those with g functions and gave the others 2s and 3p shells, which CASINO does not allow with backflow or MOLGSCREENING. QP writes its determinants for every wave function, so its file always gives an MDET block, of a single determinant after an SCF. And run one QP job at a time on a machine: two started together can collide over a network port, and one of them then hangs for ever.

With that version of QP, CASINO’s density of the converted orbitals reproduces QP’s own, computed by QP’s own code, to about one part in 10¹⁴ on average and 10¹¹ at worst, for water and for the open-shell lithium atom, every orbital, sign included, to 1E-11 or better, and for the lithium atom a VMC run with no Jastrow factor and no cusp correction gives QP’s Hartree-Fock energy within two error bars. For QP’s CIPSI expansions of water with up to 11282 determinants and of the lithium dimer with up to 10003, the determinants in the file give back QP’s own variational energy to 1E-13 Ha, so their order and signs are what trexio2qmc takes them to be; CASINO’s value of the whole wave function agrees with QP’s to ten figures or better, except very close to a point where the reference determinant nearly vanishes, where it keeps seven; and for the lithium dimer a VMC run with no Jastrow factor gives QP’s variational energy to within two and a half error bars of a few mHa each. In all, 48 of QP’s default files, for 35 systems, convert. The cost of a step grows in proportion to the number of determinants: for ten electrons and ten thousand determinants a step costs as much as five or six hundred with one. As a demonstration, all-electron fixed-node DMC of C2 in the cc-pVTZ basis, with a CASINO Jastrow factor, gives -75.8615(12) Ha with QP’s Hartree-Fock determinant, as published for that basis, and -75.8954(7) Ha with a 132-determinant CIPSI expansion from QP (its 1s electrons frozen in the CIPSI): 34 mHa lower, half the fixed-node error of the Hartree-Fock nodes gone, with QP’s coefficients just as they came. If you set cusp_correction : T with any multideterminant expansion, use v3.1.402 or later: before it a virtual orbital could be cusp-corrected against another orbital’s value, or not at all. For this C2 expansion the fix moved the DMC energy by less than its error bar, but that is not something to rely on.

I (MDT) haven’t yet tried files from other codes other than these two. PySCF’s TREXIO writer is in PySCF’s development version from September 2026 and in no release yet; with PySCF 2.14.0, pip install pyscf-forge provides it. The trexio_tools package converts the output of some other codes to TREXIO, though not, at present, MOLDEN files. You need Python 3 with NumPy and the trexio package (pip install trexio). See the README in CASINO/utils/wfn_converters/trexio, Section 8.19 of the manual, and the example in CASINO/examples/wfn_generation/TREXIO.

(8) GAUSSIAN (94/98/03/09)

GAUSSIAN is an extremely large and widely used commercially available quantum chemistry package which implements pretty much every quantum chemistry technique. That said, the CASINO distribution contains the utility ‘gaussiantoqmc‘ which can read in GAUSSIAN formatted checkpoint files (along with the standard output file) and produce a CASINO gwfn.data.

The GAUSSIAN-CASINO interface can supposedly deal with the following sorts of calculation:

• Hartree-Fock and DFT ground states, open and closed shell.
• CIS excited states, open and closed shell.
• CASSCF states.
• Time-dependent HF (TD-HF) or DFT (TD-DFT) excited states.

CASINO reads spherical d, f and g functions only, so ask GAUSSIAN for spherical ones: gaussiantoqmc converts Cartesian ones too, but CASINO won’t read the result, and from v3.1.385 it refuses h functions rather than write a file CASINO can’t read.

A large amount of detailed information about how to use gaussiantoqmc is given in Section 8.9 of the CASINO manual.

Trail-Needs pseudopotentials (and some corresponding Gaussian basis sets) are provided in our pseudopotential library in GAUSSIAN format.

Note that if the gaussiantoqmc utility doesn’t do what you want (and it may not, since it’s more than 25 years old, and the person who wrote it disappeared not long afterwards) then you might ask Katharina Doblhoff-Dier, who has apparently written a new equivalent utility from scratch. Note that none of the CASINO developers are rich enough to afford a GAUSSIAN license.

(9) GAMESS-US

“GAMESS is a program for ab initio molecular quantum chemistry. Briefly, GAMESS can compute SCF wave functions ranging from RHF, ROHF, UHF, GVB, and MCSCF. Correlation corrections to these SCF wave functions include Configuration Interaction, second order perturbation Theory, and Coupled-Cluster approaches, as well as the Density Functional Theory approximation. Excited states can be computed by CI, EOM, or TD-DFT procedures“.

GAMESS-US is supported for d, f and g functions through the gamess2qmc converter distributed with CASINO, which Alexander Badinski wrote many years ago and to which Kevin Gasperich added f functions in 2015. With GAMESS version July 15, 2024 (R2 Patch 1) the orbitals it writes reproduce the electron density of GAMESS’s own orbitals to a few parts in 10¹⁰ for ordinary basis sets (a few parts in 10⁷ in rms for the test cases, whose exponents GAMESS prints to seven decimal places), and a VMC run with no Jastrow factor and no cusp correction gives GAMESS’s Hartree-Fock energy within statistical error, for methane with only d, only f and only g functions (the test cases in CASINO/examples/generic/gauss_dfg, which now include the GAMESS inputs and outputs), for water, for the NH₂ radical by UHF and by ROHF, for water with ccECP pseudopotentials, for N₂ and for a broken-symmetry singlet UHF; the density test also passes for water in GAMESS’s own symmetry. Its companion getdet carries the expansion of a determinant CI into CASINO, and for a small case the VMC energy of the expansion is the CI energy. Put ISPHER=1 in $CONTRL, run gamess2qmc -t hf -l vec.dat job.log, where vec.dat holds the orbital coefficients from the $VEC group of the punch file (the README says how), and give an atom with a pseudopotential the corresponding CASINO xx_pp.data file. Before v3.1.421 nothing above d could actually reach CASINO by this route: gamess2qmc stopped on g functions, and CASINO itself refused f and g functions in any file that said it came from GAMESS, a check left over from 2008. Both are fixed in v3.1.421, which also puts gamess2qmc and getdet on the path when CASINO is built (neither could be run as installed before); writes a broken-symmetry singlet UHF wave function as spin-unrestricted, where CASINO used to be given the alpha orbitals for both spins when the input set MULT=1, and every other kind as spin-restricted, so that a CI on orbitals read in (SCFTYP=NONE) can be read whether or not its input set MULT=1; and no longer mistakes the table of Lz values GAMESS prints for a spin-unrestricted linear molecule for more orbitals. From v3.1.453 a comment in the GAMESS input no longer affects the spin restriction: before it, a CI on orbitals read in whose input mentioned SCFTYP=UHF in a comment was written spin-unrestricted, and CASINO could not read it.

GAMESS also has a CASINO writer of its own, written by Albert Defusco and switched on with CASINO=.TRUE. in $CONTRL. It still exists in the July 2024 version, but I cannot recommend it. It writes every d function a factor of root three too small, which leaves the energy unchanged when every orbital is made of d functions alone, as in the d-only test molecule (hence the old claim that it worked “up to d functions”), but not when they mix with s and p functions, as they do in water; it stops GAMESS when it meets an f or g function; it writes UHF and ROHF wave functions as one set of orbitals labelled spin-unrestricted; it writes an atom with a pseudopotential with its atomic number unchanged and its valence charge plus 200, where CASINO wants its atomic number plus 200 and its valence charge; and whenever the number of primitive Gaussians is a multiple of four it leaves a blank line in the basis set which CASINO cannot read. Since v3.1.518 CASINO checks at start-up that the orbitals it reads are orthonormal, and it warns about a file from this writer whenever its d functions mix with s and p functions, as in water. Use gamess2qmc.

(10) TURBOMOLE

TURBOMOLE is a quantum chemical program package, initially developed in the group of Prof. Dr. Reinhart Ahlrichs at the University of Karlsruhe and at the Forschungszentrum Karlsruhe, and now run by a commercial company. It provides all standard and state of the art methods for ground state calculations (Hartree-Fock, DFT, MP2, CCSD(T)), excited state calculations at different levels (full RPA, TDDFT, CIS(D), CC2, ADC(2), …), geometry optimizations, transition state searches, and molecular dynamics calculations.

TURBOMOLE’s orbitals reach CASINO through the MOLDEN format. In the directory of a dscf or ridft run, type tm2molden and accept its defaults, which writes molden.input; then type molden2qmc 0 molden.input. Use the file tm2molden writes by default, and not the one from tm2molden norm, which TURBOMOLE’s manual recommends for programs that expect MOLDEN’s own normalisation, or from tm2molden multiwfn: their d, f and g coefficients are larger by factors of √3, √15 and √105, and converter 0 turns them, without complaint, into orbitals with too much d, f and g in them (for water in def2-TZVP the energy comes out about 20 mHa too high). Such a file converts correctly with molden2qmc 5.

With TURBOMOLE 8.0.1 I have tested this for s to g functions. The orbitals molden2qmc writes reproduce TURBOMOLE’s own electron density to its eighth decimal place, the precision to which TURBOMOLE prints it, and a VMC run with no Jastrow factor and no cusp correction gives TURBOMOLE’s Hartree-Fock energy within statistical error, for water in def2-SVP (with and without symmetry), def2-TZVP and def2-QZVP, for triplet CH₂ by UHF, for water’s PBE0 orbitals from ridft, and for methane with only d, only f and only g functions (the test cases in CASINO/examples/generic/gauss_dfg, where the TURBOMOLE inputs now are). With DFT orbitals the VMC energy is that of the determinant of Kohn-Sham orbitals, which is not the DFT energy and lies well above it; dscf, run as Hartree-Fock from those orbitals, prints it as the energy of its first iteration. See Section 8.20 of the CASINO manual.

The interface Stefan Grimme wrote in 2001, a routine to be built into the TURBOMOLE source, is kept in CASINO/utils/wfn_converters/turbomole_old as a record only; it is not maintained and should not be used.

(11-15) MOLPRO, CFOUR,  PSI4, DALTON, ORCA, NWCHEM , OPENMOLCAS, PYSCF (Q-CHEM..)

                             

Mike Deible and Vladimir Konjkov wrote the converter molden2qmc, since modified by Pablo López Ríos and MDT, which writes a gwfn.data file from a file in the standard MOLDEN format. Its first argument says which code wrote the file: 0 for TURBOMOLE, 1 for PSI4 or PySCF, 2 for CFOUR, 3 for ORCA, 4 for DALTON, 5 for Molpro, MOLCAS or OpenMolcas, 6 for NWChem and 7 for Q-Chem.

The MOLDEN format is also supposedly supported by ACESII, Jaguar, and others.

I (MDT, Oct 2026) have tested the route for Molpro, PSI4, DALTON, NWChem, Q-Chem, OpenMolcas, ORCA, PySCF and TURBOMOLE, as below; CFOUR I haven’t been able to try yet.

That said, note that apparently CFOUR’s implementation of MOLDEN is a little special.. and requires various vectors to be reordered before the standard CASINO molden2qmc converter will work. To do this, replace the file /libr/reorderdf.f in the CFOUR distribution with the file utils/wfn_converters/cfour/reorderdf.f from the CASINO distribution, then recompile CFOUR.

Molpro is supported for d, f and g functions. After the SCF write the MOLDEN file with put,molden,mol.molden and type molden2qmc 5 mol.molden. With Molpro 2026.1 the orbitals molden2qmc writes reproduce Molpro’s own orbitals and electron density to one or two parts in 10⁹, the precision to which its MOLDEN file is written, and a VMC run with no Jastrow factor and no cusp correction gives Molpro’s Hartree-Fock energy within statistical error, for methane with only d, only f and only g functions (the test cases in CASINO/examples/generic/gauss_dfg, now made with Molpro 2026.1), for water with basis sets up to g functions, with and without symmetry, and for triplet CH₂ by ROHF and by UHF. Before v3.1.536molden2qmc converted the coordinates, which Molpro writes in Angstrom, with a factor slightly different from Molpro’s own, and so moved every atom by two parts in 10⁹ of its distance from the origin; no energy you could compute notices that, but from v3.1.536 it uses the factor Molpro writes into the file. Give the SCF card a wf directive naming the state you want: without one Molpro 2026.1 chooses the spin from its initial guess, and took our methane with d functions to a triplet. If an atom’s first shell is a g function, which happens only in test bases like ours, Molpro leaves the line that opens that atom’s shells out of the file’s [GTO] section and molden2qmc stops; its README says how to put the line back. Molpro 2026.1 also writes TREXIO files (put,trexio), but they hold the geometry and no orbitals, so there is no TREXIO route from Molpro yet. See Section 8.12 of the CASINO manual.

PSI4 is supported for d, f and g functions. With PSI4 1.11 the orbitals molden2qmc writes reproduce PSI4’s own electron density to better than one part in 10^9, and a VMC run with no Jastrow factor and no cusp correction agrees with PSI4’s Hartree-Fock energy within statistical error, for methane with only d, only f and only g functions (the test cases in CASINO/examples/generic/gauss_dfg) and for ordinary molecules. At the end of the PSI4 input write the MOLDEN file with E, wfn = energy('scf', return_wfn=True) followed by psi4.molden(wfn, 'psi4.molden'), then type molden2qmc 1 psi4.molden to produce gwfn.data. Don’t use the option molden_write true, which in PSI4 1.11 stops with an error once the SCF has finished and writes nothing. CASINO needs spherical harmonics, and PSI4 builds some basis sets, 6-31G* among them, from Cartesian functions unless the input sets puream true: set it, since molden2qmc refuses a Cartesian file.

From CASINO v3.1.228 this holds also when PSI4 has removed near-linear dependencies from the basis, which it does whenever an eigenvalue of the overlap matrix falls below S_TOLERANCE, and which large diffuse basis sets, augmented ones among them, can bring about. PSI4 then writes fewer orbitals than basis functions, and before v3.1.228 molden2qmc turned that, without a word, into a gwfn.data file CASINO could not read. It now completes the file with placeholder orbitals whose coefficients are all zero and prints a warning naming them. They must never be occupied: don’t promote an electron into one in an MDET block, and don’t set neu or ned above the number of orbitals the warning gives for that spin, as for an ion. From v3.1.247 CASINO refuses a run that occupies one; earlier versions run it, and its results are meaningless. If you use pseudopotentials, name the atoms that carry them with --pseudoatoms: PSI4 writes such an atom’s valence charge where its atomic number should be, and from v3.1.258 molden2qmc stops if one is left out, where before it made it, without a word, an all-electron atom with the wrong charge.

DALTON is supported for d, f and g functions. With DALTON 2020.1 run without symmetry, the orbitals molden2qmc writes reproduce DALTON’s own electron density to a few parts in 10^6, the six decimals its MOLDEN file carries, and a VMC run with no Jastrow factor and no cusp correction gives DALTON’s Hartree-Fock energy within statistical error, for methane with only d, only f and only g functions (the test cases in CASINO/examples/generic/gauss_dfg, which now include DALTON’s inputs) and for ordinary molecules. Convert with molden2qmc 4 molden.inp. Before v3.1.258, run DALTON without symmetry and label the atoms with bare element symbols: molden2qmc read atomic numbers from the labels, so O1 or the H_1 DALTON writes for an atom made by symmetry stopped it, and it ignored the occupations, so DALTON’s orbitals, listed symmetry by symmetry, gave the wrong determinant without a word. From v3.1.258 both are fixed, and DALTON’s files from runs with symmetry give its energy too.

NWChem is supported for d, f and g functions. With NWChem 7.3.1, the orbitals molden2qmc writes reproduce NWChem’s own electron density to better than one part in 10^9, and a VMC run with no Jastrow factor and no cusp correction gives NWChem’s Hartree-Fock energy within statistical error, for methane with only d, only f and only g functions (the test cases in CASINO/examples/generic/gauss_dfg, which now include NWChem’s inputs), for water, for the spin-unrestricted NH2 radical and for water with ccECP pseudopotentials. Write the MOLDEN file with the property module (moldenfile, with molden_norm none: NWChem 7.3 stops without a molden_norm line, and molden_norm nwchem gives a file molden2qmc gets wrong), put basis spherical in the input, since NWChem’s basis is Cartesian by default, and convert with molden2qmc 6 name.molden, naming any atom with a pseudopotential with --pseudoatoms. From v3.1.370 molden2qmc says plainly why it cannot convert a Cartesian file, where it used to stop with a bare assertion.

OpenMolcas is supported for d, f and g functions in the same way. With OpenMolcas v26.06 the orbitals reproduce its own density to a few parts in 10^8, the eight decimals its MOLDEN file carries, and the energy test passes for the same molecules, with and without symmetry. Convert the file the SCF module writes with molden2qmc 5 project.scf.molden. OpenMolcas gives an atom with a pseudopotential its atomic number in the MOLDEN file and nothing else shows the pseudopotential, so every such atom must be named with --pseudoatoms, and a valence charge other than that of a Trail-Needs pseudopotential written into the file by hand. Before v3.1.370 a file converted without --pseudoatoms became, without a word, an all-electron calculation on the wrong basis; from v3.1.370 molden2qmc warns when the electrons in the occupied orbitals and the charge of the nuclei disagree, as they then do.

ORCA is supported for d, f and g functions, with or without pseudopotentials. Run ORCA as usual, write the MOLDEN file with orca_2mkl <basename> -molden, and type molden2qmc 3 <basename>.molden.input to produce gwfn.data. Always use code 3: ORCA writes its d, f and g functions with a normalisation of its own and with the signs of some of them reversed, and only that converter undoes this. With ORCA 6.1.1 the orbitals molden2qmc writes reproduce ORCA’s own electron density to a few parts in 10^8, and a VMC run with no Jastrow factor and no cusp correction gives ORCA’s Hartree-Fock energy within statistical error, for methane with only d, only f and only g functions (the test cases in CASINO/examples/generic/gauss_dfg, which now include ORCA’s inputs), for water with basis sets up to g and with augmented ones, for unrestricted Hartree-Fock, and for water with one of our pseudopotentials. ORCA writes an atom that has a pseudopotential with its atomic number, and puts the valence charge in a section of its own. Before v3.1.359 molden2qmc ignored that section and gave the atom the valence charge of our Trail-Needs pseudopotential for that element instead, which is right for the light elements but not for the def2 pseudopotentials ORCA uses by default from rubidium on: for iodine gwfn.data said 7 where the potential has 25. From v3.1.359 it reads ORCA’s charges. Name exactly the atoms that carry a pseudopotential with --pseudoatoms, and it will tell you if you get them wrong. CASINO then needs the same pseudopotential in its own _pp.data format.

Q-Chem is supported for d, f and g functions, spherical or Cartesian, for restricted, restricted open-shell and unrestricted Hartree-Fock and DFT orbitals, and with def2 effective core potentials. Put MOLDEN_FORMAT TRUE and PRINT_ORBITALS 10000 in the $rem section (without PRINT_ORBITALS Q-Chem writes no orbitals into its MOLDEN output), and Q-Chem appends a MOLDEN file to its output. From v3.1.1047 molden2qmc reads that output itself: type molden2qmc 7 job.out to produce gwfn.data. It takes the MOLDEN block written at the end of the job, and from the output the numbers of alpha and beta electrons, which the MOLDEN file does not hold and without which a restricted open-shell wave function cannot be converted correctly. With Q-Chem 7.0 the orbitals molden2qmc writes reproduce Q-Chem’s own orbitals and electron density to the precision of the file Q-Chem writes, between one part in 10¹⁰ and one in 10⁷ depending on the basis, for methane with only d, only f and only g functions (the test cases in CASINO/examples/generic/gauss_dfg, which now include Q-Chem’s inputs), for water in spherical and Cartesian basis sets up to g, for triplet CH₂ by ROHF and UHF, from PBE0 orbitals and for HI with a def2 pseudopotential. In every Hartree-Fock case tested a VMC run with no Jastrow factor gives Q-Chem’s Hartree-Fock energy within statistical error, and DMC energies of water with Q-Chem’s orbitals and with PySCF’s agree to within about two standard errors. Q-Chem writes an atom with a pseudopotential with its atomic number: name it with --pseudoatoms and put its valence charge in the third field of its [Atoms] line; if the charge is wrong, molden2qmc says what it must be. Q-Chem 7.0 does not accept the ccECP pseudopotentials. Before v3.1.1047 molden2qmc refused Q-Chem’s Cartesian functions and wrote a restricted open-shell wave function’s gwfn.data as a closed shell’s, with an electron too many for each unpaired one. See the Q-Chem section of the CASINO manual’s chapter on trial wave functions from other programs.

PySCF is supported for d, f and g functions as well, through code 1. With PySCF 2.14.0 write the file after the SCF with pyscf.tools.molden.from_scf(mf, 'mol.molden') and type molden2qmc 1 mol.molden, naming any atom with a pseudopotential with --pseudoatoms, and keep PySCF’s default spherical basis, since molden2qmc refuses a Cartesian file. The orbitals reproduce PySCF’s own electron density to better than one part in 10⁹, and a VMC run with no Jastrow factor and no cusp correction gives PySCF’s Hartree-Fock energy within about three error bars, for water, for methane with only d, only f and only g functions, and for the lithium atom by UHF; and the gwfn.data file is the one trexio2qmc makes from PySCF’s TREXIO file of the same orbitals, to thirteen figures, with the same VMC energy to every digit. For a CASSCF or other multideterminant wave function from PySCF, use TREXIO (entry 7).

Slater basis set

(16) ADF (now part of the Amsterdam Modeling Suite, from SCM: www.scm.com)

ADF is a molecular DFT and Hartree-Fock code, and is essentially the only widely used quantum chemistry program that uses Slater-type orbitals natively rather than Gaussians. CASINO can evaluate Slater functions directly, by setting atom_basis_type : slater-type in the input file, so ADF is our only practical route to an STO trial wave function.

The converter is Vladimir Konjkov’s adf2stowf, on GitHub at https://github.com/Konjkov/adf2stowf, and from v3.1.205 a copy of it is distributed with CASINO, in CASINO/utils/wfn_converters/adf, and installed in bin_qmc with the other utilities. It is his work, under his MIT licence, and from v3.1.300 the copy is his version 1.2.0 with one fix of ours, described in the README there; adf2stowf --version says so. Don’t also install adf2stowf from PyPI into the same environment: that copy is then found first, and the latest release there is still 1.1.0 (2 October 2026), which lacks our fix and three of his own. It needs NumPy and SciPy, which on most Linux systems means a Python virtual environment: python3 -m venv adf2stowf-env, source adf2stowf-env/bin/activate, pip install numpy scipy. Your ADF input should contain the TotalEnergy key, without which ADF prints no total energy to check CASINO’s against, and should set Relativity Level None, since ADF’s default is scalar ZORA and CASINO is non-relativistic. ADF now writes its data to ams.results/adf.rkf, the file it used to call TAPE21: dump it with dmpkf ams.results/adf.rkf > TAPE21.asc, then run adf2stowf --cusp-method=none in the same directory to produce stowfn.data. In CASINO set cusp_correction : T, which imposes the electron-nucleus cusp at run time without touching the file.

Done this way, the orbitals reproduce ADF’s own electron density to about 1e-14, and a VMC run with no Jastrow factor and no cusp correction agrees with ADF’s Hartree-Fock energy within statistical error, the caesium cation included.

If you go on to optimise the MO coefficients of the Slater-type orbitals in CASINO, use v3.1.331 or later. From v3.1.312 an empty MO COEFFICIENTS block no longer sets an orbital’s first coefficient to zero, which had made LiH’s VMC energy 0.12 au too high, and from v3.1.331 only coefficients of equal magnitude are tied together; a block written by an earlier version can then be refused, with a message saying to empty it. CASINO’s Slater-type orbitals are for atoms and molecules only: from v3.1.269 it refuses a periodic stowfn.data.

Norbert Nemec’s older converter, adf2stowf.py, written for ADF 2008.01 and moved to CASINO/utils/wfn_converters/adf_old in September 2025, was removed in v3.1.200: it cannot run under Python 3, and it transformed d and f functions wrongly. From that version the recipe is in the README in CASINO/utils/wfn_converters/adf and in Section 8.2 of the CASINO manual.

A defect worth knowing about if you have used this route before. Every Slater orbital with principal quantum number 5 was being normalised 0.015 per cent too low, silently, because someone can’t calculate factorials, and an orbital with n of 6 or more produced an undefined normalisation which an optimised build would run straight through while reporting success. ADF’s basis sets reach n=5 from rubidium, n=6 from caesium and n=7 from francium, so ADF users were the only people this could reach. It is fixed in CASINO v3.1.147, which also refuses any stowfn.data carrying a shell beyond n=10. If you have run all-electron QMC with Slater orbitals on rubidium or anything heavier using a CASINO older than v3.1.147, your wave function was wrong, slightly up to xenon and unpredictably from caesium on: update and rerun.

Numerical orbitals

CASINO is capable of using numerical orbitals represented on grids for atoms and diatomic molecules.

(17) ATSP2K

For the atomic case we supply a converter extractdet which converts the output of the program ATSP2K into CASINO awfn.data format (further details are in section 8.3 of the CASINO manual).

extractdet is built by hand against ATSP2K’s own library, as the README in CASINO/utils/wfn_converters/a2sp2k/Extractdet says (from v3.1.346 its recipes run as printed). With ATSP2K’s 2009 package the converted orbitals agree with ATSP2K’s to about 1E-8 at its own grid points, and a VMC run with no Jastrow factor gives ATSP2K’s energy within statistical error, for Hartree-Fock on Be, C, N and Ne and a two-configuration MCHF on Be. One fault remains: when the first configuration’s final term has three characters, extractdet writes the counts line of awfn.data a byte late, and CASINO then cannot read it.

(18) 2DHF

For the diatomic case, one may use the code 2DHF, now distributed as x2dhf (version 3.0, from https://github.com/x2dhf/x2dhf). Its output may be converted into the CASINO dwfn.data format using the supplied CASINO utility uf2dwfn, which from v3.1.347 reads both x2dhf 3.0 and the older 2DHF (2005); build it with ./install, or with ./install 2dhf2005 for files from the old code. With x2dhf 3.0 the converted orbitals agree with x2dhf’s to about 1E-14, and a VMC run with no Jastrow factor gives its Hartree-Fock energy within statistical error, for LiH, FH and N2. Further details are in Section 8.21 of the CASINO manual.

Both utilities were written by John Trail, and adapted for modern realities by Mike Towler.

LAPW basis set

From v3.1.1162 CASINO reads all-electron LAPW orbitals: inside each muffin-tin sphere an orbital is its LAPW expansion, the core states are orbitals too, and between the spheres it is the plane-wave sum or blips made from it. The files are lapwfn.data, whose format is specified in CASINO/utils/wfn_converters/wien2k/SPEC.md so that any LAPW program can write it from its own radial functions and coefficients, and pwfn.data for the plane waves between the spheres. The calculation must be non-relativistic, since CASINO’s Hamiltonian is, without spin polarisation or spin-orbit coupling, and with the LAPW basis in every channel, since an APW+lo channel gives orbitals with a kink at the sphere surface; the LAPW section of the CASINO manual’s chapter on the trial wave function has the details.

(19) WIEN2k

WIEN2k is the all-electron full-potential LAPW program of Peter Blaha, Karlheinz Schwarz and their co-workers at the TU Wien. CASINO’s converter w2k2casino, in CASINO/utils/wfn_converters/wien2k (Python 3 with NumPy), reads a converged non-relativistic WIEN2k 24.1 calculation on a cubic lattice and writes lapwfn.data and pwfn.data; w2k_klist.py beside it writes the k-point list the simulation cell needs, and w2k_prepare.sh runs the WIEN2k steps the converter reads. It refuses, naming the cause, a relativistic, spin-orbit coupled or spin-polarised case, an APW+lo channel, a lattice that is not cubic and an SCF that is not converged. The orbitals it writes reproduce WIEN2k’s own to about 1e-7 of the orbital for diamond (a few parts in 1e6 for TiC), and a VMC run of the diamond determinant from them gives the same energy, within statistical error, as the same determinant written by Elk, exciting and FLEUR. A worked example is in CASINO/examples/wfn_generation/WIEN2K, and the WIEN2k section of the manual’s chapter on other programs has the details, with the relativistic correction at the DFT level for diamond and TiC, which is reported apart and never folded into a QMC energy.

(20) Elk, exciting and FLEUR

Elk, exciting and FLEUR are free all-electron full-potential LAPW programs, Elk and exciting under the GPL and FLEUR under the MIT licence. In October 2026 MDT added to each of them a writer of the same two files, one source file in the program’s own style and a short patch to the program’s own files, and offered it to the program’s authors: in Elk 11.2.3 a task, number 900; in exciting sodium.0.2 a property, <lapwfn/>; in FLEUR MaX-R8.1 a command-line option, fleur -lapwfn. Each writes the orbitals of a converged non-relativistic ground state at the k points a simulation cell needs (each comes with a tool that writes that list), real wherever they can be made real, and refuses with a message what the files cannot carry: spin polarisation, spin-orbit coupling, a relativistic treatment, an APW+lo channel, and more. They were tested on diamond and zincblende BN (Elk), on diamond, zincblende BN and LiH (exciting) and on diamond, silicon, zincblende and wurtzite BN and a trigonal form of carbon (FLEUR): the orbitals rebuilt from the files reproduce each program’s own to 1.3e-5 of each orbital’s maximum or better inside the spheres and to 1e-10 or better between them, and the VMC energy of diamond’s determinant is the same from all four programs’ files within its statistical error of a few mHa.

The writers have been offered to the three programs’ authors; until the programs include them, each is available from the CASINO developers on request, as a patch against the program’s release with its tests and a README that gives the route in full. The section on Elk, exciting and FLEUR in the manual’s chapter on other programs has the details.

Numeric atom-centred basis set

(21) FHI-aims

FHI-aims is the all-electron electronic-structure program of Volker Blum and his co-workers, whose basis functions are numeric atom-centred orbitals: radial functions tabulated on a logarithmic grid about each atom, each multiplied by a real spherical harmonic and going to zero at a cutoff radius a few bohr out, a basis at once compact and able to hold the exact atomic cusp and the exact free-atom limit. From v3.1.1239 CASINO evaluates such orbitals directly, with atom_basis_type : nao in the input file, in molecules and, from v3.1.1291, in crystals, at real or complex k points. It evaluates them from the same cubic splines FHI-aims itself evaluates, so a molecule’s orbitals are those of the generating calculation to machine precision, with no refit to Gaussians and no projection onto a grid; a crystal’s radial functions are splined again by the converter from the tables FHI-aims writes, on the same grid, and reproduce FHI-aims’s orbitals to a few parts in 10⁵ of their largest value. The file it reads is naowfn.data, a format of CASINO’s own, specified in the manual so that another program’s numeric orbitals can be written to it. The converter aims2qmc, written by MDT in October 2026 and distributed in CASINO/utils/wfn_converters/aims (Python 3 with NumPy, and for a molecule the trexio package), writes it: for a molecule from the TREXIO file an FHI-aims calculation exports, and for a crystal from the band output and the radial functions FHI-aims writes into its run directory. It reads those files and, if given, FHI-aims’s output file, and contains no part of FHI-aims’s source.

The FHI-aims calculation must be non-relativistic: put relativistic none in control.in, since the scalar-relativistic orbitals FHI-aims uses by default are not eigenfunctions of the Hamiltonian CASINO samples, and CASINO refuses a file whose header names a relativistic treatment. Hartree-Fock (xc hf) or any functional may be used, with any species defaults, and calculate_all_eigenstates writes the empty orbitals too, which a multideterminant expansion may need. For a molecule, FHI-aims must have been built with its TREXIO option (USE_TREXIO in its CMake cache, which needs the TREXIO library built with HDF5), and the export is asked for with four more lines in control.in: trexio_export basis, trexio_export integrals mo 1.0e-4, trexio_export filename mol.h5 and trexio_export back_end hdf5. Then aims2qmc -a aims.out mol.h5 writes naowfn.data, taking the total energy and the relativistic treatment from FHI-aims’s output file for CASINO to report and check (without -a the header says unknown, and CASINO warns). It refuses a periodic TREXIO file, a nuclear charge that is not a whole number, and any basis that is not the numeric atom-centred one. The converter was written for FHI-aims 261002 with trexio 2.6.1.

FHI-aims’s TREXIO export is for molecules, and a crystal needs no TREXIO: its orbitals are taken from FHI-aims’s band output. The calculation runs on a Gamma-centred grid, k_grid n₁ n₂ n₃ (for a twisted simulation cell, the grid offset by the twist with k_offset, which FHI-aims allows with a functional and refuses at Hartree-Fock), spin-unpolarised, with KS_method serial, output basis, output eigenvectors, output overlap_matrix and one output band line of two points for each point of the grid that is not the second point of another line (four lines for a 2x2x2 grid; the README gives the pattern). Then aims2qmc --npcell n₁ n₂ n₃ . in the run directory, or --scell with the nine entries of scell_matrix, and --twist for a twisted simulation cell, writes naowfn.data for that simulation cell: the converter works out the k points the cell needs, refuses a cell whose points the calculation did not provide, naming them, and checks every set of eigenvectors against FHI-aims’s own overlap matrix at its k point. It refuses a spin-polarised crystal, a run that moved the atoms, and a run with normalize_basis_3d.

In CASINO, set atom_basis_type : nao, with periodic : F for a molecule, or periodic : T with npcell or scell_matrix as given to the converter for a crystal, and neu and ned counting every electron of the simulation cell: the orbitals are all-electron, and no pseudopotential file may be in the directory. Spin-restricted and spin-unrestricted files are read, and multideterminant excitations through the usual MDET block (in a crystal at real k points only); at a general twist the orbitals are complex and CASINO is run with complex_wf : T. A polymer or a slab, backflow, the MPC interaction, use_gpcc and sparse are refused at input. The cusp at each nucleus is FHI-aims’s own, which its core orbitals have to a fraction of a per cent and its valence orbitals to within some per cent, and cusp_correction is not used by the type. By instruction count, evaluating these orbitals costs about two thirds of evaluating a Gaussian basis of comparable size (water, 69 functions against the 58 of cc-pVTZ); in a crystal an evaluation runs over the images of every atom within reach of the electron, so that its cost is that of the molecule multiplied by the number of those images, some hundreds in a small cell.

Checked, for the beryllium atom, water and N2: CASINO’s values of every orbital, with their gradients and Laplacians, agree with an independent evaluation of the same file to about 1e-15 of their largest values, and the VMC energy of the determinant without a Jastrow factor agrees with the Hartree-Fock energy FHI-aims reports to within two error bars of about a millihartree each (for the beryllium atom, from a long run, -14.568463(330) against FHI-aims’s -14.56832068 Ha). Two things to know when you compare. FHI-aims’s total energy with its light species defaults carries an integration-grid error, some 1e-4 Ha and for some atoms a few mHa, which CASINO’s expectation value of the same determinant does not, so the two agree more closely at tight settings: for the spin-polarised nitrogen atom they are 4 mHa apart at light settings and 0.4 error bars apart at tight. And a Jastrow factor and DMC then proceed as for any other orbital type: for water, fixed-node DMC from FHI-aims’s Hartree-Fock determinant gives -76.419357(978) Ha and from a cc-pVTZ Gaussian Hartree-Fock determinant (PySCF) -76.419306(956), the same within the error bar. In a crystal, without a Jastrow factor, the kinetic energy of the determinant is FHI-aims’s to within the error bar, whatever the method, when the occupations are whole and the simulation cell’s k points are the grid of the calculation; the total energy is the determinant’s own with Ewald interactions, and at Hartree-Fock differs from FHI-aims’s by the exchange energy’s dependence on the Coulomb interaction, Ewald in CASINO and cut in FHI-aims, which vanishes as the simulation cell grows.

Two worked examples are in CASINO/examples/wfn_generation. FHI-AIMS is the beryllium atom at Hartree-Fock with light species defaults, with the FHI-aims input files, the TREXIO file it wrote, the converted naowfn.data and an input for a VMC run of the determinant; the same atom is a case of the test suite (be_atom_nao). FHI-AIMS_crystal is lithium hydride, PBE with light species defaults on a 2x2x2 grid, with the FHI-aims inputs, the converted naowfn.data and an input for a VMC run of the determinant’s 32 electrons in the 2x2x2 supercell, whose kinetic energy is FHI-aims’s 8.0868 Ha per primitive cell; the same crystal at Gamma and at a quarter twist with complex orbitals are cases of the test suite (lih_crystal_nao and lih_crystal_nao_twist). The README in CASINO/utils/wfn_converters/aims and the FHI-aims section of the manual’s chapter on other programs have the details, and nao_check : T makes CASINO write every orbital of one spin of a naowfn.data file (so neu must equal ned), with gradients and Laplacians, at given points and stop (in a crystal the Bloch orbitals of every band at every k point in use), for anyone checking a converter or writing the file from another program.