mirror of
https://github.com/triqs/dft_tools
synced 20240719 01:13:40 +02:00
Merge pull request #101 from TRIQS/vaspupdate2.0
VASP interface update
This commit is contained in:
commit
5a8996731d
@ 1,147 +0,0 @@


import pytriqs.utility.mpi as mpi


from pytriqs.operators.util import *


from pytriqs.archive import HDFArchive


from triqs_cthyb import *


from pytriqs.gf import *


from triqs_dft_tools.sumk_dft import *


from triqs_dft_tools.converters.wien2k_converter import *




dft_filename='Gd_fcc'


U = 9.6


J = 0.8


beta = 40


loops = 10 # Number of DMFT scloops


sigma_mix = 1.0 # Mixing factor of Sigma after solution of the AIM


delta_mix = 1.0 # Mixing factor of Delta as input for the AIM


dc_type = 0 # DC type: 0 FLL, 1 Held, 2 AMF


use_blocks = True # use bloc structure from DFT input


prec_mu = 0.0001


h_field = 0.0




# Solver parameters


p = {}


p["max_time"] = 1


p["length_cycle"] = 50


p["n_warmup_cycles"] = 50


p["n_cycles"] = 5000




Converter = Wien2kConverter(filename=dft_filename, repacking=True)


Converter.convert_dft_input()


mpi.barrier()




previous_runs = 0


previous_present = False


if mpi.is_master_node():


f = HDFArchive(dft_filename+'.h5','a')


if 'dmft_output' in f:


ar = f['dmft_output']


if 'iterations' in ar:


previous_present = True


previous_runs = ar['iterations']


else:


f.create_group('dmft_output')


del f


previous_runs = mpi.bcast(previous_runs)


previous_present = mpi.bcast(previous_present)




SK=SumkDFT(hdf_file=dft_filename+'.h5',use_dft_blocks=use_blocks,h_field=h_field)




n_orb = SK.corr_shells[0]['dim']


l = SK.corr_shells[0]['l']


spin_names = ["up","down"]


orb_names = [i for i in range(n_orb)]




# Use GF structure determined by DFT blocks


gf_struct = [(block, indices) for block, indices in SK.gf_struct_solver[0].iteritems()]


# Construct U matrix for densitydensity calculations


Umat, Upmat = U_matrix_kanamori(n_orb=n_orb, U_int=U, J_hund=J)


# Construct Hamiltonian and solver


h_int = h_int_density(spin_names, orb_names, map_operator_structure=SK.sumk_to_solver[0], U=Umat, Uprime=Upmat, H_dump="H.txt")


S = Solver(beta=beta, gf_struct=gf_struct)




if previous_present:


chemical_potential = 0


dc_imp = 0


dc_energ = 0


if mpi.is_master_node():


S.Sigma_iw << HDFArchive(dft_filename+'.h5','a')['dmft_output']['Sigma_iw']


chemical_potential,dc_imp,dc_energ = SK.load(['chemical_potential','dc_imp','dc_energ'])


S.Sigma_iw << mpi.bcast(S.Sigma_iw)


chemical_potential = mpi.bcast(chemical_potential)


dc_imp = mpi.bcast(dc_imp)


dc_energ = mpi.bcast(dc_energ)


SK.set_mu(chemical_potential)


SK.set_dc(dc_imp,dc_energ)




for iteration_number in range(1,loops+1):


if mpi.is_master_node(): print "Iteration = ", iteration_number




SK.symm_deg_gf(S.Sigma_iw,orb=0) # symmetrise Sigma


SK.set_Sigma([ S.Sigma_iw ]) # set Sigma into the SumK class


chemical_potential = SK.calc_mu( precision = prec_mu ) # find the chemical potential for given density


S.G_iw << SK.extract_G_loc()[0] # calc the local Green function


mpi.report("Total charge of Gloc : %.6f"%S.G_iw.total_density())




# Init the DC term and the real part of Sigma, if no previous runs found:


if (iteration_number==1 and previous_present==False):


dm = S.G_iw.density()


SK.calc_dc(dm, U_interact = U, J_hund = J, orb = 0, use_dc_formula = dc_type)


S.Sigma_iw << SK.dc_imp[0]['up'][0,0]




# Calculate new G0_iw to input into the solver:


if mpi.is_master_node():


# We can do a mixing of Delta in order to stabilize the DMFT iterations:


S.G0_iw << S.Sigma_iw + inverse(S.G_iw)


ar = HDFArchive(dft_filename+'.h5','a')['dmft_output']


if (iteration_number>1 or previous_present):


mpi.report("Mixing input Delta with factor %s"%delta_mix)


Delta = (delta_mix * delta(S.G0_iw)) + (1.0delta_mix) * ar['Delta_iw']


S.G0_iw << S.G0_iw + delta(S.G0_iw)  Delta


ar['Delta_iw'] = delta(S.G0_iw)


S.G0_iw << inverse(S.G0_iw)


del ar




S.G0_iw << mpi.bcast(S.G0_iw)




# Solve the impurity problem:


S.solve(h_int=h_int, **p)




# Solved. Now do postprocessing:


mpi.report("Total charge of impurity problem : %.6f"%S.G_iw.total_density())




# Now mix Sigma and G with factor sigma_mix, if wanted:


if (iteration_number>1 or previous_present):


if mpi.is_master_node():


ar = HDFArchive(dft_filename+'.h5','a')['dmft_output']


mpi.report("Mixing Sigma and G with factor %s"%sigma_mix)


S.Sigma_iw << sigma_mix * S.Sigma_iw + (1.0sigma_mix) * ar['Sigma_iw']


S.G_iw << sigma_mix * S.G_iw + (1.0sigma_mix) * ar['G_iw']


del ar


S.G_iw << mpi.bcast(S.G_iw)


S.Sigma_iw << mpi.bcast(S.Sigma_iw)




# Write the final Sigma and G to the hdf5 archive:


if mpi.is_master_node():


ar = HDFArchive(dft_filename+'.h5','a')['dmft_output']


if previous_runs: iteration_number += previous_runs


ar['iterations'] = iteration_number


ar['G_tau'] = S.G_tau


ar['G_iw'] = S.G_iw


ar['Sigma_iw'] = S.Sigma_iw


ar['G0%s'%(iteration_number)] = S.G0_iw


ar['G%s'%(iteration_number)] = S.G_iw


ar['Sigma%s'%(iteration_number)] = S.Sigma_iw


del ar




# Set the new double counting:


dm = S.G_iw.density() # compute the density matrix of the impurity problem


SK.calc_dc(dm, U_interact = U, J_hund = J, orb = 0, use_dc_formula = dc_type)




# Save stuff into the dft_output group of hdf5 archive in case of rerun:


SK.save(['chemical_potential','dc_imp','dc_energ'])




if mpi.is_master_node():


ar = HDFArchive("dftdmft.h5",'w')


ar["G_tau"] = S.G_tau


ar["G_iw"] = S.G_iw


ar["Sigma_iw"] = S.Sigma_iw

