VASP Forum

Dear developers,
I got a bug when doing transport calculations on VASP-6.6.0, so the calculation stopped.
Could you please help me to figure out what it is and how I can fix it?
I am not sure if it is an error due to the input file or due to a memory issue.
I attached the input files below for your reference.

I appreciate your support very much
Benjamin
------------------------------------------------------
[compute-3-2:13040] osc_ucx_component.c:375 Error: OSC UCX component priority set inside component query failed

-----------------------------------------------------------------------------
| _ ____ _ _ _____ _ |
| | | | _ \ | | | | / ____| | | |
| | | | |_) | | | | | | | __ | | |
| |_| | _ < | | | | | | |_ | |_| |
| _ | |_) | | |__| | | |__| | _ |
| (_) |____/ \____/ \_____| (_) |
| |
| internal error in: wave_window.F at line: 469 |
| |
| Invalid rank 0 ib: 7 ik: 8 is: 1 |
| |
| If you are not a developer, you should not encounter this problem. |
| Please submit a bug report. |
| |
-----------------------------------------------------------------------------
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
Proc: [[60449,1],0]
Errorcode: 1

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
prterun has exited due to process rank 0 with PID 0 on node compute-3-2 calling
"abort". This may have caused other processes in the application to be
terminated by signals sent by prterun (as reported here).
--------------------------------------------------------------------------

After rechecking, I suppose it might be related to a parallel issue.
The calculation got such an error since I used "mpirun -np 16".
The error is solved by switching to a serial calculation.

Any suggestion to solve this parallel issue is appreciated.

Many thanks,
Benjamin

The issue here is the usage of ELPH_KPAR=1.
This tag is not documented in our wiki because it is not a fully suported feature.
The solution to run your calculation in parallel should be to not set ELPH_KPAR in the INCAR file.

That being said, I will look into fixing this issue in an upcoming release.
Thank you for reporting it.
Let me know if removing it still does not fix your issue.

Thank you for your suggestion.
However, the problem of parallel calculation can not be solved by removing the tag.
The error shown as below:

------------------------------------------------------------------------------
-----------------------------------------------------------------------------
| _ ____ _ _ _____ _ |
| | | | _ \ | | | | / ____| | | |
| | | | |_) | | | | | | | __ | | |
| |_| | _ < | | | | | | |_ | |_| |
| _ | |_) | | |__| | | |__| | _ |
| (_) |____/ \____/ \_____| (_) |
| |
| internal error in: wave_window.F at line: 232 |
| |
| Displacement too large |
| |
| If you are not a developer, you should not encounter this problem. |
| Please submit a bug report. |
| |
-----------------------------------------------------------------------------

STOP 1
STOP 1
STOP 1
STOP 1
STOP 1
STOP 1
STOP 1
STOP 1
STOP 1
STOP 1
STOP 1
STOP 1
STOP 1
--------------------------------------------------------------------------
prterun detected that one or more processes exited with non-zero status,
thus causing the job to be terminated. The first process to do so was:

Process name: [prterun-compute-3-0-26244@1,6]
Exit code: 1

Running your calculation without ELPH_KPAR=1 set worked in my case (I tested with 4 mpi ranks).
In order to be able to help you further, could you provide some more details about your run like how many MPI ranks are you using and which toolchain?

Thank you.

Originally, I used openmpi 5.0 + gcc tool chain 13.4.0 + mkl 2026.0
This gives the error in the first post.

I changed to openmpi 4.1.6 + gcc tool chain 13.4.0 + mkl 2026.0.
This combination is now working.

And you are right, I think that ELPH_KPAR=1 is problematic.