Wrong Uele for periodic system with large basis

Top Page > Browsing

Wrong Uele for periodic system with large basis

Date: 2017/06/05 00:00
Name: Daniil: Dear all,

I tried to calculate periodic Nb2O5 with rather large basis set and got about twice as large Uele. Here is my input file:
##############################################################################################
System.CurrrentDirectory ./ # default=./
DATA.PATH /home/daniil/openmx3.8_mpigcc/DFT_DATA13 # default=../DFT_DATA13
System.Name nb2o5
level.of.stdout 1 # default=1 (1-3)
level.of.fileout 2 # default=1 (1-3)
Species.Number 2
<Definition.of.Atomic.Species
Nb Nb9.0-s9p8d5f3 Nb_PBE13
O O7.0-s6p5d3f1 O_PBE13
Definition.of.Atomic.Species>
Atoms.Number 28
Atoms.SpeciesAndCoordinates.Unit Ang # Ang|AU
<Atoms.SpeciesAndCoordinates
1 O 4.90721 0.16645 0.26352 3.0 3.0
2 O 3.21395 2.01348 2.07888 3.0 3.0
3 O -0.36093 1.34232 0.48312 3.0 3.0
4 Nb 1.42271 1.33695 1.16144 7.0 6.0
5 O 7.10093 2.51820 0.26352 3.0 3.0
6 O 6.37906 5.20284 4.61648 3.0 3.0
7 O 4.18535 2.85109 4.61648 3.0 3.0
8 O 11.27221 0.16645 2.70352 3.0 3.0
9 O 0.73593 2.51820 2.70352 3.0 3.0
10 O 0.01407 5.20284 2.17648 3.0 3.0
11 O 10.55035 2.85109 2.17648 3.0 3.0
12 O 8.79418 0.67116 2.07888 3.0 3.0
13 O 8.07232 3.35581 2.80112 3.0 3.0
14 O 2.49209 4.69813 2.80112 3.0 3.0
15 O 9.57895 2.01348 4.51888 3.0 3.0
16 O 2.42918 0.67116 4.51888 3.0 3.0
17 O 1.70732 3.35581 0.36112 3.0 3.0
18 O 8.85709 4.69813 0.36112 3.0 3.0
19 O -1.08279 4.02697 4.39688 3.0 3.0
20 O 6.00407 1.34232 2.92312 3.0 3.0
21 O 5.28221 4.02697 1.95688 3.0 3.0
22 Nb 10.58543 1.34769 1.16144 6.5 6.5
23 Nb 9.86357 4.03234 3.71856 6.5 6.5
24 Nb 0.70085 4.02160 3.71856 6.5 6.5
25 Nb 7.78771 1.33695 3.60144 6.5 6.5
26 Nb 4.22043 1.34769 3.60144 6.5 6.5
27 Nb 3.49857 4.03234 1.27856 6.5 6.5
28 Nb 7.06585 4.02160 1.27856 6.5 6.5
Atoms.SpeciesAndCoordinates>
Atoms.UnitVectors.Unit Ang # Ang|AU
<Atoms.UnitVectors
12.73000 0.00000 0.00000
-1.44372 5.36929 0.00000
-0.00000 -0.00000 4.88000
Atoms.UnitVectors>
scf.XcType GGA-PBE # LDA|LSDA
scf.SpinPolarization NC # On|Off
scf.maxIter 1000 # default=40
scf.EigenvalueSolver Band # Recursion|Cluster|Band
scf.Kgrid 3 6 6 # means 4x4x4
scf.Mixing.Type rmm-diisk # Simple|Rmm-Diis|Gr-Pulay
scf.Mixing.History 30
HS.fileout on # on|off, default=off
##############################################################################################

With it I got Uele about -410 (hadn't converged yet).
While with moderate basis:
Nb Nb9.0-s5p4d3f Nb_PBE13
O O7.0-s3p2d1 O_PBE13
Uele was -195.169333981641 and eigenvalues were reasonable.
What could lead to a problem here?

Best regards,
Daniil

Page: [1]

Re: Wrong Uele for periodic system with large basis ( No.1 )

Date: 2017/06/05 05:20
Name: Chris Latham

Hello Daniil,

It looks like the basis set is overcomplete, and has resulted in an unphysical SCF solution. This is a purely numerical problem, and not the fault of OpenMX.

Use a smaller basis.

Best wishes,

Christopher.

Re: Wrong Uele for periodic system with large basis ( No.2 )

Date: 2017/06/05 08:52
Name: Daniil

Hi Chris,

That is obvious assumption, but it looks like that it is not the case. I am now rerunning calculation with "scf.ProExpn.VNA off" and at the first scf step Uele is about -203, which is close to smaller basis result. So that, the problem seems to be in projector expanding, or at least in something related to it. (At the first scf step in the case of smaller basis, Uele was also about -203)

Best regards,
Daniil

Re: Wrong Uele for periodic system with large basis ( No.3 )

Date: 2017/06/05 18:31
Name: Chris Latham

Hello Daniil,

The basis is so enormous that you may still be in trouble. Have you tried increasing scf.energycutoff? However, I think you will be better off making a smaller, optimized basis in the long run. If this solves your problem, then please let us know, and mark the thread as [SOLVED].

Best wishes,

Christopher.

Re: Wrong Uele for periodic system with large basis ( No.4 )

Date: 2017/06/05 21:13
Name: Daniil

Hello Chris,

My calculations are still running, but Uele is already -195.576557939641, so that it is very likely to converge to a value similar to smaller basis result.
So, it is theoretically possible to use such basis sets in Openmx, however, with "scf.ProExpn.VNA off" only.

I checked manual once more and found this node: openmx-square.org/openmx_man3.8/node175.html . So, it is a known problem. Unfortunately, increasing scf.energycutoff also significantly increases memory usage, and for example, value of 500 Ryd leads to out of memory error on my resources.

Best regards,
Daniil

Page: [1]