vasp 6.5.1 & intel-onapi 2025.3.1.55

[michaela._fechner]

Dear vasp users,

I currently experimenting to compile vasp 6.5.1 with intel-onapi 2025.3.1.55, I am aware that this is not in the current toolchain of vasp. However, since intel does not give a download for the HPC toolkit 2024 anymore, I give it a try.

So far compilation runs smooth using "makefile.include.oneapi" no problem also most tests run fine and also my calculation. If I switch to the "makefile.include.oneapi_omp", again compiles fine and also same set of tests runs fine.
But now the issue once I try a production calculation with a ''moderate'' load I always end up in segmentation "issues" (see below).

So my question is this a known issues and does anybody has some hints?

best wishes
Michael

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
libc.so.6 00007F80FBC25DF0 Unknown Unknown Unknown
vasp_std 0000000000B04680 Unknown Unknown Unknown
libiomp5.so 00007F810754FDC9 __kmp_invoke_micr Unknown Unknown
libiomp5.so 00007F81074CA03B __kmp_fork_call Unknown Unknown
libiomp5.so 00007F810748BE00 __kmpc_fork_call Unknown Unknown
vasp_std 0000000000AD0CED Unknown Unknown Unknown
vasp_std 0000000000AD25D6 Unknown Unknown Unknown
vasp_std 0000000001D09305 Unknown Unknown Unknown
vasp_std 000000000040CA2D Unknown Unknown Unknown
libc.so.6 00007F80FBC0FCA8 Unknown Unknown Unknown
libc.so.6 00007F80FBC0FD65 __libc_start_main Unknown Unknown
vasp_std 000000000040C941 Unknown Unknown Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
libc.so.6 00007F0593E25DF0 Unknown Unknown Unknown
vasp_std 0000000000B04680 Unknown Unknown Unknown
libiomp5.so 00007F059F74FDC9 __kmp_invoke_micr Unknown Unknown
libiomp5.so 00007F059F6CA03B __kmp_fork_call Unknown Unknown
libiomp5.so 00007F059F68BE00 __kmpc_fork_call Unknown Unknown
vasp_std 0000000000AD0CED Unknown Unknown Unknown
vasp_std 0000000000AD25D6 Unknown Unknown Unknown
vasp_std 0000000001D09305 Unknown Unknown Unknown
vasp_std 000000000040CA2D Unknown Unknown Unknown
libc.so.6 00007F0593E0FCA8 Unknown Unknown Unknown
libc.so.6 00007F0593E0FD65 __libc_start_main Unknown Unknown
vasp_std 000000000040C941 Unknown Unknown Unknown

[ahampel]

Hi Michael,

we did not update the toolchains yet for VASP 6.5.1 on the wiki since these are actually the toolchains the testsuite was run on. However, for our nightly testsuite runs of the current development branch we are actually already using intel oneapi 2025.3.2, intel-oneapi-mkl/2025.3.1-omp, and most importantly, intel-oneapi-mpi/2021.17.2 . Which MPI version are you using? We are aware of a bug that affects MPI reductions on intel mpi in version 2021.16.2 or earlier. This could maybe line up with your problems. For us the full testsuite and also larger workloads ( I tested a PBE0 run on 256 Si atoms, and a standard PBE run on 348 atoms) worked fine so far.

Could you maybe also share some input files? Maybe I can cross-check this. But let's first compare MPI versions.

Best,
Alex

[michaela._fechner]

Moin Alex,

Thanks for having a look at this. I am using intel-oneapi-hpc-toolkit-2025.3.1.55, but I noticed that my issue was more related to the cluster configuration. I tried running the same job on a second cluster and did not encounter the issue there.

It turns out that KMP_STACKSIZE has to be set, and then everything works fine and my jobs run as expected. Interestingly, this is not required when compiling with gcc.

So I would say the problem is solved.

[ahampel]

Moin Michael

ah yes that also fits this problem. In general for OMP enabled jobs and builds of VASP it is recommended to set this (https://www.vasp.at/wiki/Combining_MPI_and_OpenMP) . Intel also accepts export OMP_STACKSIZE=1024m . Just put this in all your job scripts etc. I always tend to forget about this issue for real world loads. The problem is that his is under the hood different for gcc and intel.

I think we cannot reliably detect if the stacksize has been set by the user on runtime. But I will kick-off a discussion.

Best,
Alex