Fermionic signs (user-defined site)

Question

Hi,

I'm still struggling with defining my own site class for a Hubbard-like model for two orbitals per site. I noticed the following behaviour, which is kind of weird for me. To debug my program, I calculated all the matrix elements of two-site Hamiltonian and I found that I don't understand what is going on with signs when a creation-annihilation operator pair was applied. To further clarify it I have artificially set all the elements of F operator to +1. And I arrived at following situation:
- I have a term in autoMPO:
ampo += t,"CdagAUp",j,"CAUp",j+1;
ampo += t,"CdagAUp",j+1,"CAUp",j;
- t=0.5
- All the elements of CAUp and CdagAUp are +1 or 0
- All the elements of F are +1 or 0
- And yet, the matrix element of a two site Hamiltonian between states connected by these elements is -0.5.

So, the question is: am I missing something about the fermionic operators? I know that in the Hubbard class there are Fup and Fdn operators - should I write analogous operators for myself? What are they for? (in the tutorial on Jordan-Wigner strings there is a F_j operator for spinful Jordan-Wigner transformation - are they somehow related to it? I assumed that all the sign changes related to swapping operators within one site are included in C, Cdag operators, but maybe I'm wrong.)

Answer 1

Hi Varelse,
I didn't anticipate that people would try to customize the SiteSet + AutoMPO system as much as you have. In lieu of a proper fermionic IQTensor system, which is a future feature we want to add, we have had to rely on some ad-hoc approaches to dealing with fermionic operators in AutoMPO. Right now, the AutoMPO system only checks if the first letter of an operator is "C"; if so it treats it as anti-commuting which would explain the minus sign you saw.

Until I get a proper system of anti-commuting indices built into ITensor, unfortunately we have to rely on this kind of ad-hoc approach. But we could make it better by letting users customize which operators are to be treated as fermionic. If you are interested in continuing with this, let's think of a better system and I can implement it. For example, there could be a user-extensible function isFermionic(SiteSetType, string) -> bool which you one could overload for a particular SiteSet to specify which operators are fermionic. Then AutoMPO could use that.

I'm pretty busy at the moment but I will try to experiment to see what seems best. Please ping me again if you haven't heard from me in a week or so.

Miles

Comments

Hi. sorry for not replying for so long. Yes, it seems to be the case that the sign arises from anticommutation rules (knowing this, I found a bug in my code and now it works fine).

For now, the current approach - "if a name starts with C, it is fermionic" - works for me. What I think is more needed is a little more documentation. For example, I got a little confused about the order in which the operators are applied.  They are sorted according to site index - but I am not sure if in decreasing or increasing order.

Just to explain why I need my own site class - I have a system in which I have two orbitals per site, but there is no tunneling within the site (there is just an exchange interaction).  Apparently in such a situation writing the site as two Hubbard sites is not a good idea, because at some point You have to divide Your real physical site in half.

Anyway, thanks for Your reply, it was really helpful.

---

Ok great. I never did get around to trying the better system, but I still could. Realistically it won't be until late December or January before I'd likely get to it.

I may have mentioned but ultimately I'd like to put in a proper anticommuting index system which I have planned but will require lots of testing. This system would remove the need to use hacks like checking the operator name to have anticommuting operators.