TRIQS / triqs_0.x

DEPRECATED -- This is the repository of the older versions of TRIQS
Other
11 stars 9 forks source link

compilation problem on Fedora 17 #133

Closed gmm05126 closed 11 years ago

gmm05126 commented 11 years ago

Dear all, I am trying to install TRIQS on Fedora 17 (3.5.1-1.fc17.x86_64) 32 AMD Opteron(TM) cores. Could you please help me to resolve the compilations problem. Please find below output messages after cmake and make.

Thanks in advance for you help. Best, Martin (postdoc Uni Regensburg, Germany)

cmake /home/wien2k/CODES/TRIQS/git_src -DBOOST_SOURCE_DIR=/home/wien2k/CODES/TRIQS/boost_1_47_0 -DCMAKE_INSTALL_PREFIX=/home/wien2k/CODES/TRIQS/bin

OUTPUT:

-- Installation directory is /home/wien2k/CODES/TRIQS/bin -- DYNAMIC Built -- CMAKE_GENERATOR: Unix Makefiles -- CMAKE_CL_64: -- CMAKE_SIZEOF_VOID_P: 8 -- CMAKE_GENERATOR: Unix Makefiles -- CMAKE_CL_64: -- Build type: Release -- MPI compiler was /usr/lib64/openmpi/bin/mpicxx -- Python interpreter /bin/python -- Python interpreter ok : version 2.7.3 -- PYTHON_INCLUDE_DIRS = /usr/include/python2.7 -- PYTHON_NUMPY_INCLUDE_DIR = /usr/lib64/python2.7/site-packages/numpy/core/include -- PYTHON_SITE_PKG = /usr/lib/python2.7/site-packages -- PYTHON_LIBRARY = /usr/lib64/python2.7/config/libpython2.7.so -- PYTHON_EXTRA_LIBS =-lpthread -ldl -lutil -- PYTHON_LINK_FOR_SHARED = -Xlinker -export-dynamic -- Numpy include in /usr/lib64/python2.7/site-packages/numpy/core/include -- HDF5_LIBRARIES = debug;/usr/lib64/libhdf5_hl.so;/usr/lib64/libhdf5.so;/usr/lib64/libz.so;/usr/lib64/librt.so;/usr/lib64/libm.so;/usr/lib64/libhdf5_cpp.so;optimized;/usr/lib64/libhdf5_hl.so;/usr/lib64/libhdf5.so;/usr/lib64/libz.so;/usr/lib64/librt.so;/usr/lib64/libm.so;/usr/lib64/libhdf5_cpp.so -- Triqs general lib detection ( but boost ) -- Adding definitions -D_LARGEFILE_SOURCE;-D_LARGEFILE64_SOURCE;-D_BSD_SOURCE;-D_FORTIFY_SOURCE=2;-D_LARGEFILE_SOURCE;-D_LARGEFILE64_SOURCE;-D_BSD_SOURCE;-D_FORTIFY_SOURCE=2 -- Adding include /usr/include/openmpi-x86_64;/usr/include;/usr/include/python2.7;/usr/lib64/python2.7/site-packages/numpy/core/include -- Adding libs /usr/lib64/openmpi/lib/libmpi_cxx.so;/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/libdl.so;debug;/usr/lib64/libhdf5_hl.so;/usr/lib64/libhdf5.so;/usr/lib64/libz.so;/usr/lib64/librt.so;/usr/lib64/libm.so;/usr/lib64/libhdf5_cpp.so;optimized;/usr/lib64/libhdf5_hl.so;/usr/lib64/libhdf5.so;/usr/lib64/libz.so;/usr/lib64/librt.so;/usr/lib64/libm.so;/usr/lib64/libhdf5_cpp.so;/usr/lib64/python2.7/config/libpython2.7.so -- Adding library dir
-- Python modules will be installed in /home/wien2k/CODES/TRIQS/bin/lib/python2.7/site-packages/pytriqs -- I am using boost sources from /home/wien2k/CODES/TRIQS/boost_1_47_0 to compile a mini boost_for_triqs -- BOOST_INCLUDE_DIR = /home/wien2k/CODES/TRIQS/boost_1_47_0 -- You are not using mkl -- cblas header found at /usr/local/MATLAB/R2012a-cs/toolbox/rtw/rtwdemos/crl_demo/cblas.h -- Could NOT find Git (missing: GIT_EXECUTABLE) -- 64 bit machine : Adding -fpic -- Preparing python module ArrayTests -- Making pytriqs/Base/Tests/array_tests.py -- Preparing python module test_converter -- Making pytriqs/Tools/test/pytriqs_test_converter.py -- Preparing python module GF -- Making pytriqs/Base/GF_Local/pytriqs_GF.py -- Preparing python module LatticeTools -- Making pytriqs/Base/Lattice/pytriqs_LatticeTools.py -- MPI launch command is : /usr/lib64/openmpi/bin/mpiexec -np PROCS EXECUTABLE ARGS


