Getting "IQIndex does not contain given QN block" when the AutoMPO clearly conserves spin and charge

Question

Hi Miles,

I'm using AutoMPO to create IQMPOs, and I get the following message when I run my code:

I = IQIndex("Hl2",2,Link|60)
("hl2_0",2,Link|286) QN()

qn = (Sz=-2,Nf=-2)
From line 536, file iqindex.cc

IQIndex does not contain given QN block.

IQIndex does not contain given QN block.
Aborted

Here's a minimal example of my code:

#include "itensor/all.h"

using namespace std;
using namespace itensor;

int main(int argc, char* argv[])
{
    int N=2;
    int i=1;

    auto sites = Hubbard(N);
    auto ampo=AutoMPO(sites);
    ampo+=.25,"Cdagup",i  ,"Cup",i+1,"Cdagup",i  ,"Cup",i+1;
    IQMPO N1 = IQMPO(ampo);
    return 0;
}

I realize this is a stupid MPO to try to define, since it is obviously zero. But terms like these occur when I am looping over a lot of terms I want to add to my AutoMPO, and whenever they occur I get the same error. I could try to separate terms like this out, but it's bit painful. Is it possible there's some bug that's leading to this error, or does AutoMPO just break when trying to handle terms that are identically zero?

Answer 1

Hi, so this is actually a really good question. I have been thinking pretty hard about it and examining where things go wrong inside AutoMPO.

So on a higher level of abstraction, what happens first is that the two "Cdagup" operators are multiplied together since they act on the same site. Of course that's the correct thing to do. Then the code analyzes the resulting tensor, assuming it's not zero, and figures out its quantum number structure. It turns out this quantum number structure is incompatible with the IQMPO being built, which is what triggers the error.

So that's actually a reasonable thing for the code to do, for two reasons. The first reason is maybe a bit 'picky', but one can argue that even if the tensors which happen to violate the symmetry of the IQMPO always happen to be numerically zero, it's still inappropriate to accept such terms as input if they violate the symmetry (plus that's useful to catch them for finding deeper bugs in the logic of the AutoMPO construction).

The second reason is more practical, which is that checking whether each operator going into the IQMPO is numerically zero can be costly and also unreliable for cases where users genuinely want to add quite small terms (this can occur in quantum chemistry or in studies of small perturbations to lattice models, say).

So for now, I think the best thing to do is to leave the behavior as-is, perhaps with me improving the error message if possible.

What you can do is to put an if statement that checks for a term like

"Cdagup",i,"Cup"j,"Cdagup",k,"Cup",l

whether i==k or j==l.

In a quantum chemistry code I'm currently using I have similar terms and I have just such a check to eliminate invalid / zero terms like this.

Will that work for your case?

Miles

Comments

Fair enough! Yeah, I'll just do that, shouldn't be terrible. Thanks!