Conversions in c2x
C2x does not offer complete conversion between the input files of the various DFT codes its supports. It is intended to automate as much as is reasonably possible, leaving the rest for manual attention. This page discusses some of the issues that prevent complete automatic conversion.
The basic operation of c2x is that it converts input to its own internal representation, and then produces output from that. With a few exceptions, information which has no representation in c2x's internal format is discarded.
Some DFT codes use a plane-wave basis set, described with a single cut-off parameter. Others use more complicated localised basis sets which cannot be described in this fashion. Castep will choose a cut-off for the basis set automatically based on the pseudopotentials used: other codes require it to be stated explicitly.
Castep will auto-generate pseudopotentials. Most other codes will not. Those codes which need pseudopotentials given explicitly do not necessarily read each other's formats. C2x currently makes no attempt to convert pseudopotentials.
Siesta has a way of specifying that the initial spin on an atom should be the maximum possible. Other codes require an explicit number in electrons. Determining the maximum possible spin for an atom is not trivial - it would require consideration of the pseudopotential used. C2x currently reads this syntax as simply +1 and -1.
Most codes allow one to specify initial spins by atom. Some only by atom type, so that for antiferromagnetic systems one needs two types of differing spin for the same species.
Unit Cell and Atomic Positions
Most codes specify three cartesian axes, and then the positions of all atoms in the unit cell. Some specify symmetry operations, and a reduced set of atoms or axes parameters. Extreme examples are Crystal, which specifies a space group (from 1 to 230), sometimes supplemented by flags specifying choice of origin and whether rhombohedral or hexagonal, and the reduced set of atoms. Abinit can optional use this system too. This leads to over 250 different possibilities to test, and c2x has not been tested that thoroughly. (Spglib will return symmetry operations for a given Hall number, so c2x attempts to convert the space group to a Hall number, and then calls spglib to enumerate the operations. If compiled without spglib support, c2x is unable to process input in this format.)
A middle way is shown by Quantum Espresso, which can specify cartesian axes and all atoms, or can express the axes in terms of Bravais lattices. It recognises 17 Bravais lattices, and for each has two ways of describing the required parameters. This leads to at least three dozen ways of describing just the unit cell.
Most codes support symmetry. Some list all operations, others just give a space-group number. For magnetic systems some ignore the extra complications of magnetic symmetry, other support full magnetic symmetry, which extends the number of space groups beyond the standard 230. The extra operations can transform spin-up bands into spin-down, so require significant extra support in the code. As two examples, Abinit supports magnetic symmetry operations, Castep does not.
Currently c2x makes no attempt to preserve or convert between the various ways of specifying constraints for ionic relaxation.
There are many parameters specifying details of the calculation required. Very few of these does c2x attempt to convert, not least because many have no conversion. One of the few which c2x does attempt to preserve is a convergence criterion specified in energy change per atom (or per unit cell).