-- **** WARNING **** -- Wien2k users : after installation of TRIQS, copy the files from -- /home/wien2k/CODES/TRIQS/bin/share/triqs/Wien2k_SRC_files/SRC_templates -- to your Wien2k installation WIENROOT/SRC_templates (Cf documentation).
-- This is not handled automatically by the installation process.


-- Preparing optional python module CTHyb -- Preparing python module CTHyb -- Making pytriqs/Solvers/HybridizationExpansion/pytriqs_Solver_HybridizationExpansion.py -- Preparing the various scripts -- Configuring done -- Generating done -- Build files have been written to: /home/wien2k/CODES/TRIQS/triqs_build

make -j32 OUTPUT: Linking Fortran executable dmftproj CMakeFiles/dmftproj.dir/orthogonal_wannier.f.o: In function orthogonal_wannier_': orthogonal_wannier.f:(.text+0x591): undefined reference tozgemm_' orthogonalwannier.f:(.text+0x6a3): undefined reference to `zgemm' CMakeFiles/dmftproj.dir/orthogonal_wannier.f.o: In functionorthogonal_wannier_so_': orthogonal_wannier.f:(.text+0x27ac): undefined reference tozgemm_' orthogonalwannier.f:(.text+0x28c1): undefined reference to`zgemm' CMakeFiles/dmftproj.dir/density.f.o: In function density_': density.f:(.text+0x2457): undefined reference tozgemm' CMakeFiles/dmftproj.dir/density.f.o:density.f:(.text+0x3533): more undefined references to `zgemm' follow CMakeFiles/dmftproj.dir/orthogonal.f.o: In functionsqrt_eigenvec_': orthogonal.f:(.text+0x16a): undefined reference tozheev' CMakeFiles/dmftproj.dir/orthogonal.f.o: In function`sqrtm': orthogonal.f:(.text+0x1119): undefined reference to `zgemm_' collect2: error: ld returned 1 exit status make[2]: * [pytriqs/Wien2k/dmftproj/dmftproj] Error 1 make[1]: * [pytriqs/Wien2k/dmftproj/CMakeFiles/dmftproj.dir/all] Error 2 make[1]: *\ Waiting for unfinished jobs.... [ 0%] [ 0%] Building CXX object foreignlibs/boost/CMakeFiles/boost_for_triqs.dir/home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/once.cpp.o Building CXX object foreignlibs/boost/CMakeFiles/boost_for_triqs.dir/home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/thread.cpp.o In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/platform.hpp:17:0, from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/once.hpp:12, from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/once.cpp:7: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/config/requires_threads.hpp:29:4: error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/once.hpp:12:0, from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/once.cpp:7: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/platform.hpp:67:9: error: #error "Sorry, no boost threads are available for this platform." In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/once.cpp:7:0: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/once.hpp:18:2: error: #error "Boost threads unavailable on this platform" In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/platform.hpp:17:0, from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/config.hpp:20, from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/thread.cpp:8: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/config/requires_threads.hpp:29:4: error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/config.hpp:20:0, from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/thread.cpp:8: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/detail/platform.hpp:67:9: error: #error "Sorry, no boost threads are available for this platform." In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/thread.cpp:10:0: /home/wien2k/CODES/TRIQS/boost_1_47_0/boost/thread/thread.hpp:19:2: error: #error "Boost threads unavailable on this platform" In file included from /home/wien2k/CODES/TRIQS/boost_1_47_0/libs/thread/src/pthread/once.cpp:7:0:

