Bug in running B3LYP with IVDW=12

Problems running VASP: crashes, internal errors, "wrong" results.


Moderators: Global Moderator, Moderator

Post Reply
Message
Author
KWH
Jr. Member
Jr. Member
Posts: 57
Joined: Fri Feb 09, 2018 2:05 am
License Nr.: 5-1063

Bug in running B3LYP with IVDW=12

#1 Post by KWH » Mon Jun 29, 2026 10:22 pm

I encountered a bug in attempting to do a b3lyp with GD3 vdW correction. Attached are all the associated files. How do I fix/get-around this?

You do not have the required permissions to view the files attached to this post.

michael_wolloch
Global Moderator
Global Moderator
Posts: 246
Joined: Tue Oct 17, 2023 10:17 am

Re: Bug in running B3LYP with IVDW=12

#2 Post by michael_wolloch » Tue Jun 30, 2026 3:00 pm

Dear KWH,

I tried to reproduce the bug on a small workstation using an Intel OpenMP compile of version 6.2.0 (as you seem to have) on 8 ranks and 2 threads. The calculation finishes the first SCF cycle normally, but segfaults at the first ionic update (also not good, but different).

However, when I use only one OpenMP thread per rank, the error you observe appears.

Please try again with 4-8 MPI ranks and a couple of OpenMP threads for each rank, and report back. The very large number of MPI ranks you used (124) for such a small system will not speed up the calculation.

As a side note: your setting of NCORE=124 is extremely inefficient. Usually, for an OpenMP compile, it is ignored anyhow and reset to 1 internally, but only if OMP_NUM_THREADS>1. If you are using an OpenMP build, make sure to set OMP_NUM_THREADS to a reasonable value for your system (e.g., 4 to 8 is usually fine), or set NCORE as described in the documentation, to get performant FFTs.

Otherwise, you can try to compile without OpenMP.

I tested a bit with the current release version, 6.6.0, and did not encounter the bug you found, even when running with only 1 thread with the OpenMP version. However, I did sporadically encounter another bug that I will investigate.

Let me know if setting OMP_NUM_THREADS>1 works for you,
Cheers, Michael


KWH
Jr. Member
Jr. Member
Posts: 57
Joined: Fri Feb 09, 2018 2:05 am
License Nr.: 5-1063

Re: Bug in running B3LYP with IVDW=12

#3 Post by KWH » Sat Jul 11, 2026 9:23 pm

Thank you.
I tried to implement your suggestions, but I think I got it wrong. In the submission script I have:
#SBATCH --ntasks=20
#SBATCH --cpus-per-task=4
#SBATCH --mem-per-cpu=7300
### this will commit 80 cpu's to the job
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK

And in the INCCAR file I have
NCORE = 4

And the calculation is for a single k point (1 1 1).

When I try to run this the electronic optimization starts but then end in eror.

[cn187:121052:0:121112] Caught signal 11 (Segmentation fault: address not mapped to object at address 0x14706dc3e000)
[cn187:121049:0:121095] Caught signal 11 (Segmentation fault: address not mapped to object at address 0x14d35eaaa000)
forrtl: severe (154): array index out of bounds
forrtl: severe (154): array index out of bounds
[cn187:121057:0:121128] Caught signal 11 (Segmentation fault: address not mapped to object at address 0x14923c7b3000)
*** longjmp causes uninitialized stack frame ***: terminated
*** longjmp causes uninitialized stack frame ***: terminated
*** longjmp causes uninitialized stack frame ***: terminated
*** longjmp causes uninitialized stack frame ***: terminated
*** longjmp causes uninitialized stack frame ***: terminated
*** longjmp causes uninitialized stack frame ***: terminated
[cn187:121059:0:121092] Caught signal 11 (Segmentation fault: address not mapped to object at address 0x14b6e9d18000)
*** longjmp causes uninitialized stack frame ***: terminated
*** longjmp causes uninitialized stack frame ***: terminated
*** longjmp causes uninitialized stack frame ***: terminated

Can you identify what I am doing wrong and how I should change the INCAR and batch file?


michael_wolloch
Global Moderator
Global Moderator
Posts: 246
Joined: Tue Oct 17, 2023 10:17 am

Re: Bug in running B3LYP with IVDW=12

#4 Post by michael_wolloch » Fri Jul 17, 2026 12:44 pm

Dear KWH,

Sorry for the delay; I somehow missed the notification for that post.

As stated before, NCORE is ignored when you are using the OpenMP version and have OMP_NUM_THREADS>1.

Without the detailed input and output files, it is impossible to reproduce the error you get and debug it. But I did test your calculation again with an Intel compile (2022.0.1 compilers and MKL, 2021.5.0 MPI) of 6.2.0 on 32 cores of an Intel(R) Xeon(R) Platinum 8480+ CPU. I used 8 ranks with 4 threads each. I simplified the INCAR as follows:

Code: Select all

 SYSTEM = phenyl pyridine
# Accuracy controls:
 PREC = ACCURATE
 ENCUT = 500
# Electronic loop controls:
 ALGO = Normal
 EDIFF = 0.5E-5
 NELMIN = 4
 NELMDL = -10
 NELM = 100
 ISMEAR = 0
 SIGMA = 0.1
 LREAL = Auto
 MAXMIX=150
# Relaxation control:
 IBRION = 2
 NSW = 100
 POTIM = 0.500000
 ISIF = 2
 EDIFFG = -0.0250
IDIPOL   = 4
LDIPOL   = .True.
DIPOL = 0.5 0.5 0.5
ISPIN = 1
# Custom options
## B3LYP with vdW
LHFCALC = .TRUE.       # Enable hybrid functional
GGA     = B3           # Select B3LYP definition
AEXX    = 0.2          # 20% HF exchange
AGGAX   = 0.72         # 72% B88 exchange correction
AGGAC   = 0.81         # 81% LYP correlation
ALDAC   = 0.19         # 19% VWN3 LDA correlation
IVDW    = 12           # DFT-D3 with Becke-Johnson damping (Recommended)

Notable changes:

  • switched to ALGO=Normal, which is the default; Usually that works well for hybrids.

  • increased SIGMA to 0.1. You had a very small value, which is usually not necessary and can make convergence harder.

  • removed LPLANE because simpler INCARs are usually better for troublesome calculations. The VASP defaults are well tested and robust.

  • lowered EDIFF a bit to get more accurate forces.

  • increased NELM to give the electronic minimizer more time to converge.

  • Added MAXMIX=150, since ALGO=Normal uses the density mixer, and it is prudent for a relaxation to keep the mixer filled between ionic steps.

  • added dipole corrections as appropriate for a molecule. This might spoil convergence somewhat, but it is a saver option. It turns out that there is no dipole, so you can remove those tags.

With the settings above, I had stable, fast relaxation, although the blocked Davidson was unable to fully converge on the first ionic step within the 100 available steps. The calculation converged in 9 ionic steps, and it took less than 10 minutes.

Please copy my INCAR settings and run on 8 ranks, 4 threads. If this does not work, please send me information about your compilation and the cluster you are running on.

Cheers, Michael


Post Reply