MPO from MPS

[1ucasvb]

Extension to MPO class to allow creation of MPOs from a MPS, and extra features.

Collaboration by Thiago O. Maciel.

[mtfishman]

Hi, thanks for the pull request. May I ask what your use case for adding this function is? I ask because in general, it is better to treat this type of object in a "sparse" way, i.e. instead of explicitly forming the MPO from the outer product of the MPS tensors, it is better to treat the MPS tensors separately. Since that is the case, I worry that adding this function may encourage people to use this method instead of doing it in a more efficient way.

Possibly a better thing to do would be to make a special class, like OuterProductMPO, which acts like an MPO but just stores the MPS that you want to create the MPO from, instead of explicitly forming the MPO tensors. That could possibly clean up some current code. For example, applyMPO(MPS,OuterProductMPO) could be simplified by internally calling overlap(MPS,MPS). However, I am not sure if this is totally necessary right now, and would lead to us having to support all of the MPO functionality on OuterProductMPO.

Cheers,
Matt

[1ucasvb]

We are using this to develop a MPO optimization algorithm related to density matrices and various operators: basically, optimizing A via Tr[rho.A]. The idea was to explorie a model of mixed states made out of convex combinations of pure states (GHZ and W in particular), and this format seemed sufficient for that purpose.

I agree that a sparse representation would probably be ideal for MPO representation of pure states, but anything beyond that would require the full fledged MPO (as far as I can understand the problem here).

I suppose we could create a sparse class, which could be converted on the fly when such manipulations take place. But I honestly don't know where I'd begin with that approach.

This all may be an obscure usage that won't warrant an inclusion, but we figured it could be helpful to share.

[mtfishman]

I see, you would like this function as a way to help create your starting density matrix rho = |psi><psi|, but then use rho as a mixed state. That seems reasonable. I suppose we can put a warning in the documentation that in general it is preferred to work in a sparse way with |psi>, and this function is just a convenient constructor for a density matrix.

[1ucasvb]

Yes, exactly. We're doing rhoW = |W><W| and rhoGHZ = |GHZ><GHZ|, then mixing them to get our mixed state MPO.

I suppose we can put a warning in the documentation that in general it is preferred to work in a sparse way with |psi>, and this function is just a convenient constructor for a density matrix.

That would be a good idea, and should cover your concerns. There's really no reason to use this unless you will truly be dealing with a mixed state.

[mtfishman]

One thing we could do is give this function a name besides MPO, for example outerProductMPO. Before I looked at the code, I thought that maybe what you meant by MPO(MPS) was taking an MPS and then adding a dummy Index to each ITensor in the MPS to make it an MPO. I am not sure what that would be useful for, but I guess the point is that there is not one unique way of making an MPO out of an MPS, so it may be good to give it a more specific name.

[1ucasvb]

I see. That's a fair point.

As of now it's implemented as a constructor under MPO. Should I then just create an isolated MPOt outerProductMPO(MPSt mps) function, or is there any convention I should follow for such a function? I'm not familiar with something comparable currently in ITensor (a "conversion function").

Actually, given your considerations, perhaps it may be semantically better to move this into the MPS class as an instance's method instead, so that the syntax makes it clear you're converting a given MPS to a MPO via an outer product.

If that sounds reasonable, let me know and I'll make the appropriate changes. Cheers!

[mtfishman]

I think it is best to just group it with other MPO functions/constructors, in mps/mpo.h and mps/mpo.cc, since I would consider it a specialized MPO constructor. What you can do is model it off of the toMPO(AutoMPO) function (implemented in mps/autompo.h and mps/autompo.cc), another specialized MPO constructor.

We could think about adding an optional Args to it, to allow people to request properties of the resulting MPO (like a maximum bond dimension, custom link type, etc), but that could be added later.

Thanks for the contributions!