Atomization energy problem

[jber]

Hi,

the problem is that the maximal jumps in energy from changing the number of bands
reach 0.005 eV = 0.01 kcal/mol per atom, and don't converge with large number of bands (up to 35).
I noticed it happens at least for C, O, F, Si, Cl atoms (maybe others).
When calculating atomization energies of larger molecules one can easily get larger errors.

A longer story: i'm trying to reproduce results from DOI: 10.1063/1.1926272.
The article mentions 0.46 kcal/mol agreement between vasp and gaussian PBE results on G2_1 set.
I see strange total energy jumps when changing the number of bands.
This seems to happen only for isolated atoms. I have tested both F and F_h potentials,
with vasp.5.2.11 18Jan11 complex on CentOS5 x86_64 AMD opteron, gfortran 4.1.2, openmpi 1.3.3, acml 4.0.1,
and vasp.5.2.2 15Apr09 complex on CentOS5 x86_64 Intel Xeon, ifort 11.1.072, openmpi 1.3.3, acml 4.4.0,
run in parallel on 4 or 8 cores, and in serial.
Both executables give the same overall behaviour, with few exceptions when energies differ.

This is illustrated by the results below for F_h, with several eigensolvers available in vasp
and with LDIAG = .TRUE. or .FALSE.
Run the example with run.sh (the whole takes ~2 days, so check just few numbers of bands)
and extract results with results.sh. Relevant vasp input files attached.

The question is: do you see the same behaviour on your vasp installations?
If so, what would be the recommended way of calculating energies of atoms in vasp?
Please attach INCAR.

Best regards

Code: Select all

INCAR?test
?SIGMA?=?0.000000
?NELECT?=?7.000000
?EDIFF?=?1.00e-08
?PREC?=?high
?NBANDS?=?15
?ISMEAR?=?-1
?NUPDOWN?=?1
?NPAR?=?1
?LASPH?=?.TRUE.
?ADDGRID?=?.FALSE.
?LPLANE?=?.FALSE.
?LSCALAPACK?=?.FALSE.
?ISPIN?=?2
?MAGMOM?=?1*1.0000?
?LDIAG?=?.TRUE.
?ALGO?=?Normal

Code: Select all

KPOINTS?test
0
Monkhorst-Pack
1?1?1?
0?0?0

Code: Select all

?F?
?1.0000000000000000
????12.0000000000000000????0.0000000000000000????0.0000000000000000
?????0.0000000000000000???12.0100000000000016????0.0000000000000000
?????0.0000000000000000????0.0000000000000000???12.0199999999999996
???1
Cartesian
??6.0000000000000000??6.0050000000000008??6.0099999999999998

Code: Select all

