I am a new Elk user, myself. I am a bit more familiar with plane-wave pseudopotential codes, and am a developer of BerkeleyGW. (Stop by the forums some time! I try to help out over there.)
I am having difficulty with getting even a "regular" self-consistent calculation of the charge density to complete. I have searched the forums for help, but nothing quite seems to work out. I adapted my input file from the "HSE" example in the "examples" directory, and added some suggested changes based on forum Q&A from past users, with some parameter choices that are more or less consistent with the literature.
The input file is below:
! Hybrid functional example using libxc. Note that the DFT step should be run
! separately with task=0. Then the hybrid step should be run with task=5.
! Example by Tyrel McQueen.
tasks
0
!tasks
! 5
! first run task=0 with PBE...
xctype
100 101 130
!...then uncomment the following and run with task=5 for hybrid GGA
! (note that only the correlation functional is set)
!xctype
! 100 0 406
lmaxo
8
lmaxapw
8
!lmaxo
! 10
!lmaxapw
! 10
trimvg
true
gmaxvr
6.0
ngridk
4 4 4
autolinengy
true
mixtype
3
autoswidth
true
beta0
0.2
nempty
5
avec
16.74318801 0.00000000 0.00000000
0.00000000 16.74318801 0.00000000
0.00000000 0.00000000 11.95989243
Info(elk): several copies of Elk may be running in this path
(this could be intentional, or result from a previous crash,
or arise from an incorrect MPI compilation)
Info(elk): current task : 0
Info(checkmt): reduced muffin-tin radius of species 3 (C) from 1.8000 to 1.3645
Info(checkmt): reduced muffin-tin radius of species 4 (N) from 1.8000 to 1.0971
Info(checkmt): reduced muffin-tin radius of species 5 (H) from 1.4000 to 0.6468
Warning(linengy): could not find 4 linearisation energies in s.c. loop 1
My jobscript makes use of OpenMP parallelization, and I tried to be conscientious about memory usage. I use 1 MPI process, 32 OpenMP processes, across 4 of NERSC's Cori Haswell Nodes (128 GB each).
I use the provided pseudopotential files, without any modifications. From searching around the forums, this may be an issue, though it looks like the code is adjusting the muffin-tin radii of the smaller atoms apropriately.
Any help will be much appreciated.
Thank you very much,
Bradford Barker
Graduate Student, UC Berkeley
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
your system is simply too large for an all electron calculation with 520 electrons.
you should switch back to the pseudo-potential based plane-wave codes,
otherwise it is computationally not feasible.
There is nothing wrong with your input, and I can run it; however it takes forever....
Here my output :
...
Total nuclear charge : -520.0000000
Total core charge : 360.0000000
Total valence charge : 160.0000000
Total excess charge : 0.000000000
Total electronic charge : 520.0000000
...
Bests
LUCA
Last edit: luca 2017-04-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
your choice of basis set is unnecessary large, or rather your lack of choice ;-)
You determine the basis set with the parameter RGKMAX, which default values is 7.0 (dimensionless) but should in principle always be set explicitly.
This parameter is defined as R G_max where R is a real space length and G_max is the maximum distance to a reciprocal lattice point plus the k-point. The default value of R is the average R_MT. With the many H-atoms in your setup this leads to a small R and whence a large G_max=7/R. Instead I suggest you choose (since it is primarily p-electrons that need to be treated)
rgkmax
6
isgkmax
1
where the latter parameter will determine that R=R_1=R_Pb, the muffin-tin radius of the first atom which is Pb in your case.
see manual for more details and literature for description (for instance the book by DJ Singh and me).
The problem will still be large but considerably smaller. If it works you can check convergence by varying the parameter RGKMAX.
Best wishes,
Lars
Last edit: Lars Nordström 2017-04-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
with ELK you can calculate only small systems with small number of electrons.
And even for small systems calculations can be very time consuming depending on the parameters
to reach convergence.
In your case even for
rgkmax
6
isgkmax
1
it is still time consuming, but now scf is much faster (as i checked).
Best wishes
LUCA
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you might get good/decent results for values of RGKMAX as low as 4 or lower. At least you can converge first for such low values and then increase the value and check for convergence ...
/Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Elk Users,
I am a new Elk user, myself. I am a bit more familiar with plane-wave pseudopotential codes, and am a developer of BerkeleyGW. (Stop by the forums some time! I try to help out over there.)
I am having difficulty with getting even a "regular" self-consistent calculation of the charge density to complete. I have searched the forums for help, but nothing quite seems to work out. I adapted my input file from the "HSE" example in the "examples" directory, and added some suggested changes based on forum Q&A from past users, with some parameter choices that are more or less consistent with the literature.
The input file is below:
! Hybrid functional example using libxc. Note that the DFT step should be run
! separately with task=0. Then the hybrid step should be run with task=5.
! Example by Tyrel McQueen.
tasks
0
!tasks
! 5
! first run task=0 with PBE...
xctype
100 101 130
!...then uncomment the following and run with task=5 for hybrid GGA
! (note that only the correlation functional is set)
!xctype
! 100 0 406
lmaxo
8
lmaxapw
8
!lmaxo
! 10
!lmaxapw
! 10
trimvg
true
gmaxvr
6.0
ngridk
4 4 4
autolinengy
true
mixtype
3
autoswidth
true
beta0
0.2
nempty
5
avec
16.74318801 0.00000000 0.00000000
0.00000000 16.74318801 0.00000000
0.00000000 0.00000000 11.95989243
spinorb
.true.
sppath
'~/codes/elk-4.3.6/species/'
nwrite
1
atoms
5
'Pb.in'
2
0.00000000 0.00000000 0.00000000
0.49999980 0.49999980 0.00000000
'I.in'
6
0.00000000 0.00000000 0.49999980
0.49999980 0.49999980 0.49999980
0.21697871 0.28302109 0.00000000
0.28302109 0.78302089 0.00000000
0.78302089 0.71697851 0.00000000
0.71697851 0.21697871 0.00000000
'C.in'
2
0.46615701 -0.03384279 0.40427815
0.03384279 0.46615701 0.59572145
'N.in'
2
0.53384260 0.03384279 0.59572145
-0.03384279 0.53384260 0.40427815
'H.in'
12
0.38261835 -0.11738145 0.45278609
0.41254833 0.05542310 0.31230928
0.55542291 -0.08745148 0.31230928
0.50518280 -0.02810257 0.73299517
0.49630380 0.14609745 0.61844261
0.65307007 0.03656251 0.58571561
0.11738145 0.38261835 0.54721352
0.08745148 0.55542291 0.68769032
-0.05542310 0.41254833 0.68769032
0.01278528 0.48694771 0.26498259
-0.01545917 0.65182731 0.39880027
-0.15188338 0.51578154 0.39906255
The output is below:
Elk code version 4.3.06 started
Info(elk): several copies of Elk may be running in this path
(this could be intentional, or result from a previous crash,
or arise from an incorrect MPI compilation)
Info(elk): current task : 0
Info(checkmt): reduced muffin-tin radius of species 3 (C) from 1.8000 to 1.3645
Info(checkmt): reduced muffin-tin radius of species 4 (N) from 1.8000 to 1.0971
Info(checkmt): reduced muffin-tin radius of species 5 (H) from 1.4000 to 0.6468
Warning(linengy): could not find 4 linearisation energies in s.c. loop 1
My jobscript makes use of OpenMP parallelization, and I tried to be conscientious about memory usage. I use 1 MPI process, 32 OpenMP processes, across 4 of NERSC's Cori Haswell Nodes (128 GB each).
I use the provided pseudopotential files, without any modifications. From searching around the forums, this may be an issue, though it looks like the code is adjusting the muffin-tin radii of the smaller atoms apropriately.
Any help will be much appreciated.
Thank you very much,
Bradford Barker
Graduate Student, UC Berkeley
Dear Bradford,
your system is simply too large for an all electron calculation with 520 electrons.
you should switch back to the pseudo-potential based plane-wave codes,
otherwise it is computationally not feasible.
There is nothing wrong with your input, and I can run it; however it takes forever....
Here my output :
...
Total nuclear charge : -520.0000000
Total core charge : 360.0000000
Total valence charge : 160.0000000
Total excess charge : 0.000000000
Total electronic charge : 520.0000000
...
Bests
LUCA
Last edit: luca 2017-04-13
Dear Luca,
Thank you very much for the information. What, roughly, is the limit on the system size for reasonable calculations with ELK?
Thank you very much,
Bradford
Dear Bradford,
your choice of basis set is unnecessary large, or rather your lack of choice ;-)
You determine the basis set with the parameter RGKMAX, which default values is 7.0 (dimensionless) but should in principle always be set explicitly.
This parameter is defined as R G_max where R is a real space length and G_max is the maximum distance to a reciprocal lattice point plus the k-point. The default value of R is the average R_MT. With the many H-atoms in your setup this leads to a small R and whence a large G_max=7/R. Instead I suggest you choose (since it is primarily p-electrons that need to be treated)
rgkmax
6
isgkmax
1
where the latter parameter will determine that R=R_1=R_Pb, the muffin-tin radius of the first atom which is Pb in your case.
see manual for more details and literature for description (for instance the book by DJ Singh and me).
The problem will still be large but considerably smaller. If it works you can check convergence by varying the parameter RGKMAX.
Best wishes,
Lars
Last edit: Lars Nordström 2017-04-13
Dear Bradford,
with ELK you can calculate only small systems with small number of electrons.
And even for small systems calculations can be very time consuming depending on the parameters
to reach convergence.
In your case even for
rgkmax
6
isgkmax
1
it is still time consuming, but now scf is much faster (as i checked).
Best wishes
LUCA
you might get good/decent results for values of RGKMAX as low as 4 or lower. At least you can converge first for such low values and then increase the value and check for convergence ...
/Lars