ISMEAR=0 work?

[quantumable]

Dear Triqs devs,

I have successfully followed the tutorial you proposed for the DFT+DMFT calculation for the case of SrVO3. I have a problem with my system which is a molecule that I do not use the tetrahedron method. I use ISMEAR=0. But the system trash when "plovasp plo.cfg". Can you tell me if the code works with ISMEAR=0 or if you have a suggestion when I use ISMEAR=0?

[the-hampel]

Hi Olivier,

Can you tell me a bit more about the error you observe? That is not really helping me to identify the problem. I can say, that the Vasp converter (are you talking about the Vasp converter? Please make that clear!) works for all ISMEAR values. The only thing that only works for ISMEAR=-5 is the calculation of the DOS in plovasp . So probably you have the tag DOSMESH in your plo.cfg? Otherwise there should be no problems.

• Alex

[quantumable]

thank you for your reply. indeed by removing the DOSMESH parameter it works. just to be sure to have understood the different parameters corresponding to the energy windows. Emin and Emax represent here the energy window where we have an important weight of the target orbitals. and the EWINDOW parameter represents (Emin-Ef; Emax-Ef) ?

Olivier

[the-hampel]

Very good. Yes indeed. The energy window is given relative to the Fermi Level as you write. Importantly the window also determines in which window the projectors are orthonormalized. A smaller window will produce more extended projector functions, but occupations closer to band fillings (it will spread some of the electrons on tails to other orbitals), wheres a larger window will produce more localized projectors, because weight can live on other bands. This is pretty much up to you to decide. Depending on the problem and the physics you want to capture.

Here is an example for SrMoO3 for different choices of windows:

• gray: VASP total DOS (no good kpoint convergence, just for illustration)
• purple: 3 projectors for the 3 t2g orbitals at the Fermi level with window -2.5 to 2 eV
• orange: same projectors but for window -9 to 9 eV. You can see less DOS around E_f, but some weight at lower energies where the oxygens are
• blue 5 projectors for all 5 d orbitals in the larger window

[quantumable]

I work on the Kondo effect. I chose EMIN=-18eV EMAX=5.
I have some questions:

Since I have a magnetic system as in the example, why is the non-magnetic calculation done during the vasp calculation? in the INCAR file I have this for example LORBIT=14 LOCPROJ = 1 : d : Pr 2 LOCPROJ = 2 4 6 9 : p : Pr 2

the parameter "IONS"(plo.cfg) is not clear for me. how to define the shell for the 4 atoms of N interacting with the atoms subject of the correlation in the file? like here? or it is necessary to define for each atom a shell

BASENAME = Mn [Group 1] SHELLS = 1 2 EWINDOW = -5 4 NORMION = False NORMALIZE = True [Shell 1] # Mn d shell LSHELL = 2 IONS = 1 CORR = True TRANSFORM = 1.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0 1.0 [Shell 2] # N p shell LSHELL = 1 IONS = 2 4 6 9 CORR = False TRANSFORM = 1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1.0

[quantumable]

I also have a problem with the cript for the calculation of the local lattice green's function Nio_local_lattice_GF.py from the tutorial when I run it I have this error

Starting run with 112 MPI rank(s) at : 2021-08-14 00:59:42.279120 Traceback (most recent call last): File "/home/olivier/WORK_tuto_Ni/ NiO_local_lattice_GF.py", line 59, in n_orbs = SK.proj_mat_csc.shape[2] AttributeError: 'NoneType' object has no attribute 'shape' Traceback (most recent call last): File "/home/olivier/WORK_tuto_Ni/NiO_local_lattice_GF.py", line 59, in n_orbs = SK.proj_mat_csc.shape[2] AttributeError: 'NoneType' object has no attribute 'shape' Traceback (most recent call last):

how to solve this?

[the-hampel]

These are many questions. I cannot answer all of your system related questions. I can only try to answer some technical questions / issues you asked here. Let's start here:

