NECI-testcode
This is a new page to post info on how to migrate the test code between machines, as was done between discovery and scepter recently. I will be adding to this as and when I have spare time. --js615 12:52, 12 October 2009 (BST)
Setting up the testcode
1. Check out the components
This script written by JSS sets the correct permissions for the CLEAN directory, including the "2" sticky. To take advantage of these permissions, all group members need to add umask 2 to their .bashrc files.
#!/bin/bash -x SVN=https://wwmm.ch.cam.ac.uk/svn2/groups/alavi mkdir CLEAN chgrp alavi CLEAN chmod 2775 CLEAN cd CLEAN svn co $SVN/NECI/trunk NECI svn co $SVN/CPMD/branches/QMC/trunk CPMD svn co $SVN/testcode testcode
Although this example uses svn, other version control software can be used. Currently, svn and git are supported by the testcode.
CPMD then needs to be told where NECI is:
js615@scepter:~/CLEAN/CPMD> cat .compileconf NECIsrc=/home/js615/CLEAN/NECI
2. Compiling the libraries
Certain compilers require certain libraries to be available when compiling CPMD and NECI. Which libraries are required can be investigated in the file checktest_config.
js615@scepter:~/CLEAN/testcode/main_testcode/tools> cat checktest_config
This contains blocks like this.
[PC-PGI] modules = pgi/32/8.0/5 use.own fftw3.2.2/32/pgi job_types = neci job_categories = NECI
Although not all versions are used, it is convenient to compile lapack and fftw across a range of compilers so that they are accessible to the test code.
Download the latest fftw and lapack into ~/local/lib. There are then four scripts (written by JSS) used to compile these with different compilers. Make edits to the versions as appropriate.
It's important to note that the current version of fftw (3.2.2) doesn't compile with pathscale.
Also, to use lapack as a library, different files need to be present in the lapack directories:
ln -s lapack_LINUX.a liblapack.a
See Lapack compilation for more information.
3. Setting up the libraries as modules
The command
module load use.own
allows use of local libraries via environment modules in the folder ~/privatemodules. See Environment modules for more information. The test code requires each library to be set up in this manner.
The procedure to set up a module is as follows:
js615@scepter:~/privatemodules> mkdir -p fftw3.2/64 js615@scepter:~/privatemodules> vi fftw3.2/64/pathscale
And then use the following input:
#%Module1.0##################################################################### ## ## ## set root /home/js615/local/lib/fftw-3.2 set version 3.2.2 module-whatis "Loads version $version of the fftw library, compiled in 64-bit." prepend-path LIBRARY_PATH $root/lib prepend-path LD_LIBRARY_PATH $root/lib prepend-path MANPATH $root/manpages/man/
Change the root to reflect where you've actually got this version of fftw.
The following statement should be added to the end of modules compiled with pathscale:
if { [ llength [ array get env PSC_GENFLAGS ] ] } {
set mypscflags "-L $root/lib $env(PSC_GENFLAGS)"
} else {
set mypscflags "-L $root/lib"
}
setenv PSC_GENFLAGS $mypscflags
Now the same module files need to be made for lapack. These require a slightly different header:
js615@scepter:~/privatemodules/lapack3.1.1/32> cat ifort #%Module1.0##################################################################### ## ## ## set root /home/js615/local/lib/lapack-3.1.1/32/ifort prepend-path LIBRARY_PATH $root/lib prepend-path LIBRARY_PATH $root/include prepend-path LD_LIBRARY_PATH $root/lib prepend-path LD_LIBRARY_PATH $root/include prepend-path MANPATH $root/manpages/man/
Note that in the current set-up there is slightly more information in these files, including (proc ModulesHelp and module-whatis). These have been ommitted here for clarity. People who are curious can go to the directory above and 'cat' the current file.
There is a more elegant solution to creating multiple modules for different compilers, using .base files. Furthermore, there is a better way to set PSC_GENFLAGS for pathscale. The build above is sufficient for the test code. To see these designs, go to:
scepter:/home/jss43/privatemodules
and also look at Environment modules.
4. Link the libraries to the test code.
The test code has a file called checktest_config which tells it which modules to load for each compiler. This is currently at:
js615@scepter:~/CLEAN/testcode/main_testcode/tools/checktest_config
These need to match the directory structure of your privatemodules set-up. To test this, take a block of checktest_config:
[PC-PGI] modules = pgi/32/8.0/5 use.own fftw3.2.2/32/pgi job_types = neci job_categories = NECI
and try to load everything on the "modules =" line (a "module purge" might be needed to avoid conflicts). E.g.
js615@scepter:~/CLEAN/testcode/main_testcode/tools> module load pgi/32/8.0/5 use.own fftw3.2.2/32/pgi