My Community

Dear all,

1) is there a maximum number of atoms(/kpoints/cellvolume/bands/...) for systems treated in VASP?(if so, ofcourse what is that limit)

2) why is the formating of the OUTCAR file set up to only work for very small systems (eg a system with slab of 100 Ge_d atoms can't write the number of electrons, the expected amount of memory needed for storing wavefunctions etc)

Danny

1) there is max a number ions when the symmetrized forces are checked (NIOND=256 in subroutine CHECK, dyna.F), and there is a max. number of k-points along each direction of the BZ (45) and of tetrahedra (90000) if you use the tetrahedron method for BZ integration), but there are no other restrictions
2) 9999999 electrons and 9.999GByte to store the wavefunctions (written in main.f) as well as 999.999999 electrons (written in subroutine BZINT, tet.F) are not "very small", I think. Please feel free to change the output formats, if they are not appropriate for your calculations

[quote author=256 in subroutine CHECK, dyna.F), and there is a max. number of k-points along each direction of the BZ (45) and of tetrahedra (90000) if you use the tetrahedron method for BZ integration), but there are no other restrictions
[/quote]</span>

1) you have to change the PARAMETER in the source code and recompile
2) yes, if you have really big cells, I agree with you on that....

Dear Admin,

i have 552 atoms system (includes Caesium (Cs)). using KPOINTS [ 4 4 1] and also tried [3 3 1] but even first electronic step is not converged, and thus do not have WAVECAR file, to continue the job from CONTCAR.

it already consumed about 45 hours in trying both KPOINTS, in parts.
About 35 minutes is consumed to write the very first line of calculations in OSZICAR file.
As a test i reduced NELM to very low (=10), hoping that it might write WAVECAR to continue. But obviously the file is not written as its not converged in electronic step.
copying some part of 'log' file created during the run.
---------------- -----------
FFT: planning ...
WAVECAR not read
entering main loop
N E dE d eps ncg rms rms(c)
DAV: 1 0.213800803607E+05 0.21380E+05 -0.76810E+05 16992 0.107E+03
DAV: 2 0.223263167516E+04 -0.19147E+05 -0.18574E+05 23616 0.211E+02
DAV: 3 -0.231909458488E+04 -0.45517E+04 -0.45154E+04 20304 0.105E+02
DAV: 4 -0.261932664885E+04 -0.30023E+03 -0.29731E+03 21216 0.330E+01
DAV: 5 -0.262831301267E+04 -0.89864E+01 -0.89383E+01 23184 0.558E+00
DAV: 6 -0.262858028828E+04 -0.26728E+00 -0.26695E+00 23568 0.896E-01
DAV: 7 -0.262859218044E+04 -0.11892E-01 -0.11879E-01 24024 0.173E-01
DAV: 8 -0.262859280616E+04 -0.62573E-03 -0.62531E-03 23544 0.329E-02
DAV: 9 -0.262859283219E+04 -0.26030E-04 -0.25995E-04 19272 0.680E-03
DAV: 10 -0.262859283400E+04 -0.18077E-05 -0.17970E-05 13920 0.174E-03
1 F= -.26967630E+04 E0= -.26962533E+04 d E =-.269676E+04
BRION: g(F)= 0.510E+03 g(S)= 0.000E+00
bond charge predicted
N E dE d eps ncg rms rms(c)
DAV: 1 -0.254093218569E+04 0.87661E+02 -0.66352E+03 16872 0.387E+01 0.246E+02
------------------------ ----------------
Later i reduced the structure a bit and now 500 atoms (approx). the Even then it doesn't seem improved.
May i know. if there is any way to speed up and get the structure optimised?
Regards

SKM wrote: ↑Thu Feb 06, 2020 5:21 amBut obviously the file is not written as its not converged in electronic step.

WAVECAR should be written even if you electronic convergence did not finish.

Using ~500 atoms and that many k-points will be very expensive no matter what you do. The best approach is to carefully check, if that system size is actually necessary. If you really need it, then ideally you have a sufficiently efficient HPC resource that you can do multiple steps. Because the WAVECAR files will be huge, too, and generally it is not a good idea to write huge amount of data on HPC machines, because their I/O is slow. So you want to switch of writing WAVECAR altogether and just restart from the density (ISTART = 1; LWAVE = .FALSE.).

Also make sure you are aware of all parallelization options of Vasp, you want to use KPAR (set to the number of irreducible k-points), NCORE (set to the size of a single node or half of it), and then a total number of CPU that is approximately NCORE times larger, so ~KPAR * NCORE^2. You may also want to check the tags NSIM and LPLANE and/or compile the code with scalapack.