... etc ... etc ... all related to boost/thread

The CMakeCache.txt you can find here: https://gist.github.com/gmm05126/5535285

aichhorn commented 11 years ago

There is also an issue not realted to boost. When trying to link dmftproj, the linker cannot find the blas/lapack libraries. Obviously, they are not detected. Do you have them in some strange non-standard location, and not in /usr/lib?

gmm05126 commented 11 years ago

Hi! Thanks for your hint. Lapack and blas sit in /usr/lib64/ When checking ./CMakeFiles/CMakeOutput.log file, there are following lines with blas/lapack [grep output]:

/bin/gfortran CMakeFiles/cmTryCompileExec1736813534.dir/testFortranCompiler.f.o -o cmTryCompileExec1736813534 -rdynamic /usr/lib64/libblas.so /bin/gfortran CMakeFiles/cmTryCompileExec3604646137.dir/testFortranCompiler.f.o -o cmTryCompileExec3604646137 -rdynamic /usr/lib64/liblapack.so /usr/lib64/libblas.so

I tried to go with "ccmake ." in advance mode to set by hands the libs like: BLAS_LIBRARY /usr/lib64/libblas.so BLAS_blas_LIBRARY /usr/lib64/libblas.so LAPACK_LIBRARY /usr/lib64/liblapack.so LAPACK_LIBS /usr/lib64/liblapack.so LAPACK_lapack_LIBRARY /usr/lib64/liblapack.so

I have got the following error (pasting just the linking problem): Linking Fortran executable dmftproj /bin/ld: CMakeFiles/dmftproj.dir/orthogonalwannier.f.o: undefined reference to symbol 'zgemm' /bin/ld: note: 'zgemm_' is defined in DSO /lib64/libblas.so.3 so try adding it to the linker command line /lib64/libblas.so.3: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: * [pytriqs/Wien2k/dmftproj/dmftproj] Error 1 make[1]: * [pytriqs/Wien2k/dmftproj/CMakeFiles/dmftproj.dir/all] Error 2

It looks like incompatibility of the libblas.so.3?

Martin

mferrero commented 11 years ago

Hi Martin.

Can you tell me what c++ compiler you are using (what version)? There have been problems with thread support in boost <= 1.48 with the experimental version of g++ 4.7. If you happen to have g++ 4.7 experimental, you might want to download a version of boost >= 1.49.

Let's see if we can fix this problem and then we'll see about the other linking problem.

Cheers,

Michel

gmm05126 commented 11 years ago

Hi Michel, Thanks for your hint. I downloaded boost_1_53_0 and did next try, but stopped again, see below. I am using the following for compiler (from ccmake):

CMAKE_CXX_COMPILER /bin/c++ CMAKE_C_COMPILER /bin/gcc MPI_CXX_COMPILER /usr/lib64/openmpi/bin/mpicxx

where: /bin/c++ --version c++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) /bin/gcc --version gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) /usr/lib64/openmpi/bin/mpicxx --version g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2

Best, Martin

Here is output after promising "green" it looks like:

Linking Fortran executable dmftproj [ 32%] Building CXX object foreignlibs/boost/CMakeFiles/boost_for_triqs.dir/home/wien2k/CODES/TRIQS/boost_1_53_0/libs/python/src/object/enum.cpp.o /bin/ld: CMakeFiles/dmftproj.dir/orthogonalwannier.f.o: undefined reference to symbol 'zgemm' /bin/ld: note: 'zgemm_' is defined in DSO /lib64/libblas.so.3 so try adding it to the linker command line /lib64/libblas.so.3: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: * [pytriqs/Wien2k/dmftproj/dmftproj] Error 1 make[1]: * [pytriqs/Wien2k/dmftproj/CMakeFiles/dmftproj.dir/all] Error 2 make[1]: *\ Waiting for unfinished jobs....

... etc ... etc ...

Linking CXX shared library libboost_for_triqs.so [ 42%] Built target boost_for_triqs make: *\ [all] Error 2

aeantipov commented 11 years ago

Hi, Martin.

Try setting LAPACK_LINKER_FLAGS to something like -L/usr/lib64 -llapack -lblas

