Time-envolving an IQMPS with Trotter Gates

Question

Hi, Miles

I was having a problem with time-evolving with Trotter Gates. I copied the code through the link http://itensor.org/docs.cgi?page=formulas/tevol_trotter and changed the sites to the 1D Hubbard model. The error showed up if I included the on-site potential term like this,

    hterm += -1*sites.op("Cdagup", b)*sites.op("Cup", b + 1);
    hterm += -1*sites.op("Cdagup", b + 1)*sites.op("Cup", b);
    hterm += -1*sites.op("Cdagdn", b)*sites.op("Cdn", b + 1);
    hterm += -1*sites.op("Cdagdn", b + 1)*sites.op("Cdn", b);
    hterm += 0.5*sites.op("Nupdn", b);
    if (b == (N - 1)) hterm += 0.5*sites.op("Nupdn", b+1);

If I were left with only the hopping term, the code worked fine. I have also tried changing the potential term to,

    hterm += 0.5*sites.op("Nupdn", b) *sites.op("Nupdn", b+1);

and surprisingly it worked too, both in IQMPS and MPS(with and without quantum numbers). Different kind of error appeared when I swithed the term to,

    hterm += 0.5*sites.op("Nupdn", b) *sites.op("Nupdn", b);

The error message was "Mismatched IQIndex arrows", for both IQMPS and MPS, so I was thinking the problem may be related to the conservation of quantum numbers. I noticed the article "time-evolving an MPS with MPO" and the original potential term worked well with the exactapplyMPO, but I would like to take advantage of the trotter decomposition because I only have nearest neighbor interaction.

There is another concerned about time-evolving with quantum numbers. I used the IQTensor, IQMPO...class to find the ground state, @@ \left\vert 0\right\rangle @@ ,which has the total elctron of n, but the state that I want to evolve is @@ C_{i}^{\dagger }\left\vert 0\right\rangle @@ , which is by applying electron creation operator to the ground state. Using the exactApplyMPO will turn it into MPS instead of IQMPS, and I have to do time-evolving without quantum numbers. Is there a way that I could keep the conserved quantum number? I was thinking naively something like "exactApplyIQMPO()", or "toIQMPS()", while I did realize that generally an MPS could have no conserved quantum number.

Answer 1

Hi, so for the Trotter bug, I think you already have a bug when you try to add different tensors into hterm with different numbers of indices. First you are adding two site operators (four-index tensors) then you are adding single site operators (two-index tensors). In debug mode this should immediately give an error, though perhaps you were running an optimized build in which case the error could happen somewhat later in the code.

So I'd suggest just doing an outer product of your single-site operators with identity operators, like this:

 hterm += 0.5*sites.op("Nupdn", b)*sites.op("Id",b+1);

Regarding the use of exactApplyMPO, it is a function that works for both MPS and IQMPS, and it shouldn't be turning anything into an MPS if you give it an IQMPS and an IQMPO. What arguments are you passing to it?

Best regards,
Miles

Comments

Thank you very much for the immediate reply. I have tried compiling in debug mode and the error read " additional relocation overflows omitted from the output". I didn't realize that the problem was the multi-site operator. I tried adding the identity operator as you suggested and it worked pretty well. I was just thinking about the other terms like,

            hterm += 0.5*sites.op("Ntotal", b) *sites.op("Ntotal", b);

So I added an identity operator of b+1 site to this term, and one of b site to the hopping term,

            hterm += -t * sites.op("Cdagup", b)*sites.op("Cup", b + 1) * sites.op("Id", b);
            hterm += -t * sites.op("Cdagup", b + 1)*sites.op("Cup", b)* sites.op("Id", b);
            hterm += -t * sites.op("Cdagdn", b)*sites.op("Cdn", b + 1)* sites.op("Id", b);
            hterm += -t * sites.op("Cdagdn", b + 1)*sites.op("Cdn", b)* sites.op("Id", b);
            hterm += 0.5*sites.op("Ntotal", b) *sites.op("Ntotal", b) * sites.op("Id", b + 1);

Unfortunately, the error showed up again. Is there any way that I could avoid this problem?

As for the exactApplyMPO, I was going to apply the electron creation operator, which is an MPO, to my IQMPS state(Conserved total electron). What I did was using toMPS() to get to the MPS state and applied exactApplyMPO to get to the target state that I wanted.

            IQMPS psi0;
            MPS psi0_mps = toMPS(psi0);
            auto C = MPO(ampo); //ampo += "Cdagup", i;
            MPS target = exactApplyMPO(C, psi_mps,  argu);
            (time-evolving "target" in an IQTensor, IQMPO class)

I was wondering if there is something I could do to attached "total electron number" to the target state and make it a IQMPS.

Best regards,
Yixuan

---

Hi Yixuan,
Your code examples are showing me that you are not quite understanding yet some important things about what the sites.op("Opname",i) function calls are returning or perhaps how the * operator works in ITensor.

What I mean is that the result of a call to sites.op("Opname",b) is a tensor with two indices: one which is the site index of site "b" and the other which is the same index (site b) but with a prime level of one. So we could call these indices sb and sb' just for convenience.

Then if you * together two such operators, for the same site, like sites.op("Ntot",b)*sites.op("Ntot",b), then because the * operator contracts all matching indices, the sb indices will be contracted and the sb' indices will be contracted and the result will be a scalar (0 index tensor). So this does not do operator multiplication like on paper.

Another comment is that "Ntotal" is not the name of an operator provided by the Hubbard site set. However there is an operator named "Ntot". Perhaps this is what you mean?

Finally, what do you mean by saying "the electron creation operator, which is an MPO?". Whether or not it is an MPO or an IQMPO depends on how you define it. So are you defining it to be an MPO? If you define it to be an IQMPO instead, then it will be an IQMPO.

Since it is just a single-site operator anyway, I would recommend not using MPO techniques at all, but instead doing this:

auto newA = sites.op("Cdagup",i) * psi.A(i);
newA.noprime();
psi.setA(i,newA);

What the above code does it to retrieve the Cdagup_i operator from the site set, then apply it to the i'th tensor of the IQMPS. Then it sets the prime level to zero (since the "ket" index of the Cdagup operator has a prime level of one). Then it puts this new tensor back into the IQMPS at the i'th location.

---

Hi Miles,

You are right. I'm sorry I totally forgot about the contraction of same indices. I can make one of the sites.op("Ntot",b) prime level of two and the other one of level one to avoid this. And also, I mistyped the number operator. The operator should be "Ntot".

I was thinking that the electron creation operator could not be made into a IQMPO because it did not conserve the total number of electron. However, as you suggested, for single-site operator I could just manipulate the corresponding tensor of the IQMPS. I have tried and succeed it. Thank you so much for helping me clear the confusion I had.

Best regards,
Yixuan

---

Hi Yixuan,
Ok glad you are making a lot of progress. Actually, there's no problem with an operator like Cdag being represented as an IQMPO (other than the separate issue that for a single operator it's more efficient just to use it directly on one site rather than making a whole mpo for it).

But on a technical level, it's fine for IQMPO's and IQTensor's to have a net "flux" meaning they can change the number of particles. It's just that they have to change the number in a well-defined way. This means that an IQMPO can't represent an operator like C+Cdag in a context where one is conserving particle number, because C+Cdag doesn't make a well-defined change to the particle number unlike C or Cdag separately. There is one other issue too, which is more of a bug at the moment, which is that the AutoMPO system has difficulties making just a single Cdag operator, but that's really purely a bug and something we should fix.

Miles