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

+1 vote
asked Oct 31 by jclaes (340 points)

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?

1 Answer

+1 vote
answered Nov 9 by miles (19,400 points)
selected Nov 9 by jclaes
 
Best answer

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

commented Nov 9 by jclaes (340 points)
Fair enough! Yeah, I'll just do that, shouldn't be terrible. Thanks!
Welcome to ITensor Support Q&A, where you can ask questions and receive answers from other members of the community.

Formatting Tips:
  • To format code, indent by four spaces
  • To format inline LaTeX, surround it by @@ on both sides
  • To format LaTeX on its own line, surround it by $$ above and below
  • For LaTeX, it may be necessary to backslash-escape underscore characters to obtain proper formatting. So for example writing \sum\_i to represent a sum over i.
If you cannot register due to firewall issues (e.g. you cannot see the capcha box) please email Miles Stoudenmire to ask for an account.

To report ITensor bugs, please use the issue tracker.
...