Andrey.

gmm05126 commented 11 years ago

Hi, Thanks for the advice. I have set: LAPACK_LIBS -L/usr/lib64 -llapack -lblas since I do not see in toggle mode the LAPACK_LINKER_FLAGS. Compilation went a step further, it seems now the blas/lapack is linked, but now I have problem with cblas.h file. I do not have such a header file in my system. It seems that the cblas.h does not come with devel version of the blas libs. Do you have any idea?

Cheers, Martin

aeantipov commented 11 years ago

That one is set by CBLAS_INCLUDE_DIR - that's probably /usr/include or something like that

Andrey.

P.S. The way I do it - write a script - something like this and then just run it. This one I tested for the mkl-provided blas and lapack.

cmake \
-DBOOST_SOURCE_DIR=/Volumes/Users/antipov/dist/boost_1_49_0 \
-DBLAS_LIBRARY="-L${MKLROOT}/lib -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lm" \
-DLAPACK_LIBRARY="-L${MKLROOT}/lib -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lm" \
-DLAPACK_LIBS="-L${MKLROOT}/lib -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lm" \
-DLAPACK_LINKER_FLAGS=-L${MKLROOT} -L${MPIROOT}/lib -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lpthread -lm \
-DCBLAS_INCLUDE_DIR=${MKLROOT}/include \
-DCMAKE_INSTALL_PREFIX= ..some_path...
..path_to_triqs..
mferrero commented 11 years ago

Yes I think Fedora does not ship cblas.h in the blas devel. You should probably get it from some other package. You might want to get it from atlas-devel-3.8.4-3.fc17.

Cheers!

gmm05126 commented 11 years ago

Hi Michel, & Andrey

I updated atlas-devel and the cblas.h is in. With that I am able to go up to 47%, but I am stacking

on the following error:

[ 47%] Building CXX object triqs/utility/proto/test/CMakeFiles/algebra_fnt2.dir/algebra_fnt2.cpp.o Linking CXX executable algebra_fnt2 CMakeFiles/algebra_fnt2.dir/algebra_fnt2.cpp.o: In function void boost::numeric::bindings::blas::gemm_impl<double>::invoke<triqs::arrays::matrix_view<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> >, triqs::arrays::matrix_view<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> >, triqs::arrays::matrix<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> > >(double, triqs::arrays::matrix_view<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> > const&, triqs::arrays::matrix_view<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> > const&, double, triqs::arrays::matrix<double, triqs::arrays::Option::options<triqs::arrays::Tag::C, void, void, void> >&)': algebra_fnt2.cpp:(.text._ZN5boost7numeric8bindings4blas9gemm_implIdE6invokeIN5triqs6arrays11matrix_viewIdNS7_6Option7optionsINS7_3Tag1CEvvvEEEESE_NS7_6matrixIdSD_EEEEvdRKT_RKT0_dRT1_[_ZN5boost7numeric8bindings4blas9gemm_implIdE6invokeIN5triqs6arrays11matrix_viewIdNS7_6Option7optionsINS7_3Tag1CEvvvEEEESE_NS7_6matrixIdSD_EEEEvdRKT_RKT0_dRT1_]+0x6a): undefined reference tocblas_dgemm' collect2: error: ld returned 1 exit status make[2]: * [triqs/utility/proto/test/algebra_fnt2] Error 1 make[1]: * [triqs/utility/proto/test/CMakeFiles/algebra_fnt2.dir/all] Error 2

make: *\ [all] Error 2

I have also tried Andrey's mkl configuration, which got trapped on:


