The largest _w90_tolerance_

[Lanlin123]

Hi everyone,
When I did a CSC caculation, I met the error shown as the following figure. Here I have a question that how I choose the largest w90_tolerance to get reasonable result.

[Lanlin123]

Besides, in my calculation, band_energy_modscf defined in code file qe_manager.py can't be found in mod_sef.out file as there is not a line including "(sum(wg*et))". Could you give me some advice? Thanks!

[phibeck]

Hi,
the error tells you that two shells that are equivalent at the ground state level (i.e. at the beginning of your calculation) start to become numerically inequivalent during the CSC workflow.

To avoid the error, you can in principle lower the tolerance in the input file in the [advanced] parameters section, in your case you could set w90_tolerance = 6e-3. In practice, what you should do is increase the accuracy of your calculation to make sure that the errors introduced by the mapping of sites don't grow too large. For this I would recommend increasing the accuracy of your impurity solver (in case it is CT-HYB, here are some guidelines https://triqs.github.io/cthyb/latest/guide/cthyb_convergence_tests.html) and the number of k-points.

Regarding your second question, I believe this will be fixed if you reinstall the latest version of Quantum Espresso. @alberto-carta could you comment on this?

[the-hampel]

Okay so let's discuss a bit the part about the occupations. The change you see in occupations is totally reasonable. You are right that in principle there are three t2g like bands at the Fermi level that are filled 1/6, i.e. one electron in SrVO3. However, in pd-models where you include oxygens the lattice Greens function is now including all the oxygen states (3 x 3 orbitals times 2 for spin) which can holds 18 electrons and are completely filled. This is why you end up with 19 electrons in the lattice Gf. No extracting the local Green's function of the d electrons is now not giving you 1 electron anymore, because the orbitals are not purely made out of the 3 t2g like states but rather atomic like d orbitals that mix with the oxygen. Hence, your orbitals also have some occupation stemming from the O-p orbitals. I think 2.7 is totally reasonable. And the fact that you get the same number in bloch and wannier basis is very good.

Can you take the large kpoint calculation, check that there are no imaginary numbers in svo_hr.dat, and then run solid_dmft using the cthyb solver one DMFT iteration. If that works we go back to ctseg.

[Lanlin123]

Hi @the-hampel,
I have used cthyb solver, and it do work. But the calculation speed is a bit slow. The Accumulating process hasn't finished yet. Files can be accessed from https://github.com/Lanlin123/test-for-SrVO3. As the warmup process was successfully completed, which is different from the ctseg solver case, I think the cthyb sover do work. The problem is with ctseg solver.

[the-hampel]

Hi, the output now looks really good with respect to imaginary elements etc. Nice. Now let's try to understand why ctseg fails. I cloned your repo that you shared and played around with it. The problem is that you try to run the impurity solver with all off-diagonal terms in the hybridization (enforce_off_diag=True), but thanks to your nice wannierization your problem is really diagonal. This you can see in the output of the local Hamiltonian (H_loc0 and rho) in the top. In cthyb there is default cut-off for off-diagonal terms, something like 10^-12 or so, which probably removes the off-diagonal components by default in the solver. However, the ctseg solver does not have this. To help the solver do the following in the input:

enforce_off_diag = False
block_threshold= 1e-5   

This will give you now a more diagonal block_structure:

 | block struct. solver: {'up_0': 1, 'up_1': 1, 'up_2': 1, 'up_3': 1, 'up_4': 1, 'down_0': 1, 'down_1': 1, 'down_2': 1, 'down_3': 1, 'down_4': 1}
  | deg. orbitals : [['up_0', 'up_1', 'up_2', 'down_0', 'down_1', 'down_2'], ['up_3', 'up_4', 'down_3', 'down_4']]

Correctly identifying the t2g and eg as degenerate. With this change in the input file ctseg runs for me (before I could reproduce your problem). Additionally consider:

measure_G_iw=False

That should improve speed further and does not help you much. The setting for the block_structure has always done with care. You have to check afterwards if the correct block structure and degeneracies are detected. This is why by default it is not done.

Let me know if this fixes your problem.

[Lanlin123]

Hi @the-hampel ,
Sorry for the late reply as there are too many things going on recently. I add the tag enforce_off_diag=True in the ctseg solver caculation and it works. The correct block structure and degeneracies are detected. I’m very grateful to you and your team for helping me over a long period of time.

Best regards,
Lanlin.

[the-hampel]

You are very welcome - happy to hear that it works now.

[phibeck]

Hi @Lanlin123, this seems to be a bug in the Wannier90Converter. I've opened an issue in https://github.com/TRIQS/solid_dmft/issues/76. We'll try to address this as soon as possible, thanks for providing input files.

Hi @Lanlin123 the bug you reported should be fixed in the unstable branch of DFTTools. TRIQS/dft_tools#252. You can recompile at it should be gone, or alternatively you can set a disentanglement window (you can make it as large as you want) and that should fix it, too. Let us know if you encounter any more issues.

[Lanlin123]

Hi @phibeck,
Yeah, I see. Thanks for your works.