@ 19,7 +19,7 @@ extensions = ['sphinx.ext.autodoc',


source_suffix = '.rst'




project = u'TRIQS DFTTools'


copyright = u'20112013, M. Aichhorn, L. Pourovskii, V. Vildosola, C. Martins'


copyright = u'20112019'


version = '@DFT_TOOLS_VERSION@'




mathjax_path = "@TRIQS_MATHJAX_PATH@/MathJax.js?config=default"


@ 32,6 +32,7 @@ html_context = {'header_title': 'dft tools',


'header_subtitle': 'connecting <a class="triqs" style="fontsize: 12px" href="http://triqs.github.io/triqs">TRIQS</a> to DFT packages',


'header_links': [['Install', 'install'],


['Documentation', 'documentation'],


['Tutorials', 'tutorials'],


['Issues', 'issues'],


['About DFTTools', 'about']]}


html_static_path = ['@CMAKE_SOURCE_DIR@/doc/_static']



@ 16,18 +16,31 @@ Basic notions


basicnotions/structure






User guide





Construction of local orbitals from DFT







.. toctree::


:maxdepth: 2




guide/conversion






DFT+DMFT







.. toctree::


:maxdepth: 2




guide/dftdmft_singleshot


guide/SrVO3


guide/dftdmft_selfcons




Postprocessing







.. toctree::


:maxdepth: 2




guide/analysis


guide/full_tutorial


guide/transport







@ 40,8 +40,8 @@ If required, we have to load and initialise the realfrequency self energy. Most


you have your self energy already stored as a realfrequency :class:`BlockGf <pytriqs.gf.BlockGf>` object


in a hdf5 file::




ar = HDFArchive('case.h5', 'a')


SigmaReFreq = ar['dmft_output']['Sigma_w']


with HDFArchive('case.h5', 'r') as ar:


SigmaReFreq = ar['dmft_output']['Sigma_w']




You may also have your self energy stored in text files. For this case the :ref:`TRIQS <triqslibs:welcome>` library offers


the function :meth:`read_gf_from_txt`, which is able to load the data from text files of one Green function block


@ 73,7 +73,6 @@ and additionally set the chemical potential and the double counting correction f


chemical_potential, dc_imp, dc_energ = SK.load(['chemical_potential','dc_imp','dc_energ'])


SK.set_mu(chemical_potential)


SK.set_dc(dc_imp,dc_energ)


del ar




.. _dos_wannier:





117
doc/guide/conv_W90.rst
Normal file
117
doc/guide/conv_W90.rst
Normal file
@ 0,0 +1,117 @@


.. _convW90:




Wannier90 Converter


===================




Using this converter it is possible to convert the output of


`wannier90 <http://wannier.org>`_


Maximally Localized Wannier Functions (MLWF) and create a HDF5 archive


suitable for oneshot DMFT calculations with the


:class:`SumkDFT <dft.sumk_dft.SumkDFT>` class.




The user must supply two files in order to run the Wannier90 Converter:




#. The file :file:`seedname_hr.dat`, which contains the DFT Hamiltonian


in the MLWF basis calculated through :program:`wannier90` with ``hr_plot = true``


(please refer to the :program:`wannier90` documentation).


#. A file named :file:`seedname.inp`, which contains the required


information about the :math:`\mathbf{k}`point mesh, the electron density,


the correlated shell structure, ... (see below).




Here and in the following, the keyword ``seedname`` should always be intended


as a placeholder for the actual prefix chosen by the user when creating the


input for :program:`wannier90`.


Once these two files are available, one can use the converter as follows::




from triqs_dft_tools.converters import Wannier90Converter


Converter = Wannier90Converter(seedname='seedname')


Converter.convert_dft_input()




The converter input :file:`seedname.inp` is a simple text file with


the following format (do not use the text/comments in your input file):




.. literalinclude:: images_scripts/LaVO3_w90.inp




The example shows the input for the perovskite crystal of LaVO\ :sub:`3`


in the roomtemperature `Pnma` symmetry. The unit cell contains four


symmetryequivalent correlated sites (the V atoms) and the total number


of electrons per unit cell is 8 (see second line).


The first line specifies how to generate the :math:`\mathbf{k}`point


mesh that will be used to obtain :math:`H(\mathbf{k})`


by Fourier transforming :math:`H(\mathbf{R})`.


Currently implemented options are:




* :math:`\Gamma`centered uniform grid with dimensions


:math:`n_{k_x} \times n_{k_y} \times n_{k_z}`;


specify ``0`` followed by the three grid dimensions,


like in the example above


* :math:`\Gamma`centered uniform grid with dimensions


automatically determined by the converter (from the number of


:math:`\mathbf{R}` vectors found in :file:`seedname_hr.dat`);


just specify ``1``




Inside :file:`seedname.inp`, it is crucial to correctly specify the


correlated shell structure, which depends on the contents of the


:program:`wannier90` output :file:`seedname_hr.dat` and on the order


of the MLWFs contained in it. In this example we have four lines for the


four V atoms. The MLWFs were constructed for the t\ :sub:`2g` subspace, and thus


we set ``l`` to 2 and ``dim`` to 3 for all V atoms. Further the spinorbit coupling (``SO``)


is set to 0 and ``irep`` to 0.


As in this example all 4 V atoms are equivalent we set ``sort`` to 0. We note


that, e.g., for a magnetic DMFT calculation the correlated atoms can be made


inequivalent at this point by using different values for ``sort``.




The number of MLWFs must be equal to, or greater than the total number


of correlated orbitals (i.e., the sum of all ``dim`` in :file:`seedname.inp`).


If the converter finds fewer MLWFs inside :file:`seedname_hr.dat`, then it


stops with an error; if it finds more MLWFs, then it assumes that the


additional MLWFs correspond to uncorrelated orbitals (e.g., the O\ `2p` shells).


When reading the hoppings :math:`\langle w_i  H(\mathbf{R})  w_j \rangle`


(where :math:`w_i` is the :math:`i`th MLWF), the converter also assumes that


the first indices correspond to the correlated shells (in our example,


the Vt\ :sub:`2g` shells). Therefore, the MLWFs corresponding to the


uncorrelated shells (if present) must be listed **after** those of the


correlated shells.


With the :program:`wannier90` code, this can be achieved by listing the


projections for the uncorrelated shells after those for the correlated shells.


In our `Pnma`LaVO\ :sub:`3` example, for instance, we could use::




Begin Projections


V:l=2,mr=2,3,5:z=0,0,1:x=1,1,0


O:l=1:mr=1,2,3:z=0,0,1:x=1,1,0


End Projections




where the ``x=1,1,0`` option indicates that the VO bonds in the octahedra are


rotated by (approximatively) 45 degrees with respect to the axes of the `Pbnm` cell.




The converter will analyse the matrix elements of the local Hamiltonian


to find the symmetry matrices `rot_mat` needed for the globaltolocal


transformation of the basis set for correlated orbitals


(see section :ref:`hdfstructure`).


The matrices are obtained by finding the unitary transformations that diagonalize


:math:`\langle w_i  H_I(\mathbf{R}=0,0,0)  w_j \rangle`, where :math:`I` runs


over the correlated shells and `i,j` belong to the same shell (more details elsewhere...).


If two correlated shells are defined as equivalent in :file:`seedname.inp`,


then the corresponding eigenvalues have to match within a threshold of 10\ :sup:`5`,


otherwise the converter will produce an error/warning.


If this happens, please carefully check your data in :file:`seedname_hr.dat`.


This method might fail in nontrivial cases (i.e., more than one correlated


shell is present) when there are some degenerate eigenvalues:


so far tests have not shown any issue, but one must be careful in those cases


(the converter will print a warning message).




The current implementation of the Wannier90 Converter has some limitations:




* Since :program:`wannier90` does not make use of symmetries (symmetryreduction


of the :math:`\mathbf{k}`point grid is not possible), the converter always


sets ``symm_op=0`` (see the :ref:`hdfstructure` section).


* No charge selfconsistency possible at the moment.


* Calculations with spinorbit (``SO=1``) are not supported.


* The spinpolarized case (``SP=1``) is not yet tested.


* The postprocessing routines in the module


:class:`SumkDFTTools <dft.sumk_dft_tools.SumkDFTTools>`


were not tested with this converter.


* ``proj_mat_all`` are not used, so there are no projectors onto the


uncorrelated orbitals for now.





100
doc/guide/conv_generalhk.rst
Normal file
100
doc/guide/conv_generalhk.rst
Normal file
@ 0,0 +1,100 @@


.. _convgeneralhk:




A general H(k)


==============




In addition to the more extensive Wien2k, VASP, and W90 converters,


:program:`DFTTools` contains also a light converter. It takes only


one inputfile, and creates the necessary hdf outputfile for


the DMFT calculation. The header of this input file has a defined


format, an example is the following (do not use the text/comments in your


input file):




.. literalinclude:: images_scripts/case.hk




The lines of this header define




#. Number of :math:`\mathbf{k}`points used in the calculation


#. Electron density for setting the chemical potential


#. Number of total atomic shells in the hamiltonian matrix. In short,


this gives the number of lines described in the following. IN the


example file give above this number is 2.


#. The next line(s) contain four numbers each: index of the atom, index


of the equivalent shell, :math:`l` quantum number, dimension


of this shell. Repeat this line for each atomic shell, the number


of the shells is given in the previous line.




In the example input file given above, we have two inequivalent


atomic shells, one on atom number 1 with a full dshell (dimension 5),


and one on atom number 2 with one pshell (dimension 3).




Other examples for these lines are:




#. Full dshell in a material with only one correlated atom in the


unit cell (e.g. SrVO3). One line is sufficient and the numbers


are `1 1 2 5`.


#. Full dshell in a material with two equivalent atoms in the unit


cell (e.g. FeSe): You need two lines, one for each equivalent


atom. First line is `1 1 2 5`, and the second line is


`2 1 2 5`. The only difference is the first number, which tells on


which atom the shell is located. The second number is the


same in both lines, meaning that both atoms are equivalent.


#. t2g orbitals on two nonequivalent atoms in the unit cell: Two


lines again. First line is `1 1 2 3`, second line `2 2 2 3`. The


difference to the case above is that now also the second number


differs. Therefore, the two shells are treated independently in


the calculation.


#. dp Hamiltonian in a system with two equivalent atoms each in


the unit cell (e.g. FeSe has two Fe and two Se in the unit


cell). You need for lines. First line `1 1 2 5`, second


line


`2 1 2 5`. These two lines specify Fe as in the case above. For the p


orbitals you need line three as `3 2 1 3` and line four


as `4 2 1 3`. We have 4 atoms, since the first number runs from 1 to 4,


but only two inequivalent atoms, since the second number runs


only form 1 to 2.




Note that the total dimension of the hamiltonian matrices that are


read in is the sum of all shell dimensions that you specified. For


example number 4 given above we have a dimension of 5+5+3+3=16. It is important


that the order of the shells that you give here must be the same as


the order of the orbitals in the hamiltonian matrix. In the last


example case above the code assumes that matrix index 1 to 5


belongs to the first d shell, 6 to 10 to the second, 11 to 13 to


the first p shell, and 14 to 16 the second p shell.




#. Number of correlated shells in the hamiltonian matrix, in the same


spirit as line 3.




#. The next line(s) contain six numbers: index of the atom, index


of the equivalent shell, :math:`l` quantum number, dimension


of the correlated shells, a spinorbit parameter, and another


parameter defining interactions. Note that the latter two


parameters are not used at the moment in the code, and only kept


for compatibility reasons. In our example file we use only the


dshell as correlated, that is why we have only one line here.




#. The last line contains several numbers: the number of irreducible


representations, and then the dimensions of the irreps. One


possibility is as the example above, another one would be 2


2 3. This would mean, 2 irreps (eg and t2g), of dimension 2 and 3,


resp.




After these header lines, the file has to contain the Hamiltonian


matrix in orbital space. The standard convention is that you give for


each :math:`\mathbf{k}`point first the matrix of the real part, then the


matrix of the imaginary part, and then move on to the next :math:`\mathbf{k}`point.




The converter itself is used as::




from triqs_dft_tools.converters.hk_converter import *


Converter = HkConverter(filename = hkinputfile)


Converter.convert_dft_input()




where :file:`hkinputfile` is the name of the input file described


above. This produces the hdf file that you need for a DMFT calculation.




For more options of this converter, have a look at the


:ref:`refconverters` section of the reference manual.





144
doc/guide/conv_vasp.rst
Normal file
144
doc/guide/conv_vasp.rst
Normal file
@ 0,0 +1,144 @@


.. _convVASP:






Interface with VASP


===================




.. warning::


The VASP interface is in the alphaversion and the VASP part of it is not


yet publicly released. The documentation may, thus, be subject to changes


before the final release.




*Limitations of the alphaversion:*




* The interface works correctly only if the kpoint symmetries


are turned off during the VASP run (ISYM=1).




* Generation of projectors for kpoint lines (option `Lines` in KPOINTS)


needed for Bloch spectral function calculations is not possible at the moment.




* The interface currently supports only collinearmagnetism calculation


(this implis no spinorbit coupling) and


spinpolarized projectors have not been tested.




A detailed description of the VASP converter tool PLOVasp can be found


in the :ref:`PLOVasp User's Guide <plovasp>`. Here, a quickstart guide is presented.




The VASP interface relies on new options introduced since version


5.4.x. In particular, a new INCARoption `LOCPROJ`


and new `LORBIT` modes 13 and 14 have been added.




Option `LOCPROJ` selects a set of localized projectors that will


be written to file `LOCPROJ` after a successful VASP run.


A projector set is specified by site indices,


labels of the target local states, and projector type:




 `LOCPROJ = <sites> : <shells> : <projector type>`




where `<sites>` represents a list of site indices separated by spaces,


with the indices corresponding to the site position in the POSCAR file;


`<shells>` specifies local states (see below);


`<projector type>` chooses a particular type of the local basis function.


The recommended projector type is `Pr 2`. The formalism for this type


of projectors is presented in


`M. Schüler et al. 2018 J. Phys.: Condens. Matter 30 475901 <https://doi.org/10.1088/1361648X/aae80a>`_.




The allowed labels of the local states defined in terms of cubic


harmonics are:




* Entire shells: `s`, `p`, `d`, `f`




* `p`states: `py`, `pz`, `px`




* `d`states: `dxy`, `dyz`, `dz2`, `dxz`, `dx2y2`




* `f`states: `fy(3x2y2)`, `fxyz`, `fyz2`, `fz3`,


`fxz2`, `fz(x2y2)`, `fx(x23y2)`.




For projector type `Pr 2`, one should also set `LORBIT = 14` in the INCAR file


and provide parameters `EMIN`, `EMAX`, defining, in this case, an


energy range (energy window) corresponding to the valence states.


Note that, as in the case


of a DOS calculation, the position of the valence states depends on the


Fermi level, which can usually be found at the end of the OUTCAR file.




For example, in case of SrVO3 one may first want to perform a selfconsistent


calculation, then set `ICHARGE = 1` and add the following additional


lines into INCAR (provided that V is the second ion in POSCAR):




 `EMIN = 3.0`


 `EMAX = 8.0`


 `LORBIT = 14`


 `LOCPROJ = 2 : d : Pr 2`




The energy range does not have to be precise. Important is that it has a large


overlap with valence bands and no overlap with semicore or high unoccupied states.




Conversion for the DMFT selfconsistency cycle







The projectors generated by VASP require certain postprocessing before


they can be used for DMFT calculations. The most important step is to normalize


them within an energy window that selects band states relevant for the impurity


problem. Note that this energy window is different from the one described above


and it must be chosen independently of the energy


range given by `EMIN, EMAX` in INCAR.




Postprocessing of `LOCPROJ` data is generally done as follows:




#. Prepare an input file `<name>.cfg` (e.g., `plo.cfg`) that describes the definition


of your impurity problem (more details below).




#. Extract the value of the Fermi level from OUTCAR and paste it at the end of


the first line of LOCPROJ.




#. Run :program:`plovasp` with the input file as an argument, e.g.:




 `plovasp plo.cfg`




This requires that the TRIQS paths are set correctly (see Installation


of TRIQS).




If everything goes right one gets files `<name>.ctrl` and `<name>.pg1`.


These files are needed for the converter that will be invoked in your


DMFT script.




The format of input file `<name>.cfg` is described in details in


the :ref:`User's Guide <plovasp>`. Here we just consider a simple example for the case


of SrVO3:




.. literalinclude:: images_scripts/srvo3.cfg




A projector shell is defined by a section `[Shell 1]` where the number


can be arbitrary and used only for user convenience. Several


parameters are required




 **IONS**: list of site indices which must be a subset of indices


given earlier in `LOCPROJ`.


 **LSHELL**: :math:`l`quantum number of the projector shell; the corresponding


orbitals must be present in `LOCPROJ`.


 **EWINDOW**: energy window in which the projectors are normalized;


note that the energies are defined with respect to the Fermi level.




Option **TRANSFORM** is optional but here, it is specified to extract


only three :math:`t_{2g}` orbitals out of five `d` orbitals given by


:math:`l = 2`.




The conversion to a h5file is performed in the same way as for Wien2TRIQS::




from triqs_dft_tools.converters.vasp_converter import *


Converter = VaspConverter(filename = filename)


Converter.convert_dft_input()




As usual, the resulting h5file can then be used with the SumkDFT class.




Note that the automatic detection of the correct block structure might


fail for VASP inputs.


This can be circumvented by setting a bigger value of the threshold in


:class:`SumkDFT <dft.sumk_dft.SumkDFT>`, e.g.::




SK.analyse_block_structure(threshold = 1e4)




However, do this only after a careful study of the density matrix and


the projected DOS in the localized basis.



174
doc/guide/conv_wien2k.rst
Normal file
174
doc/guide/conv_wien2k.rst
Normal file
@ 0,0 +1,174 @@


.. _convWien2k:




Interface with Wien2k


=====================




We assume that the user has obtained a selfconsistent solution of the


KohnSham equations. We further have to require that the user is


familiar with the main in/output files of Wien2k, and how to run


the DFT code.




Conversion for the DMFT selfconsistency cycle







First, we have to write the necessary


quantities into a file that can be processed further by invoking in a


shell the command




`x lapw2 almd`




We note that any other flag for lapw2, such as c or so (for


spinorbit coupling) has to be added also to this line. This creates


some files that we need for the Wannier orbital construction.




The orbital construction itself is done by the Fortran program


:program:`dmftproj`. For an extensive manual to this program see


:download:`TutorialDmftproj.pdf <images_scripts/TutorialDmftproj.pdf>`.


Here we will only describe the basic steps.




Let us take the compound SrVO3, a commonly used


example for DFT+DMFT calculations. The input file for


:program:`dmftproj` looks like




.. literalinclude:: images_scripts/SrVO3.indmftpr




The first three lines give the number of inequivalent sites, their


multiplicity (to be in accordance with the Wien2k *struct* file) and


the maximum orbital quantum number :math:`l_{max}`. In our case our


struct file contains the atoms in the order Sr, V, O.




Next we have to


specify for each of the inequivalent sites, whether we want to treat


their orbitals as correlated or not. This information is given by the


following 3 to 5 lines:




#. We specify which basis set is used (complex or cubic


harmonics).


