hande-qmc / hande Goto Github PK

Hello hande Developers!

Problem

I was building hande using the Intel 2020 compiler toolchain and I ran into an error at compile time because it was trying to compile with the -openmp flag. After a bit of digging, I found that as of 2018, that flag was no longer supported and users had to replace it with -qopenmp. See the Intel docs for the specifics.

Here are my configuration commands:

./cmakeconfig.py --fc=$FC --cc=$CC --lua=/mnt/home/jsmith/apps/lua-5.3.5/src/build --mpi --mpi-with-scalapack --blacs=intelmpi --omp
...
...
cd build
make
...
...
[100%] Linking Fortran executable ../bin/hande.cmake.x
ifort: command line error: option '-openmp' is not supported. Please use the replacement option '-qopenmp'
make[2]: *** [bin/hande.cmake.x] Error 1
make[1]: *** [src/CMakeFiles/hande.cmake.x.dir/all] Error 2
make: *** [all] Error 2

I tried to tinker with the settings passed to ./cmakeconfigure.py to ensure that only the proper flag was used, but I didn't have any luck. Eventually, I found that the following CMake file was the cause of the old flag:

Proposed Solution

I edittedcmake/custom/math_libs.cmake, changed -openmp to -qopenmp (see below), and hande compiled without issue.

            if(MKL_COMPILER_BINDINGS MATCHES Intel)
                set(_omp_flag -qopenmp)
            endif()

I'm not sure if this is the best solution, but I wanted to share it in case others ran into the same issue.

