QN degeneracy caused "segmentation fault" for odd number of sites

+1 vote
asked Mar 13 by JunjieChen (340 points)

Here by "QN" degeneracy I mean that two Index-QN pair defined in an IQIndex have the same QN (quantum number). For example, the following two pairs are degenerate :

Index(nameint("pzm101",n),1,Site),QN({0,-1},{2,1},{0,1},{0,1})
Index(nameint("pzm020",n),1,Site),QN({0,-1},{2,1},{0,1},{0,1})

if such degeneracy appears in the definition of IQIndex, than "segmentation fault" might happen. I seems we can redefine a Index-QN pair with two sector:

Index(nameint("pzm***",n),2,Site),QN({0,-1},{2,1},{0,1},{0,1})

But it may have problems when we try to define operators. On the other hand, QN only receive at most 4 slots, I can no longer add an additional quantum number to distinguish these two states.

Thank you.

commented Mar 14 by Zhiyu (280 points)
Hi Junjie,

For your last question, I think maybe you can edit the qn.h to allow more QNs.

There are code as follows:


    explicit
    QN(qn_t q0);

    QN(qn_t q0,
       qn_t q1);

    QN(qn_t q0,
       qn_t q1,
       qn_t q2);

    QN(qn_t q0,
       qn_t q1,
       qn_t q2,
       qn_t q3);

you may just try to add a similiar one:

    QN(qn_t q0,
       qn_t q1,
       qn_t q2,
       qn_t q3,
       qn_t q4);

Would that work?

Zhiyu
commented Mar 14 by JunjieChen (340 points)
Hi, Zhiyu, it should work. But it seems that all quantum number defined in QN object should a good quantum number of the Hamiltonian, otherwise error occurs. I shall do some tests and discuss it with you later. Thank you.

1 Answer

0 votes
answered Apr 9 by miles (16,940 points)

Hi Junjie,
Sorry I haven't replied sooner. Based on my understanding of your situation, I think the correct way to proceed is to define some of the Index objects making up your IQIndex definition to have a size greater than 1. So I mean the second thing you suggested.

You said about this second way that "it may have problems when we try to define operators" but I don't see how it would lead to a problem defining operators. Can you tell me what problem you think it would cause when defining operators?

If it helps, recall that when you "index" into an IQIndex, meaning when you write I(n) for some IQIndex "I" and an integer "n", then the associated sector (the things labeled by the Index-QN object pairs) is determined by counting through the sizes of each sector, starting from the beginning. So if all of the sectors (Index objects) are of size 1, as it usually the case for a site IQIndex, then the n'th value corresponds to the n'th sector. But this doesn't have to be the case. If, say, the first sector has size 1 and the second sector has size 2, then I(3) means we are still in the second sector, just the second value within the second sector.
(This concept is briefly explained here in the diagram near the end: http://itensor.org/docs.cgi?page=book/iqindex in the diagram near the end showing the "Index value").

So for defining an operator there should not necessarily be a problem for some of the sectors to have a size > 1.

Miles

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.
...