#. The four numbers refer to *s*, *p*, *d*, and *f* electrons,


resp. Putting 0 means doing nothing, putting 1 will calculate


**unnormalized** projectors in compliance with the Wien2k


definition. The important flag is 2, this means to include these


electrons as correlated electrons, and calculate normalized Wannier


functions for them. In the example above, you see that only for the


vanadium *d* we set the flag to 2. If you want to do simply a DMFT


calculation, then set everything to 0, except one flag 2 for the


correlated electrons.


#. In case you have a irrep splitting of the correlated shell, you can


specify here how many irreps you have. You see that we put 2, since


eg and t2g symmetries are irreps in this cubic case. If you don't


want to use this splitting, just put 0.


#. (optional) If you specifies a number different from 0 in above line, you have


to tell now, which of the irreps you want to be treated


correlated. We want to t2g, and not the eg, so we set 0 for eg and


1 for t2g. Note that the example above is what you need in 99% of


the cases when you want to treat only t2g electrons. For eg's only


(e.g. nickelates), you set 10 and 01 in this line.


#. (optional) If you have specified a correlated shell for this atom,


you have to tell if spinorbit coupling should be taken into


account. 0 means no, 1 is yes.




These lines have to be repeated for each inequivalent atom.




The last line gives the energy window, relative to the Fermi energy,