Linking Fortran executable dmftproj /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to __kmpc_ok_to_fork' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_end_single' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to `kmpc_ordered' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_for_static_init_8' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference toomp_get_thread_num' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_barrier' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference toomp_get_num_threads' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference toomp_get_num_procs' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_dispatch_next_4' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_end_reduce_nowait' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_critical' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_dispatch_fini_8' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_atomic_cmplx8_add' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_atomic_float4_add' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_serialized_parallel' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_end_critical' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_dispatch_init_8' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference toompc_set_nested' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_for_static_init_8u' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference toomp_get_nested' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_dispatch_fini_4' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to`kmpc_atomic_float8_max' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to omp_in_parallel' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_push_num_threads' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to __kmpc_reduce_nowait' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference toomp_get_max_threads' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to `kmpc_for_static_init_4' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_end_serialized_parallel' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_flush' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_single' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_dispatch_next_8' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_atomic_float8_add' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_atomic_float4_max' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_end_master' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_dispatch_init_4' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to`kmpc_global_thread_num' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to __kmpc_end_ordered' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference tokmpc_fork_call' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to `kmpc_atomic_fixed8_add' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_for_static_fini' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to__kmpc_master' /opt/intel/composer_xe_2013.3.163/mkl/lib/intel64/libmkl_intel_thread.so: undefined reference to`__kmpc_atomic_cmplx4_add' collect2: error: ld returned 1 exit status make[2]: * [pytriqs/Wien2k/dmftproj/dmftproj] Error 1 make[1]: * [pytriqs/Wien2k/dmftproj/CMakeFiles/dmftproj.dir/all] Error 2 make[1]: *\ Waiting for unfinished jobs....

Do you have some idea how to go on? Thanks in advance, Martin

mferrero commented 11 years ago

Hi. Now that you have atlas, you should link against it. So you should just add -latlas to you lapack linking.

gmm05126 commented 11 years ago

Hi Michel, Thanks for the -latlas. Now TRIQS compiles but I can not pass several, I guess critical, tests. Please see list below. Should I understand that as not working binary? Thanks in advance, Martin

The following tests FAILED: 39 - group_indices_nopy (Failed) 82 - group_indices_wpy (Failed) 109 - ExampleTestH5 (Failed) 110 - HDF5_IO (Failed) 111 - GF_Init (Failed) 112 - GF_BasOps (Failed) 113 - dos1 (Failed) 114 - Wien2kconvert (Failed) 116 - SingleSiteBethe (Failed) 117 - CDMFT_4_sites (Failed) 118 - HubbardI (Failed) Errors while running CTest

mferrero commented 11 years ago

It looks to me like there must be some problem with the HDF5, which is involved in all these tests. Can you check the content of the following files in your build directory:

pytriqs/Base/test/HDF5_IO_output pytriqs/Base/test/HDF5_IO_output.err

Then we can try to figure out what went wrong.

gmm05126 commented 11 years ago

Dear Michel,

Both the files HDF5_IO_output and HDF5_IO_output.err are empty,

Martin

mferrero commented 11 years ago

I see. Well then could you show me the result of

h5dump pytriqs/Base/test/HDF5_IO.output.h5

You can put the result in gist. Thanks!

gmm05126 commented 11 years ago

Hi Michel, I am placing the output right below, since it is not that long.

Thanks for your interest. Best, Martin

HDF5 "pytriqs/Base/test/HDF5_IO.output.h5" { GROUP "/" { DATASET "a" { DATATYPE H5T_IEEE_F64LE DATASPACE SCALAR DATA { (0): 1 } } GROUP "b" { ATTRIBUTE "TRIQS_HDF5_data_scheme" { DATATYPE H5T_STRING { STRSIZE H5T_VARIABLE; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "PythonListWrap" } } DATASET "0000000000" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 1 } } DATASET "0000000001" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 2 } } DATASET "0000000002" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 3 } } } DATASET "c" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 100 } } DATASET "d" { DATATYPE H5T_STD_I64LE DATASPACE SIMPLE { ( 2, 3 ) / ( 2, 3 ) } DATA { (0,0): 1, 2, 3, (1,0): 4, 5, 6 } } GROUP "e" { ATTRIBUTE "TRIQS_HDF5_data_scheme" { DATATYPE H5T_STRING { STRSIZE H5T_VARIABLE; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "PythonTupleWrap" } } DATASET "0000000000" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 1 } } DATASET "0000000001" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 2 } } DATASET "0000000002" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 3 } } } GROUP "f" { ATTRIBUTE "TRIQS_HDF5_data_scheme" { DATATYPE H5T_STRING { STRSIZE H5T_VARIABLE; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "PythonDictWrap" } } DATASET "a" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 25 } } DATASET "b" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 20 } } } GROUP "g" { DATASET "a" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 98 } } GROUP "b" { ATTRIBUTE "TRIQS_HDF5_data_scheme" { DATATYPE H5T_STRING { STRSIZE H5T_VARIABLE; STRPAD H5T_STR_NULLTERM; CSET H5T_CSET_ASCII; CTYPE H5T_C_S1; } DATASPACE SCALAR DATA { (0): "PythonTupleWrap" } } DATASET "0000000000" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 1 } } DATASET "0000000001" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 2 } } DATASET "0000000002" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 3 } } } DATASET "c" { DATATYPE H5T_STD_I64LE DATASPACE SCALAR DATA { (0): 200 } } } } }

