MixedIQTensor with complex coefficients not working ?

Question

Hello Miles,

I got an execution error with a code using MixedIQTensor with complex coefficients. The error is the following:

terminate called after throwing and instance of 'ITerror'
what(): doTask not defined for task CalcDiv and storage type QMixed< Cplx >
Aborted

Is there any physical reason why MixedIQTensor should not have complex coefficients ?

Additional information:
This error arises when transforming AutoMPO into IQMPO. The MixedIQTensor with complex coefficients is defined in a new SystemSite class. Transformation to MPO works fine.

Best,

Samuel

Comments

Hi Samuel,

I think this also happens for real coefficients. The reason is that the divergence of a MixedIQTensor is not well defined, the sum of all the quantum numbers of indices for each element of MixedIQTensor is not the same. It seems we need every operator to be IQTensor when generating an IQMPO. For spin systems, I usually use "S+", "S-" instead of "Sx", "Sy" to avoid this error. Thanks.

Jin

---

Hello Jin,

Thanks a lot, you're right. Writing the simple Haldane Hamiltonian in terms of "Sx" and "Sy" gives the same error.
However, is there a way to overcome this kind of issue for more complicated operators ? Indeed, the fact that the quantum flux of each non-zero block of an operator must be the same is rather restrictive, meaning that the only non-zero blocks must lie on the same "generalized diagonal" (0-th, 1st, 2nd, 3rd or negative diagonal). This is the case typically for "S+" and "S-" in SU(2) spin chains. But there are some models which have U(1) symmetry without exhibiting the above property (or maybe they do, but not by taking simple linear combinations as $S_x \pm i S_y$.)
Another way to formulate the question is: does the following statement holds ?
"For any system with U(1) symmetry, one can find a set of generators satisfying the underlying algebra, such that these generators can be expressed as IQTensors."

Samuel

---

Hi Samuel. Because any operator can be expressed as a sum of "generalized diagonal" operators, I think we can overcome this issue for any complicated operators as long as the Hamiltonian has U(1) symmetry.

Answer 1

Hi Samuel,
Sorry about the slow reply - I agree with Jin's response (Jin: feel free to post your comments as a reply instead of just comments if you are confident about them). So I don't think the issue has to do with complex numbers per se but rather the issue of using a non-IQTensor operator in an IQTensor / quantum number conserving context, which causes the code to attempt to compute the divergence of a mixedIQTensor which is not well defined. (Part of the the reason mixedIQTensors exist, in fact.)

A bit more backgroun on why there's such a thing as a mixed IQTensor: earlier on we decided on a design where there is a single SiteSet type for both ITensors and IQTensors for the same type of Hilbert space. (So like SpinHalf, SpinOne, etc. can be used in both an ITensor and IQTensor context.) Thus the return type of the .op method is IQTensor, since IQTensors can always be converted to ITensors. However, there are some operators that are not well-defined IQTensors, such as Sx. So I made a storage type "mixedIQTensor" that can sort of "smuggle" an ITensor in an IQTensor guise.

In the future we may just have two versions of every site set, so like IQSpinHalf as well as SpinHalf.

Another fix might be to make IQTensors less strict about having a well defined divergence as you suggest in the comments. However there's at least one big issue with this: for efficiency when constructing an IQTensor we use the flux, as soon as it can be determined, to work out all of the blocks that can possibly be non-zero and allocate storage for them in one go. That way we only call the allocator once and don't have to resize the memory or have non-contiguous IQTensor memory. Those things could cause big slowdowns.

So in the end the situation as I see it is: (1) one can always work with operators such as S+ and S- that change quantum numbers in a well-defined way for symmetric Hamiltonians; and (2) restricting IQTensors to just these operator types leads to big efficiencies so it's worth it.

Best regards,
Miles