errors installing on SGI Altix 350 Dalton 2013.0

Problems with Dalton installation? Find answers or ask for help here
Post Reply
cozzi
Posts: 4
Joined: 25 Nov 2013, 20:22
First name(s): Marc
Last name(s): Cozzi
Affiliation: Univ. of Notre Dame
Country: United States

errors installing on SGI Altix 350 Dalton 2013.0

Post by cozzi » 25 Nov 2013, 20:39

Trying to build/install 2013.0 release on an SGI Altix 350
Intel ifort/icc v 10.1 mkl /10.0.011 cmake 2.8.12.1 python 2.7.6
./setup --fc=ifort --cc=icc --cxx=icpc --sgi-mpt
cd build
make
runs for about 10-15 min.
See the error message at the end of this post.
I don’t think I can install any newer version of the Intel compilers.

Thanks for any help,
Marc


Linking Fortran static library ../lib/libgen1int_interface.a
[ 1%] Built target gen1int_interface
Scanning dependencies of target pelib
[ 1%] Creating directories for 'pelib'
[ 1%] Performing download step for 'pelib'

[ 1%] No patch step for 'pelib'
[ 1%] No update step for 'pelib'
[ 2%] Performing configure step for 'pelib'
-- The Fortran compiler identification is Intel
-- Check for working Fortran compiler: /opt/intel/fc/10.1.008/bin/ifort
-- Check for working Fortran compiler: /opt/intel/fc/10.1.008/bin/ifort -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /opt/intel/fc/10.1.008/bin/ifort supports Fortran 90
-- Checking whether /opt/intel/fc/10.1.008/bin/ifort supports Fortran 90 -- yes
-- Configuring done
-- Generating done
-- Build files have been written to: /users1/altix/DALTON-2013.0-Source/build/external/pelib-build
[ 2%] Performing build step for 'pelib'
Scanning dependencies of target pelib
[ 16%] Building Fortran object CMakeFiles/pelib.dir/src/pe_precision.F90.o
[ 33%] Building Fortran object CMakeFiles/pelib.dir/src/interfaces/pe_blas_interfaces.F90.o
[ 50%] Building Fortran object CMakeFiles/pelib.dir/src/interfaces/pe_integral_interfaces.F90.o
[ 66%] Building Fortran object CMakeFiles/pelib.dir/src/interfaces/pe_lapack_interfaces.F90.o
[ 83%] Building Fortran object CMakeFiles/pelib.dir/src/pe_variables.F90.o
[100%] Building Fortran object CMakeFiles/pelib.dir/src/polarizable_embedding.F90.o
Linking Fortran static library libpelib.a
[100%] Built target pelib
[ 2%] Performing install step for 'pelib'
[100%] Built target pelib
Install the project...
-- Install configuration: "release"
-- Installing: /users1/altix/DALTON-2013.0-Source/build/external/lib/libpelib.a
[ 2%] Completed 'pelib'
[ 2%] Built target pelib
Scanning dependencies of target generate_binary_info
[ 2%] Built target generate_binary_info
Scanning dependencies of target dalton
[ 2%] Building Fortran object CMakeFiles/dalton.dir/DALTON/input/input_reader.F90.o
[ 2%] Building Fortran object CMakeFiles/dalton.dir/DALTON/lucita/lucita_cfg.F90.o
[ 3%] Building Fortran object CMakeFiles/dalton.dir/DALTON/lucita/dalton_mpi.F90.o
[ 3%] Building Fortran object CMakeFiles/dalton.dir/DALTON/lucita/lucita_mcscf_ci_cfg.F90.o
[ 3%] Building Fortran object CMakeFiles/dalton.dir/DALTON/abacus/parallel_communication_models_mpi.F90.o
[ 3%] Building Fortran object CMakeFiles/dalton.dir/DALTON/gp/one_sided_communication_wrappers.F90.o
[ 3%] Building Fortran object CMakeFiles/dalton.dir/DALTON/abacus/rma_windows.F90.o
fortcom: Error: rma_windows.F90, line 61: This entity cannot be PUBLIC since its derived type is PRIVATE. [RMA_WIN_INFO]
type(rma_win), public :: rma_win_info
---------------------------^
compilation aborted for /users1/altix/DALTON-2013.0-Source/DALTON/abacus/rma_windows.F90 (code 1)
make[3]: *** [CMakeFiles/dalton.dir/DALTON/abacus/rma_windows.F90.o] Error 1
make[2]: *** [CMakeFiles/dalton.dir/DALTON/abacus/rma_windows.F90.o.provides] Error 2
make[1]: *** [CMakeFiles/dalton.dir/all] Error 2
make: *** [all] Error 2

bast
Posts: 1210
Joined: 26 Aug 2013, 13:22
First name(s): Radovan
Last name(s): Bast
Affiliation: none
Country: Germany

Re: errors installing on SGI Altix 350 Dalton 2013.0

Post by bast » 25 Nov 2013, 22:10

hi Marc,
there is nothing wrong with the compiler.
can you please try to replace the line 43 in file DALTON/abacus/rma_windows.F90.

Code: Select all

  type rma_win
by