I also have a problem with the cript for the calculation of the local lattice green's function Nio_local_lattice_GF.py from the tutorial when I run it I have this error

Starting run with 112 MPI rank(s) at : 2021-08-14 00:59:42.279120 Traceback (most recent call last): File "/home/olivier/WORK_tuto_Ni/ NiO_local_lattice_GF.py", line 59, in n_orbs = SK.proj_mat_csc.shape[2] AttributeError: 'NoneType' object has no attribute 'shape' Traceback (most recent call last): File "/home/olivier/WORK_tuto_Ni/NiO_local_lattice_GF.py", line 59, in n_orbs = SK.proj_mat_csc.shape[2] AttributeError: 'NoneType' object has no attribute 'shape' Traceback (most recent call last):

how to solve this?

I think the error message is pretty clear. The object SK.proj_mat_csc does not exist. I checked the script. Which is actually the fille NiO_local_lattice_GF.py and I think there is a mistake there. I will fix that. You have to change line 59 to

n_orbs = SK.proj_mat.shape[2]

. Let me know if that works. I will try as well. Next let's take a look at this error:

File "/home2020/home/MnPc_DMFT/f.py", line 139, in S.solve(h_int = H, p) File "/home2020/home/triqs/install/lib/python3.8/site-packages/triqs_cthyb/solver.py", line 140, in solve solve_status = SolverCore.solve(self, params_kw) RuntimeError: .. Error occurred at Sun Aug 15 10:21:17 2021

.. Error .. calling C++ overload .. solve() -> void .. in implementation of method SolverCore.solve .. C++ error was : .. Triqs runtime error at /home2020/home/triqs/cthyb.src/c++/triqs_cthyb/solver_core.cpp : 141

Largest imaginary element of delta(infty) e.g. of the local part of G0: 0.000124901, is larger than the set parameter imag_threshold 1e-13 .. Error occurred on node 22

This error occurs when your projectors are not well converged and produce imaginary overlap between orbitals. Like imaginary hopping amplitudes. The script is doing exactly what it is supposed to do and crashes because the input is not good. In this case the cthyb solver complains to you. Please try to converge your input KS states from VASP better before doing the projection. Make sure that the column rms is converged down to 10-8 or lower. See also here for some details: https://flatironinstitute.github.io/solid_dmft/md_notes/vasp_csc.html#convergence-of-projectors-with-vasp .

If you are actually treating a molecule it might be beneficial to actually use the wannier90 interface instead. Wannier90 MLWF are way more controlled for hyb orbitals than projectors and you can visualize them. Did you look into that?

[the-hampel]

I fixed now the example with commit https://github.com/TRIQS/dft_tools/commit/a1b5421864a53ce17aea81cdd2ca803db1e269b0 . You do not necessarily update your installation, but indeed the tutorial was wrong. I fixed both the plo.cfg and the converter.py script. The NiO_local_lattice_GF.py was doing the right thing, but the converter was not correctly setup. Let me know if there are still problems with that. I also changed the INCAR file a bit for NiO, to have a bitter better accuracy. The changes can also be directly be seen in the doc: https://triqs.github.io/dft_tools/unstable/tutorials/nio_csc.html

[quantumable]

I modified the file plo.cfg converter.py nio.py I have an error during the calculation using nio.py error:

Traceback (most recent call last): File "/home/TUTO_DMFT/nio.py", line 9, in from triqs_dft_tools.block_structure import gf_struct_flatten ImportError: cannot import name 'gf_struct_flatten' from 'triqs_dft_tools.block_structure' (/home/triqs/install/lib/python3.8/site-packages/triqs_dft_tools/block_structure.py)

