Thanks Leo!
We’ll fix it right away.
Emanuel
On Dec 4, 2015, at 3:52 PM, Leo Fang leofang@phy.duke.edu wrote:
Hello all,
This is a bug report associated a working fix for the hybridization solver (cc: Dr. Gull, Dr. Antipov); the ALPS library 2.2.b3 works fine.
Using gdb, it is clear that the variable "info" in line 282 of hybblasmatrix.hpp (or line 280 in the GitHub-hosted version) is declared but not properly initialized, so depending on the compiler and the environment (I tested on two different machines with different Linux distributions) a nonzero value could be assigned to this variable, causing dgesv to complain. To fix it, just initialize it with zero. Changing CMAKE_BUILD_TYPE (as I proposed earlier) does not guarantee to avoid this bug.
Sincerely, Leo (Fang Yao-Lung) Duke Physics
2015-12-03 22:25 GMT-05:00 Leo Fang <leofang@phy.duke.edu mailto:leofang@phy.duke.edu>: Hello all,
I used the following command to build the ALPS 2.2.0.b3 library (with Boost source code):
cmake \ -D ALPS_BUILD_TESTS=OFF \ -D ALPS_BUILD_EXAMPLES=OFF \ -D ALPS_BUILD_APPLICATIONS=ON \ -D ALPS_BUILD_PYTHON=ON \ -D LAPACK_64_BIT=ON \ -D Boost_ROOT_DIR=/home/yf30/alps-2.2.b3-r7462-src-with-boost/boost/ \ -D CMAKE_BUILD_TYPE=Release \ -D CMAKE_INSTALL_PREFIX=/home/yf30/alps/ \ -D CMAKE_C_COMPILER=/usr/bin/gcc \ -D CMAKE_CXX_COMPILER=/usr/bin/g++ \ -D ALPS_ENABLE_MPI=ON \ -D MPI_CXX_COMPILER=/usr/lib64/openmpi/bin/mpicxx \ -D MPI_C_INCLUDE_PATH=/usr/include/openmpi-x86_64/ \ -D MPI_C_LIBRARIES="/usr/lib64/openmpi/lib/libmpi.so;/usr/lib64/openmpi/lib/libopen-pal.so;/usr/lib64/openmpi/lib/libopen-rte.so" \ -D MPI_CXX_INCLUDE_PATH=/usr/include/openmpi-x86_64/ \ -D MPI_CXX_LIBRARIES="/usr/lib64/openmpi/lib/libmpi_cxx.so;/usr/lib64/openmpi/lib/libopen-pal.so;/usr/lib64/openmpi/lib/libopen-rte.so" \ /home/yf30/alps-2.2.b3-r7462-src-with-boost/alps/
However, when I execute the hybridization solver, the program terminates with the following error message:
(input parameter omitted) Hybridization Expansion Simulation CT-HYB Part of the ALPS DMFT Project Usage requires citation of the ALPS CT-HYB paper and the ALPS paper Refer to the documentation for more information. process 0 of total: 1 starting simulation in dgesv: info was not zero.
After a lot of trials and errors, I found that if I set "CMAKE_BUILD_TYPE=Debug" when building ALPS, this error does not show up and I do get correct results. I thought the only difference between a debug build and a release build is that the former has an extra "-g" flag to include debug symbols. Why would the lapack function dgesv be wrong?
Thanks.
Sincerely, Leo (Fang Yao-Lung) Duke Physics