Code: Select all

  type, public :: rma_win
please let me know if this worked, in that case i will
also correct it in the repository so that it gets into 2013.1.
radovan

cozzi
Posts: 4
Joined: 25 Nov 2013, 20:22
First name(s): Marc
Last name(s): Cozzi
Affiliation: Univ. of Notre Dame
Country: United States

Re: errors installing on SGI Altix 350 Dalton 2013.0

Post by cozzi » 25 Nov 2013, 22:27

Thank you for the fast response!

do I need to do a make clean and the whole ./setup thing again?

regards,

--marc

bast
Posts: 1210
Joined: 26 Aug 2013, 13:22
First name(s): Radovan
Last name(s): Bast
Affiliation: none
Country: Germany

Re: errors installing on SGI Altix 350 Dalton 2013.0

Post by bast » 25 Nov 2013, 22:34

cozzi wrote:Thank you for the fast response!

do I need to do a make clean and the whole ./setup thing again?

regards,

--marc
no you don't need to make clean or re-setup. just edit the file,
go back to the build directory and type "make". it should resume where it stopped.

cozzi
Posts: 4
Joined: 25 Nov 2013, 20:22
First name(s): Marc
Last name(s): Cozzi
Affiliation: Univ. of Notre Dame
Country: United States

Re: errors installing on SGI Altix 350 Dalton 2013.0

Post by cozzi » 27 Nov 2013, 15:59

Thank you. Radovan
I applied the changes as you suggested before and the build did indeed get past this point.
However, after 20-30 min, the build seems to stall/stick/loop while building-----
[ 17%] Building Fortran object CMakeFiles/dalton.dir/DALTON/abacus/linearlr.F.o
[ 18%] Building Fortran object CMakeFiles/dalton.dir/DALTON/abacus/average.F.o
[ 18%] Building Fortran object CMakeFiles/dalton.dir/DALTON/abacus/angpso.F.o
[ 18%] Building Fortran object CMakeFiles/dalton.dir/DALTON/abacus/angkin.F.o
[ 18%] Building Fortran object CMakeFiles/dalton.dir/DALTON/amfi/amfi.F.o

Even did a make clean and re did the ./setup biz.
The fortran compiler is chewing up CPU time but nothing is getting done past amfi.F.
/opt/intel/fc/10.1.008/bin/fortcom @/tmp/ifortwoCAzDarg at 99%cpu for hours.

Even tried building on a different SGI Altix 3700 system, same thing, same place, amfi.F.o

regards,

--marc

bast
Posts: 1210
Joined: 26 Aug 2013, 13:22
First name(s): Radovan
Last name(s): Bast
Affiliation: none
Country: Germany

Re: errors installing on SGI Altix 350 Dalton 2013.0

Post by bast » 27 Nov 2013, 19:24

thanks Marc for the confirmation. i will apply the change to the repository.
it will be part of 2013.1 patch.
about amfi.F: a possible workaround will be to lower compiler optimization for this
one file (while keeping it for all other files).
for this edit cmake/compilers/FortranFlags.cmake and insert in line 106 (it is a minus o zero at the end):
set_source_files_properties(DALTON/amfi/amfi.F PROPERTIES COMPILE_FLAGS "-O0")
so it should look like this:

Code: Select all

...
    if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
        message("--Switch off warnings due to incompatibility XCode 4 and Intel 11 on OsX 10.6")
        set(CMAKE_Fortran_FLAGS
            "${CMAKE_Fortran_FLAGS} -Qoption,ld,-w"
            )
    endif()
    set_source_files_properties(DALTON/amfi/amfi.F PROPERTIES COMPILE_FLAGS "-O0")
endif()
after you edit the file, remove the build dir, repeat setup and compile. hopefully it will then work.
good luck,
radovan

User avatar
jeff_science
Posts: 24
Joined: 02 Sep 2013, 20:32
First name(s): Jeff
Last name(s): Hammond
Affiliation: Intel Labs
Country: United States
Location: Chicago, IL
Contact:

Re: errors installing on SGI Altix 350 Dalton 2013.0

Post by jeff_science » 27 Nov 2013, 21:11

If amfi.F is so hard to compile with optimization, perhaps it should be split into multiple files that are easier for the compiler to swallow. We have such issues in NWChem and I just split the code. Resorting to -O0 should be reserved for exceptional cases and only done to the exact set of subroutines requiring it when this is done.

bast
Posts: 1210
Joined: 26 Aug 2013, 13:22
First name(s): Radovan
Last name(s): Bast
Affiliation: none
Country: Germany

Re: errors installing on SGI Altix 350 Dalton 2013.0

Post by bast » 27 Nov 2013, 21:17

jeff_science wrote:If amfi.F is so hard to compile with optimization, perhaps it should be split into multiple files that are easier for the compiler to swallow. We have such issues in NWChem and I just split the code. Resorting to -O0 should be reserved for exceptional cases and only done to the exact set of subroutines requiring it when this is done.
hi Jeff, i agree. your suggestion is a better and more permanent solution.
and i would never recommend to go to -O0 in performance critical code parts.
in this case i expect that this will not make any noticeable difference anywhere.