that is used for the projective Wannier functions. Note that, in


accordance with Wien2k, we give energies in Rydberg units!




After setting up this input file, you run:




`dmftproj`




Again, adding possible flags like so for spinorbit coupling. This


program produces the following files (in the following, take *case* as


the standard Wien2k place holder, to be replaced by the actual working


directory name):




* :file:`case.ctqmcout` and :file:`case.symqmc` containing projector


operators and symmetry operations for orthonormalized Wannier


orbitals, respectively.


* :file:`case.parproj` and :file:`case.sympar` containing projector


operators and symmetry operations for uncorrelated states,


respectively. These files are needed for projected


densityofstates or spectralfunction calculations in


postprocessing only.


* :file:`case.oubwin` needed for the charge density recalculation in


the case of fully selfconsistent DFT+DMFT run (see below).




Now we convert these files into an hdf5 file that can be used for the


DMFT calculations. For this purpose we


use the python module :class:`Wien2kConverter <dft.converters.wien2k_converter.Wien2kConverter>`. It is initialized as::




from triqs_dft_tools.converters.wien2k_converter import *


Converter = Wien2kConverter(filename = case)




The only necessary parameter to this construction is the parameter `filename`.


It has to be the root of the files produces by dmftproj. For our


example, the :program:`Wien2k` naming convention is that all files are


called the same, for instance


:file:`SrVO3.*`, so you would give `filename = "SrVO3"`. The constructor opens


an hdf5 archive, named :file:`case.h5`, where all the data is


stored. For other parameters of the constructor please visit the


:ref:`refconverters` section of the reference manual.




After initializing the interface module, we can now convert the input


text files to the hdf5 archive by::




Converter.convert_dft_input()




This reads all the data, and stores it in the file :file:`case.h5`.


In this step, the files :file:`case.ctqmcout` and


:file:`case.symqmc`


have to be present in the working directory.




After this step, all the necessary information for the DMFT loop is


stored in the hdf5 archive, where the string variable


`Converter.hdf_filename` gives the file name of the archive.




At this point you should use the method :meth:`dos_wannier_basis <dft.sumk_dft_tools.SumkDFTTools.dos_wannier_basis>`


contained in the module :class:`SumkDFTTools <dft.sumk_dft_tools.SumkDFTTools>` to check the density of


states of the Wannier orbitals (see :ref:`analysis`).




You have now everything for performing a DMFT calculation, and you can


proceed with the section on :ref:`singleshot DFT+DMFT calculations <singleshot>`.




Data for postprocessing







In case you want to do postprocessing of your data using the module


:class:`SumkDFTTools <dft.sumk_dft_tools.SumkDFTTools>`, some more files


have to be converted to the hdf5 archive. For instance, for


calculating the partial density of states or partial charges


consistent with the definition of :program:`Wien2k`, you have to invoke::




Converter.convert_parproj_input()




This reads and converts the files :file:`case.parproj` and


:file:`case.sympar`.




If you want to plot band structures, one has to do the


following. First, one has to do the Wien2k calculation on the given


:math:`\mathbf{k}`path, and run :program:`dmftproj` on that path:




 `x lapw1 band`


 `x lapw2 band almd`


 `dmftproj band`






Again, maybe with the optional additional extra flags according to


Wien2k. Now we use a routine of the converter module allows to read


and convert the input for :class:`SumkDFTTools <dft.sumk_dft_tools.SumkDFTTools>`::




Converter.convert_bands_input()




After having converted this input, you can further proceed with the


:ref:`analysis`. For more options on the converter module, please have


a look at the :ref:`refconverters` section of the reference manual.




Data for transport calculations







For the transport calculations, the situation is a bit more involved,


since we need also the :program:`optics` package of Wien2k. Please


look at the section on :ref:`Transport` to see how to do the necessary


steps, including the conversion.





@ 1,492 +1,27 @@


.. _conversion:




Orbital construction and conversion


===================================


Supported interfaces


====================




The first step for a DMFT calculation is to provide the necessary


input based on a DFT calculation. We will not review how to do the DFT


calculation here in this documentation, but refer the user to the


documentation and tutorials that come with the actual DFT


package. Here, we will describe how to use output created by Wien2k,


as well as how to use the lightweight general interface.


package. At the moment, there are two full charge self consistent interfaces, for the


Wien2k and the VASP DFT packages, resp. In addition, there is an interface to Wannier90, as well


as a lightweight generalpurpose interface. In the following, we will describe the usage of these


conversion tools.




Interface with Wien2k







We assume that the user has obtained a selfconsistent solution of the


KohnSham equations. We further have to require that the user is


familiar with the main in/output files of Wien2k, and how to run


the DFT code.




Conversion for the DMFT selfconsistency cycle


