Running Abinit in virtual box Ubuntu

xbai33 · Post by **xbai33** » Tue Jan 19, 2021 11:39 pm

Dear All,

By following the tutorial, I was able to compile all the dependence and Abinit from scratch in a virtual box Ubuntu on my Windows workstation. I can run Abinit to check version information. However, when performing "make test_fast", I receive a "SIGILL" error. The error message, my cpu info and build info at presented below. Could you help me to resolve this issue? Thank you!

Best,
Xiaojian Bai

================================================================================

=== [ionmov= 2] Broyden-Fletcher-Goldfard-Shanno method (forces)
================================================================================

--- Iteration: (1/5) Internal Cycle: (1/1)
--------------------------------------------------------------------------------

Cartesian coordinates (xcart) [bohr]
-7.27544561160973E-01 0.00000000000000E+00 0.00000000000000E+00
7.27544561160973E-01 0.00000000000000E+00 0.00000000000000E+00
Reduced coordinates (xred)
-6.06287134300811E-02 0.00000000000000E+00 0.00000000000000E+00
6.06287134300811E-02 0.00000000000000E+00 0.00000000000000E+00

---SELF-CONSISTENT-FIELD CONVERGENCE--------------------------------------------

getcut: wavevector= 0.0000 0.0000 0.0000 ngfft= 24 20 20
ecut(hartree)= 4.500 => boxcut(ratio)= 2.09440

1/G**2 cut-off applied in the following step : cutoff-mode = CRYSTAL

1/G**2 cut-off applied in the following step : cutoff-mode = CRYSTAL

1/G**2 cut-off applied in the following step : cutoff-mode = CRYSTAL

--- !WARNING
src_file: m_drivexc.F90
src_line: 707
message: |
Density went too small (lower than xc_denpos) at 2454 points
and was set to xc_denpos = 1.00E-14. Lowest was -0.14E-06.
Likely due to too low boxcut or too low ecut for pseudopotential core charge.

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:
#0 0x7fdce950ed01 in ???
#1 0x7fdce950ded5 in ???
#2 0x7fdce915b20f in ???
#3 0x7fdce9ae9212 in ???
#4 0x7fdce998e5d9 in ???
#5 0x7fdce98e909a in ???
#6 0x55f5910f5d03 in __m_cgtools_MOD_cg_zgemv
at ../../../src/44_abitools/m_cgtools.F90:898
#7 0x55f5910f61f3 in __m_cgtools_MOD_projbd
at ../../../src/44_abitools/m_cgtools.F90:3274
#8 0x55f5909d68c7 in __m_cgwf_MOD_cgwf
at ../../../src/67_common/m_cgwf.F90:690
#9 0x55f5903d0764 in __m_vtowfk_MOD_vtowfk
at ../../../src/79_seqpar_mpi/m_vtowfk.F90:411
#10 0x55f5903b9874 in __m_vtorho_MOD_vtorho
at ../../../src/79_seqpar_mpi/m_vtorho.F90:961
#11 0x55f590348a89 in __m_scfcv_core_MOD_scfcv_core
at ../../../src/94_scfcv/m_scfcv_core.F90:1572
#12 0x55f59033d29e in scfcv_scfcv
at ../../../src/94_scfcv/m_scfcv.F90:712
#13 0x55f5903353b5 in __m_mover_MOD_mover
at ../../../src/95_drive/m_mover.F90:604
#14 0x55f590326e73 in __m_gstate_MOD_gstate
at ../../../src/95_drive/m_gstate.F90:1297
#15 0x55f59023079e in __m_gstateimg_MOD_gstateimg
at ../../../src/95_drive/m_gstateimg.F90:562
#16 0x55f59021cf00 in __m_driver_MOD_driver
at ../../../src/95_drive/m_driver.F90:783
#17 0x55f59020a425 in abinit
at ../../../src/98_main/abinit.F90:391
#18 0x55f59020ff3c in main
at ../../../src/98_main/abinit.F90:88

