Question about using AutoMPO for fermionic Hamiltonians with spin-orbit coupling

Question

Hi,

I have a question about the sign convention of AutoMPO in fermionic systems where the Hamiltonian does not conserve spin, e.g. due to the presence of spin-orbit coupling.

I would like to code the term (in latex form)

$$
c^\dag{\uparrow,b} c{\downarrow,b+1} + h.c.
$$

when building up the Hamiltonian. I get correct benchmark results for the ground-state energy of the Hamiltonian when I use the lines

ampo += 1,"Cdagup",b,"Cdn",b+1;
ampo += 1,"Cup",b,"Cdagdn",b+1;

in itensor language. However, when I intuitively read these two lines "word by word", they would read (in latex form)

$$
c^\dag{\uparrow,b} c{\downarrow,b+1} +c{\uparrow,b} c^\dag{downarrow,b+1}
$$

which upon anticommuting the second term yields

$$
c^\dag{\uparrow,b} c{\downarrow,b+1} - h.c.
$$

i.e. an anti-hermitian operator. By contrast, if I put a relative minus sign between the two lines of itensor code, thus intuitively writing a hermitian operator, I get unphysical results. Also, for spin-conserving terms, there is no similar sign issues, and everything can be coded intuitively using AutoMPO. Is there a simple rule for the sign-convention in general non-spin-conserving terms?

Thank you very much in advance for your help.

Answer 1

Hi, thanks for the question. AutoMPO should be able to handle the case you described just fine. There may be a bug, though, because I agree with you about the signs you want to put versus the signs you are finding actually work with the code.

Which version of ITensor are you using? We made some fixes to AutoMPO a few months back.

If you are using the very latest version already, I'll step through AutoMPO and check that it's putting in the minus signs it should be for this case.

Miles

Comments

Hi Miles,

Thanks for the swift reply. Yes, I am using the latest version from June 19, 2016. A global sign would not be a big issue, but if some F_i operator is missing in the implementation of the C_j, it could be a occupation-number dependent sign which would be more problematic. However, from my (non-exhaustive) benchmarks it seems like there is only a global sign missing.

Best, Jan

---

Hi Jan,
I just thought of something else that might be the cause of the problem (i.e. it might not have to do with AutoMPO).  You are defining a non-spin-conserving Hamilton, but I presume you are using the Hubbard site set (i.e. auto sites = Hubbard(N);) However this will define a local Hilbert space with spin quantum numbers, which doesn't make sense for this model.

To turn of spin quantum numbers, you need to construct the Hubbard site set with the "ConserveSz" option set to false, like this:

auto sites = Hubbard(N,{"ConserveSz",false});

You can print out one of the sites (e.g. Print(sites(1)); ) and look at the quantum numbers to confirm that Sz is not there.

Maybe you are already doing this in which case I definitely need to have a look at AutoMPO. But if not please try it and let me know if it fixes your issue. Thanks -

---

I'll have to ask you more about the global sign too, but first let's resolve this spin quantum number question then we can recheck the energies -

---

Hi Miles,

I now checked with  "Hubbard sites(N,{"ConserveSz",false});". There are no changes regarding the sign issues described in my first question.

However, when comparing results obtained with version 1.1.1 and version 2.0.10, I had another issue directly relating to the non-spin-conserving terms:  Previously, I only used MPO and MPS, and put a chemical potential term to get the particle number right. Now, I also did some runs using IQMPO and IQMPS. With version 1.1.1 the results are completely consistent with those not using IQ.. (i.e. the sign problem described above remains but the code compiles and runs fine). There, I also used "Hubbard sites(N,{"ConserveSz",false})" to conserve Nf but to allow for spin-non-conserving terms. When trying to use the same code with version 2.0.10 (with the include statements properly adjusted), the code compiled and started running, but then gave a segmentation fault immediately after starting the "dmrg(psi,H,sweeps,{"Quiet",quiet})" routine. That is, the Hamiltonian as an IQMPO and the initial state as an IQMPS (for the initial state I simply used the Neel state from the exthubbard.cc sample file) where created without complaints before the segmentation fault.

Best, Jan

---

Hi Jan,
Hm, segfault is never good! It could be any number of things (major or minor) but I'd need to know the details of the code and the error message. What I mean by "error message" is that I'm guessing you were running the code in fully optimized form. If you compile and run it in "debug mode" (for more info see here: http://itensor.org/docs.cgi?page=formulas/debug_mode ) then in many cases you will see a much more helpful error message about what went wrong.

If you'd like you can send me your whole code, or a simplified version, at miles.stoudenmire@gmail.com and I can see if I reproduce your error.

Miles