unusual blacs names and scalapack support in 6.10.3

option, parallelism,...

Moderators: fgoudreault, mcote

Forum rules
Please have a look at ~abinit/doc/config/build-config.ac in the source package for detailed and up-to-date information about the configuration of Abinit 8 builds.
For a video explanation on how to build Abinit 7.x for Linux, please go to: http://www.youtube.com/watch?v=DppLQ-KQA68.
IMPORTANT: when an answer solves your problem, please check the little green V-like button on its upper-right corner to accept it.
Locked
carlos_rf
Posts: 3
Joined: Thu Jan 26, 2012 9:18 pm

unusual blacs names and scalapack support in 6.10.3

Post by carlos_rf » Thu Jan 26, 2012 10:48 pm

Hi all,

I am trying to install abinit 6.10.3 with scalapack support in several of our clusters, and I think I am having trouble becasue of the way we name our blacs libraries. Instead of the usual "libblacs...." all of ours are names "blacs..." What I have tried is to set the linalg flavor to custom, and the linalg libraries to the relevant mkl libraries and scalapack (MKL 10.0, --with-linalg-incs="-I$MKL_INC" --with-linalg-libs="-L$MKL_LIB -lmkl_lapack -lmkl_intel_lp64 -lmkl -lguide -lpthread -L$SCALAPACK_LIB -lscalapack $SCALAPACK_LIB/blacs_MPI-LINUX-0.a $SCALAPACK_LIB/blacsF77init_MPI-LINUX-0.a " but configure always tells me that there is no BLACS support and that there is no parallel library support.

A usable Makefile is generated, and the MKL libraries are linked correctly when abinit builds, but I also need to include scalapack.

I also tried puting the BLACS info on FC_LDFLAGS but I got the same result. Any ideas? Could I simply modify the generated Makefile to force the use of scalapack?

Thanks in advance,
Carlos

carlos_rf
Posts: 3
Joined: Thu Jan 26, 2012 9:18 pm

Re: unusual blacs names and scalapack support in 6.10.3

Post by carlos_rf » Fri Jan 27, 2012 12:11 am

I think I managed to sort this out and, as usual, it was a user issue! I had to hack a bit the provided configure to get some info on why the blacs libraries where not being accepted/found. In case somebody faces this problem, the solution is simple:

1) Use the C blacs libraries
2) Create local links to the libraries and name them libblacs... so that configure accepts them
3) Done

I still need to complete the build and do the validation for the scalapack part, but I think this was a simple error on my side.

Carlos

User avatar
pouillon
Posts: 651
Joined: Wed Aug 19, 2009 10:08 am
Location: Spain
Contact:

Re: unusual blacs names and scalapack support in 6.10.3

Post by pouillon » Fri Jan 27, 2012 1:03 am

You might also want to look into config.log to know what configure is exactly complaining about. I would be curious to see the error message.
Yann Pouillon
Simune Atomistics
Donostia-San Sebastián, Spain

carlos_rf
Posts: 3
Joined: Thu Jan 26, 2012 9:18 pm

Re: unusual blacs names and scalapack support in 6.10.3

Post by carlos_rf » Fri Jan 27, 2012 4:57 pm

It looks like there were two issues:

1) I think the test was looking for the C blacs_gridinit, and I had only included the F77 version of the library in the command line
2) Second I had the blacs libraries in the wrong order so there where the usual undefined references and both blacs and scalapack failed to link in the test.

I think this is all that there was to it, but let me know if you think otherwise. Let me know if you want me to re-run configure with my old options and send you the exact error messages.

Now everything has built without issues, and I can see that the scalapack info is in abinit ("grep pzheevx ./abinit" reports a match). All the sequential tests and the regular parallel tests (seqpar and gw) have passed, but I do not seem to have any pre-packaged tests for scalapack (the option is described in the documentation, but the input files do not exists in /tests).

I am not a domain scientist in this area, I work in the performance optimization and evaluation group at the Texas Avanced Computing Center http://www.tacc.utexas.edu and I am trying to make sure we have a package our users can work with confidence. Can you suggest a set of input files in the test directory that I can re-purpose for a scalapack test?

Locked