Here is what I get when running "lscpu"

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 46 bits physical, 48 bits virtual
CPU(s): 20
On-line CPU(s) list: 0-19
Thread(s) per core: 1
Core(s) per socket: 20
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz
Stepping: 7
CPU MHz: 2194.500
BogoMIPS: 4389.00
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 640 KiB
L1i cache: 640 KiB
L2 cache: 20 MiB
L3 cache: 330 MiB
NUMA node0 CPU(s): 0-19
Vulnerability Itlb multihit: KVM: Mitigation: VMX unsupported
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __use
r pointer sanitization
Vulnerability Spectre v2: Mitigation; Full generic retpoline, STIBP disa
bled, RSB filling
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Mitigation; TSX disabled
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mt
rr pge mca cmov pat pse36 clflush mmx fxsr sse
sse2 ht syscall nx rdtscp lm constant_tsc rep
_good nopl xtopology nonstop_tsc cpuid tsc_kno
wn_freq pni pclmulqdq ssse3 cx16 pcid sse4_1 s
se4_2 x2apic movbe popcnt aes xsave avx rdrand
hypervisor lahf_lm abm 3dnowprefetch invpcid_
single fsgsbase avx2 invpcid rdseed clflushopt
md_clear flush_l1d arch_capabilities

Here is what I get when running "abinit -b"

=== Build Information ===
Version : 9.2.2
Build target : x86_64_linux_gnu9.3
Build date : 20210119

=== Compiler Suite ===
C compiler : gnu9.3
C++ compiler : gnu9.3
Fortran compiler : gnu9.3
CFLAGS : -g -O2 -mtune=native -march=native
CXXFLAGS : -g -O2 -mtune=native -march=native
FCFLAGS : -g -ffree-line-length-none -I/home/xbq/local/include -I/home/xbq/local/include
FC_LDFLAGS :

=== Optimizations ===
Debug level : basic
Optimization level : standard
Architecture : intel_xeon

=== Multicore ===
Parallel build : /home/xbq/local/
Parallel I/O :
openMP support : no
GPU support :

=== Connectors / Fallbacks ===
LINALG flavor : openblas
FFT flavor : fftw3
HDF5 : yes
NetCDF : yes
NetCDF Fortran : yes
LibXC : yes
Wannier90 : no

=== Experimental features ===
Exports :
GW double-precision :

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Default optimizations:
-O2 -mtune=native -march=native

Optimizations for 43_ptgroups:
-O0

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

gmatteo · Post by **gmatteo** » Wed Jan 20, 2021 12:35 am

#5 0x7fdce98e909a in ???
#6 0x55f5910f5d03 in __m_cgtools_MOD_cg_zgemv
at ../../../src/44_abitools/m_cgtools.F90:898

This part of the backtrace indicates that SIGILL is raised by ZGEMV (matrix-vector multiplication provided by openblas).
I would suggest to recheck the compilation of openblas and the flags passed to the compiler. You may want to disable architecture-dependent optimization flags.

From https://docs.abinit.org/tutorial/compil ... leshooting

If the code raises the SIGILL signal, it means that the CPU attempted to execute an instruction it didn’t understand. Very likely, your executables/libraries have been compiled for the wrong architecture. This may happen on clusters when the CPU family available on the frontend differs from the one available on the compute node and aggressive optimization options (-O3, -march, -xHost, etc) are used. Removing the optimization options and using the much safer -O2 level may help. Alternatively, one can configure and compile the source directly on the compute node or use compilation options compatible both with the frontend and the compute node (ask your sysadmin for details).

xbai33 · Post by **xbai33** » Wed Jan 20, 2021 2:49 pm

Thank you very much for your reply. It is indeed a problem with running Openblas in virtualbox. I recompiled it with "make -j2 TARGET=SANDYBRIDGE". The program can now finish the calculation, but a different error occurs with IO. Please see the error information below. I can't find anything about this error about "H5ACmpio.c" on the internet. Do you have some idea what might cause this?

fftdatar_write: About to write data to: testin_fasto_TIM1_DEN with iomode: IO_MODE_FORTRAN
IO operation completed. cpu: 0.00 [s] , wall: 0.00 [s] <<< TIME
abinit: H5ACmpio.c H5AC__log_moved_entry: Assertion `!entry_dirty' failed.

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0 0x7f94d04b0d01 in ???
#1 0x7f94d04afed5 in ???
#2 0x7f94d00e620f in ???
#3 0x7f94d00e618b in ???
#4 0x7f94d00c5858 in ???
#5 0x7f94d00c5728 in ???
#6 0x7f94d00d6f35 in ???
#7 0x7f94cfa1739e in H5AC__log_moved_entry
at /home/xbai33/local/src/hdf5-1.12.0/src/H5ACmpio.c:1100
#8 0x7f94cf5d0c22 in H5AC_move_entry
at /home/xbai33/local/src/hdf5-1.12.0/src/H5AC.c:1100
#9 0x7f94cf77f61f in H5HF__man_iblock_root_double
at /home/xbai33/local/src/hdf5-1.12.0/src/H5HFiblock.c:580
#10 0x7f94cf778b37 in H5HF__hdr_update_iter
at /home/xbai33/local/src/hdf5-1.12.0/src/H5HFhdr.c:1055
#11 0x7f94cf775ec4 in H5HF__man_dblock_new
at /home/xbai33/local/src/hdf5-1.12.0/src/H5HFdblock.c:397
#12 0x7f94cf785bde in H5HF__man_insert
at /home/xbai33/local/src/hdf5-1.12.0/src/H5HFman.c:137
#13 0x7f94cf7623a9 in H5HF_insert
at /home/xbai33/local/src/hdf5-1.12.0/src/H5HF.c:394
#14 0x7f94cf73bee0 in H5G__dense_insert
at /home/xbai33/local/src/hdf5-1.12.0/src/H5Gdense.c:426
#15 0x7f94cf7556fd in H5G_obj_insert
at /home/xbai33/local/src/hdf5-1.12.0/src/H5Gobj.c:594
#16 0x7f94cf7b0773 in H5L__link_cb
at /home/xbai33/local/src/hdf5-1.12.0/src/H5L.c:1887
#17 0x7f94cf760f39 in H5G__traverse_real
at /home/xbai33/local/src/hdf5-1.12.0/src/H5Gtraverse.c:629
#18 0x7f94cf761d21 in H5G_traverse
at /home/xbai33/local/src/hdf5-1.12.0/src/H5Gtraverse.c:854
#19 0x7f94cf7a8118 in H5L__create_real
at /home/xbai33/local/src/hdf5-1.12.0/src/H5L.c:2044
#20 0x7f94cf7b27ce in H5L_link_object
at /home/xbai33/local/src/hdf5-1.12.0/src/H5L.c:1803
#21 0x7f94cf67ef6c in H5D__create_named
at /home/xbai33/local/src/hdf5-1.12.0/src/H5Dint.c:410
#22 0x7f94cf9e8816 in H5VL__native_dataset_create
at /home/xbai33/local/src/hdf5-1.12.0/src/H5VLnative_dataset.c:74
#23 0x7f94cf9c1d73 in H5VL__dataset_create
at /home/xbai33/local/src/hdf5-1.12.0/src/H5VLcallback.c:1834
#24 0x7f94cf9cc41d in H5VL_dataset_create
at /home/xbai33/local/src/hdf5-1.12.0/src/H5VLcallback.c:1868
#25 0x7f94cf642aa6 in H5Dcreate2
at /home/xbai33/local/src/hdf5-1.12.0/src/H5D.c:150
#26 0x7f94cff938b8 in ???
#27 0x7f94cff94f5d in ???
#28 0x7f94cff957d9 in ???
#29 0x7f94cff97f76 in ???
#30 0x7f94cff98c3f in ???
#31 0x7f94cff986c4 in ???
#32 0x7f94cff985ce in ???
#33 0x7f94cff39a26 in ???
#34 0x7f94d07d0424 in __netcdf_MOD_nf90_enddef
at /home/xbai33/local/src/netcdf-fortran-4.5.3/fortran/netcdf_file.f90:82
#35 0x7f94d28273e1 in __m_nctk_MOD_nctk_set_datamode
at ../../../../../shared/common/src/27_toolbox_oop/m_nctk.F90:1020
#36 0x7f94d2830845 in __m_nctk_MOD_nctk_defnwrite_dpvars
at ../../../../../shared/common/src/27_toolbox_oop/m_nctk.F90:1898
#37 0x7f94d22eb6b8 in __m_energies_MOD_energies_ncwrite
at ../../../src/44_abitypes_defs/m_energies.F90:619
#38 0x7f94d22eeb74 in __m_results_gs_MOD_results_gs_ncwrite
at ../../../src/44_abitypes_defs/m_results_gs.F90:780
#39 0x7f94d1578cc3 in __m_outscfcv_MOD_outscfcv
at ../../../src/94_scfcv/m_outscfcv.F90:619
#40 0x7f94d15631df in __m_scfcv_core_MOD_scfcv_core
at ../../../src/94_scfcv/m_scfcv_core.F90:2165
#41 0x7f94d1559f7e in scfcv_scfcv
at ../../../src/94_scfcv/m_scfcv.F90:712
#42 0x7f94d1552085 in __m_mover_MOD_mover
at ../../../src/95_drive/m_mover.F90:604
#43 0x7f94d1543b6b in __m_gstate_MOD_gstate
at ../../../src/95_drive/m_gstate.F90:1297
#44 0x7f94d144d7de in __m_gstateimg_MOD_gstateimg
at ../../../src/95_drive/m_gstateimg.F90:562
#45 0x7f94d1439f40 in __m_driver_MOD_driver
at ../../../src/95_drive/m_driver.F90:783
#46 0x7f94d1427425 in abinit
at ../../../src/98_main/abinit.F90:391
#47 0x7f94d142cf3c in main
at ../../../src/98_main/abinit.F90:88

xbai33 · Post by **xbai33** » Wed Jan 20, 2021 11:32 pm

Dear Gmatteo,

Thank you very much for you input. It is a problem with Openblas on virtualbox. After some search, I found that in order for Openblas to function properly, the "TARGET" option needs to be specified. Following command works for me

make -j2 TARGET=SANDYBRIDGE

I then encountered a second problem related to IO. The error message is shown below. After some pain, I figured out that the error occurs because the most recent version of hdf5 1.12.0 was used. After reverting to an earlier version of 1.10.7, everything runs smoothly. Current tutorial does not indicate what version of hdf5 was used. It would be great to add that information and help other new users avoid this issue. Thank you~

abinit: H5ACmpio.c H5AC__log_moved_entry: Assertion `!entry_dirty' failed.

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0 0x7ffff3bc33ff in ???
#1 0x7ffff3bc3387 in ???
#2 0x7ffff3bc4a77 in ???
#3 0x7ffff3bbc1a5 in ???
#4 0x7ffff3bbc251 in ???
#5 0x7ffff629bf3b in H5AC__log_moved_entry
at /storage/home/hcoda1/8/xbai33/p-mmourigal6-0/local/src/hdf5-1.12.0/src/H5ACmpio.c:1100
#6 0x7ffff5e70e89 in H5AC_move_entry

Post by **jbeuken** » Sat Jan 23, 2021 10:48 am

Hi,

You can find this information :

1) on the ABINIT website :

https://www.abinit.org/fallbacks

2) in the tarball : config/specs/fbversion.conf

Code: Select all

[9.2]
atompaw = 4.1.0.6
bigdft = abinit-1.7.1.28
hdf5 = 1.10.6
libpsml = 1.1.7
libxc = 4.3.4
lapack = abinit_6.10
netcdf4 = 4.6.3
netcdf4_fortran = 4.5.2
wannier90 = 2.0.1.1
xmlf90 = 1.5.3.1

Best,
jmb

mverstra · Post by **mverstra** » Mon May 03, 2021 5:30 pm

Hi all,

it's very strange that the hdf small version is not backwards compatible. I have encountered the same thing on an old cluster of ours with the (new) hdf 1.12 and netcdf 4.7.4. They should ensure API and binary compatibility at least until version 2!

ABINIT Discussion Forums

Running Abinit in virtual box Ubuntu [SOLVED]

Running Abinit in virtual box Ubuntu [SOLVED]

Re: Running Abinit in virtual box Ubuntu

Re: Running Abinit in virtual box Ubuntu

Re: Running Abinit in virtual box Ubuntu

Re: Running Abinit in virtual box Ubuntu

Re: Running Abinit in virtual box Ubuntu