The docs (https://hande.readthedocs.io/en/latest/manual/compile-with-cmake.html) suggest a minimum of CMake v3.6, but using cmake in the code it suggests CMake 3.12 is needed.

Compiling with CMake generates the print_info.c and git_info.F90 files. If one wants to than switch to compiling via mkconfig.py than those files have to be manually deleted, else they are included for compilation twice and it fails at linking stage. I suggest that mkconfig.py should delete "lib/local/print_info.c" and "lib/local/git_info.c" if they exist.

We only test MPI builds with travis. We should also have a similarly perfunctory test of serial builds.

This needs to be manually specified in the arguments cmakeconfig.py (as --add-definitions=HAVE_SSE2 I think). Could it be automatically determined whether to use this?

Travis build are failing

I have encountered this error
AttributeError: module 'pandas.io.formats' has no attribute 'terminal'
when running $~/hande/tools/reblock_hande.py -m fciqmcoutput (my pandas version is 1.0.1).
This problem was resolved by downgrading pandas to 0.22.

The full error message in ipython is
$%pdb
$%run ~/hande/tools/reblock_hande.py -m fciqmcoutput

AttributeError Traceback (most recent call last)
~/hande/tools/reblock_hande.py in parse_args(args)
218 try:
--> 219 cols = pd.util.terminal.get_terminal_size()[0]
220 except AttributeError:
~/anaconda3/lib/python3.7/site-packages/pandas/util/init.py in getattr(name)
15 else:
---> 16 raise AttributeError(f"module 'pandas.util' has no attribute '{name}'")
17
AttributeError: module 'pandas.util' has no attribute 'terminal'
During handling of the above exception, another exception occurred:
AttributeError Traceback (most recent call last)
~/hande/tools/reblock_hande.py in
313 if name == 'main':
314
--> 315 main(sys.argv[1:])
~/hande/tools/reblock_hande.py in main(args)
304 '''
305
--> 306 options = parse_args(args)
307 run_hande_blocking(options.filenames, options.start_iteration,
308 options.end_iteration, options.plotfile,
~/hande/tools/reblock_hande.py in parse_args(args)
220 except AttributeError:
221 # terminal module moved in pandas 0.20
--> 222 cols = pd.io.formats.terminal.get_terminal_size()[0]
223 if not sys.stdout.isatty():
224 cols = -1
AttributeError: module 'pandas.io.formats' has no attribute 'terminal'

/home/new_ljm/hande/tools/reblock_hande.py(222)parse_args()
220 except AttributeError:
221 # terminal module moved in pandas 0.20
--> 222 cols = pd.io.formats.terminal.get_terminal_size()[0]
223 if not sys.stdout.isatty():
224 cols = -1

We've renamed master to main in hande and hande-dev but broken the CI

Hello,

I encountered 6 failed tests and 13 skipped when running python testcode.py -c serial on my laptop. Here is an example of test.err. Is something wrong with my computer?

My operating system is ubuntu 18.04.4 LTS (Bionic Beaver) and other information gcc (Ubuntu 7.5.0-3ubuntu118.04) 7.5.0, GNU Fortran (Ubuntu 7.5.0-3ubuntu118.04) 7.5.0. I followed the user's guide and compiled it with ./cmakeconfig.py build and set export OMP_NUM_THREADS=1

Using the Intel 20.2 compilers and OpenMPI, the ifciqmc/np4/hubbard_k_1d_ifciqmc_load/ test fails with a segmentation fault. This seems related to line 310 in load_balancing.f90

"spawn%proc_map = proc_map".

Removing this line (while probably breaking the code) stops the segmentation fault. Older compilers do not seem to cause this problem.

When running the test suite on a node using SLURM it's necessary to add this to my userconfig for the test-suite
launch_parallel = srun --mpi=pmi2 -N1 -n tc.nprocs
How might we work out a sensible way of doing this automatically in cmake? [this requires a patch to testcode too]

When using make (rather than cmake+make), print_info.c is only updated when running mkconfig.py. This means that (e.g.) the commit and branch info are correct only at the time mkconfig.py is run, not when hande is compiled. This is annoying if you're in the habit of switching branches (like I am).

Compiling a debug build (with bounds check or address sanitizer) should trigger this. At least it does for me with gcc 8.1.0. It may or may not be triggered by other compilers/optimization levels/etc.

I get:

At line 379 of file src/excitations.F90
Fortran runtime error: Index '1068897958' of dimension 2 of array 'basis%bit_lookup' above upper bound of 186

Error termination. Backtrace:
#0  0x559603fb5d8e in __excitations_MOD_create_excited_det
	at src/excitations.F90:379
#1  0x559603dddf0f in __importance_sampling_MOD_dmqmc_weighting_fn
	at src/importance_sampling.f90:259
#2  0x559603dde28a in __importance_sampling_MOD_dmqmc_int_pic_free_importance_sampling
	at src/importance_sampling.f90:170
#3  0x559603ff53b0 in __spawning_MOD_spawn_importance_sampling
	at src/spawning.F90:187
#4  0x559603e6ee36 in __dmqmc_MOD_do_dmqmc_spawning_attempt
	at src/dmqmc.f90:490
#5  0x559603e73492 in __dmqmc_MOD_do_dmqmc
	at src/dmqmc.f90:305
#6  0x559603de7128 in lua_dmqmc
	at src/lua_hande_calc.f90:660
#7  0x7f03a3b9ebd5 in ???
#8  0x7f03a3bab91c in ???
#9  0x7f03a3b9eeae in ???
#10  0x7f03a3b9ef00 in ???
#11  0x7f03a3b9e321 in ???
#12  0x7f03a3b9f1fa in ???
#13  0x7f03a3b9a8e3 in ???
#14  0x55960407b355 in __flu_binding_MOD_flu_pcall
	at lib/aotus/LuaFortran/flu_binding.f90:355
#15  0x559604071f7b in __aotus_module_MOD_open_config_chunk
	at lib/aotus/source/aotus_module.f90:143
#16  0x559603ee0d38 in __lua_hande_MOD_run_lua_hande
	at src/lua_hande.F90:111
#17  0x559603e7add0 in hande
	at src/core.f90:13
#18  0x559603e7ae30 in main
	at src/core.f90:3

The actual index changes from run-to-run, so I suspect some uninitialized variable somewhere. git bisect indicates it was introduced in 722c73c.

cc: @fdmalone @xrq-phys

When I compile in debug mode, I get

hande/build/lib/local/print_info.c:185:13: warning: no previous declaration for ‘report_mpi3’ [-Wmissing-declarations] const char *report_mpi3() { ^~~~~~~~~~~ hande/build/lib/local/print_info.c:197:13: warning: no previous declaration for ‘report_shmem’ [-Wmissing-declarations] const char *report_shmem() {

These functions are also not used. Is this on purpose or should they really be used?

Just noticed that some of the code in the new documentation is missing. It's probably wrong indentation...

The energy of 2d lattice hubbard_real doesn't agree with hubbard_k and hubbard_real seems to be the problematic one. For example, the FCI energy of {1,0} ,{ 0,1 } lattice with t=1 and U=0 (tight binding limit) should be -4. For the electron =2 ms=0, the total energy is -8 which is reproduced from hubbard_k. However, hubbard_r gives -4. The same problem is encountered in {1,1}, {1, -1} lattice.

It seems to not be granted access to a repository it needs...

Running cmakeconfig.py without any options should, I think, generate something sane. However:

cmake -DCMAKE_Fortran_COMPILER=gfortran -DEXTRA_FCFLAGS="''" -DCMAKE_C_COMPILER=gcc -DEXTRA_CFLAGS="''" -DPYTHON_INTERPRETER="''" -DLUA_ROOT="''" -DENABLE_MPI="False" -DENABLE_SCALAPACK="False" -DENABLE_OPENMP="False" -DENABLE_BLAS=auto -DENABLE_LAPACK=auto -DMKL_FLAG=off -DMATH_LIB_SEARCH_ORDER="MKL;ESSL;OPENBLAS;ATLAS;ACML;SYSTEM_NATIVE" -DBLAS_LANG=Fortran -DLAPACK_LANG=Fortran -DSCALAPACK_LIBRARIES="''" -DBLACS_IMPLEMENTATION="openmpi" -DEXPLICIT_LIBS="''" -DHANDE_DSFMT_MEXP="19937" -DHANDE_DET_SIZE="32" -DHANDE_POP_SIZE="32" -DHANDE_EXE_NAME=""hande.cmake.x"" -DENABLE_HDF5="False" -DENABLE_UUID="False" -DTRLan_LIBRARIES="''" -DENABLE_SINGLE_PRECISION="False" -DENABLE_BACKTRACE="False" -DENABLE_INTRINSIC_POPCNT="False" -DCMAKE_BUILD_TYPE=release -G"Unix Makefiles" -H/home/james/hande/src/hande -B/home/james/hande/src/hande/build

-- The Fortran compiler identification is GNU 7.3.1
-- The C compiler identification is GNU 7.3.1
-- Check for working Fortran compiler: /usr/bin/gfortran
-- Check for working Fortran compiler: /usr/bin/gfortran  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/bin/gfortran supports Fortran 90
-- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting Fortran/C Interface
-- Detecting Fortran/C Interface - Found GLOBAL and MODULE mangling
-- Verifying Fortran/C Compiler Compatibility
-- Verifying Fortran/C Compiler Compatibility - Success
-- Found PythonInterp: /usr/bin/python (found version "3.6.4") 
-- Setting (unspecified) option LUA_ROOT: 
-- Found Lua: /usr/lib/liblua5.3.so;/usr/lib/libm.so (found suitable exact version "5.3.4") 
-- Setting option ENABLE_MPI: False
-- Setting option ENABLE_OPENMP: False
-- Setting option ENABLE_BLAS: auto
-- Setting option ENABLE_LAPACK: auto
-- Setting option MKL_FLAG: off
-- Setting option MATH_LIB_SEARCH_ORDER: MKL;ESSL;OPENBLAS;ATLAS;ACML;SYSTEM_NATIVE
-- Setting option BLAS_LANG: Fortran
-- Setting option LAPACK_LANG: Fortran
-- Setting (unspecified) option SCALAPACK_LIBRARIES: 
-- Setting option BLACS_IMPLEMENTATION: openmpi
-- Searching for BLAS using search order MKL;ESSL;OPENBLAS;ATLAS;ACML;SYSTEM_NATIVE
-- Setting -DHAVE_SYSTEM_NATIVE_BLAS
-- Found BLAS: SYSTEM_NATIVE (/lib64/libblas.so)
-- Searching for LAPACK using search order MKL;ESSL;OPENBLAS;ATLAS;ACML;SYSTEM_NATIVE
-- Setting -DHAVE_SYSTEM_NATIVE_LAPACK
-- Found LAPACK: SYSTEM_NATIVE (/lib64/liblapack.so)
-- Configuring incomplete, errors occurred!
See also "/home/james/hande/src/hande/build/CMakeFiles/CMakeOutput.log".

CMake Error at cmake/custom/math_libs.cmake:514 (message):
  You requested linking to ScaLAPACK, but an implementation was not set
Call Stack (most recent call first):
  CMakeLists.txt:37 (include)

We should not be attempting to link scalapack in serial builds. Help @robertodr ?