About compiling cp2k

[nadler]

Hi Phil,

Try to reduce the optimization flags, this helped me to get rid of the 
segmentation faults with earlier versions of ifort. Start with -O0 and if 
the error disappears, try -O2 which should be enough. Then also, if you use 
the arch file as you've posted it you should move the part

MKL = /usr/local/intel/composer_xe_2011_sp1.9.293/mkl 
MKL_INC = $(MKL)/include/fftw 
MKL_LIB = $(MKL)/lib/intel64 

INTEL_MKL_LIB=$(HOME)/cp2k/fftw3xf

to the top of the file. Otherwise  -I$(MKL_INC) has nothing to include. 
With the new Intel compilers the FFTW is now contained in the MKL library 
directly and there is no need to build the wrapper:
http://software.intel.com/en-us/articles/build-cp2k-using-intel-fortran-compiler-professional-edition/

I hope this helps.

Regards,
Roger


On Monday, April 16, 2012 9:27:47 PM UTC+2, Phil Song wrote:
>
> Hi, all: 
>
> I am trying to compile cp2k serial version with the newest intel 
> fortran compiler (64 Compiler XE Version 12.1.3.293 Build 20120212). 
> And I have used a config file (attached later) for compiling, where I 
> have compiled the fftw3 that comes with the intel MKL library and put 
> it on $(HOME)/cp2k/fftw3xf for linking (because I am not the 
> administrator of the cluster). Both the compiling and linking went 
> smoothly. 
>
> However, when I tried to run one of the test example in the cp2k/tests/ 
> QS directory. The program crashed in the middle of the run after 
> display "QUICKSTEP" with a segmentation fault (SIGSEGV). I have tried 
> to open up a debugger to see what happened and I have found that the 
> segmentation fault was originated from the following stack: 
>
> =========================================================================== 
>
> #0  0x00007f575fcfb985 in mkl_blas_dgemm_mscale () in /usr/local/intel/ 
> composer_xe_2011_sp1.9.293/mkl/lib/intel64/libmkl_mc3.so 
> #1  0x00007f576245b9a5 in mkl_blas_dgemm_mscale () in /usr/local/intel/ 
> composer_xe_2011_sp1.9.293/mkl/lib/intel64/libmkl_core.so 
> #2  0x00007f575ffa5313 in mkl_blas_xdgemm () in /usr/local/intel/ 
> composer_xe_2011_sp1.9.293/mkl/lib/intel64/libmkl_mc3.so 
> #3  0x00007f576245d369 in mkl_blas_xdgemm () in /usr/local/intel/ 
> composer_xe_2011_sp1.9.293/mkl/lib/intel64/libmkl_core.so 
> #4  0x00007f5763485dff in mkl_blas_dgemm () in /usr/local/intel/ 
> composer_xe_2011_sp1.9.293/mkl/lib/intel64/libmkl_sequential.so 
> #5  0x00007f5763bbf11b in dgemm () in /usr/local/intel/ 
> composer_xe_2011_sp1.9.293/mkl/lib/intel64/libmkl_intel_ilp64.so 
> #6  0x0000000000ecdb8a in basis_set_types_mp_init_orb_basis_set_ () 
> in /home/ysong/cp2k/cp2k-2.2/exe/Linux-x86-64-intel/cp2k.sopt 
> #7  0x0000000000eaf716 in atomic_kind_types_mp_init_atomic_kind_set_ 
> () in /home/ysong/cp2k/cp2k-2.2/exe/Linux-x86-64-intel/cp2k.sopt 
> #8  0x0000000001629043 in qs_environment_mp_qs_init_subsys_ () in / 
> home/ysong/cp2k/cp2k-2.2/exe/Linux-x86-64-intel/cp2k.sopt 
> #9  0x000000000163023f in qs_environment_mp_qs_init_ () in /home/ysong/ 
> cp2k/cp2k-2.2/exe/Linux-x86-64-intel/cp2k.sopt 
> #10 0x000000000085b35c in qs_main_mp_quickstep_create_force_env_ () 
> in /home/ysong/cp2k/cp2k-2.2/exe/Linux-x86-64-intel/cp2k.sopt 
> #11 0x0000000000465341 in f77_interface_mp_create_force_env_ () in / 
> home/ysong/cp2k/cp2k-2.2/exe/Linux-x86-64-intel/cp2k.sopt 
> #12 0x000000000040bc8a in cp2k_runs_mp_cp2k_run_ () in /home/ysong/ 
> cp2k/cp2k-2.2/exe/Linux-x86-64-intel/cp2k.sopt 
> #13 0x000000000040ae44 in cp2k_runs_mp_run_input_ () in /home/ysong/ 
> cp2k/cp2k-2.2/exe/Linux-x86-64-intel/cp2k.sopt 
> #14 0x0000000000407a06 in MAIN__ () in /home/ysong/cp2k/cp2k-2.2/exe/ 
> Linux-x86-64-intel/cp2k.sopt 
> =========================================================================== 
>
>
> I was trying to further debug the cp2k source code to figure out where 
> the problems came from. But it seemed that the parameters passed to 
> basis_set_types_mp_init_orb_basis_set seemed all right. Therefore, I 
> am very confused. Could this be a problem with the newest MKL, which I 
> think is unlikely? Or could this be a bug in the cp2k source? Or could 
> I did not compile and link the program correctly? 
>
> I have spent quite a long time look at this and still could not solve 
> it. I hope someone can help me with this and any suggestion will be 
> greatly appreciated. 
>
> Thanks a lot! 
>
> Best, 
> Phil Song 
>
> The machine that I have used to compile cp2k is equipped with a quad 
> core i7 920. 
>
> The config file Linux-x86-64-intel.sopt for compilation is attached as 
> follow. 
>
> =========================================================================== 
>
> CC       = icc 
> CPP      = 
> FC       = ifort 
> LD       = ifort 
> AR       = xiar -r 
> DFLAGS   = -D__INTEL -D__FFTSG -D__FFTW3 -D__FFTMKL 
> CPPFLAGS = -C -traditional $(DFLAGS) -I$(MKL_INC) 
> FCFLAGS  = $(DFLAGS) -I$(MKL_INC) -O3 -xHost -heap-arrays 64 -fpp - 
> free 
> FCFLAGS2 = $(DFLAGS) -I$(MKL_INC) -O1 -xHost -heap-arrays 64 -fpp - 
> free 
> LDFLAGS  = $(FCFLAGS) 
>
> MKL = /usr/local/intel/composer_xe_2011_sp1.9.293/mkl 
> MKL_INC = $(MKL)/include/fftw 
> MKL_LIB = $(MKL)/lib/intel64 
>
> INTEL_MKL_LIB=$(HOME)/cp2k/fftw3xf 
>
> LIBS     = -L$(MKL_LIB) -L$(INTEL_MKL_LIB) \ 
>            -lfftw3xf_intel \ 
>            -lmkl_intel_ilp64 -lmkl_sequential -lmkl_core -lpthread -lm 
>
> OBJECTS_ARCHITECTURE = machine_intel.o 
>
> graphcon.o: graphcon.F 
>         $(FC) -c $(FCFLAGS2) $< 
>
> qs_vxc_atom.o: qs_vxc_atom.F 
>         $(FC) -c $(FCFLAGS2) $< 
> ===========================================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20120417/d2096654/attachment.htm>