Two-orbital AIM nonphysical result

[steffenbackes]

Dear all,

after having installed the ctHyb solver successfully, I wanted to try out a simple test case for a two-orbital model with density-density interaction.
I'm using Ubuntu 14.04, gcc version 4.8.2, with a checkout of the TRIQS toolkit and ctHyb a few days ago. All tests have been passed successfully.

I basically followed the examples in the documentation and modified them accordingly. You can find the resulting script here:
http://www.itp.uni-frankfurt.de/~backes/aim.py

The problem is that the impurity Greensfunction for the second orbital is very different from the first orbital, with the imaginary part being positive for some frequencies, even though the Hamiltonian is symmetric. The first orbital seems to be ok.
The Greensfunction for the first spin looks like this:

I also checked for the case U=0, where I regain G0 for the first orbital, but a nonphysical result for the second orbital.
Can someone point out what I'm doing wrong here?
Thanks a lot.

Steffen

[steffenbackes]

Ok, I found out that I get correct results when setting
"use_segment_picture = False"
Why is this neccessary, even though the Hamiltonian commutes with all number operators? Am I overlooking something?

[mferrero]

Hi,

There are actually two requirements you need to satisfy if you want to use the segment picture. One is that the Hamiltonian commutes with all number operators. The other (which very often goes together with this property) is that the Green's function is fully diagonal. In other words, all Green's function blocks must have dimension 1x1. In your input you define the gf_struct to be

gf_struct = [ ('up', [0,1]), ('down', [0,1]) ]

This tells the solver that the Green's function has two blocks of dimension 2x2. It is not wrong to define it like this, but it is not compatible with the segment picture. You should rather define it as

gf_struct = [ ('up-0',[0]), ('up-1',[0]), ('down-0',[0]), ('down-1',[0]) ]

If you do this, all blocks have dimension 1x1 and you can leave the segment picture flag to True. I tested this and it works.

Cheers!

[steffenbackes]

Great, thanks! I just wasn't aware of this, now it's working fine.
Now I'm also using the wien2triqs interface to generate a 5orbitals/2 spin Hamiltonian with the MultiBandSolver. If I include the Spin-Flip terms (setting the flag to True), it's actually faster than without. Is this reasonable because the acceptance probabilities change in a certain way or does this indicate there's something wrong on my side?
I have to add that I didn't finish the calculation yet because it takes quite some time, just wondering.

[mferrero]

Hi,

Speed is not the whole story. When you turn on spin-flips, you turn off the segment picture. One consequence is that the acceptance rate of your Monte Carlo moves goes down. Many moves are rejected quickly which might sometimes result in a faster code (in the sense that it does N steps faster than without spin-flips). However, the low acceptance rate has another consequence: more noise. So what one really has to compare is the time to produce data with about the same error bar. I guess that using spin flips you would need many more MC steps to produce the same error bars as without spin-flips with an overall slower code.

[steffenbackes]

Thanks, yes I was also thinking of something along the lines of this effect. Is there something like a member function or some other way to access the acceptance probability or number of accepted moves, or perturbation order after a finished run?

[mferrero]

Just increase the verbosity (I think 3 is the max). The acceptance rates will be printed out.