""""""""""""""""""""""""""""""""""""""""""""""




First, we have to write the necessary


quantities into a file that can be processed further by invoking in a


shell the command




`x lapw2 almd`




We note that any other flag for lapw2, such as c or so (for


spinorbit coupling) has to be added also to this line. This creates


some files that we need for the Wannier orbital construction.




The orbital construction itself is done by the Fortran program


:program:`dmftproj`. For an extensive manual to this program see


:download:`TutorialDmftproj.pdf <images_scripts/TutorialDmftproj.pdf>`.


Here we will only describe the basic steps.




Let us take the compound SrVO3, a commonly used


example for DFT+DMFT calculations. The input file for


:program:`dmftproj` looks like




.. literalinclude:: images_scripts/SrVO3.indmftpr




The first three lines give the number of inequivalent sites, their


multiplicity (to be in accordance with the Wien2k *struct* file) and


the maximum orbital quantum number :math:`l_{max}`. In our case our


struct file contains the atoms in the order Sr, V, O.




Next we have to


specify for each of the inequivalent sites, whether we want to treat


their orbitals as correlated or not. This information is given by the


following 3 to 5 lines:




#. We specify which basis set is used (complex or cubic


harmonics).


#. The four numbers refer to *s*, *p*, *d*, and *f* electrons,


resp. Putting 0 means doing nothing, putting 1 will calculate


**unnormalized** projectors in compliance with the Wien2k


definition. The important flag is 2, this means to include these


electrons as correlated electrons, and calculate normalized Wannier


functions for them. In the example above, you see that only for the


vanadium *d* we set the flag to 2. If you want to do simply a DMFT


calculation, then set everything to 0, except one flag 2 for the


correlated electrons.


#. In case you have a irrep splitting of the correlated shell, you can


specify here how many irreps you have. You see that we put 2, since


eg and t2g symmetries are irreps in this cubic case. If you don't


want to use this splitting, just put 0.


#. (optional) If you specifies a number different from 0 in above line, you have


to tell now, which of the irreps you want to be treated


correlated. We want to t2g, and not the eg, so we set 0 for eg and


1 for t2g. Note that the example above is what you need in 99% of


the cases when you want to treat only t2g electrons. For eg's only


(e.g. nickelates), you set 10 and 01 in this line.


#. (optional) If you have specified a correlated shell for this atom,


you have to tell if spinorbit coupling should be taken into


account. 0 means no, 1 is yes.




These lines have to be repeated for each inequivalent atom.




The last line gives the energy window, relative to the Fermi energy,


that is used for the projective Wannier functions. Note that, in


accordance with Wien2k, we give energies in Rydberg units!




After setting up this input file, you run:




`dmftproj`




Again, adding possible flags like so for spinorbit coupling. This


program produces the following files (in the following, take *case* as


the standard Wien2k place holder, to be replaced by the actual working


directory name):




* :file:`case.ctqmcout` and :file:`case.symqmc` containing projector


operators and symmetry operations for orthonormalized Wannier


orbitals, respectively.


* :file:`case.parproj` and :file:`case.sympar` containing projector


operators and symmetry operations for uncorrelated states,


respectively. These files are needed for projected


densityofstates or spectralfunction calculations in


postprocessing only.


* :file:`case.oubwin` needed for the charge density recalculation in


the case of fully selfconsistent DFT+DMFT run (see below).




Now we convert these files into an hdf5 file that can be used for the


DMFT calculations. For this purpose we


use the python module :class:`Wien2kConverter <dft.converters.wien2k_converter.Wien2kConverter>`. It is initialized as::




from triqs_dft_tools.converters.wien2k_converter import *


Converter = Wien2kConverter(filename = case)




The only necessary parameter to this construction is the parameter `filename`.


It has to be the root of the files produces by dmftproj. For our


example, the Wien2k naming convention is that all files are


called the same, for instance


:file:`SrVO3.*`, so you would give `filename = "SrVO3"`. The constructor opens


an hdf5 archive, named :file:`case.h5`, where all the data is


stored. For other parameters of the constructor please visit the


:ref:`refconverters` section of the reference manual.




After initializing the interface module, we can now convert the input


text files to the hdf5 archive by::




Converter.convert_dft_input()




This reads all the data, and stores it in the file :file:`case.h5`.


In this step, the files :file:`case.ctqmcout` and


:file:`case.symqmc`


have to be present in the working directory.




After this step, all the necessary information for the DMFT loop is


stored in the hdf5 archive, where the string variable


`Converter.hdf_filename` gives the file name of the archive.




At this point you should use the method :meth:`dos_wannier_basis <dft.sumk_dft_tools.SumkDFTTools.dos_wannier_basis>`


contained in the module :class:`SumkDFTTools <dft.sumk_dft_tools.SumkDFTTools>` to check the density of


states of the Wannier orbitals (see :ref:`analysis`).




You have now everything for performing a DMFT calculation, and you can


proceed with the section on :ref:`singleshot DFT+DMFT calculations <singleshot>`.




Data for postprocessing


""""""""""""""""""""""""




In case you want to do postprocessing of your data using the module


:class:`SumkDFTTools <dft.sumk_dft_tools.SumkDFTTools>`, some more files


have to be converted to the hdf5 archive. For instance, for


calculating the partial density of states or partial charges


consistent with the definition of Wien2k, you have to invoke::




Converter.convert_parproj_input()




This reads and converts the files :file:`case.parproj` and


:file:`case.sympar`.




If you want to plot band structures, one has to do the


following. First, one has to do the Wien2k calculation on the given


:math:`\mathbf{k}`path, and run :program:`dmftproj` on that path:




 `x lapw1 band`


 `x lapw2 band almd`


 `dmftproj band`






Again, maybe with the optional additional extra flags according to


Wien2k. Now we use a routine of the converter module allows to read


and convert the input for :class:`SumkDFTTools <dft.sumk_dft_tools.SumkDFTTools>`::




Converter.convert_bands_input()




After having converted this input, you can further proceed with the


:ref:`analysis`. For more options on the converter module, please have


a look at the :ref:`refconverters` section of the reference manual.




Data for transport calculations


"""""""""""""""""""""""""""""""




For the transport calculations, the situation is a bit more involved,


since we need also the :program:`optics` package of Wien2k. Please


look at the section on :ref:`Transport` to see how to do the necessary


steps, including the conversion.




Interface with VASP







.. warning::


The VASP interface is in the alphaversion and the VASP part of it is not


yet publicly released. The documentation may, thus, be subject to changes


before the final release.




Note that this VASP interface relies on new options introduced since version


5.4.x.




Additionally, the interface only works correctly if the kpoint symmetries


are turned off during the VASP run (ISYM=1).




The output of raw (nonnormalized) projectors is controlled by an INCAR option


LOCPROJ whose complete syntax is described in the VASP documentaion.




The definition of a projector set starts with specifying which sites


and which local states we are going to project onto.


This information is provided by option LOCPROJ




 `LOCPROJ = <sites> : <shells> : <projector type>`




where `<sites>` represents a list of site indices separated by spaces,


with the indices corresponding to the site position in the POSCAR file;


`<shells>` specifies local states (e.g. :math:`s`, :math:`p`, :math:`d`,


:math:`d_{x^2y^2}`, etc.);


`<projector type>` chooses a particular type of the local basis function.




Some projector types also require parameters `EMIN`, `EMAX` in INCAR to


be set to define an (approximate) energy window corresponding to the


valence states.




When either a selfconsistent (`ICHARG < 10`) or a nonselfconsistent


(`ICHARG >= 10`) calculation is done VASP produces file `LOCPROJ` which


will serve as the main input for the conversion routine.






Conversion for the DMFT selfconsistency cycle


""""""""""""""""""""""""""""""""""""""""""""""




In order to use the projectors generated by VASP for defining an


impurity problem they must be processed, i.e. normalized, possibly


transformed, and then converted to a format suitable for DFT_tools scripts.




Currently, it is necessary to add the Fermi energy by hand as the fifth value


in the first line of the LOCPROJ file before the next steps can be executed.




The processing of projectors is performed by the program :program:`plovasp`


invoked as




 `plovasp <plo.cfg>`




where `<plo.cfg>` is a input file controlling the conversion of projectors.




The format of input file `<plo.cfg>` is described in details in


