diff --git a/doc/guide/conv_vasp.rst b/doc/guide/conv_vasp.rst index 12b1488b..4c5a6484 100644 --- a/doc/guide/conv_vasp.rst +++ b/doc/guide/conv_vasp.rst @@ -8,7 +8,7 @@ The VASP interface relies on new options introduced since version 5.4.x In particular, a new INCAR-option `LOCPROJ `_, the new `LORBIT` modes 13 and 14 have been added, and the new `ICHARG` mode 5 for charge -self-consistent DFT+DMFT calculations have been added. +self-consistent DFT+DMFT calculations have been added. The VASP interface for charge self-consistent calculations is officially supported as of VASP version 6.5.0 (see `VASP ICHARG=5 documentation `_). It is highly recommended to compile VASP with hdf5 support enabled (`-DVASP_HDF5`) to enable features of the interface. This allows to use the interface while symmetries are switched on in VASP, and enables spin-polarized feedback in charge self-consistent calculations to VASP. The VASP interface methodologically builds on the so called projection on localized orbitals (PLO) scheme, where the resulting KS states from DFT are @@ -18,26 +18,16 @@ The implementation is presented in `M. Schüler et al. 2018 J. Phys.: Condens. Matter 30 475901 `_. The interface consists of two parts, :py:mod:`PLOVASP`, a collection of -python classes and functions converting the raw VASP output to proper projector +python classes and functions converting the VASP output to proper projector functions, and the python based :py:mod:`VaspConverter`, which creates a h5 archive from the :py:mod:`PLOVASP` output readable by `SumkDFT`. Therefore, the conversion consist always of two steps. Here, we will present a guide how the interface `can` be used to create input for a DMFT calculation, using SrVO3 as an example. Full examples can be found in the :ref:`tutorial section of DFTTools`. -Limitations of the interface -============================ +For VASP version older than 6.5.0 there are a few limitation of the interface as it was not officially supported and only text file based. See `Remarks for VASP older than 6.5.0`_ for details. -* The interface works correctly only if the k-point symmetries - are turned off during the VASP run (ISYM=-1). -* Generation of projectors for k-point lines (option `Lines` in KPOINTS) - needed for Bloch spectral function calculations is not possible at the moment. -* The interface currently supports only collinear-magnetism calculation - (this implies no spin-orbit coupling) and spin-polarized projectors have not - been tested. -* The converter needs the correct Fermi energy from VASP, which is read from - the LOCPROJ file. However, VASP by default does not output this information. - Please see `Remarks on the VASP version`_. +Generation of projectors for k-point lines (option `Lines` in KPOINTS) needed for Bloch spectral function calculations is not possible at the moment. VASP: generating raw projectors =============================== @@ -383,16 +373,20 @@ For two correlated sites, one can define the file as follows: 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0 -Remarks on the VASP version -=============================== +Remarks for VASP older than 6.5.0 +================================= -In the current version of the interface the Fermi energy is extracted from the -DOSCAR. However, if one pursues to do charge self-consistent calculations one -needs to write the Fermi energy to the projectors (`LOCPROJ` file), as the DOSCAR -is only updated after a full SCF/NSCF run. The file should contain the Fermi energy -in the header. One can either copy the Fermi energy manually there after a successful -VASP run, or modify the VASP source code slightly, by replacing the following line in -`locproj.F` (around line 695): +The above mentioned interface has some limitations for VASP versions older than 6.5.0: + +* The interface works correctly only if the k-point symmetries + are turned off during the VASP run (ISYM=-1). +* The interface currently supports only collinear-magnetism calculation + (this implies no spin-orbit coupling) and spin-polarized projectors have not + been tested. +* The converter needs the correct Fermi energy from VASP, which is read from + the LOCPROJ file. However, VASP by default does not output this information. + +For VASP older than 6.5.0 the Fermi level cannot be extracted from the `vaspout.h5` file, then interface falls back to extract the Fermi level from the DOSCAR. However, if one pursues to do charge self-consistent calculations one needs to write the Fermi energy to the projectors (`LOCPROJ` file), as the DOSCAR is only updated after a full SCF/NSCF run. The file should contain the Fermi energy in the header. One can either copy the Fermi energy manually there after a successful VASP run, or modify the VASP source code slightly, by replacing the following line in `locproj.F` (around line 695): :: < WRITE(99,'(4I6," # of spin, # of k-points, # of bands, # of proj" )') NS,NK,NB,NF @@ -417,7 +411,6 @@ Next, we need to pass this option when calling from `electron.F` and `main.F` Now Vasp should print in the header of the `LOCPROJ` file additionally the Fermi energy. - Another critical point for CSC calculations is the function call of `LPRJ_LDApU` in VASP. This function is not needed, and was left there for debug purposes, but is called every iteration. Removing the call to this function in `electron.F` in line 644 speeds up the calculation significantly in the `ICHARG=5` mode. Moreover, this prevents VASP from generating the `GAMMA` file, which should ideally only be done by the DMFT code after a successful DMFT step, and then be read by VASP. diff --git a/doc/guide/dftdmft_selfcons.rst b/doc/guide/dftdmft_selfcons.rst index 10e14085..87d5619f 100644 --- a/doc/guide/dftdmft_selfcons.rst +++ b/doc/guide/dftdmft_selfcons.rst @@ -133,8 +133,8 @@ Once VASP reaches the point where the projectors are generated it creates a lock file `vasp.lock` and waits until the lock file is removed. The shell script, in turn, waits for the VASP process and once the lock file is created it starts a DMFT iteration. The DMFT iteration -must finish by generating a Kohn-Sham (KS) density matrix (file `GAMMA`) -and removing the lock file. The VASP process then reads in `GAMMA` +must finish by generating a Kohn-Sham (KS) density matrix (file `GAMMA` or `vaspgamma.h5`) +and removing the lock file. The VASP process then reads in `GAMMA`/`vaspgamma.h5` and proceeds with the next iteration. PLOVasp interface provides a shell-script :program:`vasp_dmft` (in the triqs bin directory):: vasp_dmft [-n ] -i -j [-v ] [-p ] [] @@ -162,7 +162,7 @@ calculations with the main difference that its functionality (apart from the lines importing other modules) should be placed inside a function `dmft_cycle()` which will be called every DMFT cycle and returns both the correlation energy and the SumK object. -VASP has a special INCAR `ICHARG=5` mode, that has to be switched on to make VASP wait for the `vasp.lock` file, and read the updated charge density after each step. One should add the following lines to the `INCAR` file:: +VASP has a special INCAR `ICHARG=5 `_ mode, that has to be switched on to make VASP wait for the `vasp.lock` file, and read the updated charge density after each step. One should add the following lines to the `INCAR` file:: ICHARG = 5 NELM = 1000 @@ -170,6 +170,7 @@ VASP has a special INCAR `ICHARG=5` mode, that has to be switched on to make VAS IMIX=1 BMIX=0.5 AMIX=0.02 + LSYNCH5=True Technically, VASP runs with `ICHARG=5` in a SCF mode, and adding the DMFT changes to the DFT density in each step, so that the full DFT+DMFT charge @@ -187,6 +188,8 @@ To understand the difference please make sure to read `ISTART flag VASP wiki `NELMIN` ensure that VASP does not terminate after the default number of iterations of 60. +The `LSYNCH5` flag is set to `True` to ensure that the VASP writte vaspout.h5 file can be read while VASP is running. Starting from VASP 6.5.0 all communication between VASP and TRIQS is performed through two h5 files: `vaspout.h5 `_ and `vaspgamma.h5 `_ when VASP is compiled with hdf5 support. + For more detailed and fine grained methods to run Vasp in CSC also on clusters see the methods implemented in `solid dmft `_.