zipUpApplyMPO vs fitApplyMPO

Question

Looking at your source code, I found a method called zipUpApplyMPO. This method isn't described in your documentation, but I tried it out, and it seemed to yield the same results as fitApplyMPO, only (in my case) faster. Is there a reason zipUpApplyMPO is missing from documentation, and how does it compare to fitApplyMPO?

Answer 1

Hi, good question. The zip-up method for applying an MPO to an MPS is described in this paper: https://arxiv.org/abs/1002.1305 (motivation and discussion starts around page 5).

It's a sort of "quasi-controlled" algorithm for applying an MPO, meaning that you can get it to converge to arbitrary accuracy with sufficiently small truncations, but you can also encounter some cases where it behaves poorly in practice depending on numerical details of how the MPO and MPS are constructed internally (such as whether the tensors obey right- and left- orthogonality constraints or not).

In practice I haven't been to happy with its performance, typically finding that I need to take quite small truncation cutoffs to get accurate results. But maybe it works well for your case or perhaps it can be improved. So it's present in ITensor as sort of an experimental feature but I don't want to steer new users to it.

Recently I made a major improvement to the exactApplyMPO algorithm that drastically improves its scaling. It's a fully controlled algorithm that should give consistent results across a wide range of MPOs and MPS. Its only drawback is that to leading order it scales as an additional power of the MPO bond dimension compared to fitApplyMPO or zipUpApplyMPO, which is non-trivial of course. But it could be acceptably fast for your case and should be the most reliable algorithm. So please try that and see if it's fast enough for you.

The problem with fitApplyMPO is that it can fail to converge (no matter how many sweeps are done) if the product of the MPO times the MPS is too different from the original MPS. But fitApplyMPO can work pretty well for MPOs that are not too far from the identity, such as when doing time evolution with a small step size.

Anyway you can see that this is a tricky business, which is why I recommend people try exactApplyMPO first.

In the future I'm planning to replace all these methods by a single method "applyMPO" that defaults to exactApply, but can accept an optional argument that tells the method to try one of the less reliable but faster algorithms such as fitApply. Also I'm planning to try a hybrid algorithm that could combine the best aspects of exactApply and fitApply (reliability and good scaling).

Comments

Just curious, is there a deep reason for fitApply's failure?

---

Hi, so I'm not sure what reasons count as deep or not, but the reason for the possible failure of fitApply is that it projects the current MPO times MPS product into some reduced basis ("MPS basis") which comes from some initial guess for the new MPS. If this initial guess is bad, then the basis is bad, and the new tensors used to update the two sites of the MPS are missing components they should otherwise have. This two-site tensor is used to expand the basis, so if it's deficient the basis will continue to be deficient. So one can get into sort of an endless loop where the basis is bad and never gets better.

This situation is analogous to gradient descent, where a bad initial starting point can cause one to get stuck in a local minimum. In that case, the gradient does ultimately go to zero and things look converged, but one can be far from the correct answer (true global minimum).

So probably the best MPO times MPS algorithm is to use a more reliable, or totally controlled MPS times MPO algorithm which scales worse but from which one can demand limited accuracy (by over-truncating), then use the output of that algorithm to initialize fitApply which has the best scaling.