:ref:`plovasp`. Here we just give a simple example for the case


of SrVO3:




.. literalinclude:: images_scripts/srvo3.cfg




A projector shell is defined by a section `[Shell 1]` where the number


can be arbitrary and used only for user convenience. Several


parameters are required




 **IONS**: list of site indices which must be a subset of indices


given earlier in `LOCPROJ`.


 **LSHELL**: :math:`l`quantum number of the projector shell; the corresponding


orbitals must be present in `LOCPROJ`.


 **EWINDOW**: energy window in which the projectors are normalized;


note that the energies are defined with respect to the Fermi level.




Option **TRANSFORM** is optional but here it is specified to extract


only three :math:`t_{2g}` orbitals out of five `d` orbitals given by


:math:`l = 2`.




For the conversion to a h5 file we use on the python level (in analogy to the Wien2kConverter)::




from triqs_dft_tools.converters.vasp_converter import *


Converter = VaspConverter(filename = filename)


Converter.convert_dft_input()




As usual, the resulting h5file can then be used with the SumkDFT class.




Note that the automatic detection of the correct blockstructure might fail for VASP inputs.


This can be circumvented by increase the :class:`SumkDFT <dft.sumk_dft.SumkDFT>` threshold to e.g.::




SK.analyse_block_structure(threshold = 1e4)




However, only do this after a careful study of the density matrix and the dos in the wannier basis.




A general H(k)







In addition to the more complicated Wien2k converter,


:program:`DFTTools` contains also a light converter. It takes only


one inputfile, and creates the necessary hdf outputfile for


the DMFT calculation. The header of this input file has a defined


format, an example is the following (do not use the text/comments in your


input file):




.. literalinclude:: images_scripts/case.hk




The lines of this header define




#. Number of :math:`\mathbf{k}`points used in the calculation


#. Electron density for setting the chemical potential


#. Number of total atomic shells in the hamiltonian matrix. In short,


this gives the number of lines described in the following. IN the


example file give above this number is 2.


#. The next line(s) contain four numbers each: index of the atom, index


of the equivalent shell, :math:`l` quantum number, dimension


of this shell. Repeat this line for each atomic shell, the number


of the shells is given in the previous line.




In the example input file given above, we have two inequivalent


atomic shells, one on atom number 1 with a full dshell (dimension 5),


and one on atom number 2 with one pshell (dimension 3).




Other examples for these lines are:




#. Full dshell in a material with only one correlated atom in the


unit cell (e.g. SrVO3). One line is sufficient and the numbers


are `1 1 2 5`.


#. Full dshell in a material with two equivalent atoms in the unit


cell (e.g. FeSe): You need two lines, one for each equivalent


atom. First line is `1 1 2 5`, and the second line is


`2 1 2 5`. The only difference is the first number, which tells on


which atom the shell is located. The second number is the


same in both lines, meaning that both atoms are equivalent.


#. t2g orbitals on two nonequivalent atoms in the unit cell: Two


lines again. First line is `1 1 2 3`, second line `2 2 2 3`. The


difference to the case above is that now also the second number


differs. Therefore, the two shells are treated independently in


the calculation.


#. dp Hamiltonian in a system with two equivalent atoms each in


the unit cell (e.g. FeSe has two Fe and two Se in the unit


cell). You need for lines. First line `1 1 2 5`, second


line


`2 1 2 5`. These two lines specify Fe as in the case above. For the p


orbitals you need line three as `3 2 1 3` and line four


as `4 2 1 3`. We have 4 atoms, since the first number runs from 1 to 4,


but only two inequivalent atoms, since the second number runs


only form 1 to 2.


.. toctree::


:maxdepth: 2




Note that the total dimension of the hamiltonian matrices that are


read in is the sum of all shell dimensions that you specified. For


example number 4 given above we have a dimension of 5+5+3+3=16. It is important


that the order of the shells that you give here must be the same as


the order of the orbitals in the hamiltonian matrix. In the last


example case above the code assumes that matrix index 1 to 5


belongs to the first d shell, 6 to 10 to the second, 11 to 13 to


the first p shell, and 14 to 16 the second p shell.




#. Number of correlated shells in the hamiltonian matrix, in the same


spirit as line 3.


conv_wien2k


conv_vasp


conv_W90


conv_generalhk




#. The next line(s) contain six numbers: index of the atom, index


of the equivalent shell, :math:`l` quantum number, dimension


of the correlated shells, a spinorbit parameter, and another


parameter defining interactions. Note that the latter two


parameters are not used at the moment in the code, and only kept


for compatibility reasons. In our example file we use only the


dshell as correlated, that is why we have only one line here.




#. The last line contains several numbers: the number of irreducible


representations, and then the dimensions of the irreps. One


possibility is as the example above, another one would be 2


2 3. This would mean, 2 irreps (eg and t2g), of dimension 2 and 3,


resp.




After these header lines, the file has to contain the Hamiltonian


matrix in orbital space. The standard convention is that you give for


each :math:`\mathbf{k}`point first the matrix of the real part, then the


matrix of the imaginary part, and then move on to the next :math:`\mathbf{k}`point.




The converter itself is used as::




from triqs_dft_tools.converters.hk_converter import *


Converter = HkConverter(filename = hkinputfile)


Converter.convert_dft_input()




where :file:`hkinputfile` is the name of the input file described


above. This produces the hdf file that you need for a DMFT calculation.




For more options of this converter, have a look at the


:ref:`refconverters` section of the reference manual.






Wannier90 Converter







Using this converter it is possible to convert the output of


`wannier90 <http://wannier.org>`_


Maximally Localized Wannier Functions (MLWF) and create a HDF5 archive


suitable for oneshot DMFT calculations with the


:class:`SumkDFT <dft.sumk_dft.SumkDFT>` class.




The user must supply two files in order to run the Wannier90 Converter:




#. The file :file:`seedname_hr.dat`, which contains the DFT Hamiltonian


in the MLWF basis calculated through :program:`wannier90` with ``hr_plot = true``


(please refer to the :program:`wannier90` documentation).


#. A file named :file:`seedname.inp`, which contains the required


information about the :math:`\mathbf{k}`point mesh, the electron density,


the correlated shell structure, ... (see below).




Here and in the following, the keyword ``seedname`` should always be intended


as a placeholder for the actual prefix chosen by the user when creating the


input for :program:`wannier90`.


Once these two files are available, one can use the converter as follows::




from triqs_dft_tools.converters import Wannier90Converter


Converter = Wannier90Converter(seedname='seedname')


Converter.convert_dft_input()




The converter input :file:`seedname.inp` is a simple text file with


the following format (do not use the text/comments in your input file):




.. literalinclude:: images_scripts/LaVO3_w90.inp




The example shows the input for the perovskite crystal of LaVO\ :sub:`3`


in the roomtemperature `Pnma` symmetry. The unit cell contains four


symmetryequivalent correlated sites (the V atoms) and the total number


of electrons per unit cell is 8 (see second line).


The first line specifies how to generate the :math:`\mathbf{k}`point


mesh that will be used to obtain :math:`H(\mathbf{k})`


by Fourier transforming :math:`H(\mathbf{R})`.


Currently implemented options are:




* :math:`\Gamma`centered uniform grid with dimensions


:math:`n_{k_x} \times n_{k_y} \times n_{k_z}`;


specify ``0`` followed by the three grid dimensions,


like in the example above


* :math:`\Gamma`centered uniform grid with dimensions


automatically determined by the converter (from the number of


:math:`\mathbf{R}` vectors found in :file:`seedname_hr.dat`);


just specify ``1``




Inside :file:`seedname.inp`, it is crucial to correctly specify the


correlated shell structure, which depends on the contents of the


:program:`wannier90` output :file:`seedname_hr.dat` and on the order


of the MLWFs contained in it. In this example we have four lines for the


four V atoms. The MLWFs were constructed for the t\ :sub:`2g` subspace, and thus


we set ``l`` to 2 and ``dim`` to 3 for all V atoms. Further the spinorbit coupling (``SO``)


is set to 0 and ``irep`` to 0.


As in this example all 4 V atoms are equivalent we set ``sort`` to 0. We note


that, e.g., for a magnetic DMFT calculation the correlated atoms can be made


