Conflict between corr_to_inequiv and with_dc

[ZhijieFan]

Hi,

I am recently doing DMFT+DFT calculation on FeSb2. FeSb2 has two equivalent Fe atoms per unit cell. Thus I use the following input parameters.

[model]
lattice = wannier90
seedname = FeSb2
nelec = 28.0
ncor = 2
norb = 5
interaction = kanamori
kanamori = [(5.0, 3.0, 1.0)]
corr_to_inequiv = 0, 0
bvec = [(1.094060, 0.0, 0.0),(0.0, 0.979605, 0.0),(0.0, 0.0, 2.025527)]
nk0 = 2
nk1 = 2
nk2 = 4

[system]
beta = 40
mu = 14.7
with_dc = True

This will raise an IndexError: list index out of range.

Traceback (most recent call last):
File "/home/zhijiefan/software/dcore/lib/python2.7/site-packages/dcore/sumkdft.py", line 283, in
Unexpected error: list index out of range
_main_mpi(args.model_hdf5_file, args.input_file, args.output_file)
File "/home/zhijiefan/software/dcore/lib/python2.7/site-packages/dcore/sumkdft.py", line 198, in _main_mpi
sk.calc_mu(params['prec_mu'])
File "/home/zhijiefan/software/triqs/lib/python2.7/site-packages/triqs_dft_tools/sumk_dft.py", line 1772, in calc_mu
verbosity=3)[0]
File "/home/zhijiefan/software/triqs/lib/python2.7/site-packages/pytriqs/utility/dichotomy.py", line 54, in dichotomy
y1 = function(x)
File "/home/zhijiefan/software/triqs/lib/python2.7/site-packages/triqs_dft_tools/sumk_dft.py", line 1765, in
mu=mu, iw_or_w=iw_or_w, broadening=broadening)
File "/home/zhijiefan/software/triqs/lib/python2.7/site-packages/triqs_dft_tools/sumk_dft.py", line 1720, in total_density
ik=ik, mu=mu, iw_or_w=iw_or_w, with_Sigma=with_Sigma, with_dc=with_dc, broadening=broadening)
File "/home/zhijiefan/software/triqs/lib/python2.7/site-packages/triqs_dft_tools/sumk_dft.py", line 496, in lattice_gf
sigma_minus_dc = self.add_dc(iw_or_w)
File "/home/zhijiefan/software/triqs/lib/python2.7/site-packages/triqs_dft_tools/sumk_dft.py", line 1603, in add_dc
dccont = numpy.dot(self.rot_mat[icrsh], numpy.dot(self.dc_imp[icrsh][
IndexError: list index out of range

The reason for this error is that self.dc_imp[icrsh] only have 1 elemets but icrsh will loop from 0,1.
If we track down this dc_imp, we can found that it calculated in set_dc_imp(self, dm_sh) function in dmft_core.py. The calculation of dc_imp only loops over inequivalent shells which is 1 in my case. Thus if n_inequiv_shells!=n_corr_shells, double counting correction will not work.

Do you have any suggested solution? If I don't use corr_to_inequiv setting the calculation will be too slow using TRIQS/cthyb solver.

Thank you

Zhijie Fan

[shinaoka]

Hi,

Thank you for the feedback.
This is clearly a bug.
I will discuss with other developers.

[ZhijieFan]

Thank you for your reply.
I guess the calculation of dc_imp should probably loop over n_corr_shells. I am not very sure about that. I am still learning dft+dmft.
Hopefully you can come up with a fix soon.

[shinaoka]

I've implemented a fix in the branch "dc_fix".
If you are familiar with git, could you confirm that this fixes your problem?

[ZhijieFan]

Sorry for the late reply. I install the new branch on my test machine. It works now. I will test it on the clustter today.

One more question, I am using triqs/cthyb solver now which is insanely slow for FeSb2 case. I would like to test ALPS/ct-hyb solver. What statistics value (time limit) do you recommend for a 5-orbital system?

Best,
Zhijie

[ZhijieFan]

Hi,

I set Timelimit to 300 but ALPS/ct-hyb solver is raising error:

Acceptance_rate_global_shift was measured on only some of the MPI processes.

Do you have any suggestions?

Best,
Zhijie

[shinaoka]

Hi, that error message means that the timelimit is too short to thermalize Monte Carlo sampling.
Could you show me the whole output from DCore?
Then, I could see if there is more room for improvement.

[ZhijieFan]

Attached this entire folder of the calculation with both input and outputs. The delta.txt in work/imp_shell0_ite1 is removed due to large size.

The simulation of FeSb2 seems to be very troublesome and problematic. The output using triqs/cthyb solver also gives unphysical self-energies.

Run_6_alsp.zip

[shinaoka]

OK, shall we move to #83 and close this issue?

[shinaoka]

The fix has been integrated into the develop branch.