Hello!
Sorry for this late reply! I assume you got the example from this page on our Wiki: https://vasp.at/wiki/Dielectric_properties_of_Si, correct? While the example certainly contains the essential INCAR tags to try it out there is little context about the calculation. May I suggest to have a look at the more recent tutorials, specifically for linear response here: https://www.vasp.at/tutorials/latest/re ... sponse-e01. There the difference between LCALCEPS and LEPSILON is discussed (see also the Wiki page here). In the data you attached you did perform both calculations at the same time. Maybe this is technically possible but I am pretty sure this was not intended in the example. Rather you should either use the INCAR tags in this section
Code: Select all
## Static dielectric properties by means of DFPT
#NBANDS = 4
#EDIFF = 1E-6
#LEPSILON = .TRUE.
## try to add this to the DFPT calculation
#LPEAD = .TRUE.
## to get the ionic contributions to the
## static dielectric properties from
## perturbation theory
#IBRION = 8
or in the other section:
Code: Select all
## Static dielectric properties by means of PEAD
#EDIFF = 1E-8 # finite field requires very tight convergence
#LCALCEPS = .TRUE.
#NELM = 100
Generally, the examples and tutorials are set up in such way that they require a minimum amount of computational resources. Hence, VASP will not perform well if many MPI ranks are used here. Even worse, since VASP requires at least one band for each MPI rank, the number of bands in your second run was automatically increased to 40 just because that is also the number of MPI ranks used. Because this technical requirement contradicted the input given in the INCAR file, VASP issues the warning message you mentioned. For more details about the parallelization have a look at our corresponding Wiki page and NBANDS. There is also a video online from our team which explains a lot about parallelization in VASP : https://www.youtube.com/watch?v=KzIuL_e0zz8.
Since you mentioned specific numbers (order of 300 bands, 2 nodes with 64-cores each): whether the calculation you have in mind will actually saturate the CPU cores of the given machines needs to be tested carefully. I would recommend to benchmark with different number of cores before starting into actual production runs. Some hints on this topic are given on our Wiki here.
All the best,
Andreas Singraber