Yambo Community Forum

Dear all,

I faced a linking problem while trying to compile yambo-3.2.1-r.506 on Magerit-CeSViMa. This supercomputer consists of IBM PowerPC servers (BladeCenter JS20 and JS21). My problem is that I could compile and link yambo and p2y, however there was an error while linking ypp:

(eval mpif90 -q64 -O3 -qnoescape -qnostrict -qarch=ppc970 -qtune=ppc970 -I/gpfs/projects/ehu35/maurizia/D_marton/yambo-3.2.1/include -o ypp driver.o getopt.o mod_YPP.o ypp_i.o ypp_init.o ypp_init_load.o k_grids.o excitons_driver.o electrons_driver.o plot_check_and_launch.o plot_gnuplot.o plot_xcrysden.o excitons_sort_and_report.o -L/gpfs/projects/ehu35/maurizia/D_marton/yambo-3.2.1/lib -lbse -linterface -lsetup -lqp_ctl -lbz_ops -lwf_and_fft -lio -lcommon -lcommunicate -lparser -lxc_functionals -lmodules -lexternal_c /gpfs/apps/LAPACK/3.0/64/liblapack.a /gpfs/apps/BLAS/1.0.0/64/lib/libblas.a -lnetcdf -llocal -lm ) > /dev/null
/gpfs/projects/ehu35/maurizia/D_marton/yambo-3.2.1/lib/libbse.a(K_output_file.o):(.text+0x270): undefined reference to `o_eels'
/gpfs/projects/ehu35/maurizia/D_marton/yambo-3.2.1/lib/libbse.a(K_output_file.o):(.text+0xce0): undefined reference to `o_eels'
/gpfs/projects/ehu35/maurizia/D_marton/yambo-3.2.1/lib/libbse.a(K_output_file.o):(.text+0x1600): undefined reference to `o_eels'
/gpfs/projects/ehu35/maurizia/D_marton/yambo-3.2.1/lib/libbse.a(K_output_file.o):(.text+0x1f20): undefined reference to `o_eels'
make[1]: *** [ypp] Error 1
make[1]: Leaving directory `/gpfs/projects/ehu35/maurizia/D_marton/yambo-3.2.1_test/ypp'
make: *** [ypp] Error 2

I searched through the forum and the source as well, hoping that there is a trivial problem, and I also tried to modify the configure options (see the original version below), but I could only worsen things. Anyway, it seems that yambo and p2y binaries work well, at least I got reasonable results.

Here are the options I pass to configure:
PF90=xlf90_r FC=xlf90_r F77=xlf_r CC=xlc_r CPP="cpp -E -P" --with-blas=/gpfs/apps/BLAS/1.0.0/64/lib/libblas.a --with-lapack=/gpfs/apps/LAPACK/3.0/64/liblapack.a --with-p2y=4.0 --with-iotk=/gpfs/projects/ehu35/espresso-4.0.5/iotk --with-netcdf-include=/gpfs/apps/NETCDF/3.6.0/64/include --with-netcdf-lib=/gpfs/apps/NETCDF/3.6.0/64/lib --with-fftw=/gpfs/apps/FFTW/3.2/64/lib --enable-msgs-comps=no

Lapack, blas, fftw libraries and espresso were built by the support, and the version of the IBM fortran/c compiler is 12.1/10.1.

Any help will be appreciated. I could send further details on the compilation if needed.

Yours,
Marton

#-------------------------------------------------#
# M\'arton V\"or\"os #
# PhD student #
# Department of Atomic Physics, #
# Budapest University of Technology and Economics #
# Budafoki út 8., H-1111, Budapest, Hungary #
# http://www.fat.bme.hu/MartonVoros #
#-------------------------------------------------#

Hello Marton,

Maybe xlf is stricter than other compilers. I do not know since I am not using it. (you may look at http://www.yambo-code.org/doc/compiling.php , there is something on xlf). So maybe other people know better... The following may be a quick fix.

It is true that o_eels, called in one of the library (libbse) that "you" are linking is not referenced. Other compilers seem to be fine with that.

You may try to add -lpol_function when linking (e.g. you can add it in the ypp/Makefile under "llibs=", I am not sure of the order, try just before or after -lbse, save and close the file, and do "make" just in that directory, e.g. ypp)

Of course linking pol_function may lead to more undefined references . In that case all the libs that are needed are in the folder lib (*.a) in your yambo dir, you can see what is in there using "ar -t somelib.a", e.g
I hope this help.

Let us know.
m

PS Please edit your signature in the user control panel (the profile tab), in that way it will be included automatically to all your post! Thanks.

Dear Myrta,

Your quick fix worked: putting -lpol_function after -lbse in ypp/Makefile, row "llibs=" solved the problem, now I have a working ypp executable. Thank you for your fast reply!

(signature edited)

Yours,
Marton

Dear Myrta,

It seems that I spoke too soon... I was so happy to get it linked. I was mistaken that "ypp -H" would actually tell if ypp works or not. Unfortunately, now I have the following problem if I try to generate an input with ypp:
Do you have any idea what happens?

Furthermore, I think I found a small bug. After I had a compilation failure with mod_logo.f (note the suffix ".f", in the makefile I have f90suffix = .f), it wasn't removed after make clean_all. Therefore if I recompiled the code with new (and good) compiler options, the same compiler error appeared. I don't really know if this is a real problem, but the file mod_parser_m.f also remained after the compilation failure.

Yours,
Marton

vormar wrote: Do you have any idea what happens?

The problem is solved reducing the optimization option. -O3 seems to be too aggressive for some parts of the code. I have taken note of changing the optimization to -O2 for modules, for example. In this case, indeed, it is mod_com.F and mod_IO.F that up messed up by the xlf optimization.

So, as temporary work-around, you can either pass the correct options to the configure or change the config/setup (after running the configure) according to

f90flags = -q64 -O2 -qnoescape -qnostrict -qarch=ppc970 -qtune=ppc970
pf90flags = -q64 -O2 -qnoescape -qnostrict -qarch=ppc970 -qtune=ppc970
f77flags = -q64 -O2 -qnoescape -qnostrict -qarch=ppc970 -qtune=ppc970