Skip to content

DMRG calculations are staggeringly slower than in previous versions #381

Closed

Description

So, I just upgraded to MPSKit 0.13.9 and TensorKit 0.16.2 from 0.13.8 and 0.15.3 respectively, and for whatever reason the performance of DMRG is far worse for the same code. To be concrete, here is a complete example that you can try:

using MPSKit, MPSKitModels, TensorKit, BenchmarkTools

# Parameters for the Hamiltonian
L = 30
χ = 1
Δ = 0.1
Ω = 0.0
C = 1.0

function potential_vdW(L, C)
    f(i, j) = i==j ? 0 : abs(i-j)^(-6)
    V = [C*f(i,j) for i in 1:L, j in 1:L]
    return V
end

function rydberg_chain_hamiltonian(L, Ω, Δ, V)
    n̂ = TensorMap(ComplexF64[0 0; 0 1], ℂ^2 → ℂ^2)
    chain = fill(ℂ^2, L)
    single_site = Dict()
    for I in eachindex(chain)
        single_site[(I,)] = (Ω/2)*σˣ() - Δ*n̂
    end
    two_site = Dict()
    for I in 1:L 
        for J in I+1:L 
            two_site[(I,J)] = V[I,J]* (n̂⊗n̂)
        end
    end

    H = FiniteMPOHamiltonian(chain, single_site)+FiniteMPOHamiltonian(chain, two_site)

    return H
end 

H = rydberg_chain_hamiltonian(L, Ω, Δ, V)
ψ₀ = FiniteMPS(rand, ComplexF64, L, ℂ^2, ℂ^χ)
println("Starting ground state calculation.")
@btime ψ, _, _ = find_groundstate(ψ₀, H, DMRG(; tol=1e-6, verbosity=0))

As you can see, I have only 30 points in my chain, and I use bond dimension 1, because it should be good for the problem (Ω=0 is classical so no need for entanglement). It should be a relatively quick calculation, but in my machine it took 73.314 seconds according to btime.

On the other hand, if I use MPSKit 0.13.8 and TensorKit 0.15.3, according to btime execution takes a mere 1.1 seconds, about 70 times less!

Activity

  1. lkdvos commented on Feb 11, 2026

    @lkdvos
    Member

    I think I was able to trace back the issue to some unfortunate combination of events that previously masked a performance pitfall in BlockTensorKit, that was now uncovered.
    This should be resolved after QuantumKitHub/BlockTensorKit.jl#43 is merged and released, hopefully regaining the original performance (and possibly being slightly faster, but no promises there).

    Thanks for reporting this though, I would not have noticed this for quite a while otherwise!

  2. AndreasChristophilopoulos commented on Feb 11, 2026

    @AndreasChristophilopoulos
    Author

    That's very nice. I will eagerly await the release and test it.

  3. linked a pull request that will close this issueBump v0.13.10 #379on Feb 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions