Non-contracting product in ITensor Julia

Question

Hi,

I know that the C++ ITensor versions overload the "/" operator to do non-contracting product between itensors. Is there a similar functionality in Julia? I couldn't find it very easily.

Thanks,
Amartya

Answer 1

Hi Amartya,
We haven’t defined that one in the Julia version. One reason is that it became hard to define it for QN conserving tensors in the C++ version. Another is just that we weren’t sure if anyone was using it.

Could I ask what your use case for it is?

Miles

Comments

Hi Miles,

Typically real time path integral codes are written using path arrays and other custom structures.  I am playing around with Feynman-Vernon influence functional formalism based on ITensor.  The first step was to have the dynamics of a single two level system coupled to a harmonic bath.  I am now thinking of doing many two level systems connected to each other as an extended system that is talking to a harmonic bath.  For a nearest neighbor interaction, it should be simple enough to do.  It would be a two-dimensional PEPS like decomposition.  I wanted to be able to handle non-nearest neighbor interactions by adding extra bonds instead of having the bond dimension grow out of bounds.  I think I might need something like a non-contracting product for that.

Using the SVD decomposition for reducing the size of the space and making the representation more compact might help a lot with extended systems with short range interactions.  I am already seeing some improvements over my old codes for the single two level system case in terms of storage requirements.  I have not yet compared performance, but those codes are in C++ and I was just playing with the Julia version, where my code may not be the most optimized.

I can discuss in greater depth if you are interested.

Best,

Amartya

---

Hi Miles,

I have defined a non-contracting product of basic tensors which works for my case.  I don't know if it is of any interest to the community.  Would you please explain to me the issues arising with QN-conserving tensors?  I have never really used them in ITensor.

Hope you are having a great holiday!

Best,

Amartya

---

Hi Amartya,
Thanks for your patience on my slow answer to this (and also on your SVD PR - we really do need to get to that and appreciate your contribution).

So I haven't thought about the non-contracting product in the context of QN's for a while, but I just thought about it a bit and I think recall what the problem was. (I'll give a more concrete example below.) The problem, I believe, is that there are lots of situations where if you input two QN-conserving ITensors, which currently we require to have a single, well-defined overall QN flux, then the output of the non-contracting product can result in a tensor that violates this condition, and will not have a well-defined QN flux.

There may be some resolutions to this issue:
1. we could just throw an error for these cases, but still allow the non-contracting product to work otherwise
2. we could introduce a more general kind of QN ITensor which is allowed to have non-zero blocks corresponding to *different* fluxes

However, I'm not sure if 1 is worth it, and 2 opens up a whole can of worms in terms of what guarantees we can provide about QN conservation and also about performance of block-sparse calculations (i.e. what if the quote "block sparse" tensor has most of its blocks actually non-zero?).

Now for a concrete example (and please tell me if you happen to catch a flaw in this example, as I may have misremembered some details even about what non-contracting product is supposed to do), say there are two tensors A and B. Let's say they each individually have a well-defined QN flux of zero. Let's say they each have two indices as well. A has indices i and j, and B has indices j and k (all with Out arrows). So that means that any non-zero block of A or B correspond to settings of the indices where the QN's of i and j add up to zero, or the QNs of j and k add up to zero.

Now if we do the non-contracting product of A and B, what we mean is that we "lock" or "tie" the j index of each together, to get a new tensor C_ijk. But when we do this, say then if Index i carries a QN q, then j will have to carry a QN of -q by the condition that A has zero flux. But then also k will carry a QN of q because B also had zero flux. So the overall QN of that block will be q-q+q which is q. However q can take multiple values, so then the flux of C can take multiple values, making it not a valid QN ITensor.

So I hope that example is both clear and accurate!

Best regards,
Miles

---

One last comment about the possible solution #1 of just allow non-contracting product but throwing an error in some cases. I think this might be more confusing than helpful, because it's subtle to understand the cases where it fails and why. So it would be like a very fiddly tool that errors a lot, and I'm not sure if the user experience of that would be a good balance with its usefulness. But maybe I'm wrong about that.

Another solution we might pursue is just to ask people to use diagonal ITensors (like the "delta" tensor) to accomplish the same result as what the non-contracting product does. Then we could more easily explain the unallowed cases as ones where the diagonal ITensor does not conserve QNs.

---

Thank you, Miles.  I have been also been really caught up with work.  I hope to be able to think along the lines that you have indicated more over the next couple of weeks, after brushing up on the QN-conserving ITensors.