No?of?bands?->?TOTEN:?LDIAG?=?.TRUE.?(NaN?in?OUTCAR?);?LDIAG?=?.FALSE.?(NaN?in?OUTCAR?)
Normal
04:?????????-0.790025?eV,?OK;?????????-0.790066?eV,?OK
05:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
06:?????????-0.790024?eV,?OK;?????????-0.790024?eV,?OK
07:?????????-0.790024?eV,?OK;?????????-0.790024?eV,?OK
08:?????????-0.790066?eV,?OK;?????????-0.790066?eV,?OK
09:?????????-0.790024?eV,?OK;?????????-0.790024?eV,?OK
10:?????????-0.790066?eV,?OK;?????????-0.790024?eV,?OK
11:?????????-0.790066?eV,?OK;?????????-0.790024?eV,?OK
12:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
13:?????????-0.790066?eV,?OK;?????????-0.790024?eV,?OK
14:?????????-0.789735?eV,?OK;?????????-0.790024?eV,?OK
15:?????????-0.789735?eV,?OK;?????????-0.790066?eV,?OK
20:?????????-0.789735?eV,?OK;?????????-0.790066?eV,?OK
25:?????????-0.790066?eV,?OK;?????????-0.789735?eV,?OK
30:?????????-0.790024?eV,?OK;?????????-0.789735?eV,?OK
35:?????????-0.790066?eV,?OK;?????????-0.789735?eV,?OK
VeryFast
04:?????????80.638803?eV,?OK;?????????83.039021?eV,?OK
05:?????????44.617975?eV,?OK;?????????36.570190?eV,?OK
06:?????????36.557698?eV,?OK;?????????38.534380?eV,?OK
07:?????????12.947947?eV,?OK;?????????12.953125?eV,?OK
08:?????????12.947840?eV,?OK;?????????12.947840?eV,?OK
09:?????????-0.790024?eV,?OK;?????????-0.790025?eV,?OK
10:?????????-0.790024?eV,?OK;?????????-0.790066?eV,?OK
11:?????????-0.790066?eV,?OK;?????????-0.790066?eV,?OK
12:?????????-0.790024?eV,?OK;?????????-0.790024?eV,?OK
13:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
14:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
15:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
20:?????????-0.790024?eV,?OK;?????????-0.790025?eV,?OK
25:?????????-0.789735?eV,?OK;?????????-0.790066?eV,?OK
30:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
35:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
Fast
04:?????????-0.790024?eV,?OK;?????????-0.790024?eV,?OK
05:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
06:?????????-0.790024?eV,?OK;?????????-0.790024?eV,?OK
07:?????????-0.790024?eV,?OK;?????????-0.790024?eV,?OK
08:?????????-0.790066?eV,?OK;?????????-0.790066?eV,?OK
09:?????????-0.790024?eV,?OK;?????????-0.790024?eV,?OK
10:?????????-0.790066?eV,?OK;?????????-0.790066?eV,?OK
11:?????????-0.790066?eV,?OK;?????????-0.790066?eV,?OK
12:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
13:?????????-0.790066?eV,?OK;?????????-0.790066?eV,?OK
14:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
15:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
20:?????????-0.789735?eV,?OK;?????????-0.789735?eV,?OK
25:?????????-0.790066?eV,?OK;?????????-0.790066?eV,?OK
30:?????????-0.790024?eV,?OK;?????????-0.790024?eV,?OK
35:?????????-0.790066?eV,?OK;?????????-0.790066?eV,?OK
Conjugate
04:?Failed,?;?????????-0.790024?eV,?OK
05:?Failed,?;?????????-0.789735?eV,?OK
06:?Failed,?;?????????-0.790024?eV,?OK
07:?Failed,?;?????????-0.790024?eV,?OK
08:?Failed,?;?????????-0.790066?eV,?OK
09:?Failed,?;?????????-0.789735?eV,?OK
10:?Failed,?;?????????-0.790024?eV,?OK
11:?Failed,?;?????????-0.790066?eV,?OK
12:?Failed,?;?????????-0.789735?eV,?OK
13:?Failed,?;?????????-0.790066?eV,?OK
14:?Failed,?;?????????-0.789735?eV,?OK
15:?Failed,?;?????????-0.789735?eV,?OK
20:?Failed,?;?????????-0.789735?eV,?OK
25:?Failed,?;?????????-0.790066?eV,?OK
30:?Failed,?;?????????-0.790024?eV,?OK
35:?Failed,?;?????????-0.790066?eV,?OK
All
04:?Failed,?;?????????-0.790024?eV,?OK
05:?Failed,?;?????????-0.789735?eV,?OK
06:?Failed,?;?????????-0.790024?eV,?OK
07:?Failed,?;?????????-0.790024?eV,?OK
08:?Failed,?;?????????-0.790066?eV,?OK
09:?Failed,?;?????????-0.789735?eV,?OK
10:?Failed,?;?????????-0.790024?eV,?OK
11:?Failed,?;?????????-0.790066?eV,?OK
12:?Failed,?;?????????-0.789735?eV,?OK
13:?Failed,?;?????????-0.790066?eV,?OK
14:?Failed,?;?????????-0.789735?eV,?OK
15:?Failed,?;?????????-0.789735?eV,?OK
20:?Failed,?;?????????-0.789735?eV,?OK
25:?Failed,?;?????????-0.790066?eV,?OK
30:?Failed,?;?????????-0.790024?eV,?OK
35:?Failed,?;?????????-0.790066?eV,?OK
Damped
04:?????????-0.790066?eV,?NaN;?????????-0.790066?eV,?OK
05:?????????-0.790066?eV,?NaN;?????????22.242929?eV,?OK
06:?????????-0.790025?eV,?NaN;??????????9.711788?eV,?OK
07:?????????-0.790025?eV,?NaN;?????????10.477905?eV,?OK
08:?????????-0.790025?eV,?NaN;?????????10.466385?eV,?OK
09:?????????-0.790025?eV,?NaN;?????????11.929748?eV,?OK
10:?????????-0.790066?eV,?NaN;??????????6.194233?eV,?OK
11:?????????-0.790066?eV,?NaN;?????????11.608795?eV,?OK
12:?????????-0.790025?eV,?NaN;??????????6.188213?eV,?OK
13:?????????-0.790025?eV,?NaN;?????????11.594491?eV,?OK
14:?????????-0.790066?eV,?NaN;?????????-0.790066?eV,?OK
15:?????????-0.790066?eV,?NaN;?????????-0.790066?eV,?OK
20:?????????-0.790066?eV,?NaN;?????????-0.790066?eV,?OK
25:?????????-0.790066?eV,?NaN;?????????-0.790066?eV,?OK
30:?????????-0.790066?eV,?NaN;?????????-0.790066?eV,?OK
35:?????????-0.790066?eV,?NaN;?????????-0.790066?eV,?OK