inequivalent at this point by using different values for ``sort``.




The number of MLWFs must be equal to, or greater than the total number


of correlated orbitals (i.e., the sum of all ``dim`` in :file:`seedname.inp`).


If the converter finds fewer MLWFs inside :file:`seedname_hr.dat`, then it


stops with an error; if it finds more MLWFs, then it assumes that the


additional MLWFs correspond to uncorrelated orbitals (e.g., the O\ `2p` shells).


When reading the hoppings :math:`\langle w_i  H(\mathbf{R})  w_j \rangle`


(where :math:`w_i` is the :math:`i`th MLWF), the converter also assumes that


the first indices correspond to the correlated shells (in our example,


the Vt\ :sub:`2g` shells). Therefore, the MLWFs corresponding to the


uncorrelated shells (if present) must be listed **after** those of the


correlated shells.


With the :program:`wannier90` code, this can be achieved by listing the


projections for the uncorrelated shells after those for the correlated shells.


In our `Pnma`LaVO\ :sub:`3` example, for instance, we could use::




Begin Projections


V:l=2,mr=2,3,5:z=0,0,1:x=1,1,0


O:l=1:mr=1,2,3:z=0,0,1:x=1,1,0


End Projections




where the ``x=1,1,0`` option indicates that the VO bonds in the octahedra are


rotated by (approximatively) 45 degrees with respect to the axes of the `Pbnm` cell.




The converter will analyse the matrix elements of the local Hamiltonian


to find the symmetry matrices `rot_mat` needed for the globaltolocal


transformation of the basis set for correlated orbitals


(see section :ref:`hdfstructure`).


The matrices are obtained by finding the unitary transformations that diagonalize


:math:`\langle w_i  H_I(\mathbf{R}=0,0,0)  w_j \rangle`, where :math:`I` runs


over the correlated shells and `i,j` belong to the same shell (more details elsewhere...).


If two correlated shells are defined as equivalent in :file:`seedname.inp`,


then the corresponding eigenvalues have to match within a threshold of 10\ :sup:`5`,


otherwise the converter will produce an error/warning.


If this happens, please carefully check your data in :file:`seedname_hr.dat`.


This method might fail in nontrivial cases (i.e., more than one correlated


shell is present) when there are some degenerate eigenvalues:


so far tests have not shown any issue, but one must be careful in those cases


(the converter will print a warning message).




The current implementation of the Wannier90 Converter has some limitations:




* Since :program:`wannier90` does not make use of symmetries (symmetryreduction


of the :math:`\mathbf{k}`point grid is not possible), the converter always


sets ``symm_op=0`` (see the :ref:`hdfstructure` section).


* No charge selfconsistency possible at the moment.


* Calculations with spinorbit (``SO=1``) are not supported.


* The spinpolarized case (``SP=1``) is not yet tested.


* The postprocessing routines in the module


:class:`SumkDFTTools <dft.sumk_dft_tools.SumkDFTTools>`


were not tested with this converter.


* ``proj_mat_all`` are not used, so there are no projectors onto the


uncorrelated orbitals for now.






MPI issues





==========




The interface packages are written such that all the file operations


are done only on the master node. In general, the philosophy of the


@ 495,8 +30,9 @@ yourself, you have to *manually* broadcast it to the nodes. An


exception to this rule is when you use routines from :class:`SumkDFT <dft.sumk_dft.SumkDFT>`


or :class:`SumkDFTTools <dft.sumk_dft_tools.SumkDFTTools>`, where the broadcasting is done for you.






Interfaces to other packages





============================




Because of the modular structure, it is straight forward to extend the :ref:`TRIQS <triqslibs:welcome>` package


in order to work with other bandstructure codes. The only necessary requirement is that



@ 106,15 +106,15 @@ are present, or if the calculation should start from scratch::


previous_runs = 0


previous_present = False


if mpi.is_master_node():


f = HDFArchive(dft_filename+'.h5','a')


if 'dmft_output' in f:


ar = f['dmft_output']


if 'iterations' in ar:


previous_present = True


previous_runs = ar['iterations']


with HDFArchive(dft_filename+'.h5','a') as f:


if 'dmft_output' in f:


ar = f['dmft_output']


if 'iterations' in ar:


previous_present = True


previous_runs = ar['iterations']


else:


f.create_group('dmft_output')


del f




previous_runs = mpi.bcast(previous_runs)


previous_present = mpi.bcast(previous_present)




@ 126,9 +126,8 @@ double counting values of the last iteration::




if previous_present:


if mpi.is_master_node():


ar = HDFArchive(dft_filename+'.h5','a')


S.Sigma_iw << ar['dmft_output']['Sigma_iw']


del ar


with HDFArchive(dft_filename+'.h5','r') as ar:


S.Sigma_iw << ar['dmft_output']['Sigma_iw']




S.Sigma_iw << mpi.bcast(S.Sigma_iw)


chemical_potential,dc_imp,dc_energ = SK.load(['chemical_potential','dc_imp','dc_energ'])


@ 153,11 +152,10 @@ functions) can be necessary in order to ensure convergence::


mix = 0.8 # mixing factor


if (iteration_number>1 or previous_present):


if mpi.is_master_node():


ar = HDFArchive(dft_filename+'.h5','a')


mpi.report("Mixing Sigma and G with factor %s"%mix)


S.Sigma_iw << mix * S.Sigma_iw + (1.0mix) * ar['dmft_output']['Sigma_iw']


S.G_iw << mix * S.G_iw + (1.0mix) * ar['dmft_output']['G_iw']


del ar


with HDFArchive(dft_filename+'.h5','r') as ar:


mpi.report("Mixing Sigma and G with factor %s"%mix)


S.Sigma_iw << mix * S.Sigma_iw + (1.0mix) * ar['dmft_output']['Sigma_iw']


S.G_iw << mix * S.G_iw + (1.0mix) * ar['dmft_output']['G_iw']


S.G_iw << mpi.bcast(S.G_iw)


S.Sigma_iw << mpi.bcast(S.Sigma_iw)





@ 1,37 +1,35 @@


.. _plovasp:




PLOVasp input file


==================


PLOVasp


=======




The general purpose of the PLOVasp tool is to transform


raw, nonnormalized projectors generated by VASP into normalized


projectors corresponding to userdefined projected localized orbitals (PLO).


The PLOs can then be used for DFT+DMFT calculations with or without


charge selfconsistency. PLOVasp also provides some utilities


for basic analysis of the generated projectors, such as outputting


density matrices, local Hamiltonians, and projected


density of states.


The general purpose of the PLOVasp tool is to transform raw, nonnormalized


projectors generated by VASP into normalized projectors corresponding to


userdefined projected localized orbitals (PLO). The PLOs can then be used for


DFT+DMFT calculations with or without charge selfconsistency. PLOVasp also


provides some utilities for basic analysis of the generated projectors, such as


outputting density matrices, local Hamiltonians, and projected density of


states.




PLOs are determined by the energy window in which the raw projectors


are normalized. This allows to define either atomiclike strongly


localized Wannier functions (large energy window) or extended


Wannier functions focusing on selected lowenergy states (small


energy window).


PLOs are determined by the energy window in which the raw projectors are


normalized. This allows to define either atomiclike strongly localized Wannier


functions (large energy window) or extended Wannier functions focusing on


selected lowenergy states (small energy window).




In PLOVasp all projectors sharing the same energy window are combined


into a `projector group`. Technically, this allows one to define


several groups with different energy windows for the same set of


raw projectors. Note, however, that DFTtools does not support projector


groups at the moment but this feature might appear in future releases.


In PLOVasp, all projectors sharing the same energy window are combined into a


`projector group`. Technically, this allows one to define several groups with


different energy windows for the same set of raw projectors. Note, however,


that DFTtools does not support projector groups at the moment but this feature


might appear in future releases.




A set of projectors defined on sites realted to each other either by symmetry


or by sort along with a set of :math:`l`, :math:`m` quantum numbers forms a


`projector shell`. There could be several projectors shells in a


projector group, implying that they will be normalized within


the same energy window.


A set of projectors defined on sites related to each other either by symmetry


