It is quite likely that you are the first person to have built and run Castep with the particular combination of compiler, maths library and MPI that you have selected, even if you select a serial build rather than MPI. This is true not least because Intel, one of the more popular compiler choices, produces rather a lot of releases each year.
To perform a comprehensive test that Castep has built correctly,
given the large feature set of the code, would take a while to run,
and such a test suite would be near impossible to create. The
current official build system does offer a reasonable attempt at testing
make check, and the
following suggestions, which are greatly inadequate but better than
absolutely nothing, date from the time before that existed.
The suggestion is, unsurprisingly, ethene from the c2x molecule visualisation pages. One needs a file called ethene.cell with the contents
%block LATTICE_ABC ang 8.000000 8.000000 7.000000 90.000000 90.000000 90.000000 %endblock LATTICE_ABC %block POSITIONS_ABS C 4.698560 4.000000 3.500000 C 3.301440 4.000000 3.500000 H 5.270880 4.923920 3.500000 H 2.729120 3.076080 3.500000 H 2.729120 4.923920 3.500000 H 5.270880 3.076080 3.500000 %endblock POSITIONS_ABS kpoints_mp_grid 1 1 1 kpoints_mp_offset 0.25 0.25 0.25and one called ethene.param with the contents
cut_off_energy = 40 ry iprint = 1 opt_strategy : speed
When run using a command similar to `./castep ethene', this should produce an ethene.castep file (amongst others) within about a minute (around 30s on a 2.5ish GHz Core2 / Athlon II).
Towards the end should be magic lines such as
Final energy, E = -373.6865037499 eV Final free energy (E-TS) = -373.6865037499 eV (energies not corrected for finite basis set) NB est. 0K energy (E-0.5TS) = -373.6865037499 eV
The error expected is about +/-0.000 05eV. Note that the forces are not zero, as the structure is not relaxed. In particular, the carbons have a huge 3.7eV/A force along the x axis.
(From Castep 8.0 the expected energy is about -378.015eV. Absolute energies are not well defined -- it is differences (calculated with similar versions of Castep!) which matter.)
Why any error? The code (used in this fashion) generates pseudopotentials automatically, and pseudopotential generation is very sensitive to details of arithmetic rounding - one rarely gets the same pseudopotentials on two different computer systems. This is no cause for alarm, because the absolute energies from a pseudopotential are not very meaningful. What are meaningful are the energy differences between structures when using the same pseudopotential. Generating pseudopotentials using different BLAS libraries, or with / without MPI, can shift energies by a few ueV per atom.
As on one compiler the following did show an obvious error, I would then recommend retrying this test with the parameter cut_off_energy set to `60 ry'. Variational theory says that this better basis set should give a lower energy, and indeed the answer should drop by about 3.36meV (to -373.68986eV).
Most error are obvious: the code crashes, or it fails to converge, or it converges to an answer far (eV) away from the value given. Note that the number of SCF steps needed to converge is not precisely defined, due to pseudopotential differences, random initialisation differences, and rounding differences at run time. For this system the answer is probably 17+/-1.
Ideally one would now test something metallic too, and maybe something with a rather higher atomic number than carbon. Perhaps further tests will appear here later.