cozzi
Posts: 4
Joined: 25 Nov 2013, 20:22
First name(s): Marc
Last name(s): Cozzi
Affiliation: Univ. of Notre Dame
Country: United States

Re: errors installing on SGI Altix 350 Dalton 2013.0

Post by cozzi » 02 Dec 2013, 15:10

Turning off optimization seems to have fixed the last problem with the
amfi/amfi.F.o routine. I am now running into the errors listed at the end
of the cluster 1 and 2 logs/output. Something with:
one_sided_communication_wrappers_mp_mpixwincreate ??

thanks for any help,

--marc

Altix cluster #1
[ 69%] Building Fortran object CMakeFiles/dalton.dir/binary_info.F90.o
Linking Fortran static library lib/libdalton.a
[ 69%] Built target dalton
Scanning dependencies of target dalton.x
[ 69%] Building Fortran object CMakeFiles/dalton.x.dir/DALTON/abacus/dalton.F.o
Linking Fortran executable dalton.x
lib/libdalton.a(one_sided_communication_wrappers.F90.o)(.text+0xd2): In function `one_sided_communication_wrappers_mp_mpixwincreate_':
: undefined reference to `mpi_type_get_extent_'
/usr/lib/libblas.so: undefined reference to `e_wsfe'
/usr/lib/libblas.so: undefined reference to `z_abs'
/usr/lib/liblapack.so: undefined reference to `c_sqrt'
/usr/lib/liblapack.so: undefined reference to `s_cmp'
/usr/lib/liblapack.so: undefined reference to `z_exp'
/usr/lib/liblapack.so: undefined reference to `c_exp'
/usr/lib/libblas.so: undefined reference to `do_fio'
/usr/lib/liblapack.so: undefined reference to `z_sqrt'
/usr/lib/liblapack.so: undefined reference to `s_cat'
/usr/lib/libblas.so: undefined reference to `s_stop'
/usr/lib/libblas.so: undefined reference to `c_abs'
/usr/lib/libblas.so: undefined reference to `s_wsfe'
/usr/lib/liblapack.so: undefined reference to `s_copy'
make[2]: *** [dalton.x] Error 1
make[1]: *** [CMakeFiles/dalton.x.dir/all] Error 2
make: *** [all] Error 2
[root@altix build]#
You have new mail in /var/spool/mail/root
[root@altix build]#


Altix cluster #2
[ 69%] Building Fortran object CMakeFiles/dalton.dir/binary_info.F90.o
Linking Fortran static library lib/libdalton.a
[ 69%] Built target dalton
Scanning dependencies of target dalton.x
[ 69%] Building Fortran object CMakeFiles/dalton.x.dir/DALTON/abacus/dalton.F.o
Linking Fortran executable dalton.x
lib/libdalton.a(one_sided_communication_wrappers.F90.o)(.text+0xd2): In function `one_sided_communication_wrappers_mp_mpixwincreate_':
: undefined reference to `mpi_type_get_extent_'
/usr/lib/libblas.so: undefined reference to `e_wsfe'
/usr/lib/libblas.so: undefined reference to `z_abs'
/usr/lib/liblapack.so: undefined reference to `c_sqrt'
/usr/lib/liblapack.so: undefined reference to `s_cmp'
/usr/lib/liblapack.so: undefined reference to `z_exp'
/usr/lib/liblapack.so: undefined reference to `c_exp'
/usr/lib/libblas.so: undefined reference to `do_fio'
/usr/lib/liblapack.so: undefined reference to `z_sqrt'
/usr/lib/liblapack.so: undefined reference to `s_cat'
/usr/lib/libblas.so: undefined reference to `s_stop'
/usr/lib/libblas.so: undefined reference to `c_abs'
/usr/lib/libblas.so: undefined reference to `s_wsfe'
/usr/lib/liblapack.so: undefined reference to `s_copy'
make[2]: *** [dalton.x] Error 1
make[1]: *** [CMakeFiles/dalton.x.dir/all] Error 2
make: *** [all] Error 2
[root@altix build]#
You have new mail in /var/spool/mail/root
[root@altix build]#

bast
Posts: 1210
Joined: 26 Aug 2013, 13:22
First name(s): Radovan
Last name(s): Bast
Affiliation: none
Country: Germany

Re: errors installing on SGI Altix 350 Dalton 2013.0

Post by bast » 02 Dec 2013, 17:42

does your MPI implementation support the MPI-2 standard?
MPI_Type_get_extent is to my knowledge not available in MPI-1.1.

User avatar
jeff_science
Posts: 24
Joined: 02 Sep 2013, 20:32
First name(s): Jeff
Last name(s): Hammond
Affiliation: Intel Labs
Country: United States
Location: Chicago, IL
Contact:

Re: errors installing on SGI Altix 350 Dalton 2013.0

Post by jeff_science » 02 Dec 2013, 17:48

I recommend adding support for MPI feature checking in the build system. http://www.mcs.anl.gov/research/project ... node29.htm is useful but not necessarily sufficient (because some implementations lie and others have incomplete support for more recent features). The Elemental project has CMake stuff for a number of modern MPI operations that can be cannibalized if necessary.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests