VASP Forum

I have compiled VASP 6.5.0 on a HCP cluster (VSC-5) with HDF5 support.
Problem: When running the testsuite or a small calculation, only 1 core is utilized. "make test" did not finish in a job with 12 h time limit.
I have tried several combinations of modules for the compilation, even excluding HDF5, using "make veryclean" between but the behavior does not change.

The modules I used here should in principle work. At least the system admins installed VASP as a module (without HDF5 and other extras) on the cluster with those:
intel-oneapi-mkl/2024.0.0-gcc-12.2.0 (which loads also intel-mpi/2019.10.317-gcc-12.2.0)
intel-oneapi-compilers/2024.0.0-gcc-12.2.0
hdf5/1.12.2-intel-2021.9.0

In the SLURM script I included:
"export LD_LIBRARY_PATH=/gpfs/opt/sw/zen/spack-0.19.0/opt/spack/linux-almalinux8-zen3/intel-2021.9.0/hdf5-1.12.2-tiadmsp7pkeq5xgsjn7e2cczsmzclxa4/lib:$LD_LIBRARY_PATH"

because I would otherwise get this error: "/home/vasp.6.5.0/testsuite/../bin/vasp_std: error while loading shared libraries: libhdf5_fortran.so.200: cannot open shared object file: No such file or directory"

The tests that finish are correct and in testsuite.log it (at least) says that 4 mpi-ranks are used:
CrS step STD
entering run_vasp
running 4 mpi-ranks, with 1 threads/rank, on 1 nodes
distrk: each k-point on 2 cores, 2 groups
distr: one band on 1 cores, 2 groups
vasp.6.5.0 16Dec24 (build Sep 24 2025 11:55:44) complex

What am I doing wrong here? Thanks in advance.

Best,
Lukas

I attached the relevant files

Dear Lukas,

Thank you for your question.

Could you provide more information about the tests that didn't finish or failed? I understood that the CrS test passed. In principle, the testsuite is run on 4 MPI ranks and it can take a while before the testsuite is finished. Could you provide the testsuite.log file and more detail about this small calculation you are referring to.

because I would otherwise get this error: "/home/vasp.6.5.0/testsuite/../bin/vasp_std: error while loading shared libraries: libhdf5_fortran.so.200: cannot open shared object file: No such file or directory"

This error indicates that when you load the hdf5 module the path to this library is not added. Perhaps the module was not loaded. You can also run

module list

to see what modules are loaded. Or print the LD_LIBRARY_PATH variable to see if the path is included.

Best wishes,
Alexey

Dear Alexey,

thank you for responding.

All tests passed successfully BUT the (default) fast testsuite took 11 hours. Logging onto the assigned node and using "htop" showed that only 1 of 128 CPUs was loaded.
The same issue of only 1 CPU being loaded occurs when using "mpirun -np 128 vasp_std" for other calculations besides the testsuite.

I added the testsuite.log and the LD library path as files.

Just to reiterate how I installed VASP:
1. unpacked the .tar folder
2. "make veryclean" and "module purge" after previous attempts
3. loaded the respective modules on the login node of the cluster
4. on the login node executed "make DEPS=1 -j32 all"

Best regards,

Lukas

Ok, I understood that you see that only a single CPU is being utilized. Do you only see this issue when you compile the code with HDF5 support?

intel-oneapi-mkl/2024.0.0-gcc-12.2.0 (which loads also intel-mpi/2019.10.317-gcc-12.2.0)

It seems strange that the intel-mpi/2019 would be used and not intel-oneapi-mpi-2024. Do you need to load intel-mpi/2019?

Can you please provide the output of the following command?

ldd vasp_std

No, I see the issue also when compiling without HDF5.

I took the combination of modules from the build.txt files that the system admins of the ASC (VSC-5) used to compile available VASP versions.
In those modules, intel-mpi/2019 is a dependency of intel-oneapi-mkl/2024.0.0-gcc-12.2.0.

Here is the output for "ldd bin/vasp_std"

Thanks!
Lukas

Looks like intel-mpi/2019 is not used:

libmpifort.so.12 => /gpfs/opt/sw/zen/spack-0.19.0/opt/spack/linux-almalinux8-zen3/intel-2021.9.0/intel-oneapi-mpi-2021.9.0-35bd42h7l3aobh3owwnblzmdbsbf5vtg/mpi/2021.9.0//lib/libmpifort.so.12 (0x00001457be312000)
libmpi.so.12 => /gpfs/opt/sw/zen/spack-0.19.0/opt/spack/linux-almalinux8-zen3/intel-2021.9.0/intel-oneapi-mpi-2021.9.0-35bd42h7l3aobh3owwnblzmdbsbf5vtg/mpi/2021.9.0//lib/release/libmpi.so.12 (0x00001457bc9c7000)

I think it should not be required in that case.

I took the combination of modules from the build.txt files that the system admins of the ASC (VSC-5) used to compile available VASP versions.

Do you use the same makefile.include as the system admins? Could you please provide your makefile.include?

The makefile.include and build.txt:

:)

Thank you for sending the files.

• I don't see anything incorrect in the way you built VASP. It seems to me that the issue is related to Intel MPI. We have seen that Intel MPI can cause various trouble on AMD machines and it is well optimized for Intel machines and doesn't always work so well on AMD machines.
  Could you also set this environment variable I_MPI_DEBUG=16 and run a calculation where you see this problem and attach the stdout, stderr and OUTCAR from the calculation?

• Have you spoken with the admins of your HPC? They probably know how to build VASP for your environment.

• You could also try to build VASP with GNU compilers and OpenMPI instead of Intel.