Below are the notes from the HackMD page during the workshop.
https://www.vasp.at/wiki/index.php/Number_of_bands_NBANDS Yes, in principle one should check the convergency with respect to the number of bands. VASP will determine a default number, which should be sufficient in most cases. But for very accurate simulations, or for GW simulations for example, you may need to increase it. If you want to compare the total energies of different simulations, pls. keep in mind that NBANDS has to be the same in all these cases. Also, the default NBANDS will depend on how many cores you are running on, for this reason it is good to explicitly define it in INCAR.
S: Thank you very much.
Depending on parallelization (e.g. number of nodes, cores), VASP might change your NBANDS, so a good practice is to check with
grep NBANDS OUTCAR
It depends how smooth you'd like the curves to be. Roughly double the scf one may be a good starting point. The BZ integration method and SIGMA will also influence the smearing. Some recommendations from the VASP developers: https://cms.mpi.univie.ac.at/vasp/vasp/Accurate_DOS_Band_structure_calculations.html
S: Okay. Thank you very much.
The shape of the fcc unit cell is cubic, so the volume is a^3 with each side a. An fcc unit cell contains 4 atoms. From VASP we got the volume V0 for one atom. Also compare with what you get from
grep volume OUTCAR and
grep volume vasprun.xml
Maybe "-1" is a way to say "all" in p4vasp
It's automatically set to 0.0 in p4vasp, but in the VASP output it's not set, so you would need to check its value
okay thank you.
fcc Si is metallic, but cubic diamond Si has band gap.
okay thank you.
Wrong depends what we compare with, so we'd need to do the calculation exactly the same as was done in the VASP wiki, so the same lattice parameter and settings in INCAR.
It's for a single step calculation for DOS in one go. For a 2nd step calc. it's correct that one would set ICHARG=11 and copy CHGCAR from previous calc.
Answer: You need to copy your CONTCAR to POSCAR and re-run the simulation - just a simple self-consistent run. This step is preferred if you want more accurate total energies.
Answer: depends how complicated your structure is. If you have a monoclinic structures, it may. Allow me to rephrase: whenever the cell shape changes a lot, it is good to do this step.
Answer: ISIF=3 is faster for the user in the sense that VASP will optimize the structure considering all degress of freedom (volume/shape/internal coordinates). I prefer to keep the volume fixed and optimize the positions and the cell shape, if needed, only.
Answer: You should allow the shape and positions to change for different volumes, as otherwise you may not find the equilibrium structure.
Comment S: Okay thanks a lot. I understand. So this suggests that I shall take the Structure (that I get relaxing shape plus ion positions for each volume) corresponding to the volume that gives the minimum energy. But then, with this data, if I do a EOS, it will give me an equillibrium volume but that volume has no structure associated with it. My question is shall I have to do the EOS fitting now or just take the minimum energy structure?
S: About ISIF = 2 with EDIFFG. EDIFFG can be positive or negative having different meaning. So, which one is preferrable? or do we need to use both for different purposes?
Answer: "If the change in the total (free) energy is smaller than EDIFFG between two ionic steps relaxation will be stopped. If EDIFFG is negative it has a different meaning: In this case the relaxation will stop if all forces are smaller than |EDIFFG| . This is usually a more convenient setting." The negative EDIFFG is typically preferred.
S: Okay .. thanks
Feel free to share any useful links.
NCORE are the parallelization flags that influence the speed and memory requirements of a job the most. It is a good idea to start optimizing these for your simulation and then move to optimizing
NSIM. The memory requirements increase linearly with KPAR, but not as drastically as decreasing NCORE. The number of cores of the simulation has to be divisible by NCORE*KPAR. [NCORE - how many cores work on one orbital]