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>:
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