Difference between revisions of "CamCASP/Compilation"
import>Am592 (→10.x) |
import>Am592 (→Issues) |
||
Line 55: | Line 55: | ||
====Issues==== |
====Issues==== |
||
* Newer versions of gcc (4.4.x onwards - I am not sure, perhaps even 4.3.x) result in a problem writing direct-access files with more than 16384 records. The exact number seems to fluctuate a little, but it is very close to <math>2^{14}</math>. The file gets mangled on either write or read. No other compiler seems to exhibit the problem, and nor did gfortran in mid-2009 when I used an experimental version of gfortran 4.4 or 4.3. |
* Newer versions of gcc (4.4.x onwards - I am not sure, perhaps even 4.3.x) result in a problem writing direct-access files with more than 16384 records. The exact number seems to fluctuate a little, but it is very close to <math>2^{14}</math>. The file gets mangled on either write or read. No other compiler seems to exhibit the problem, and nor did gfortran in mid-2009 when I used an experimental version of gfortran 4.4 or 4.3. |
||
+ | |||
+ | The problem is quite possibly in record_handler.F90: A simple code to write very large direct-access files works without a problem. |
||
===Compiling on Mac OS X=== |
===Compiling on Mac OS X=== |
Revision as of 11:06, 14 May 2010
CamCASP => Compilation
Notes on compiling CamCASP
PGF90
By in large, this compiler works with CamCASP.
10.x
Cannot compile gamint.F and dma.F90 without reducing optimization level to -O2. With -O3 we get an assembler error message:
pgf90 -O3 -DPGF90 -DCADPAC -DGAMESS -DSAPT2002 -DSIGNED_INTEGER -Mpreprocess -fastsse -mcmodel=medium -c /home/am592/CamCASP/5.5-dev/src/gamint.F -o gamint.o /tmp/pgf904O4eOUrbnf_T.s: Assembler messages: /tmp/pgf904O4eOUrbnf_T.s:9543: Error: no such instruction: `pmaxsd (%rcx),%xmm0' /tmp/pgf904O4eOUrbnf_T.s:9545: Error: no such instruction: `pmaxsd 16(%rcx),%xmm0' make[2]: *** [gamint.o] Error 2
A similar message is printed with dma.F90. I've seen this error with 10.1-4.
Gfortran
There seem to be problems with gfortran versions earlier than 4.3. I think it is because the preprocessor is not automatically used (even if -cpp is used, because only with version 4.4 is this option recognised). It may be possible to get around this, but for now, I've found it easier to download my own copy of GCC 4.4. It may still have bugs (at one stage it couldn't find include files when compiling Dalton) but the current version (20090219) seems OK.
GCC 4.4 will reside in its own directory. Do not install it in with the other GCC compilers as it is still under development. Because it will reside in a non-standard location, you need to set some environment scripts to get the compilation going. I use the following scripts.
1. gcc_4.4.env
#!/bin/bash gcc44="tmp/gcc-trunk" export LD_RUN_PATH=${HOME}/$gcc44/lib64 echo $LD_RUN_PATH export LD_LIBRARY_PATH=${HOME}/$gcc44/lib64:$LD_LIBRARY_PATH export PATH=${HOME}/$gcc44/bin:$PATH
2. makeall
#!/bin/bash source ./gcc_4.4.env echo $LD_RUN_PATH echo $LD_LIBRARY_PATH gfortran -v mymake='make COMPILER=gfortran MACHINE=tati ' ${mymake} clean ${mymake} all exit
These are really simple scripts. After compilation (when makeall exits) the default GCC flags will be reset, so your experimental version of GCC doesn't affect anything else.
Users should be aware that GCC and GFortran are under active development, and that incompatible changes sometimes occur. In particular, internal changes have sometimes led to linking problems, which could only be resolved by recompiling the ATLAS/lapack library with the latest version of the compiler.
Issues
- Newer versions of gcc (4.4.x onwards - I am not sure, perhaps even 4.3.x) result in a problem writing direct-access files with more than 16384 records. The exact number seems to fluctuate a little, but it is very close to <math>2^{14}</math>. The file gets mangled on either write or read. No other compiler seems to exhibit the problem, and nor did gfortran in mid-2009 when I used an experimental version of gfortran 4.4 or 4.3.
The problem is quite possibly in record_handler.F90: A simple code to write very large direct-access files works without a problem.
Compiling on Mac OS X
1. Install Fink and FinkCommander. (See http://finkcommander.sourceforge.net.) You can build all the programs from the command line -- no need for Xcode.
2. Make sure you get the latest version of gfortran, from http://gcc.gnu.org/wiki/GFortranBinaries.
3. You need the full ATLAS lapack library.
4. The CamCASP programs should compile without any problems using the scripts above. Make sure that the -static flag is not specified, though.
5. See below for information on compiling Dalton.
6. Building SAPT is troublesome, because file-names in Mac OS X are case-insensitive, so the shell script called SAPT in the SAPT bin directory gets confused with the SAPT executable called sapt. This can be worked around by renaming the SAPT script, e.g. as SAPT.sh, and commenting out the lines (around line 348) in Compall that change the first line of SAPT. (It doesn't need to be changed for Mac OS.) This must be done before attempting to run Compall -- otherwise the SAPT script will get overwritten by the sapt binary. Line 329 of Compall also needs to be changed to provide for the gfortran option. The current version of CamCASP doesn't use either SAPT or sapt unless 3rd-order energies are wanted.
7. Building Orient is fairly straightforward except for the link options.
- Omit the -static option.
- The ATLAS libraries need to be invoked by giving the full pathname of each library file in the gfortran link step -- otherwise the Mac version of ATLAS is scanned, leaving many unresolved references. That is, instead of "-llapack", specify e.g. "/usr/local/ATLAS/OSX_CORE2SSE2/lib/liblapack.a", and similarly for cblas, f77blas and atlas.
- The OpenGL libraries are provided as standard in Mac OS X. To include them, specify "-Wl,-framework,OpenGL -Wl,-framework,GLUT" in the link step.
Compiling SAPT2006
Gfortran
Here's the preamble of the Compall script I use on my Hapertown Quad-core Intel with Gfortran:
G94=NO G03=NO #/home/patkowsk/gaussian/g03 # specify path to the G98/G03 directory GAUEXE=NO # change if G98 is used instead of G03 EXTRADEFS='' # if Gaussian was compiled with -DI64 and/or -DPACK64, place # these definitions here as well # TWOGIGAMAX and/or TPDRVN can also be put here GAMESS=NO VERNO=00 # specify for Gamess CADPAC=NO DALTON=/home/am592/DALTON/dalton-2.0-2006/bin/dalton ACES=NO # molpro interface works only with fortran-90 compilers MOLPRO=NO # DIIS in CC code DIIS=YES SAPTDFT=YES ######### TARGET system ########################################## # # Curently available: sgi, ibm32, ibm64, alpha, g77, g77_64 (AMD64), # g77_32 (AMD64 in 32bit mode), pgf77 (on AMD64 32-bit only), # pgf90 (works on AMD64), ifort (on AMD64 32-bit only), sunf90, hpux. # gfortran works only partially (not recommended) ################################################################## TARGET=gfortran ########### Location of the blas and lapack library you want to use ##### # # usually ' -llapack -lblas ', but sometimes different, e.g., ' -ldxml ' on alpha, # or ' -L/scratch -llapack -lcblas -lf77blas -latlas ' on our Athlons with LAPACK # or ' -xlic_lib=sunperf ' on our strauss (SPARC). # or ' -lessl ' works on brainerd (-lblas does not work # for some reason) # ############################################################## BLAS=' -L/home/am592/ATLAS/Linux_Intel64/lib/ -llapack -lcblas -lf77blas -latlas ' BUILDLAPACK=NO # set to NO if you provide your own Lapack ... ...
When using Gfortran you will encounter another problem: Compall tries to build ATMOL1024 by default (as it finds the directory SAPT2006/atmol1024). But there is no makefile for Gfortran located in SAPT2006/atmol1024/ so move SAPT2006/atmol1024 to SAPT2006/atmol1024_not_used and Compall will bypass it.
Compiling DALTON 2.0
Patching DALTON
Obtain the patch from SAPT2006. Our version of DALTON 2.0 includes the patches in the DALTON/patches/ sub-directory. There are instructions in the README file in that directory. But all you do is:
cd DALTON patch -p0 < patches/patch-sapt-2006-1
Where patch-sapt-2006-1 happens to be the latest patch at the present time.
Gfortran
For Dalton, the configure script must be edited to allow for the use of gfortran.
- At around line 1091, after the g77 section for darwin, insert
elif [ "$F77" = gfortran ]; then cpp="-DVAR_G77 $cpp" mcpu="" copt="$mcpu -O3 -ffast-math -fexpensive-optimizations -funroll-loops" copt2="$mcpu -O2 -ffast-math -fexpensive-optimizations -funroll-loops" opt="$copt2 -std=legacy" copt="$copt -std=c99 -DRESTRICT=restrict" def='linux.x' inc='-I../include' cpp=${cpp}" -DIMPLICIT_NONE"
- At around line 1010 insert, after the pgf77 section for linux,
gfortran) # cpp="-DVAR_PGF77 $cpp" copt="-O3 -ffast-math -fexpensive-optimizations -std=c99 -DRESTRICT=restrict" opt="-O3 -ffast-math -funroll-loops" safe_opt="-O3 -ffast-math -funroll-loops" ;;
- Change line 744 to 'tab=$($ECHO "\t")'.
- In line 200 or thereabouts, add "gfortran" to the linux and darwin complists.
Some minor code changes are also needed.
- In cc/cc_pckutil.F, line 100, change z'C0000000' to transfer(z'C0000000',1). A similar change is needed in lines 236 and 238.
- In abacus/her2out.F, replace line 406 by
PERCNT = real(100*N2WRIT,kind(PERCNT)) / real(NALL,kind(PERCNT))
Finally, the script bin/dalton may need to be edited to give the correct path to the executables. (Best written as, e.g., "$DALTON/bin/dalton.x".)
Portland
BLAS and LAPACK libraries
GOTO
I just experimented with the Goto libraries. A quick LU decomposition test showed Goto to be 15% faster than the ATLAS libraries. This is quite good. The library builds flawlessly (using gcc and gfortran) and even automatically downloads and builds LAPACK so you get it all, and very quickly too. Linking is straightforward, but you need to link to -lpthreads in addition to -lgoto2. For example:
-L/home/am592/ATLAS/GotoBLAS2/ -lgoto2 -lpthread
Since the Goto library is threaded, some of the observed speedup could well be due to the threading. So more careful tests are needed. In any case, this is something to look at seriously. --alston 16:48, 8 April 2010 (BST)