Wrong gw for D=0

[aeantipov]

Succesfully installed and compiled TRIQS. I have made a run of example aim.py ( http://ipht.cea.fr/triqs/doc/user_manual/solvers/aim.html ). Everything is fine, gw over matsubaras looks smooth. The output for D=0.2 is:

However, as soon as i turn off the hybridization with the bath (D=0), I get weird imaginary frequency dependent green's function. The output for D=0 is :

Here is the diff of script against aim.py from the example (the error persists with increasing the number of QMC cycles):

antipov@r2d2_v2 ~/calc/triqs_test $ diff aim.py aim_backup.py 
5,6c5,6
D, V, U = 1.0, 0.0, 4.0
e_f, Beta = -U/2.0, 10

---

> D, V, U = 1.0, 0.2, 4.0
> e_f, Beta = -U/2.0, 50
15c15
         N_Cycles  = 100000,                      # Number of QMC cycles

---
>            N_Cycles  = 500000,                      # Number of QMC cycles

I assume it comes from a zero determinant in QMC since Delta=0.

[mferrero]

It indeed come from a zero determinant in the CTQMC. The Green's function is measured from the configurations that are generated during the Monte Carlo procedure. The important point is that the weight of a given configuration is given by its contribution to the partition function (and not by its contribution to the Green's function) in an expansion around the atomic limit. In other words, when the hybridization function is zero, all the configurations except the empty one have zero weight and therefore never appear. In particular, configurations with just one construction and one destruction operator, that would be needed to compute the Green's function, are never sampled!

As surprising as it sounds, it is thus impossible to compute the atomic limit in this implementation of the hybridization expansion CTQMC...

I will put a check in the code that makes sure the hybridization function is not zero.

[aeantipov]

I actually did the same thing with D=0.00001 and the result was the same. So some intelligent check should be useful, I guess.

[mferrero]

This is a slightly different issue. In the D=0 case, the current implementation of the hybridization expansion solver cannot find the good solution. As soon as D \ne 0, the solver can in principle find the solution, but you might need a huge Monte Carlo sampling. Indeed, the weight of a configuration is proportional to the hybridization matrix determinant which is very small when D = 1e-5. As a consequence, it might take many moves before a non-trivial configuration is accepted! But if you were to do an extremely long run you would eventually find the good answer.

A way to have a feeling for what is going on is to look at the output of the solver. At the end, it prints the acceptance rate for the different MC moves. If you see that this number is extremely small (or even 0!), you can guess that your statistics is not large enough for a reasonable answer.

[aeantipov]

But I would think as soon as one is near the atomic limit, markov chain should stop in, so to say, few steps. ( I realize it's a rather stupid question, which comes from the fact that I haven't worked with hybridization expansion before )

[mferrero]

I understand that this is a bit counter-intuitive. On the one hand, if one is close to the atomic limit, the perturbation order will be low and this makes the algorithm fast. On the other hand, the Green's function is computed from the configurations that appear in the Markov chain, and if the average perturbation order is too small (= zero) then no configuration can be used to measure the Green's function! This is a bit of a paradox, but really only happens when the hybridization function is very small or if the temperature is really high!

For more information about the precise way the algorithm works, I recommend the papers mentioned at the end of http://ipht.cea.fr/triqs/doc/user_manual/solvers/ctqmc_hyb.html

[aeantipov]

Ok, thanks for the help with that! I think this issue can be closed. By the way, does the algorithm estimate approximate error of, say, Gw or G(tau), by any auto-correlation measuring?

[mferrero]

There will soon be a tool in TRIQS to do this, but it's not available yet!