Restore QR in orthogonalize!

[emstoudenmire]

Recently switched orthogonalize! (in mps/mpo.jl) to use SVD instead of QR so it could be used for QN conserving MPS and MPO. Need to switch this back once QN conserving QR is implemented.

[orialb]

Is someone working on this? Otherwise I'll go on and implement this as the lack of QR in orthogonalize! makes my TEBD code 2X slower.

[emstoudenmire]

Hi Ori, do you mean implement the lack of a QN-conserving qr function or just turning on QR again in orthogonalize! ? As you may know, currently the QR decomposition is not implemented for QN-conserving, block-sparse ITensors (QNITensors).

[orialb]

Hi Miles, I meant that I could try to implement everything needed to get orthogonalize! working with QR for both dense and block-sparse ITensors. Unless of course this is something you want to work on yourselves or there is some reason to wait with this.

[orialb]

p.s. If you prefer to wait with block-sparse QR until you have time to implement it yourselves, maybe QR could be reactivated for dense tensors in orhotogonalize! in the meantime?
The code will be less elegant but it will be much faster (I guess this is also relevant for performing measurements on MPS and not just my TEBD code that probably no one uses currently).

[emstoudenmire]

Hi Ori, that’s a good suggestion. Actually the situation is kind of a bit nicer than that I just realized. The orthogonalize! function calls a general-purpose routine Matt created called factorize which is intended as kind of a smart, automatic factorization method that selects the best method depending on the situation. Right now it only has SVD and density matrix decomposition (not sure what a math person would call this) backends. QR is planned to be one of the future backends and could be the default for cases when no truncation is requested.

So if we just plug in a QR backend for the case of (1) no truncation and (2) non-QN-conserving ITensors for now, then orthogonalize! will start using it automatically when it is called without truncation parameters.

@mtfishman does all of the above sound correct to you?

[mtfishman]

Yes, that sounds like a good plan. In the factorize function, the plan all along was that if you asked for left or right orthogonality, and didn't ask for any truncation, it would automatically use a qr decomposition. I only didn't put it in because we don't have a block-sparse qr decomposition yet and I was still working out the internal organization of the function, but it would be fine to put it in for the dense case now.

[orialb]

Should I make a PR for this, or is it something you prefer to do on your own?

[mtfishman]

Go ahead, if it is something you want pretty soon (it has been bothering me that we don't have a block-sparse QR, so I may go and tackle that soon-ish, but it would be nice to have the logic in factorize so then we can just drop it in).