mferrero commented 11 years ago

Your archive looks fine. The tests are complaining because of some difference in the way hdf5 attributes are encoded (this changed between versions of h5py). But the actual data in the archive is OK, so I think you have a working TRIQS!

We fixed this issue with the attributes in the current development branch 1.0 (commit 1f11742) that will soon become the current release.

gmm05126 commented 11 years ago

Thanks Michel for your help with installation. Now I went through the install -jN and launching ipytriqs_notebook gives me the following import error:

Traceback (most recent call last): File "", line 6, in ImportError: No module named IPython

How to tell python where the IPython module is? Thanks, Martin

mferrero commented 11 years ago

The best to get ipython and the notebook is to first install the python-virtualenv (this package is in Fedora). Then you can follow the steps described in the documentation:

http://ipht.cea.fr/triqs/doc/user_manual/install/virtualenv.html

gmm05126 commented 11 years ago

Hi Michel, I went step-by-step and setup virtualenv. The easy_install --upgrade ipython installed updates smoothly, but invoking ipytriqs_notebook gives the same error as before: ImportError: No module named IPython

Martin

mferrero commented 11 years ago

OK, after installing the virtualenv, your default python interpreter should now be somewhere in your home directory, if you added the lines in your bashrc. You can check this by doing

which python

If this is OK, then you have to recompile TRIQS because the first time you compiled it, you were still using the system wide python which does not have ipython. If you recompile, it will use your local python that now has the ipython.

gmm05126 commented 11 years ago

Yes, my default python now is which python ~/.my_python/bin/python I have made -- (i) [make clean]; and recompiled (ii) [make -j32] anew the TRIQS; and install it (iii) [make -j32 install]. Asking for notebook ipytriqs_notebook gives exactly the same ImportError. Any idea? Thanks.

mferrero commented 11 years ago

Sorry, I haven't been clear. You have to do the cmake from scratch, not just the compilation. The cmake command is detecting your python, so this is why you need to start from scratch.

gmm05126 commented 11 years ago

Hi Michel, Thanks for your hints. I edited corresponding python lines using [ccmake .] since cmake could not give up the default /usr/bin/python. Now running ipytriqs_notebook I have got:

Traceback (most recent call last): File "", line 9, in File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/frontend/terminal/ipapp.py", line 388, in launch_new_instance app.initialize() File "", line 2, in initialize File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/config/application.py", line 84, in catch_config_error return method(app, _args, _kwargs) File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/frontend/terminal/ipapp.py", line 313, in initialize super(TerminalIPythonApp, self).initialize(argv) File "", line 2, in initialize File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/config/application.py", line 84, in catch_config_error return method(app, _args, _kwargs) File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/core/application.py", line 325, in initialize self.parse_command_line(argv) File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/frontend/terminal/ipapp.py", line 308, in parse_command_line return super(TerminalIPythonApp, self).parse_command_line(argv) File "", line 2, in parse_command_line File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/config/application.py", line 84, in catch_config_error return method(app, _args, _kwargs) File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/config/application.py", line 420, in parse_command_line return self.initialize_subcommand(subc, subargv) File "", line 2, in initialize_subcommand File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/config/application.py", line 84, in catch_config_error return method(app, _args, _kwargs) File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/config/application.py", line 352, in initialize_subcommand subapp = import_item(subapp) File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/utils/importstring.py", line 40, in import_item module = import(package,fromlist=[obj]) File "/home/wien2k/.my_python/lib/python2.7/site-packages/ipython-0.13.2-py2.7.egg/IPython/frontend/html/notebook/init.py", line 8, in raise ImportError(msg) ImportError: The IPython Notebook requires tornado >= 2.1.0

