[lammps-users] fftw and compilation issues

I’m having trouble getting lammps to compile on one of the Teragrid computers (NCSA - Abe). The problem seems to be linking to the fftw library. I am puzzled as to what to try next. A google search turned up an old post to the CPMD mailing list (replied to by Alex K.) suggesting that there is a conflict with 32 vs 64 bit compilers, but I am unsure how to resolve this issue.

First, I compiled my own copy of fftw v2.1.5 using

./configure --prefix=${HOME}/fftw-2.1.5 --disable-shared
make
make install

Next, I set up my lammps makefile to point to it:

FFT_INC = -DFFT_FFT
FFT_PATH = -L ${HOME}/fftw-2.1.5/
FFT_LIB = -lfftw

Everything compiles fine until it tries to link the .o files and it gives me the following error:

/usr/local/intel/10.1.017/lib/libimf.so: warning: warning: feupdateenv is not im
plemented and will always fail
fft3d.o(.text+0xab): In function fft_1d_only(FFT_DATA*, int, int, fft_plan_3d*) ': : undefined reference to zfft1d_’
fft3d.o(.text+0xf3): In function fft_1d_only(FFT_DATA*, int, int, fft_plan_3d*) ': : undefined reference to zfft1d_’
fft3d.o(.text+0x130): In function `fft_1d_only(FFT_DATA*, int, int, fft_plan_3d*
)’:

I also tried using the installed version of fftw v2.1.5 (doc: http://hpcsoftware.ncsa.illinois.edu/Software/user/show_all.php?deploy_id=725&view=NCSA)
with the same results.

A slight modification to the makefile, yields different results:

FFT_INC = -DFFT_FFT
FFT_PATH = ${HOME}/fftw-2.1.5/
FFT_LIB = -lfftw

Result:
ipo: error #11021: OBJREAD Error: Could not create mapping for /u/ac/jschall/fftw-2.1.5
icpc: error #10014: problem during multi-file optimization compilation (code 1)
make[1]: *** […/lmp_abe] Error 1
make[1]: Leaving directory `/u/ac/jschall/lammps/src/Obj_abe’
make: *** [abe] Error 2

Thanks inadvance.

hi dave,

I'm having trouble getting lammps to compile on one of the Teragrid
computers (NCSA - Abe). The problem seems to be linking to the fftw library.

there are a number of reasons, why you should give
the LAMMPS-ICMS version a try. the main reason is
that its OpenMP enabled pair styles will allow you to
run more than twice as fast compared to the best effort
all MPI on that machine.

I am puzzled as to what to try next. A google search turned up an old post
to the CPMD mailing list (replied to by Alex K.) suggesting that there is a
conflict with 32 vs 64 bit compilers, but I am unsure how to resolve this
issue.

this does not apply in this case. CPMD is a _very_ different animal,
starting with the fact that it is written in fortran and interfacing c and
fortran is a whole different story.

First, I compiled my own copy of fftw v2.1.5 using

./configure --prefix=${HOME}/fftw-2.1.5 --disable-shared
make
make install

Next, I set up my lammps makefile to point to it:

FFT_INC = -DFFT_FFT

this should be -DFFT_FFTW

FFT_PATH = -L ${HOME}/fftw-2.1.5/
FFT_LIB = -lfftw

Everything compiles fine until it tries to link the .o files and it gives me
the following error:

