Investigating phase transitions in ITensor

Question

Hi,

I was wondering if there is any reliable way of investigating phase transitions in ITensor.

Specifically, if one wants to know the value of some critical exponent γ such that some order parameter K scales like (distance from the phase transition)^{-γ }: is there a way to reliably extract this γ from ITensor?

As you know, dmrg/MPS rep. is not very trust worthy near phase transitions as the constant entanglement entropy area law doesn't hold. For states very close to the phase transition, the entanglement entropy goes like log(L) and formally one would need MERA.

So my question is if MERA has already been implemented in ITensor and if not, can these critical states still be investigated using just the dmrg/MPS representation?

Best,

Arnab

Answer 1

Hi Arnab,
I understand the reason for your question (which is of course about DMRG versus other tensor network algorithms versus ITensor specifically), but I would say that the notion that MPS (and DMRG) don't work well near critical points is actually a very common misconception. It's true that MPS don't scale correctly for a given, or fixed bond dimension as a function of system size versus MERA, but for a fixed system size, and even for an infinite system, MPS can capture critical behaviors exceptionally well, even obtaining precise power-law decays of correlators out to thousands of sites before eventually crossing over into an (erroneous) exponential decay. On the other hand, the required log(L) growth of bond dimension of an MPS for a critical system of length L is actually a very gentle and easily-met requirement, since log(L) is a slowly growing function of course.

On the other hand, while MERA can capture critical systems well in principle, in practice the usefulness of MERA and other kinds of tensor networks depends quite a bit on how well one is really able to optimize them. There is now some nice technology to optimize MERA, but it is not as "push button" or black box as for MPS, and that's one of the reasons we haven't included it as a standard option in ITensor yet. (Another reason is just that we are more focusing on the fundamental capabilities of the library right now, such as building in automatic handling of fermion signs and automatic differentiation capabilities etc.)

So I would strongly recommend sticking with MPS techniques for as long as possible, especially if you are studying 1D systems, because of how much simpler they are to work with and how much better the available algorithms are for them (such as DMRG, but other ones too), and then only consider more complicated tensor networks if you are sure it will give you better results for your problem or access to quantities you can't obtain with MPS.

But of course if you do have access to a pre-written MERA code, or want to use ITensor to make your own, it could be a useful comparison point for your problem. If you do decide to use ITensor to implement MERA yourself, we will try to answer any questions you may have along the way.

(Is your system of interest 1d or 2d by the way?)

• Miles

P.S. here are some references showing how well MPS actually can work for critical systems:

https://arxiv.org/abs/1805.05006

https://arxiv.org/abs/1109.5334v1 (see Fig. 12 and note the axes - MPS is doing very well!)

Comments

Hi Miles,

I just wanted to say thank you for convincing me that MPS can handle critical behaviour especially for 1D systems (which are of my interest currently) ! With some post processing, I can now indeed extract the critical exponent by looking at points slightly away from the critical point and it matches with the theoretical prediction. Thank you again!

Best,
Arnab

---

Great! I should add that of course MPS can be much harder to converge at or near critical points, so it's a good idea to do more sweeps of DMRG that might be needed for a system with a large gap. Also the long-range behaviors might be among the last thing to converge about the MPS, so care is needed. But sounds like you are getting enough convergence if you are seeing the expected results.

---

Yes, I am doing atleast 30 sweeps near the critical points and it takes my laptop an entire day to gather all the data needed to extract the exponent but fortunately I am getting sensible results!

---

That's good you're doing 30 sweeps. May I ask what sweeping parameters (max bond dimension, cutoff) you are using for each sweep? Also how long is your system in terms of the length of the MPS? Thanks -

---

Hi Miles! max bond dimension is gradually increased: (10,20,100,400,600), cutoff is 1e-12; the length of the MPS for me currently is 500 sites. Hope that helps.

---

Thanks, that's reasonable, although if it's taking your laptop 24 hours or so to run that, you may get just as good a result if you ramp the max bond dimension up more slowly. So like doing only the last 5 or 10 sweeps at bond dimension 600, and the ones before that at 500 or 400 at most. Since DMRG scales as bond dimension cubed, that could make the calculation something like 2 times faster (so only half a day).

---

Thanks Miles! Sorry to bother you with my questions again but I keep getting the following error (of svd not converging) as I approach the phase transition (not all the time; but with like probability 1/8 or so; I thought it would go away but just shows up randomly). The error shows up in the middle of the dmrg sweeps. Is there anything that I can do on my part to avoid it?

The SVD algorithm `"divide_and_conquer"` has thrown an error,
likely because of a convergance failure. You can try
other SVD algorithms that may converge better using the
`alg` (or `svd_alg` if called through `factorize` or MPS/MPO functionality) keyword argument:

 - "divide_and_conquer" is a divide-and-conquer algorithm
   (LAPACK's `gesdd`). It is fast, but may lead to some innacurate
   singular values for very ill-conditioned matrices.
   It also may sometimes fail to converge, leading to errors
   (in which case `"qr_iteration"` or `"recursive"` can be tried).

 - `"qr_iteration"` (LAPACK's `gesvd`) is typically slower
   than "divide_and_conquer", especially for large matrices,
   but is more accurate for very ill-conditioned matrices
   compared to `"divide_and_conquer"`.

 - `"recursive"` is ITensor's custom SVD algorithm. It is very
   reliable, but may be slow if high precision is needed.
   To get an `svd` of a matrix `A`, an eigendecomposition of
   ``A^{\dagger} A`` is used to compute `U` and then a `qr` of
   ``A^{\dagger} U`` is used to compute `V`. This is performed
   recursively to compute small singular values.

Returning `nothing`. For an output `F = svd(A, ...)` you can check if
`isnothing(F)` in your code and try a different algorithm.

To suppress this message in the future, you can wrap the `svd` call in the
`@suppress` macro from the `Suppressor` package.

---

Hi Arnab,
Yes, the error message is actually suggesting what you can do :^) We were aware that the default SVD algorithm of Julia (actually of the underlying LAPACK) sometimes fails, but we keep it as the default because it's usually reliable and is very fast and accurate. Unfortunately you've found one of the failure cases.

So as the error message indicates, the fix is to pass a keyword argument to change which algorithm is used. A subtlety is that the keyword arg is named `alg` if you call `svd` directly but it's called `svd_alg` if you are calling it through the `dmrg` function.

So basically please try calling DMRG as:

    dmrg(H,psi0,sweeps; svd_alg="qr_iteration")

or as

    dmrg(H,psi0,sweeps; svd_alg="recursive")

Hopefully one of those will run reliably, then please choose whichever one gives the fastest running times.

---

To expand on this a bit, in C++ ITensor we have added an automated fallback for the SVD algorithm, where if the default "divide_and_conquer" (LAPACK's gesdd) fails to converge we try the more reliable "qr_iteration" (LAPACK's gesvd). I haven't heard of that one failing to converge, but if it did we could then try the even more reliable (but slower) "recursive" algorithm. We should add this to the Julia version as well. See the discussion: https://github.com/ITensor/ITensor/pull/386

---

But for now, I would recommend trying `dmrg(H,psi0,sweeps; svd_alg="qr_iteration")` as Miles suggested.