Thanks in advance for any idea, Martin

mferrero commented 11 years ago

It seems that the notebook requires tornado >= 2.1.0. Try installing the latest tornado:

easy_install -U tornado

BTW, in order that cmake gets the good python, you can specify its location like this when calling cmake:

cmake -DPYTHON_INTERPRETER=/home/wien2k/.my_python/bin/python ...

Maybe that works better than setting it manually in the ccmake .?

gmm05126 commented 11 years ago

Hi Michel, Yes, easy_install best matches tornado 3.0.1 There was a need to install zmq and pyzmq. I did the following steps (placing to the forum for a future reference): Do the following: yum install libtool yum install e2fsprogs e2fsprogs-libs e2fsprogs-devel yum install libuuid-devel

Now Download package from http://www.zeromq.org/area:download

After this I am able to run ipytriqs_notebook. I went further with setting up DMFT calculations interfacing to Wien2k. I have prepared LDA SCF calculations (spin-polarized with spin-orbit), setup case.indmftpr file, able to run dmftproj -sp -so. But doing a one-shot Hubbard-I run invoking pytriqs case.py I am getting the following error:

Traceback (most recent call last): File "case.py", line 1, in from pytriqs.Wien2k.SumK_LDA import File "/home/wien2k/CODES/TRIQS/bin/lib/python2.7/site-packages/pytriqs/Wien2k/SumK_LDA.py", line 24, in from pytriqs.Wien2k.Symmetry import File "/home/wien2k/CODES/TRIQS/bin/lib/python2.7/site-packages/pytriqs/Wien2k/Symmetry.py", line 29, in import pytriqs.Base.Utility.MPI as MPI File "/home/wien2k/CODES/TRIQS/bin/lib/python2.7/site-packages/pytriqs/Base/Utility/MPI.py", line 30, in from pytriqs.boost.mpi import * File "/home/wien2k/CODES/TRIQS/bin/lib/python2.7/site-packages/pytriqs/boost/init.py", line 3, in import DLFCN as dl ImportError: No module named DLFCN

-----------------------------------------------------------------------------------------------------------------------------------[end error output]

Do you have an idea how to reach the DLFCN module?

I do have further questions: (i) As to the k-point parallelization; -p option and .machines file for Wien2k. The x lapw2 -c -up -so -almd -p produces several case.almblmup_* files. For that one-shot test I have just merged the particular files to a single file case.almblmup. Is that k-point parallelization bypass correct for dmftproj? Or you would suggest non-parallel run?

(ii) Concerning exchange-correlation functional. Can one use GGA in Wien2k calculations?

Thanks in advance, Martin

gmm05126 commented 11 years ago

I think I went through the DLFCN module problem, not sure if fully system compatible. The point is kind of bug in python or so. I am not expert but there are plenty discussions on internet. What I did was to download Python source package and extract h2py.py from Python-2.7.4/Tools/scripts and run h2py.py /usr/include/dlfcn.h to generate the DLFCN.py module. I have placed it to working (Wien2k) case directory. Do you know standard python place for the module? Anyway, I am able to run a single-shot with Hubbard-I, but there I have got some -- FAILURE to adjust Chemical_Potential, which should be moved to a non installation post.

mferrero commented 11 years ago

Can you see if you have a system wide DLFCN.pyc? In Ubuntu it is in the directory

/usr/lib/python2.7/plat-linux2/DLFCN.pyc

gmm05126 commented 11 years ago

Hi Michel, Oh yes! I have it there: /usr/lib64/python2.7/plat-linux2/DLFCN.pyc But I need to place it in working directory otherwise my_python can not see it in the standard place.

Martin

mferrero commented 11 years ago

For some reason, virtualenv does not make all links. So just do the following:

cd ~/.my_python/lib/python2.7 ln -s /usr/lib64/python2.7/plat-linux2 .

This way you manually add the link that virtualenv has forgotten. Then the issue with DLFCN should be solved.

Michel

gmm05126 commented 11 years ago

Yes, it resolves the problem. Thanks a lot for your help! Martin