CASINO manual - Theory of Condensed Matter

• Evidence of testing on serial and parallel machines. Remember that in general only the master
processor should write to the output file. Also, casino is supposed to compile and work on
single-processor machines without an installed MPI (Message Passing Interface) library. Use the
fake comms serial.f90 module supplied both in the utils directory and with the main code
(in general you only need worry about this if you introduce a call to an MPI routine which is
not already used in casino and which has not been ‘faked’).
• If you use MPI calls when doing the parallel bits, try to ensure they are included in the MPI-1
standard since, somewhat unbelievably, there are some computers in the world which claim not
to be able to support the 14-year-old MPI-2 standard. Currently, the only MPI-2 routine used
in casino is MPI GATHER IN PLACE, and PLR has implemented a fake version of this in the
comms parallel mpi1.f90 routine which can automatically be used on machines which do not
have an MPI-2 installation (if their CASINO ARCH file tells them so).
• Your routine uses the standard casino facilities for handling errors (errstop/errwarn etc.).
These can be found in the run control.f90 module.
• Your routine implements something that we desperately want or is in the TODO list.
A.2.2
Bad things
• We do not sacrifice speed for additional functionality. Think of another way to write it if it
slows the code down.
• We do not like to include things unless they are completely general. The development of general,
complex electronic structure codes can be set back years by people choosing to implement
functionality which works only for their current project. Nongeneral algorithms tend to get
completely thrown away and re-implemented, which wastes the time of both parties. It is not
usually much harder to write a general program than it is to write a specific one (we understand
this is not always true!).
• You should not use any calls to external libraries apart from MPI, BLAS and LAPACK.
• When writing to the output file, the new routines should not write out lots of weird arrays
(whose meaning is understood only by the author) in an incredibly scruffy format full of spelling
mistakes. In general, be as beautiful and informative as you can when writing to output, or
MDT will just have to make it so (which takes ages). If there are all sorts of special cases
which require different output, then so be it—select case and if blocks are very useful in this
regard.
• Prior agreement for modification of the code should have been obtained. Unsolicited submissions
are not accepted and can lead to moody lack of cooperation on our part.
A.3 Testing and debugging CASINO
Here is some advice on how to go about testing and debugging casino after you have made some
modifications.
• Type make debug in ~/CASINO/src/ in order to compile the code with debugging options set.
The resulting binary can be run by the runscript using runqmc −−debug or runqmc −d.
• The best compilers for debugging on PCs are, in order of decreasing preference: NAG, G95 (now
deprecated), GCC, PathScale, Intel. MDT has recently discovered that the Cray compiler is
pretty good too.
• It is a good idea to try running the code using several different compilers on several different
architectures: this maximizes the chance of finding problems. There are bugs which require
a combination of compilers to locate successfully. Note that you should always test that your
modifications work on parallel computers, if possible.
• If you encounter a problem, try changing options in the input file before looking in the code.
For example, does the problem only occur when a Jastrow factor is used? Does it only occur
when the cusp correction is used? Try to obtain the simplest set of circumstances capable of
reproducing the problem.
215