CompatHelper: bump compat for TensorKit to 0.15

[github-actions]

This pull request changes the compat entry for the TensorKit package from 0.14.9 to 0.14.9, 0.15.
This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

[github-actions]

Your PR no longer requires formatting changes. Thank you for your contribution!

[pbrehmer]

I adopted most of the easy to the new TensorKit/MatrixAlgebraKit interface and adjusted some of the naming as well. Regarding the naming there are some questions:

• Should we rename all occurences of trscheme to something like trstrat in line with the new TruncationStrategy name?
• Should we rename :sdd and :svd to something like :divideandconquer and :qriteration also more in line with the new MatrixAlgebraKit names?

In both case I don't have strong feelings and would be fine with leaving them as they are.

The main thing that's left to be done is the mess inside of /src/utility/svd.jl. There are a few choices that we have make here. Mainly they revolve around to what degree we want to redo the SVD interface (in this PR or in a separate one) to follow MatrixAlgebraKit's style. Personally, I would like to clean up this interface at some point. There are some intricacies with respect to the SVD rrules, such as the Lorentzian broadening which isn't yet activated in MatrixAlgebraKit (there the divergent terms use inv_safe). Additionally, there are some new aspects regarding the truncation algorithms because MatrixAlgebraKit introduced a TruncatedAlgorithm type while PEPSKit keeps the truncation algorithm separate (as previously in TensorKit). @leburgel Maybe we can discuss some of these things tomorrow?

One last thing I noticed was that MatrixAlgebraKit actually gauge-fixes the SVDs in some way. I was wondering if this would actually lead to element-wise convergence even without our more sophisticated gauge fixing routine. From what I heard, some PEPS practicioners actually fix their CTMRG by just fixing the SVD to reach element-wise convergence. (I do think this is an inherently worse idea and has no general guarantee to work but it would be significantly cheaper.)

[lkdvos]

I'm not sure that the SVD gauge fixing is actually sufficient: the issue remains that there are gauge degrees of freedom that you can propagate "around the ring" of environments.

[pbrehmer]

This should work now (up to small things in the tests - let's see if the CI runs through). I left most of the things on the user side untouched and tried to contain the messiness inside of the SVD wrapper interface. This way we won't have to break things in the future (hopefully). There we will have to update things to properly interface with MatrixAlgebraKit's pullbacks once we can do broadening. Also we should remember that currently all truncation errors are being set to zero; so that has to be updated once TensorKit implements that.

In any case, a more involved revamping of the PEPSKit-TensorKit-KrylovKit SVD trinity should anyway happen in a separate PR with more intention. For now this seems usable and I wouldn't want to wait much longer to make PEPSKit compatible with TensorKit v0.15.

[codecov]

Codecov Report

❌ Patch coverage is 92.21557% with 13 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/utility/svd.jl	86.53%	7 Missing ⚠️
src/algorithms/ctmrg/ctmrg.jl	66.66%	2 Missing ⚠️
src/algorithms/ctmrg/projectors.jl	92.30%	1 Missing ⚠️
src/algorithms/ctmrg/sequential.jl	50.00%	1 Missing ⚠️
src/algorithms/time_evolution/evoltools.jl	85.71%	1 Missing ⚠️
src/algorithms/truncation/truncationschemes.jl	94.11%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/Defaults.jl	85.71% <ø> (ø)
src/PEPSKit.jl	100.00% <ø> (ø)
src/algorithms/contractions/bondenv/gaugefix.jl	100.00% <100.00%> (ø)
src/algorithms/contractions/ctmrg_contractions.jl	50.89% <ø> (ø)
src/algorithms/ctmrg/gaugefix.jl	97.19% <100.00%> (ø)
src/algorithms/ctmrg/simultaneous.jl	100.00% <100.00%> (ø)
...rithms/optimization/fixed_point_differentiation.jl	91.72% <100.00%> (ø)
src/algorithms/time_evolution/simpleupdate.jl	100.00% <100.00%> (ø)
src/algorithms/time_evolution/simpleupdate3site.jl	100.00% <100.00%> (ø)
src/algorithms/truncation/bond_truncation.jl	97.01% <100.00%> (ø)
... and 9 more

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[pbrehmer]

Update: We'll have to wait until TensorKit tags a new release since the TruncationIntersection things are broken in the current version (i.e. to chain truncation strategies).

[pbrehmer]

Also something regarding truncspace seems to have broken and I'm not yet sure why. In the unit cell tests where all spaces are selected at random, we now get errors:

nested task error: ArgumentError: resulting vector space is never dual
      Stacktrace:
        [1] #truncspace#66
          @ ~/.julia/packages/TensorKit/sWn5k/src/factorizations/truncation.jl:24 [inlined]
        [2] truncspace
          @ ~/.julia/packages/TensorKit/sWn5k/src/factorizations/truncation.jl:23 [inlined]
        [3] truncation_strategy
          @ ~/repos/PEPSKit.jl/src/algorithms/ctmrg/projectors.jl:63 [inlined]
        [4] (::PEPSKit.var"#460#461"{InfiniteSquareNetwork{Tuple{TensorMap{ComplexF64, ComplexSpace, 1, 4, Vector{ComplexF64}}, TensorMap{ComplexF64, ComplexSpace, 1, 4, Vector{ComplexF64}}}}, CTMRGEnv{TensorMap{ComplexF64, ComplexSpace, 1, 1, Vector{ComplexF64}}, TensorMap{ComplexF64, ComplexSpace, 3, 1, Vector{ComplexF64}}}, HalfInfiniteProjector{SVDAdjoint{MatrixAlgebraKit.LAPACK_DivideAndConquer{@NamedTuple{}}, FullSVDReverseRule}, FixedSpaceTruncation}})(::Tuple{Int64, Int64})
          @ PEPSKit ~/repos/PEPSKit.jl/src/algorithms/ctmrg/sequential.jl:89
...

Apparently there is a new assertion in truncspace:

function truncspace(space::ElementarySpace; by = abs, rev::Bool = true)
    isdual(space) && throw(ArgumentError("resulting vector space is never dual"))
    return TruncationSpace(space, by, rev)
end

which wasn't there before. I'm wondering what's going wrong here since the inputs didn't change as far as I can tell. If someone has an idea, let me know. Otherwise, I'll take a look again on Monday.

[lkdvos]

I think this was a silent bug previously (which is why I added the assertion), also associated to how the decompositions were being handled. When we performing an SVD, you can always make the canonical choice of S not having any dual spaces, and therefore the truncation strategy should never contain a dual space, or it will give strange results. This should now be fixed, but it also means that the truncation spaces have to all be non-dual.

In some sense, this means that the choice of arrows on our states and environments is actually dictated partially by the algorithms we are performing on them, e.g. even if you start with dual spaces, an algorithm that performs SVDs could alter this.

[leburgel]

This is related to the new dualness check in the inner constructor of CTMRGEnv

Yes, during the backpropagation Zygote tries to accumulate all of the adjoints for the corners and edges by putting them in a CTMRGEnv with all other entries set to ChainRulesCore.ZeroTangent, and then adds all the contributions one by one. So the final adjoint is a CTMRGEnv with all TensorMap entries, but the assertion breaks the construction of the intermediate objects.

The easiest fix would probably be to exclude AbstractZeros from the space duality check, but this is very hacky so maybe bot the best idea. I do like having the check in the inner constructor though, to make sure nothing slips through cracks.

[pbrehmer]

Why not use trunc as the truncation strategy keyword, which would be the same as what is used in MatrixAlgebraKit.jl and TensorKit.jl? I don't really prefer trunc as a name by itself, but I think it would be nice to just be able to use the same keyword everywhere consistently.

Actually I agree. Then I'll rename all occurences of trscheme to trunc. But keep in mind that this will affect a lot of code, I hope this doesn't bother people.

I think here we can just choose whatever feels best, I would be very surprised if many people got in so deep that they really rely on these names much. I would go for whichever name gives the best chance of finding something useful when using it to search through the MatrixAlgebraKit or LinearAlgebra.LAPACK documentation.

I think here I would be fine with just leaving :sdd and :svd in place because that's still in accordance with LAPACK naming and the alternatives would be relatively long. But I'm also to rename it. I was just looking for opinions on this :-)

