Problems with DALTON installation...

Problems with Dalton installation? Find answers or ask for help here
Post Reply
olivier_blacque
Posts: 9
Joined: 24 May 2016, 09:15
First name(s): Olivier
Last name(s): Blacque
Affiliation: University Zurich
Country: Switzerland

Problems with DALTON installation...

Post by olivier_blacque » 24 May 2016, 09:44

Dear all,
I am facing some problems with the DALTON2016 installation.
Below are some outputs. Is there anybody to give me some advices?
Thanks
OB
-----------------------
./setup --fc=pgf90 --cc=gcc --cxx=g++ --blas=auto --lapack=auto
FC=pgf90 CC=gcc CXX=g++ cmake -DENABLE_MPI=OFF -DENABLE_SGI_MPT=OFF -DENABLE_OMP=OFF -DENABLE_64BIT_INTEGERS=OFF -DENABLE_GPU=OFF -DENABLE_CUBLAS=OFF -DENABLE_REAL_SP=OFF -DENABLE_STATIC_LINKING=OFF -DENABLE_SCALAPACK=OFF -DCMAKE_BUILD_TYPE=release /home/oblacque/DALTON-Source

-- System : Linux
-- Processor type : x86_64
-- Fortran compiler flags: -DVAR_PGF90 -mcmodel=medium -pgcpplibs -O3 -Mipa=fast
-- C compiler flags : -std=c99 -DRESTRICT=restrict -DFUNDERSCORE=1 -DHAVE_NO_LSEEK64 -ffloat-store -w -m64 -O3 -ffast-math -funroll-loops -ftree-vectorize -Wno-unused
-- Libraries : /usr/lib64/atlas/libf77blas.a;/usr/lib64/atlas/libcblas.a;/usr/lib64/atlas/libatlas.a;/usr/lib64/atlas/libatlas.a;/usr/lib64/atlas/liblapack.a
-- Definitions : SYS_LINUX;SYS_UNIX;VAR_PGI;COMPILER_UNDERSTANDS_FORTRAN_2003;HAVE_ATLAS_BLAS;HAVE_OPENBLAS_LAPACK;BUILD_GEN1INT;BUILD_PELIB;BUILD_QFITLIB;VAR_MFDS;_FILE_OFFSET_BITS=64;IMPLICIT_NONE;BINARY_INFO_AVAILABLE;INSTALL_BASDIR="/home/oblacque/DALTON-Source/build/basis";INSTALL_WRKMEM=64000000;INSTALL_MMWORK=1
CMake Warning:
Manually-specified variables were not used by the project:

ENABLE_CUBLAS


-- The Fortran compiler identification is PGI
-- The C compiler identification is GNU 4.8.1
-- The CXX compiler identification is GNU 4.8.1
-- Check for working Fortran compiler: /usr/pgi/linux86-64/14.10/bin/pgf90
-- Check for working Fortran compiler: /usr/pgi/linux86-64/14.10/bin/pgf90 -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/pgi/linux86-64/14.10/bin/pgf90 supports Fortran 90
-- Checking whether /usr/pgi/linux86-64/14.10/bin/pgf90 supports Fortran 90 -- yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Performing Test COMPILER_UNDERSTANDS_FORTRAN03
-- Performing Test COMPILER_UNDERSTANDS_FORTRAN03 - Success
-- Performing Test PTR_RESHAPE_WORKS
-- Performing Test PTR_RESHAPE_WORKS - Failed
-- Math lib search order is MKL;ESSL;OPENBLAS;ATLAS;ACML;SYSTEM_NATIVE
-- You can select a specific type by defining for instance -D BLAS_TYPE=ATLAS or -D LAPACK_TYPE=ACML
-- or by redefining MATH_LIB_SEARCH_ORDER
-- Found BLAS: ATLAS (/usr/lib64/atlas/libf77blas.a;/usr/lib64/atlas/libcblas.a;/usr/lib64/atlas/libatlas.a)
-- Found LAPACK: OPENBLAS (/usr/lib64/atlas/libatlas.a;/usr/lib64/atlas/liblapack.a)
-- Configuring done
-- Generating done
-- Build files have been written to: /DALTON-Source/build

configure step is done
now you need to compile the sources:
$ cd build
$ make