/usr/local/intel/10.1.017/lib/libimf.so: warning: warning: feupdateenv is
not im
plemented and will always fail
fft3d.o(.text+0xab): In function `fft_1d_only(FFT_DATA*, int, int,
fft_plan_3d*)
':
: undefined reference to `zfft1d_'
fft3d.o(.text+0xf3): In function `fft_1d_only(FFT_DATA*, int, int,
fft_plan_3d*)

this looks like you have an -DFFT_INTEL somewhere in your
makefile, _or_ didn't do a "make clean-abe" after changing it.
in that case you'd have to link to MKL.
if you want to use MKL, you probably want to use the newer
(non-fortran) FFT that ships with it.

again, LAMMPS-ICMS is what would help you. it also has an
internal FFT that would be compiled with -DFFT_NONE and
thus will _always_ work (and is not that much slower than the others).

: undefined reference to `zfft1d_'
fft3d.o(.text+0x130): In function `fft_1d_only(FFT_DATA*, int, int,
fft_plan_3d*
)':

I also tried using the installed version of fftw v2.1.5 (doc:
http://hpcsoftware.ncsa.illinois.edu/Software/user/show_all.php?deploy_id=725&view=NCSA)
with the same results.

A slight modification to the makefile, yields different results:

FFT_INC = -DFFT_FFT

again, this should be -DFFT_FFTW

FFT_PATH = ${HOME}/fftw-2.1.5/
FFT_LIB = -lfftw

you'll have to check whether this is a single or double precision compile.
quite possibly the former.

Result:
ipo: error #11021: OBJREAD Error: Could not create mapping for
/u/ac/jschall/fftw-2.1.5
icpc: error #10014: problem during multi-file optimization compilation (code
1)
make[1]: *** [../lmp_abe] Error 1
make[1]: Leaving directory `/u/ac/jschall/lammps/src/Obj_abe'
make: *** [abe] Error 2

this still looks like you are using your old fftw install.

btw: i strongly recommend to disable IPO. regardless of what the
documentation says, it will only waste your time by increasing your
compilation times and slow down your executable. these kind of
optimizations fail miserably on any larger numerical scientific software.

cheers,
    axel.

Thanks Alex,

It took a little fiddling around but I was able to compile and execute the omp version of lammps. It was much easier than the regular version due to the kissfft. I don’t think I will get much speed up because my simulation box is mostly water and about 1% other stuff. Is there any hope of seeing lj/cut/coul/long/tip4p/omp in the near future?

Also, I’ve been compiling with no-reax no-meam. At some point I’d like to try some simulations with reax. I think I am missing some libraries. Is it pretty well documented? I haven’t spent to much time looking yet. Just wondering, no big deal.

Thanks for all your help.

Dave

Thanks Alex,

It took a little fiddling around but I was able to compile and execute
the omp version of lammps. It was much easier than the regular version
due to the kissfft. I don't think I will get much speed up because my
simulation box is mostly water and about 1% other stuff. Is there any

the speed impact of the choice of FFT library itself is
independent from the number of (charged) atoms. some FFTs
run faster with specific grid sizes than others. LAMMPS
already resticts the choices to the common ones. kissfft
is an extremely minimalistic implementation, but still
fairly efficient. but the nature of the FFT algorithm is
such, that it is very difficult to gain extra performance.

hope of seeing lj/cut/coul/long/tip4p/omp in the near future?

thanks for the reminder. i was convinced we had everything covered,
but the tip4p pair styles must have slipped through the cracks.
i'll have to check, though, whether there is something that limits
the use of my threading approach to this code.

Also, I've been compiling with no-reax no-meam. At some point I'd like
to try some simulations with reax. I think I am missing some
libraries. Is it pretty well documented? I haven't spent to much time
looking yet. Just wondering, no big deal.

reaxx is fortran. what you have to figure out is which runtime
libraries are needed to link fortran and c++. this is not really
a LAMMPS specific issue, but not many codes require this (often
it is either c++ or fortran to be linked to c and that is easy to do),
so there is less documentation on it. you have to sift through
the respective compiler documentations.

cheers,
    axel.

dave,

box is mostly water and about 1% other stuff. Is there any hope of seeing
lj/cut/coul/long/tip4p/omp in the near future?

lj/cut/coul/long/tip4p/omp is now implemented.

can you send me a (small) test input?
the special treatment of TIP4P required some
non-trivial changes, and i would like to test
them before making the code ready for inclusion
into mainline-lammps.

thanks,
    axel.