[lkdvos]

The easiest fix would probably be to exclude AbstractZeros from the space duality check, but this is very hacky so maybe bot the best idea. I do like having the check in the inner constructor though, to make sure nothing slips through cracks.

How do you feel about something like this:

struct CTMRGEnv{...}
    ...
    function CTMRGEnv{}(...)
         foreach(check_ctmrg_spaces, corners)
         foreach(check_ctmrg_spaces, corners)
        new{}(...)
    end
end
check_ctmrg_spaces(x::AbstractZero) = nothing
check_ctmrg_spaces(x::CTMRG_EdgeTensor) = ...
...

I think that's both idiomatic, extensible, and not too hacky (naming up for grabs as usual)

---

Actually I agree. Then I'll rename all occurences of trscheme to trunc. But keep in mind that this will affect a lot of code, I hope this doesn't bother people.

I'm definitely in favor, will do the same for MPSKit in the next set of breaking changes I think.

I think here I would be fine with just leaving :sdd and :svd in place because that's still in accordance with LAPACK naming and the alternatives would be relatively long. But I'm also to rename it. I was just looking for opinions on this :-)

I think these symbols are fine, although in the long run it would be nice to see if we can simply always use sdd with an svd fallback at this level, and not really have to deal with this anymore.

[leburgel]

Zygote was crashing on the map(svd_vals, env₀.corners), map(svd_vals, env₀.edges) in the leading boundary routine when using gradient_alg = nothing. Since these are only used to calculate convergence I wrapped them in ignore_derivatives, which seems to solve the remaining gradient test failures.

So it's not really a problem here, but it seems that MatrixAlgebraKit.svd_vals(t::TensorMap) is not differentiable right now (@lkdvos).

[leburgel]

Only one failing test remaining. It seems that there's a CTMRG that completely fails to converge in the test for the Fermi-Hubbard model with 2-site and 3-site simple update, causing the test of the 2-site simple update energy to fail (but only in one instance for some reason). Maybe we can try growing from a smaller initial environment that doesn't have the full truncation rank yet (maybe even from a product state) to stabilize the contraction?

[Yue-Zhengyuan]

To converge the CTMRGEnv for the 2/3-site Fermi-Hubbard SU test, I now use the SUWeight as initialization. Thing should now work for all platforms.

[pbrehmer]

This would be good to go for me now (if the tests pass) :-)

[lkdvos]

Let me go over this in a bit more detail today. I'm slightly unhappy about not being able to further simplify the svd parts, but I guess it is better to first get this merged and working again, and then go in and try to simplify this further. Anyways, review incoming today

[lkdvos]

Left some final small comments, otherwise good for me!