or by an atomic sort, along with a set of :math:`l`, :math:`m` quantum numbers,


forms a `projector shell`. There could be several projectors shells in a


projector group, implying that they will be normalized within the same energy


window.




Projector shells and groups are specified by a userdefined input file


whose format is described below.


Projector shells and groups are specified by a userdefined input file whose


format is described below.




Input file format





@ 43,7 +41,7 @@ Parameters (or 'options') are grouped into sections specified as


A PLOVasp input file can contain three types of sections:




#. **[General]**: includes parameters that are independent


of a particular projector set, such as the Fermi level, additional


of a particular projector set, such as the Fermi level, additional


output (e.g. the density of states), etc.


#. **[Group <Ng>]**: describes projector groups, i.e. a set of


projectors sharing the same energy window and normalization type.


@ 51,8 +49,8 @@ A PLOVasp input file can contain three types of sections:


there should be no more than one projector group.


#. **[Shell <Ns>]**: contains parameters of a projector shell labelled


with `<Ns>`. If there is only one group section and one shell section,


the group section can be omitted and its required parameters can be


given inside the single shell section.


the group section can be omitted but in this case, the group required


parameters must be provided inside the shell section.




Section [General]


"""""""""""""""""


@ 61,24 +59,24 @@ The entire section is optional and it contains three parameters:




* **BASENAME** (string): provides a base name for output files.


Default filenames are :file:`vasp.*`.


* **DOSMESH** ([float float] integer): if this parameter is given


projected density of states for each projected orbital will be


* **DOSMESH** ([float float] integer): if this parameter is given,


the projected density of states for each projected orbital will be


evaluated and stored to files :file:`pdos_<n>.dat`, where `n` is the


orbital number. The energy


mesh is defined by three numbers: `EMIN` `EMAX` `NPOINTS`. The first two


orbital index. The energy


mesh is defined by three numbers: `EMIN` `EMAX` `NPOINTS`. The first two


can be omitted in which case they are taken to be equal to the projector


energy window. **Important note**: at the moment this option works


only if the tetrahedron integration method (`ISMEAR = 4` or `5`)


is used in VASP to produce `LOCPROJ`.


* **EFERMI** (float): provides the Fermi level. This value overrides


the one extracted from VASP output files.






There are no required parameters in this section.




Section [Shell]


"""""""""""""""




This section specifies a projector shell. Each shell section must be


This section specifies a projector shell. Each `[Shell]` section must be


labeled by an index, e.g. `[Shell 1]`. These indices can then be referenced


in a `[Group]` section.




@ 87,17 +85,17 @@ In each `[Shell]` section two parameters are required:


* **IONS** (list of integer): indices of sites included in the shell.


The sites can be given either by a list of integers `IONS = 5 6 7 8`


or by a range `IONS = 5..8`. The site indices must be compatible with


POSCAR file.


the POSCAR file.


* **LSHELL** (integer): :math:`l` quantum number of the desired local states.




It is important that a given combination of site indices and local states


given by `LSHELL` must be present in LOCPROJ file.


given by `LSHELL` must be present in the LOCPROJ file.




There are additional optional parameters that allow one to transform


the local states:




* **TRANSFORM** (matrix): local transformation matrix applied to all states


in the projector shell. The matrix is defined by (multiline) block


in the projector shell. The matrix is defined by a (multiline) block


of floats, with each line corresponding to a row. The number of columns


must be equal to :math:`2 l + 1`, with :math:`l` given by `LSHELL`. Only real matrices


are allowed. This parameter can be useful to select certain subset of


@ 105,14 +103,14 @@ the local states:


* **TRANSFILE** (string): name of the file containing transformation


matrices for each site. This option allows for a fullfledged functionality


when it comes to local state transformations. The format of this file


is described in :ref:`_transformation_file`.


is described :ref:`below <transformation_file>`.




Section [Group]


"""""""""""""""




Each defined projector shell must be part of a projector group. In the current


implementation of DFTtools only a single group is supported which can be


labeled by any integer, e.g. `[Group 1]`. This implies that all projector shells


implementation of DFTtools only a single group (labelled by any integer, e.g. `[Group 1]`)


is supported. This implies that all projector shells


must be included in this group.




Required parameters for any group are the following:


@ 121,34 +119,49 @@ Required parameters for any group are the following:


All defined shells must be grouped.


* **EWINDOW** (float float): the energy window specified by two floats: bottom


and top. All projectors in the current group are going to be normalized within


this window.


this window. *Note*: This option must be specified inside the `[Shell]` section


if only one shell is defined and the `[Group]` section is omitted.




Optional group parameters:




* **NORMALIZE** (True/False): specifies whether projectors in the group are


to be noramlized. The default value is **True**.


to be normalized. The default value is **True**.


* **NORMION** (True/False): specifies whether projectors are normalized on


a persite (perion) basis. That is, if `NORMION = True` the orthogonality


a persite (perion) basis. That is, if `NORMION = True`, the orthogonality


condition will be enforced on each site separately but the Wannier functions


on different sites will not be orthogonal. If `NORMION = False` Wannier functions


on different sites will not be orthogonal. If `NORMION = False`, the Wannier functions


on different sites included in the group will be orthogonal to each other.






.. _transformation_file




.. _transformation_file:




File of transformation matrices


"""""""""""""""""""""""""""""""




.. warning::


The description below applies only to collinear cases (i.e. without spinorbit


coupling). In this case the matrices are spinindependent.


The description below applies only to collinear cases (i.e., without spinorbit


coupling). In this case, the matrices are spinindependent.




The file specified by option `TRANSFILE` contains transformation matrices


for each ion. Each line must contain a series of floats whose number is either equal to


the number of orbitals :math:`N_{orb}` (in this case the transformation matrices


are assumed to be real) or to :math:`2 N_{orb}` (for the complex transformation matrices).


The number of lines :math:`N` must be a multiple of the number of ions :math:`N_{ion}`


The total number of lines :math:`N` must be a multiple of the number of ions :math:`N_{ion}`


and the ratio :math:`N / N_{ion}`, then, gives the dimension of the transformed


orbital space. The lines with floats can be separated by any number of empty or


comment lines which are ignored.


comment lines (starting from `#`), which are ignored.




A very simple example is a transformation matrix that selects the :math:`t_{2g}` manifold.


For two correlated sites, one can define the file as follows:


::




# Site 1


1.0 0.0 0.0 0.0 0.0


0.0 1.0 0.0 0.0 0.0


0.0 0.0 0.0 1.0 0.0




# Site 2


1.0 0.0 0.0 0.0 0.0


0.0 1.0 0.0 0.0 0.0


0.0 0.0 0.0 1.0 0.0





@ 96,12 +96,11 @@ The converter :meth:`convert_transport_input <dft.converters.wien2k_converter.Wi


reads the required data of the Wien2k output and stores it in the `dft_transp_input` subgroup of your hdf file.


Additionally we need to read and set the self energy, the chemical potential and the double counting::




ar = HDFArchive('case.h5', 'a')


SK.set_Sigma([ar['dmft_output']['Sigma_w']])


chemical_potential,dc_imp,dc_energ = SK.load(['chemical_potential','dc_imp','dc_energ'])


SK.set_mu(chemical_potential)


SK.set_dc(dc_imp,dc_energ)


del ar


with HDFArchive('case.h5', 'r') as ar:


SK.set_Sigma([ar['dmft_output']['Sigma_w']])


chemical_potential,dc_imp,dc_energ = SK.load(['chemical_potential','dc_imp','dc_energ'])


SK.set_mu(chemical_potential)


SK.set_dc(dc_imp,dc_energ)




As next step we can calculate the transport distribution :math:`\Gamma_{\alpha\beta}(\omega)`::





@ 24,7 +24,7 @@ provides a generic interface for oneshot DFT+DMFT calculations, where


only the singleparticle Hamiltonian in orbital space has to be


provided.




Learn how to use this package in the :ref:`documentation`.


Learn how to use this package in the :ref:`documentation` and the :ref:`tutorials`.






.. toctree::



25
doc/tutorials.rst
Normal file
25
doc/tutorials.rst
Normal file
@ 0,0 +1,25 @@


.. module:: triqs_dft_tools




< 