Closed adam-grofe closed 5 months ago
@adam-grofe Thanks for spotting this bug! I'll try to reproduce it and fix it right away.
Uhm, if I use gcc 11.3.0, I am not able to reproduce your problem. Just a few questions:
Thanks!
In any case, I added the missing include. If that solves the issue, I'll just merge it without asking too much :slightly_smiling_face:
Thanks @AlbertoBaiardi for fixing this! The operating system we are using is Alma Linux. In case you wanted to reproduce it, here is a conda environment that I used to compile the code:
name: qcmaquis-test
channels:
- defaults
- conda-forge
- Microsoft
dependencies:
- _libgcc_mutex=0.1=conda_forge
- _openmp_mutex=4.5=2_kmp_llvm
- binutils=2.39=hdd6e379_1
- binutils_impl_linux-64=2.39=he00db2b_1
- binutils_linux-64=2.39=h5fc0e48_13
- boost=1.82.0=py311hcb41070_0
- boost-cpp=1.82.0=he19a28c_1
- bzip2=1.0.8=h7f98852_4
- c-ares=1.18.1=h7f98852_0
- c-compiler=1.5.2=h0b41bf4_0
- ca-certificates=2022.12.7=ha878542_0
- cmake=3.26.3=h077f3f9_0
- cxx-compiler=1.5.2=hf52228f_0
- expat=2.5.0=hcb278e6_1
- gcc=11.3.0=h02d0930_13
- gcc_impl_linux-64=11.3.0=hab1b70f_19
- gcc_linux-64=11.3.0=he6f903b_13
- gsl=2.7=he838d99_0
- gxx=11.3.0=h02d0930_13
- gxx_impl_linux-64=11.3.0=hab1b70f_19
- gxx_linux-64=11.3.0=hc203a17_13
- hdf5=1.14.0=nompi_hb72d44e_103
- icu=72.1=hcb278e6_0
- kernel-headers_linux-64=2.6.32=he073ed8_15
- keyutils=1.6.1=h166bdaf_0
- krb5=1.20.1=h81ceb04_0
- ld_impl_linux-64=2.39=hcc3a1bd_1
- libaec=1.0.6=hcb278e6_1
- libblas=3.9.0=16_linux64_openblas
- libcblas=3.9.0=16_linux64_openblas
- libcurl=8.0.1=h588be90_0
- libedit=3.1.20191231=he28a2e2_2
- libev=4.33=h516909a_1
- libexpat=2.5.0=hcb278e6_1
- libffi=3.4.2=h7f98852_5
- libgcc-devel_linux-64=11.3.0=h210ce93_19
- libgcc-ng=12.2.0=h65d4601_19
- libgfortran-ng=12.2.0=h69a702a_19
- libgfortran5=12.2.0=h337968e_19
- libgomp=12.2.0=h65d4601_19
- libhwloc=2.9.1=hd6dc26d_0
- libiconv=1.17=h166bdaf_0
- liblapack=3.9.0=16_linux64_openblas
- libnghttp2=1.52.0=h61bc06f_0
- libnsl=2.0.0=h7f98852_0
- libopenblas=0.3.21=pthreads_h78a6416_3
- libsanitizer=11.3.0=h239ccf8_19
- libsqlite=3.40.0=h753d276_1
- libssh2=1.10.0=hf14f497_3
- libstdcxx-devel_linux-64=11.3.0=h210ce93_19
- libstdcxx-ng=12.2.0=h46fd767_19
- libuuid=2.38.1=h0b41bf4_0
- libuv=1.44.2=h166bdaf_0
- libxml2=2.10.4=hfdac1af_0
- libzlib=1.2.13=h166bdaf_4
- llvm-openmp=16.0.3=h4dfa4b3_0
- mkl=2023.1.0=h84fe81f_48680
- ncurses=6.3=h27087fc_1
- numpy=1.24.3=py311h64a7726_0
- openssl=3.1.0=hd590300_3
- pip=23.1.2=pyhd8ed1ab_0
- python=3.11.3=h2755cc3_0_cpython
- python_abi=3.11=3_cp311
- readline=8.2=h8228510_1
- rhash=1.4.3=h166bdaf_0
- setuptools=67.7.2=pyhd8ed1ab_0
- sysroot_linux-64=2.12=he073ed8_15
- tbb=2021.9.0=hf52228f_0
- tk=8.6.12=h27826a3_0
- tzdata=2023c=h71feb2d_0
- wheel=0.40.0=pyhd8ed1ab_0
- xz=5.2.6=h166bdaf_0
- zlib=1.2.13=h166bdaf_4
- zstd=1.5.2=h3eb15da_6
prefix: /anfhome/v-adamgrofe/.conda/envs/qcmaquis-test
and the script I used to compile it:
#!/bin/bash -l
conda activate qcmaquis-test
set -x
set -e
SCINE_ENV=/anfhome/v-adamgrofe/.conda/envs/qcmaquis-test
export CXX=${SCINE_ENV}/bin/g++
export CC=${SCINE_ENV}/bin/gcc
export FC=${SCINE_ENV}/bin/gfortran
export CFLAGS="-march=skylake-avx512 -O3 -DNDEBUG"
export CXXFLAGS=$CFLAGS
export FFLAGS=$CFLAGS
export LIBRARY_PATH=$SCINE_ENV/lib:$LIBRARY_PATH
export LD_LIBRARY_PATH=$SCINE_ENV/lib:$LD_LIBRARY_PATH
export CMAKE_PREFIX_PATH=$SCINE_ENV:$CMAKE_PREFIX_PATH
INSTALL_PATH=$SCINE_ENV
SRC_PATH=../qcmaquis/dmrg
cmake ${CMAKE_ARGS} -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$INSTALL_PATH -DBUILD_SYMMETRIES="TwoU1;SU2U1;SU2U1PG;TwoU1PG" $SRC_PATH 2>&1 | tee cmake.log && \
cmake --build . --parallel 8 2>&1 | tee build.log && \
cmake --install . --prefix $INSTALL_PATH 2>&1 | tee install.log
Yes. The problem arises also with gcc/10.2.0, but it is simple to fix the bug, just add line
#include <map>
in file qcmaquis/dmrg/framework/dmrg/utils/results_collector.h
Best, Aleksandr
Yes. The problem arises also with gcc/10.2.0, but it is simple to fix the bug, just add line
#include <map>
in file qcmaquis/dmrg/framework/dmrg/utils/results_collector.h
Best, Aleksandr
Yes, I came to the same conclusion as well. This would be nice to have in the main branch though.
Fixed in master branch
When I attempt to compile version 3.1.2 using g++ 11.3, I receive the following error:
It appears that
dmrg/framework/dmrg/utils/results_collector.h
is missing#include <map>
, where std::map is the type used bycollection
. It is odd that this hasn't been a problem in prior versions, but this should be simple fix.