CASINO manual - Theory of Condensed Matter

39.2 Implementation basics and performance
The general strategy of this implementation is to use OpenMP parallelism for the loops whose trip
counts scale with the number of electrons or atoms. In the QMC algorithm the basic logical units
that need to be parallelized are routines like
• orbital evaluation routines,
• Jastrow factor evaluation routines,
• inverse Slater matrix updating routine,
• potential energy evaluation routine,
• electron–electron and electron–nucleus distance evaluation routines,
• etc.
Extensive performance tests were done on pseudopotential systems that use the blip3d and
blip3dgamma. The best performance obtained on a AMD quadcore CPU was for a system of 1024
electrons. The speedup factor was close to 1.5 for 2 OpenMP threads and close to 2 for 4 OpenMP
threads. Larger systems had update dbar as an OpenMP bottleneck.
39.3 Using OpenMP
To use the experimental OpenMP feature, compile the code with make Openmp on a supported architecture.
Then use the option --tpp threads-per-process in the runqmc command line to specify
the number of OpenMP threads per process.
E.g. to run two processes with two threads each you would type runqmc --nproc=2 --tpp=2, ideally
on a 4-core machine. By default on batch-queueing systems the number of cores reserved for the job
will be nproc * tpp.
Note finally that when analysing timing data from Openmp runs you need to look at the ‘Real Time’
data, rather than the ‘CPU time’ data, since the CPU time is summed over all OMP threads.
A
Appendix 1: Programming guide for CASINO
Because you signed our legal agreement (you did, didn’t you?) you are not allowed to make modifications
to casino without explicit written permission from the Cambridge group. This is generally very
easy to obtain, though we do not guarantee to incorporate your changes into the public distribution
if we don’t like them, or to keep them there afterwards if we think of a better way to do it (but then,
who does?). If you have obtained this permission, then please read the following.
The main casino source code and many of the utilities are written in Fortran, which must conform
to the Fortran 95 standard (later standards are not necessarily supported by all compilers). There
are also a couple of simple C routines in the main code (for shared memory etc.). Utilities not
in Fortran should generally be written as bash shell scripts (or possibly tcsh or csh, though this
is deprecated). We did once accept a C++ pseudopotential conversion utility, though this adds to
problems with portability. The ADF converter in utils/wfn converters/adf is written in Python,
though we provide no official support for this or any other programming language. Please understand
that casino is meant to compile, setup and run out of the box on any computer in the world, and
the fewer languages we are dependent on the easier this is to achieve.
A.1 Style
casino has a Fortran95 ‘style’ which should be adhered to when writing code, both for the main source
and for the Fortran utilities. This is because it is desirable that the package has a homogeneous look
and feel (and because searching for text strings then works consistently). Everybody has their own
style. Yours is different and may even be better, but we’ve decided on one for casino and there it
is. If you don’t write your code like this, the likelihood is that MDT or someone else will reformat it
for you, and they will probably accidentally delete a crucial minus sign while correcting your routine,
211