run.sh

Code: Select all

#!/bin/sh

nbands="04?05?06?07?08?09?10?11?12?13?14?15?20?25?30?35"
algos="Normal?VeryFast?Fast?Conjugate?All?Damped"

for?n?in?${nbands};
??do
??for?a?in?${algos};
????do
????cp?-pf?F.orig/*?.
????sed?-i?"s/15/${n}/"?INCAR
????sed?-i?"s/Normal/${a}/"?INCAR
????mpiexec?vasp
????rm?-f?CHG?CHGCAR?WAVECAR
????mv?OUTCAR?${n}_${a}.OUTCAR
????mv?OSZICAR?${n}_${a}.OSZICAR
????#
????sed?-i?"s/LDIAG?=.*/LDIAG?=?.FALSE./"?INCAR
????mpiexec?vasp
????rm?-f?CHG?CHGCAR?WAVECAR
????mv?OUTCAR?${n}_${a}.OUTCAR.LDIAG_FALSE
????mv?OSZICAR?${n}_${a}.OSZICAR.LDIAG_FALSE
??done
done

results.sh

Code: Select all

#!/bin/sh

nbands="04?05?06?07?08?09?10?11?12?13?14?15?20?25?30?35"
algos="Normal?VeryFast?Fast?Conjugate?All?Damped"

echo?"No?of?bands?->?TOTEN:?LDIAG?=?.TRUE.?(NaN?in?OUTCAR?);?LDIAG?=?.FALSE.?(NaN?in?OUTCAR?)"
for?a?in?${algos};
??do
??echo?${a}
??for?n?in?${nbands};
????do
????energy=`grep?"free??energy???TOTEN"?${n}_${a}*.OUTCAR?|?cut?-d"="?-f?2`
????if?test?-z?"${energy}";
????????then
????????energy=Failed
????fi
????warning=`grep?"NaN"?${n}_${a}*.OUTCAR`
????if?!?test?-z?"${warning}";
????????then
????????warning=NaN
????else
????????if?[?"${energy}"?==?"Failed"?];
????????????then
????????????warning=''
????????else
????????????warning=OK
????????fi
????fi
????energy_ldiag_false=`grep?"free??energy???TOTEN"?${n}_${a}*.OUTCAR.LDIAG_FALSE?|?cut?-d"="?-f?2`
????if?test?-z?"${energy_ldiag_false}";
????????then
????????energy_ldiag_false=Failed
????fi
????warning_ldiag_false=`grep?"NaN"?${n}_${a}*.OUTCAR.LDIAG_FALSE`
????if?!?test?-z?"${warning_ldiag_false}";
????????then
????????warning_ldiag_false=NaN
????else
????????if?[?"${energy_ldiag_false}"?==?"Failed"?];
????????????then
????????????warning_ldiag_false=''
????????else
????????????warning_ldiag_false=OK
????????fi
????fi
????echo?"${n}:?${energy},?${warning};?${energy_ldiag_false},?${warning_ldiag_false}"
??done
done

