linking to MKL

[cantele]

Dear all,

I would like to compile yambo linking with BLAS/LAPACK/BLACS/SCALAPACK included within the MKL/Intel.

So, I just add the following line:
LDFLAGS="-i-dynamic $MKL_PATH/libmkl_scalapack_lp64.a $MKL_PATH/libmkl_solver_lp64_sequential.a -Wl,--start-group $MKL_PATH/libmkl_intel_lp64.a $MKL_PATH/libmkl_sequential.a $MKL_PATH/libmkl_core.a $MKL_PATH/libmkl_blacs_openmpi_lp64.a -Wl,--end-group -lpthread"
as an option of the configure script (the link should be right, being "automatically" generated using an Intel script).

Now, the problem is that the configure does not find the libraries. The reason, I guess, is that it does not try to compile a file where a call to some of the above libraries is done,
whereas, taking BLACS as an example, searches for files like:
cinit_lib=`find $with_blacs -name '*blacsCinit*.a'`
blacs_lib=`find $with_blacs -name '*blacs.a'`
That means that ANY "alternative" library which is not built using the standard packages, will never be detected if other library file names are used.

Any hint on how to resolve the issue?

The final configure report looks like:
#
# [VER] 3.2.1 r.448
#
# [SYS] linux@x86_64
# [SRC] /home/nm_settings/install_work_dir/yambo/yambo-3.2.1-r.448
# [BIN] /home/nm_settings/software/CODES/yambo/yambo-3.2.1-r.448/bin_QE4.0/bin
# [FFT] FFTW Fast Fourier transform
#
# [ ] Double precision
# [X] Redundant compilation
# [X] MPI
# [ ] PW (3.2) support
# [ ] ETSF I/O support
# [ ] SCALAPACK
# [X ] NETCDF/Large Files
# [XX ] Built-in BLAS/LAPACK/LOCAL
#
# [ CPP ] icc -E -ansi
# [ C ] icc -g -O2 -D_C_US -D_FORTRAN_US
# [MPICC] mpicc -g -O2 -D_C_US -D_FORTRAN_US
# [ F90 ] ifort -assume bscc -O3 -ip -xW
# [MPIF ] mpif90 -assume bscc -O3 -ip -xW
# [ F77 ] ifort -assume bscc -O3 -ip -xW
# [Cmain] -nofor_main
# [NoOpt] -assume bscc -O0 -xW
#
# [ MAKE ] make
# [EDITOR] vim
#



Thanks,

Giovanni

[myrta gruning]

Dear Giovanni

I think that what it should be used are the options --with-blacs, --with-lapack etc. (doing ./configure --help in the yambo dir gives all the options)

For blacs and scalapack, looking at the configure, you are right it would not recognize the naming of the MKL. I think that the only way, and I am not sure it will work(see below), is to hack the configure/autoconf modules.
For the blas and lapack, if you do not specify the --with-blacs, --with-lapack it will always use the local copy of it.

I have tried to link to mkl on the local cluster, and I did not succeed. In particular for the blas the problem was caxpy_ was not found (that is the test performed by the ). Since it is in the mkl blas library, it may be some inconsistency with the compilation (I did not try to understand it further). I do not know if this is may be as well be your case.
(I have also tried with newer version (wrt the yambo ones) of the autoconf module for blas to see whether it would help. It did not)

To be sure of what is going on with blas/lapack, you have to look at the config.log, e.g. if you get undefined references to caxpy, or some other file

Cheers
m

[andrea marini]

Please Giovanni, attach the config.log. I do not have direct access to a machine where mkl is installed so I cannot help straight away. If you trace back the problem to a precise call in the configure I can easily help you in hacking the configure.ac.

[cantele]

Please Giovanni, attach the config.log. I do not have direct access to a machine where mkl is installed so I cannot help straight away. If you trace back the problem to a precise call in the configure I can easily help you in hacking the configure.ac.

Dear Andrea,
attached you find the config.log together with the shell script I use to appropriately set the configure.
In the case of blacs, the problem is here:
cinit_lib=`find $with_blacs -name '*blacsCinit*.a'`
blacs_lib=`find $with_blacs -name '*blacs.a'`
That means that the configure scripts searches for files named just as the ones coming with the standard blacs. Therefore, it
prevents from using blacs coming, for example, with the intel compiler. The same applies to the lapack / blas / scalapack.

In some cases the library check is done, instead, by building a simple program like
program main
call dgemm
end program main
and then trying to compile that program using the LIBS / LDFLAGS specified as an option of configure or automatically detected by it.
This allows to use ANY linking flag, provided it correctly points to the needed libraries.


Thanks,

Giovanni

[myrta gruning]

Ciao Giovanni

I do not see any attachment

Regards,

Myrta

[cantele]

Sorry! I were sure that the files had been uploaded!

[Conor Hogan]

Just a quick comment: you might be able to modify the libraries by hand after a first configure run by editing the config/setup file, at least to check that the interface with the libraries works. I havent tried it myself yet though.

[cantele]

Even if after a long time, I would like to point out that I solved the problem just overwriting the BLACS_LIBS and SCALAPACK_LIBS directly in configure after the configure line that set them up. Not to make confusion, I've both free blacs/scalapack compiled and Intel MKL, so I instructed configure with --with-blacs and --with-scalapack options to look for the free ones, and then overwrote the configure results.

In the current version of configure, the specification of blacs and scalapack occurs via
--with-blacs=<path> Path of the BLACS library directory
--with-scalapack=<path> Path of the SCALAPACK library directory
so I cannot specify alternative names of the libraries (such options tell configure to look into a specified path the standard library names that come from the compilation of free sources, namely, *scalapack.a and *blacsCinit*.a / *blacs.a)

Instead, the specification of blas and lapack has more degrees of freedom because using
--with-blas=<lib> Use BLAS library <lib>
--with-lapack=<lib> Use LAPACK library <lib>
one can specify directly the library (including its name) rather then the path.

It would be nice if, for blacs and scalapack, one could use either the --with-blacs and --with-scalapack options or an alternative options allowing, as for blas and lapack, the direct specification of the library.

[andrea marini]

Got the message. I will try to change the SCALAPACK/BLACS flags in the next revision.

[andrea marini]

Giovanni, I am trying to modify the SCALAPACK flags but, at difference with the BLAS, there are three libraries to specify as in addition to the scalapack.a and blacs.a one need to give a blacsCinit library. Can you give me an example of the names of the three files you used together with the modified setup file ?

THX