Difference between revisions of "NECI-testcode"

From CUC3
Jump to navigation Jump to search
import>Js615
import>Js615
Line 70: Line 70:
 
##
 
##
 
##
 
##
set root /home/js615/local/lib/fftw-3.2 # This is the directory of your compiled fftw for this compiler
+
set root /home/js615/local/lib/fftw-3.2
 
set version 3.2.2
 
set version 3.2.2
 
module-whatis "Loads version $version of the fftw library, compiled in 64-bit."
 
module-whatis "Loads version $version of the fftw library, compiled in 64-bit."
Line 76: Line 76:
 
prepend-path LD_LIBRARY_PATH $root/lib
 
prepend-path LD_LIBRARY_PATH $root/lib
 
prepend-path MANPATH $root/manpages/man/
 
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 ] ] } {
 
if { [ llength [ array get env PSC_GENFLAGS ] ] } {
 
set mypscflags "-L $root/lib $env(PSC_GENFLAGS)"
 
set mypscflags "-L $root/lib $env(PSC_GENFLAGS)"
Line 82: Line 87:
 
}
 
}
 
setenv PSC_GENFLAGS $mypscflags
 
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
  +
  +
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.
  +
  +
js615@scepter:~/CLEAN/testcode/main_testcode/tools> module load pgi/32/8.0/5 use.own fftw3.2.2/32/pgi

Revision as of 16:54, 12 October 2009

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.

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.

setup_lapack.sh

[[setup_fftw.sh] compile_fftw.sh

compile_lapack.sh

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

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.

 js615@scepter:~/CLEAN/testcode/main_testcode/tools> module load pgi/32/8.0/5 use.own fftw3.2.2/32/pgi