but this seems to run with the script "dmft_ctqmc.py" that this site proposes (you can download the file "triqs3.tar" here http://www.itp.uni-bremen.de/ag-wehling/teaching/dftdmft-tutorial/triqs2-to-triqs3/)

[quantumable]

another question: I did the projection LOCPROJ = 1 : d : Pr ; LOCPROJ = 2 4 6 9 : p : Pr how to define the projections in the plo.cfg file? i did this and got some errors. [Shell 2] # N p shell LSHELL = 1 IONS = 2 4 6 9 CORR = False TRANSFORM = 1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1.0

how to define the parameter IONS for the SHELL which comprises 4 atoms whose projections are made on 4 uncorrelated atoms

I tried IONS = [2 4 6 9] and IONS = [2, 4, 6, 9]

[the-hampel]

Which version of DFTTools do you have installed? The error is related to the fact that the function gf_struct_flatten on.y exists in the unstable branch of triqs. If you want to use the older triqs installation just take the updated conveter.py and plo.cfg file of the tutorial with old nio.py script. That should work.

[the-hampel]

What exactly is the error for the p-shell? Your IONS flag should work. As the documentation describes:

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 the POSCAR file. Morever, sites can be marked to be identical by grouping them with brackets, i.e. IONS = [5 6] [7 8] will mark the sites 5 and 6 in the POSCAR (and of course also 7 and 8) to be idential. This will mark these correlated site as equivalent, and only one impurity problem per bracket group is generated.

If the sites are equivalent you can put them in brackets . Otherwise not. I would guess that your problem is related to the Transform section of your cfg file. You have to give one trafo matrix for each site. See https://triqs.github.io/dft_tools/unstable/guide/conv_vasp.html#transformation-file for details.

[the-hampel]

Regarding this error:

AssertionError: Negative eigenvalues of the overlap matrix:projectors are ill-defined

This is usually a sign, that the projectors are not well converged! Please check convergence of your KS eigenstates as I pointed out in the first place. Why do you want to keep the O-p states at all, if you are only interested in the Mn-d states? That would make maybe the creation of projectors simpler. This is definitely not a bug in the converter. It just tried to protect the user from doing something wrong.

[the-hampel]

I am glad that the tutorial worked for you now.

I cannot write for you the python scripts in detail to do so. I don't have time for that. From the tutorials of maxent: https://triqs.github.io/maxent/latest/documentation.html this should become more than clear. Did you try those?

The analysis you ask about requires simply plotting the Matsubara Gf objects from triqs. Just load them from the h5 archive and plot them with the triqs plotting routines: https://triqs.github.io/triqs/unstable/documentation/manual/triqs/plotting_protocols/plotting/plotting.html . I believe there are many examples out there how to do this. You can load and plot a self energy simply like this:

from h5 import HDFArchive
from triqs.gf import *
from triqs.plot.mpl_interface import plt,oplot

with HDFArchive('/path_to.h5','r') as h5:
    S_iw = h5['DMFT_results']['Sigma_freq_'+str(0)]

fig, (ax) = plt.subplots(1,1,figsize=(8,5))

ax.oplot(S_iw['up_0'][0,0].imag,'o',label='Im Sigma',markersize=2)

[quantumable]

how did you determine the value of the double counting. how did you choose the value 59 for the example of NiO i can use this value for my system?

[the-hampel]

Sorry this has now really nothing to do anymore with dft_tools. I urge you to read on the theory of DFT+DMFT and the inherit problem of double counting of parts of the exchange-correlation accounted for in DFT. This is highly material specific. I believe here the value is chosen close to the FLL limit DC. Here is a good overview for NiO: https://doi.org/10.1016/j.elspec.2010.05.021 . A good overview for DFT+DMFT can be for example found here: https://www2.physnet.uni-hamburg.de/services/biblio/dissertation/dissfbPhysik/___Volltexte/Michael___Karolak/Michael___Karolak.pdf or in this book: https://doi.org/10.1007/978-3-030-64904-3 .

I will close the issue now. If you have a new specific problem please open a new one.

[quantumable]

I have finished the Nio tutorial and I am now doing the calculation on system and I might have some questions about the code. So I wish we would not close the ticket yet.

[the-hampel]

Github issues are not chat channels. This is only for discussions on a specific question, regarding problems with the code or feature requests. So if you have a new specific question, please open a new issue.