[jber]

In the code section please replace each ? (question mark) by a space.
By the way in the preview mode the post looked right, apart from 2 apparently unavoidable line breaks in results.sh

[jber]

Additional information: the same problem for LDA.

[jber]

I have just created a cross reference to this post under bugreports:
http://cms.mpi.univie.ac.at/vasp-forum/ ... .9782#9782
Maybe vasp developers could have a look at this?

[jber]

I have just tested that setting ISYM = 0 in INCAR does not solve the problem.
Any ideas?

[jber]

Trying to decrease EBREAK (which dangerously depends on the number of bands,
see http://cms.mpi.univie.ac.at/vasp/vasp/W ... _tags.html)
does not help.
In the OUTCAR the first significant difference when running with different number of bands appears at related lines:
"eigenvalue-minimisations :"
"total energy-change (2. order) :"
"eigenvalues EBANDS ="
The latter differs by up to 0.3 eV in the first step.

[jber]

One solution: setting DEPER = 0.01 reduces the problem in most cases, but playing with this parameter can introduce some instabilities for large number of bands.
Still, the lack of response on the forum is a bit surprising.

[admin]

I cannot reproduce this behaviour (using standard Gaussian BZ integration however, the total energies are constant up to the 6th digit, independent of the choice of NBANDS), but please note that the smearing with should never be set to 0, but to some small value like 0.001.

[jber]

Thanks, however on my the system
the default gaussian broadening (ISMEAR = 0) does not help.
Energy still depends on the number of bands.
Here are the results for standard PAW_PBE F 08Apr2002 potential
with algo = Normal and SIGMA = 0.001:
No of bands -> TOTEN: LDIAG = .TRUE.; LDIAG = .FALSE.
04: -0.429320 eV; -0.764492 eV
05: -0.764492 eV; -0.764492 eV
06: -0.770285 eV; -0.770285 eV
07: -0.764492 eV; -0.770285 eV
08: -0.764492 eV; -0.770285 eV
09: -0.764492 eV; -0.770241 eV
10: -0.770285 eV; -0.770285 eV
11: -0.764473 eV; -0.770285 eV
12: -0.764492 eV; -0.770285 eV
13: -0.770285 eV; -0.770285 eV
14: -0.770285 eV; -0.770285 eV
15: -0.764492 eV; -0.764473 eV
20: -0.770283 eV; -0.770285 eV
25: -0.770285 eV; -0.764492 eV
30: -0.764492 eV; -0.770285 eV
35: -0.764492 eV; -0.764492 eV
and INCAR:
SIGMA = 0.001000
ISMEAR = 0
NELECT = 7.000000
EDIFF = 1.00e-08
PREC = high
NBANDS = 15
NUPDOWN = 1
NPAR = 1
LASPH = .TRUE.
ADDGRID = .FALSE.
LPLANE = .FALSE.
LSCALAPACK = .FALSE.
ISPIN = 2
MAGMOM = 1*1.0000
LDIAG = .TRUE.
ALGO = Normal

The other input files (KPOINTS, POSCAR) are as at the top of the thread.

[jber]

Could someone on the forum try it out?
All the input files are provided.
Is it a general problem, an installation issue (would be strange as I have two different vasp versions compiled with intel and gfortran compilers),
or still something bad in the INCAR?

[jber]

Another observation: setting LASPH = .FALSE. improves the situation significantly:
No of bands -> TOTEN: LDIAG = .TRUE.; LDIAG = .FALSE.
04: -0.702515 eV, OK; -0.702515 eV, OK
05: -0.702513 eV, OK; -0.702513 eV, OK
06: -0.702515 eV, OK; -0.702515 eV, OK
07: -0.702513 eV, OK; -0.702513 eV, OK
08: -0.702513 eV, OK; -0.702513 eV, OK
09: -0.702513 eV, OK; -0.702513 eV, OK
10: -0.702515 eV, OK; -0.702515 eV, OK
11: -0.702494 eV, OK; -0.702494 eV, OK
12: -0.702513 eV, OK; -0.702513 eV, OK
13: -0.702515 eV, OK; -0.702515 eV, OK
14: -0.702515 eV, OK; -0.702515 eV, OK
15: -0.702513 eV, OK; -0.702513 eV, OK
20: -0.702513 eV, OK; -0.702513 eV, OK
25: -0.702515 eV, OK; -0.702515 eV, OK
30: -0.702513 eV, OK; -0.702513 eV, OK
35: -0.702513 eV, OK; -0.702513 eV, OK

The differences LDIAG TRUE/FALSE also disappear.
DOI: 10.1063/1.1926272 explicitly states LASPH = .TRUE. for atoms.
Note how different are the total energies LASPH TRUE/FALSE.
Are we getting closer to pin-point the problem?
I'm really surprised by no participation of the users on the forum in the thread, apart from admin.

[jber]

I have run tests with vasp.5.2.12/gfortran-4.1.2/acml-4.0.1, opteron machine, PAW_PBE F 08Apr2002,
and get the following results:
No of bands: TOTEN (eV)
05: -0.764799
06: -0.765562
07: -0.764799
08: -0.764799
09: -0.764799
10: -0.765562
11: -0.764779
12: -0.764799
13: -0.765562
14: -0.765562
15: -0.764798
20: -0.765562
25: -0.765562
30: -0.764799
35: -0.764799

The inputs are as follows:

INCAR test
SIGMA = 0.001000
ISMEAR = 0
NELECT = 7.000000
EDIFF = 1.00e-08
PREC = high
NBANDS = 15
NUPDOWN = 1
NPAR = 1
LASPH = .TRUE.
ADDGRID = .FALSE.
LPLANE = .FALSE.
LSCALAPACK = .FALSE.
ISPIN = 2
MAGMOM = 1*1.0000
LDIAG = .TRUE.
ALGO = Normal

F
1.0000000000000000
12.0000000000000000 0.0000000000000000 0.0000000000000000
0.0000000000000000 12.0100000000000016 0.0000000000000000
0.0000000000000000 0.0000000000000000 12.0199999999999996
1
Cartesian
6.0000000000000000 6.0050000000000008 6.0099999999999998

KPOINTS test
0
Monkhorst-Pack
1 1 1
0 0 0

I can't provide you with the original formatting of inputs due to:
http://cms.mpi.univie.ac.at/vasp-forum/ ... hp?3.10252
Just make sure that you get correct "positions in cartesian coordinates" in the OUTCAR.

[Dr_Nick]

I can fully reproduce your results for NBANDS = 5 to 35 with the following builds:

VASP 5.2.12 on AMD Opteron:
- gcc 4.3.3 / ACML 4.4.0 / FFTW v3.3
- gcc 4.3.3 / gotoblas2 1.06 / FFTW v3.3

VASP 5.2.12 on Intel Xeon:
- Intel 12.0.3 / MKL / Intel FFTW

As a side note, I also made a test with VASP 4.6.38 on the Xeon (Intel 12.0.3 / MKL / Intel FFTW). The TOTEN values for "Aspherical result" are given here:

05: -0.764726 eV
06: -0.765151 eV
07: -0.764726 eV
08: -0.764727 eV
09: -0.764726 eV
10: -0.765152 eV
11: -0.764678 eV
12: -0.764726 eV
13: -0.765153 eV
14: -0.765143 eV
15: -0.764723 eV
20: -0.764727 eV
25: -0.765154 eV
30: -0.764727 eV
35: -0.764735 eV

As one can see they differ from the values obtained with 5.2.12.


<span class='smallblacktext'>[ Edited Tue Oct 18 2011, 04:02PM ]</span>

[jber]

Thanks for testing. Even if this is probably not strictly a bug i have reported the issue following "How to report bugs" http://cms.mpi.univie.ac.at/vasp-forum/ ... report.txt

[jber]

Just reporting: more than a month has passed, still haven't received any answer to the submitted bug report.