cd build
make

Scanning dependencies of target check_external_timestamp_qfitlib
[ 0%] Built target check_external_timestamp_qfitlib
Scanning dependencies of target check_external_timestamp_gen1int
[ 0%] Built target check_external_timestamp_gen1int
Scanning dependencies of target gen1int
[ 1%] Creating directories for 'gen1int'
[ 1%] Performing download step for 'gen1int'

[ 1%] No patch step for 'gen1int'
[ 1%] No update step for 'gen1int'
[ 1%] Performing configure step for 'gen1int'
-- The C compiler identification is GNU 4.8.1
-- The Fortran compiler identification is PGI
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working Fortran compiler: /usr/pgi/linux86-64/14.10/bin/pgf90
-- Check for working Fortran compiler: /usr/pgi/linux86-64/14.10/bin/pgf90 -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/pgi/linux86-64/14.10/bin/pgf90 supports Fortran 90
-- Checking whether /usr/pgi/linux86-64/14.10/bin/pgf90 supports Fortran 90 -- yes
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:

ENABLE_64BIT_INTEGERS


-- Build files have been written to: /home/oblacque/DALTON-Source/build/external/gen1int-build
[ 1%] Performing build step for 'gen1int'
Scanning dependencies of target gen1int
[ 0%] Building Fortran object CMakeFiles/gen1int.dir/src/xkind.F90.o
[ 1%] Building Fortran object CMakeFiles/gen1int.dir/src/london_ao.F90.o
[ 2%] Building Fortran object CMakeFiles/gen1int.dir/src/gen1int_geom.F90.o
[ 3%] Building Fortran object CMakeFiles/gen1int.dir/src/gen1int_carmom.F90.o
[ 4%] Building Fortran object CMakeFiles/gen1int.dir/src/gen1int_nucpot.F90.o
[ 5%] Building Fortran object CMakeFiles/gen1int.dir/src/gen1int_gaupot.F90.o
[ 5%] Building Fortran object CMakeFiles/gen1int.dir/src/gen1int_onehamil.F90.o
[ 6%] Building Fortran object CMakeFiles/gen1int.dir/src/gen1int.F90.o
[ 7%] Building Fortran object CMakeFiles/gen1int.dir/tools/str_decode.F90.o
[ 8%] Building Fortran object CMakeFiles/gen1int.dir/src/dump_info.F90.o
[ 9%] Building Fortran object CMakeFiles/gen1int.dir/src/error_stop.F90.o
[ 10%] Building Fortran object CMakeFiles/gen1int.dir/src/xtimer.F90.o
[ 11%] Building Fortran object CMakeFiles/gen1int.dir/src/tools/norm_contr_cgto.F90.o
[ 12%] Building Fortran object CMakeFiles/gen1int.dir/src/tools/norm_contr_sgto.F90.o
[ 13%] Building Fortran object CMakeFiles/gen1int.dir/src/tools/reorder_ints.F90.o
[ 14%] Building Fortran object CMakeFiles/gen1int.dir/src/tools/trace_ints.F90.o
[ 14%] Building Fortran object CMakeFiles/gen1int.dir/src/tools/get_address_list.F90.o
[ 15%] Building Fortran object CMakeFiles/gen1int.dir/src/basic/binom_coeff.F90.o
[ 16%] Building Fortran object CMakeFiles/gen1int.dir/src/basic/const_contr_ints.F90.o
[ 17%] Building Fortran object CMakeFiles/gen1int.dir/src/basic/hgto_to_cgto.F90.o
[ 18%] Building Fortran object CMakeFiles/gen1int.dir/src/basic/hgto_to_sgto.F90.o
[ 19%] Building Fortran object CMakeFiles/gen1int.dir/src/basic/next_permutation.F90.o
[ 20%] Building Fortran object CMakeFiles/gen1int.dir/src/basic/shell_scatter.F90.o
[ 21%] Building Fortran object CMakeFiles/gen1int.dir/src/basic/sort_cents.F90.o
[ 21%] Building Fortran object CMakeFiles/gen1int.dir/src/auxfun/aux_boys_vec.F90.o
[ 22%] Building Fortran object CMakeFiles/gen1int.dir/src/geom/geom_total.F90.o
[ 23%] Building Fortran object CMakeFiles/gen1int.dir/src/geom/geom_part_zero.F90.o
[ 24%] Building Fortran object CMakeFiles/gen1int.dir/src/geom/geom_part_one.F90.o
[ 25%] Building Fortran object CMakeFiles/gen1int.dir/src/mag/hgto_to_lcgto.F90.o
[ 26%] Building Fortran object CMakeFiles/gen1int.dir/src/mag/london_mom_hgto.F90.o
[ 27%] Building Fortran object CMakeFiles/gen1int.dir/src/carmom/carmom_deriv.F90.o
[ 28%] Building Fortran object CMakeFiles/gen1int.dir/src/carmom/carmom_hbra.F90.o
[ 28%] Building Fortran object CMakeFiles/gen1int.dir/src/carmom/carmom_hrr_ket.F90.o
[ 29%] Building Fortran object CMakeFiles/gen1int.dir/src/carmom/carmom_moment.F90.o
[ 30%] Building Fortran object CMakeFiles/gen1int.dir/src/carmom/prim_hgto_carmom.F90.o
[ 31%] Building Fortran object CMakeFiles/gen1int.dir/src/carmom/contr_cgto_carmom.F90.o
[ 32%] Building Fortran object CMakeFiles/gen1int.dir/src/carmom/contr_sgto_carmom.F90.o
[ 33%] Building Fortran object CMakeFiles/gen1int.dir/src/carmom/contr_csgto_carmom.F90.o
[ 34%] Building Fortran object CMakeFiles/gen1int.dir/src/delta/delta_geom.F90.o
[ 35%] Building Fortran object CMakeFiles/gen1int.dir/src/delta/delta_hket.F90.o
[ 35%] Building Fortran object CMakeFiles/gen1int.dir/src/delta/delta_moment.F90.o
[ 36%] Building Fortran object CMakeFiles/gen1int.dir/src/delta/prim_hgto_delta.F90.o
[ 37%] Building Fortran object CMakeFiles/gen1int.dir/src/delta/contr_cgto_delta.F90.o
[ 38%] Building Fortran object CMakeFiles/gen1int.dir/src/delta/contr_sgto_delta.F90.o
[ 39%] Building Fortran object CMakeFiles/gen1int.dir/src/nucpot/nucpot_geom.F90.o
[ 40%] Building Fortran object CMakeFiles/gen1int.dir/src/nucpot/nucpot_hket.F90.o
[ 41%] Building Fortran object CMakeFiles/gen1int.dir/src/nucpot/nucpot_hbra.F90.o
[ 42%] Building Fortran object CMakeFiles/gen1int.dir/src/nucpot/prim_hgto_nucpot.F90.o
[ 42%] Building Fortran object CMakeFiles/gen1int.dir/src/nucpot/contr_cgto_nucpot.F90.o
[ 43%] Building Fortran object CMakeFiles/gen1int.dir/src/nucpot/contr_sgto_nucpot.F90.o
[ 44%] Building Fortran object CMakeFiles/gen1int.dir/src/gaupot/gaupot_geom.F90.o
[ 45%] Building Fortran object CMakeFiles/gen1int.dir/src/gaupot/prim_hgto_gaupot.F90.o
[ 46%] Building Fortran object CMakeFiles/gen1int.dir/src/gaupot/contr_cgto_gaupot.F90.o
[ 47%] Building Fortran object CMakeFiles/gen1int.dir/src/gaupot/contr_sgto_gaupot.F90.o
[ 48%] Building Fortran object CMakeFiles/gen1int.dir/src/odist/prim_hgto_odist.F90.o
[ 49%] Building Fortran object CMakeFiles/gen1int.dir/src/odist/contr_cgto_odist.F90.o
[ 49%] Building Fortran object CMakeFiles/gen1int.dir/src/odist/contr_sgto_odist.F90.o
[ 50%] Building Fortran object CMakeFiles/gen1int.dir/src/value/prim_hgto_value.F90.o
[ 51%] Building Fortran object CMakeFiles/gen1int.dir/src/value/const_contr_gto.F90.o
[ 52%] Building Fortran object CMakeFiles/gen1int.dir/src/value/contr_cgto_value.F90.o
[ 53%] Building Fortran object CMakeFiles/gen1int.dir/src/value/contr_sgto_value.F90.o
Linking Fortran static library libgen1int.a
[ 53%] Built target gen1int
Scanning dependencies of target test_gen1int
[ 54%] Building Fortran object CMakeFiles/test_gen1int.dir/tools/html_log.F90.o
[ 54%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/recur/recur_hgto.F90.o
[ 55%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/recur/recur_mag.F90.o
[ 56%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/recur/recur_carmom.F90.o
[ 57%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/recur/recur_delta.F90.o
[ 58%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/recur/recur_nucpot.F90.o
[ 59%] Building Fortran object CMakeFiles/test_gen1int.dir/tools/int_to_str.F90.o
[ 60%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/check_difference.F90.o
[ 61%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/xyz_function.F90.o
[ 62%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/tools/test_norm_contr_gto.F90.o
[ 63%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/tools/test_reorder_ints.F90.o
[ 64%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/tools/test_trace_ints.F90.o
[ 64%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/basic/test_binom_coeff.F90.o
[ 65%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/basic/test_const_contr_ints.F90.o
[ 66%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/basic/test_hgto_to_cgto.F90.o
[ 67%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/basic/test_next_permutation.F90.o
[ 68%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/basic/test_shell_scatter.F90.o
[ 69%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/basic/test_sort_cents.F90.o
[ 70%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/auxfun/test_aux_boys_vec.F90.o
[ 71%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/geom/test_geom_total.F90.o
[ 71%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/geom/test_geom_part_zero.F90.o
[ 72%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/geom/test_geom_part_one.F90.o
[ 73%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/mag/test_hgto_to_lcgto.F90.o
[ 74%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/mag/test_london_mom_hgto.F90.o
[ 75%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/carmom/test_carmom_deriv.F90.o
[ 76%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/carmom/test_carmom_hbra.F90.o
[ 77%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/carmom/test_carmom_hrr_ket.F90.o
[ 78%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/carmom/test_carmom_moment.F90.o
[ 78%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/carmom/test_prim_hgto_carmom.F90.o
[ 79%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/carmom/test_contr_cgto_carmom.F90.o
[ 80%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/carmom/test_contr_sgto_carmom.F90.o
[ 81%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/carmom/test_contr_csgto_carmom.F90.o
[ 82%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/carmom/test_contr_sgto_kinene.F90.o
[ 83%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/carmom/test_contr_csgto_kinene.F90.o
[ 84%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/delta/test_delta_geom.F90.o
[ 85%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/delta/test_delta_hket.F90.o
[ 85%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/delta/test_delta_moment.F90.o
[ 86%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/delta/test_prim_hgto_delta.F90.o
[ 87%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/delta/test_contr_cgto_delta.F90.o
[ 88%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/delta/test_contr_sgto_delta.F90.o
[ 89%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/nucpot/test_nucpot_geom.F90.o
[ 90%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/nucpot/test_nucpot_hket.F90.o
[ 91%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/nucpot/test_nucpot_hbra.F90.o
[ 92%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/nucpot/test_prim_hgto_nucpot.F90.o
[ 92%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/nucpot/test_contr_cgto_nucpot.F90.o
[ 93%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/nucpot/test_contr_sgto_nucpot.F90.o
[ 94%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/gaupot/test_gaupot_geom.F90.o
[ 95%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/odist/test_prim_hgto_odist.F90.o
[ 96%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/value/test_prim_hgto_value.F90.o
[ 97%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/test_gen1int.F90.o
[ 98%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/f90mod/test_f90mod_sgto_kinene.F90.o
[ 99%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/f90mod/test_f90mod_sgto_carmom.F90.o
[100%] Building Fortran object CMakeFiles/test_gen1int.dir/test_f90/f90mod/test_f90mod_sgto_sphmom.F90.o
Linking Fortran executable test_gen1int
pgf90-Error-Unknown switch: -rdynamic
make[5]: *** [test_gen1int] Error 1
make[4]: *** [CMakeFiles/test_gen1int.dir/all] Error 2
make[3]: *** [all] Error 2
make[2]: *** [external/gen1int-stamp/gen1int-build] Error 2
make[1]: *** [gen1int/CMakeFiles/gen1int.dir/all] Error 2
make: *** [all] Error 2

arnfinn
Posts: 232
Joined: 28 Aug 2013, 08:02
First name(s): Arnfinn
Middle name(s): Hykkerud
Last name(s): Steindal
Location: UiT The Arctic University of Norway
Contact:

Re: Problems with DALTON installation...

Post by arnfinn » 24 May 2016, 09:57

Unfortunately, we have not tested (AFAIK) if Dalton 2016 can be compiled with pgi. I think it was possible with some earlier versions, and might be (and should be) possible again in the future, but at the moment I do not think it will work. Can you try with gfortran instead?

taylor
Posts: 524
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Tianjin University
Country: China

Re: Problems with DALTON installation...

Post by taylor » 24 May 2016, 10:14

Two further points (I agree with Arnfinn that the primary issue may very well be with Portland Group compilers and I doubt they are currently supported).

First, there is a line in your posting that implies 64-bit integers are being enabled. This, as is documented in the manual, is not generally a good idea. The only reasons to enable 64-bit integers are if you wish to address more than 16GB of memory per process (Fortran addresses memory in words, at least the way things are implemented in Dalton, and the largest memory that Dalton [LSDalton is quite different and what I say here applies only to Dalton] can address with 32-bit ints is 2"gigawords" which is 16GB), and/or if you want to run Cholesky-decomposition coupled-cluster calculations. Otherwise, given that there are various issues with 64-bit ints you should stay with the default of 32-bits. Note that this is completely independent of your hardware or operating system. The fact that the chipset is x86_64, and/or the operating system is 64-bit Linux has nothing whatever to do with the use of 32-bit or 64-bit integers within the program.

Second, could you please upload files, and not post them inline! In various browsers or Email software inline postings are well-nigh impossible to read!

Best regards
Pete

olivier_blacque
Posts: 9
Joined: 24 May 2016, 09:15
First name(s): Olivier
Last name(s): Blacque
Affiliation: University Zurich
Country: Switzerland

Re: Problems with DALTON installation...

Post by olivier_blacque » 24 May 2016, 10:21

Many thanks Arnfinn and Taylor, I am actually combining your advices for a new installation process.
I will come back to you soon for a feedback!
Best
Olivier

gaobin
Posts: 95
Joined: 27 Aug 2013, 17:56
First name(s): Bin
Last name(s): Gao
Affiliation: CTCC
Country: Norway

Re: Problems with DALTON installation...

Post by gaobin » 24 May 2016, 13:43

Hi Olivier,

I am the main author of Gen1Int library and its implementation in Dalton. I agree with what Arfinn and Pete suggested, and would like to mention more:

First, by searching "pgf90-Error-Unknown switch rdynamic", I guess your problem is that "pgf90 does not know the -rdynamic flag" (for instance, see https://cmake.org/pipermail/cmake/2009- ... 33439.html). But I do not understand why your installation could have such a flag, because I have tried to search if any CMake file of Dalton has such a setting. By looking through such CMake files: CMakeLists.txt, and those in the cmake directory and external/gen1int/CMakeLists.txt and those in the external/gen1int/cmake directory, I did not find such a setting.

Therefore, if you will still have such a problem, I would suggest that you upload files CMakeCache.txt in your build directory and CMakeCache.txt in external/gen1int-build of your build directory.

Second, I have never tried to build codes using compilers from different vendors, because I am not entirely sure if these compilers are compatible. Therefore, if possible, I would suggest that you use compilers from the same vendor.

Best regards
Gao

olivier_blacque
Posts: 9
Joined: 24 May 2016, 09:15
First name(s): Olivier
Last name(s): Blacque
Affiliation: University Zurich
Country: Switzerland

Re: Problems with DALTON installation...

Post by olivier_blacque » 24 May 2016, 13:54

Thank you Gao for your message. I will try your suggestions.
Using gfortran/gcc/g++ the installation ran really longer but ended again with some error messages.
I uploaded the complete output from the installation...
Install_Dalton2016_error2.txt
(86.29 KiB) Downloaded 339 times

taylor
Posts: 524
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Tianjin University
Country: China

Re: Problems with DALTON installation...

Post by taylor » 24 May 2016, 13:59

This is another helpful posting that should have you making progress to a successful build. With respect to mixing compilers (which I never do, so I am just quoting what the vendors say here...) Intel Fortran and gfortran (and presumably the respective C compilers) are stated to be completely interoperable. You should be able to compile Dalton with (say) gfortran and link against the Intel MKL library and everything should be fine.

This holds only while you are building serial --- that is, not MPI-parallel --- versions of the code! Unfortunately, there is a total incompatibility between the compiled binary format of Fortran module files between Intel and gfortran. They are absolutely not able to co-exist. So, if you want to build an MPI-parallel version of Dalton, you will be much more constrained. If you are using gfortran, then you will have to link against MPI libraries (and indeed use MPI compilers) that were compiled with the GNU compiler suite. In particular, Intel's MPI libraries will not do. Conversely, if you are using Intel's compilers but are linking against OpenMPI compiled with the GNU compiler stack you will have a problem: the OpenMPI libraries must also be built with the Intel compilers.

The basic problem is that while the vendors have agreed on a standard for compiled binary code, they have (radically) different standards for dealing with Fortran modules, especially where these contain only declaration statements. They are absolutely not interoperable. So the safe path for an MPI build is to stick with one software stack: entirely Intel, or entirely GNU/OpenMPI.

Best regards
Pete

taylor
Posts: 524
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Tianjin University
Country: China

Re: Problems with DALTON installation...

Post by taylor » 24 May 2016, 14:10

The immediate reaction I have is that it is clear there are problems with linking against your ATLAS library. The unsatisfied externals etc. that the build complains about all seem to be ATLAS-related. So, where did this ATLAS library come from? Was it already installed on your system (and how, and by whom: you yourself)? Did you or someone else build it? If so, using what compiler/library stack was used?

The fundamental difficulty here (and I don't for a moment imply this is your fault!) is that the more one mixes compilers, libraries, builds, systems, etc., the more places there are for incompatibilities to arise and thus problems to occur. Without more details of your system setup it is difficult to say more. But one thing to be aware of is that a 32-bit integer Dalton build is likely to be hopelessly incompatible with a 64-bit integer ATLAS build. (It is not straightforward to produce a completely 64-bit integer ATLAS build anyway, and for if/when you start trying to use OpenMPI good luck with anything needing 64-bit integers...) So one essential requirement is that all aspects of your software stack: compilers and libraries, are consistent. If your system's ATLAS was built with 64-bit integers you will have to try to build a 64-bit integer Dalton, or else rebuild the ATLAS libraries using 32-bit ints.

Best regards
Pete

gaobin
Posts: 95
Joined: 27 Aug 2013, 17:56
First name(s): Bin
Last name(s): Gao
Affiliation: CTCC
Country: Norway

Re: Problems with DALTON installation...

Post by gaobin » 24 May 2016, 14:18

Hi Olivier,

You are welcome, and from the log of your build, I can see the previous problem (pgf90-Error-Unknown switch -rdynamic) has been solved. The new error is due to the link of BLAS and LAPACK libraries. This could have several reasons: the BLAS and LAPACK libraries are not compatible with the compilers you used, or the order of these libraries matters.

Therefore, to solve your problem, I suggest that you try "make VERBOSE=1 >& Install_Dalton2016_error2.txt" and upload the file Install_Dalton2016_error2.txt. The "VERBOSE=1" will produce more information that we can try to investigate the source of your error.

Best regards
Gao

gaobin
Posts: 95
Joined: 27 Aug 2013, 17:56
First name(s): Bin
Last name(s): Gao
Affiliation: CTCC
Country: Norway

Re: Problems with DALTON installation...

Post by gaobin » 24 May 2016, 14:19

Just saw Pete's post---I totally agree. Therefore, to Olivier, please make sure your ATLAS library is compatible with your compilers.

olivier_blacque
Posts: 9
Joined: 24 May 2016, 09:15
First name(s): Olivier
Last name(s): Blacque
Affiliation: University Zurich
Country: Switzerland

Re: Problems with DALTON installation...

Post by olivier_blacque » 24 May 2016, 14:23

Thank you Pete for your very precise answers. Unfortunately, I can not be as much as you are.
I am only using Gaussian09 on that machine, under OpenSuse. Except PGI that I needed to compile the program, all other libraries came along with the installation of OpenSuse...
I am actually trying to understand all your points, and installing OpenMpi that I could get on the web...

olivier_blacque
Posts: 9
Joined: 24 May 2016, 09:15
First name(s): Olivier
Last name(s): Blacque
Affiliation: University Zurich
Country: Switzerland

Re: Problems with DALTON installation...

Post by olivier_blacque » 24 May 2016, 14:23

Ok Gao, I will check that point in priority. Thanks again!

olivier_blacque
Posts: 9
Joined: 24 May 2016, 09:15
First name(s): Olivier
Last name(s): Blacque
Affiliation: University Zurich
Country: Switzerland

Re: Problems with DALTON installation...

Post by olivier_blacque » 24 May 2016, 14:44

Here is the response of "make VERBOSE=1 >& Install_Dalton2016_error2.txt"...
Install_Dalton2016_error2.txt
(86.29 KiB) Downloaded 308 times

gaobin
Posts: 95
Joined: 27 Aug 2013, 17:56
First name(s): Bin
Last name(s): Gao
Affiliation: CTCC
Country: Norway

Re: Problems with DALTON installation...

Post by gaobin » 24 May 2016, 14:53

Hi Olivier,

What you uploaded is not from "make VERBOSE=1 >& Install_Dalton2016_error2.txt", it is still a log file of "make". Please check these two lines in the file:

~/DALTON-Source> cd build/
~/DALTON-Source/build> make

You should change the second line to "make VERBOSE=1" and upload what you will get.

Best regards
Gao

olivier_blacque
Posts: 9
Joined: 24 May 2016, 09:15
First name(s): Olivier
Last name(s): Blacque
Affiliation: University Zurich
Country: Switzerland

Re: Problems with DALTON installation...

Post by olivier_blacque » 24 May 2016, 16:27

Here it is.
Install_Dalton2016_error2.txt
(938.96 KiB) Downloaded 303 times
This time I used all compilers from PGI...

taylor
Posts: 524
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Tianjin University
Country: China

Re: Problems with DALTON installation...

Post by taylor » 24 May 2016, 17:47

Lines from (the very end of) your output like

Code: Select all

xerbla.f:(.text+0x4c): undefined reference to `_gfortran_st_write'
strongly suggest to me that you have a software incompatibility with how the ATLAS library was built on your machine and with your own build and final linking. On the one hand your link step is failing to find routines (like "dgeev") that should certainly be in a "proper" ATLAS build, and at the same time the ATLAS routines that it does find are flagging errors that should be resolved within the gfortran Fortran library.

I am not certain what to suggest here. I myself, as a notorious hacker/computer jock (I can point to my posting on getting Dalton built and running on a Raspberry Pi, and I won't even get started about how many operating systems we run at home in virtual machines...) would probably download ATLAS and build it myself from scratch, and if you want to do this --- it's actually not that difficult on typical x86_64 hardware --- I'd be happy to make suggestions, although we should probably then take it offline. But if you are not comfortable with this, the best suggestion to confirm you can build the code at all is to disable external libraries like ATLAS. Dalton comes complete with Fortran versions of BLAS/LAPACK: the performance of such Fortran, which is bog-standard and specifically excludes any optimizations and unrolling and fancy stuff, will be woeful, but you can at least verify that you know how to build the code, and that having built it, it works. After that you can start to try to use your own, or your system's, optimized libraries.

I am sorry that this is on the one hand a not-very-positive message (suggesting using the non-system libraries and getting crap performance) and on the other hand may seem like a bit of typical managerial bullshit ra-ra! to encourage you to keep at it. It is not clear to me what your problems are, but I am convinced with modest effort (on both your part and the Dalton forum contributors') this can be made to work.

Best regards
Pete

gaobin
Posts: 95
Joined: 27 Aug 2013, 17:56
First name(s): Bin
Last name(s): Gao
Affiliation: CTCC
Country: Norway

Re: Problems with DALTON installation...

Post by gaobin » 24 May 2016, 19:51

Hi Olivier,

I agree with Pete suggested, and also speculate your problem is the compatibility between compilers and BLAS/LAPACK libraries. You could either rebuild Dalton using its internal BLAS/LAPACK libraries compiled with the same compilers, or try to figure out the vendor of your BLAS/LAPACK libraries.

For the latter, I think you can try to compile the attached simple LAPACK example from http://www.mitchr.me/SS/exampleCode/blas.html by:

Code: Select all

pgf90 symEig.F /usr/lib64/atlas/libf77blas.a /usr/lib64/atlas/libcblas.a /usr/lib64/atlas/libatlas.a /usr/lib64/atlas/libatlas.a /usr/lib64/atlas/liblapack.a
or

Code: Select all

gfortran symEig.F /usr/lib64/atlas/libf77blas.a /usr/lib64/atlas/libcblas.a /usr/lib64/atlas/libatlas.a /usr/lib64/atlas/libatlas.a /usr/lib64/atlas/liblapack.a
and from the succeeded one, you might know the vendor of your BLAS/LAPACK libraries. Then you need to rebuild Dalton using that vendor.

Code: Select all

./setup --fc=fortran-compiler-from-that-vendor --cc=c-compiler-from-that-vendor --cxx=cxx-compiler-from-that-vendor --blas=auto --lapack=auto
cd build
make VERBOSE=1
and hope this will solve your problem.
Attachments
symEig.F
simple LAPACK example
(4.38 KiB) Downloaded 254 times

olivier_blacque
Posts: 9
Joined: 24 May 2016, 09:15
First name(s): Olivier
Last name(s): Blacque
Affiliation: University Zurich
Country: Switzerland

Re: Problems with DALTON installation...

Post by olivier_blacque » 24 May 2016, 20:29

Thank you Pete and Gao for your long messages!! I am far to be a specialist but I should be able to try some of your ideas tomorrow.
I will keep you inform :-)
Best regards
Olivier

olivier_blacque
Posts: 9
Joined: 24 May 2016, 09:15
First name(s): Olivier
Last name(s): Blacque
Affiliation: University Zurich
Country: Switzerland

Re: Problems with DALTON installation...

Post by olivier_blacque » 27 May 2016, 15:11

Dear all,
I could complete the installation of DALTON2016. Thank you all for your help.
First I installed successfully with the internal BLAS/LAPACK libraries. Then I restarted something which did not work, still the same compatibilty problem with ATLAS. So I just desinstalled the version of ATLAS included in OpenSuse, standard libraries remained and were enough to complete the installation. Funny, isnt it? Then a final attempt with mpi compilers, again successful.
Best wishes
Olivier

taylor
Posts: 524
Joined: 15 Oct 2013, 05:37
First name(s): Peter
Middle name(s): Robert
Last name(s): Taylor
Affiliation: Tianjin University
Country: China

Re: Problems with DALTON installation...

Post by taylor » 27 May 2016, 15:53

This sounds promising, but I am not sure what you mean by "standard libraries"? If you mean libraries that are still there after you have deinstalled some stuff that came with some OpenSUSE update/install, so these are in some sense "system libraries" that were built and installed as optimized libraries for BLAS/LAPACK: great! You should be OK now.

But if by "standard libraries" you mean the freeware Fortran-source versions we distribute with Dalton, you need to be aware that the performance of the program with such libraries is going to vary between not very good, and terrible... We include these to make sure that people can build the code and check their installation, very much as the desperate last chance. If you are not able to access some optimized BLAS/LAPACK on your machine, you need to either get someone (if you have support people --- most institutions these days have eliminated support people to "save costs"...) to build an appropriate (say) ATLAS, or to point you to the Intel MKL library, which is free to academia, or you will have to tackle this (building ATLAS or installing MKL) yourself. You will get some help through the forum for this but it is somewhat off-topic: if you want to try ATLAS yourself send me a PM and we can talk off-thread.

Best regards
Pete

gaobin
Posts: 95
Joined: 27 Aug 2013, 17:56
First name(s): Bin
Last name(s): Gao
Affiliation: CTCC
Country: Norway

Re: Problems with DALTON installation...

Post by gaobin » 27 May 2016, 20:15

Hi Olivier,

I totally agree with Pete. Therefore, if you want good performance of Dalton, you will need to figure out what "standard libraries" mean exactly. Anyway, good luck and enjoy Dalton :-)

Best regards
Gao

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest