`similar` does not work if storagetype is a PtrArray

[Qiaoyi-Li]

It seems that TensorKit.jl v0.14.1 is currently not well compatible with TensorOperations.jl. I try to use the new feature allocator = ManualAllocator() to decrease the memory pressure, which however results in an error in certain cases. The error is finally due to a similar call in @tensor macro, when a permutation is needed. Below is a minimal code example to reproduce the error:

using TensorKit
using TensorKit.TensorOperations
using TensorKit.TensorOperations: tensoralloc_contract, ManualAllocator

A = id(Rep[SU₂](0=>1))
B = id(Rep[SU₂](0=>1))

t = tensoralloc_contract(Float64, A, ((1, ), (2,)), false, B, ((1,), (2,)), false, ((1,), (2,)), Val{true}(), ManualAllocator())

similar(t) #  MethodError: no method matching PtrArrays.PtrArray{Float64, 1}(::UndefInitializer, ::Int64)

Temporarily, I add a constructor

function TensorMap{T, S, N₁, N₂, A}(::UndefInitializer,
	space::TensorMapSpace{S, N₁, N₂}) where {T, S <: IndexSpace,
	N₁, N₂,
	A <: PtrArray{T, 1}}
	d = fusionblockstructure(space).totaldim
	# data = A(undef, d) # this line will lead to an error 
     data = Array{T, 1}(undef, d)
	if !isbitstype(T)
		zerovector!(data)
	end
	return TensorMap{T, S, N₁, N₂, Array{T, 1}}(data, space)
end

to make my code continue running. Since there is not a tensorfree! for this tensor in @tensor, I construct a common tensor to avoid potential memory leaks. Is this necessary?

Any suggestions on the temporary solution would be greatly appreciated. I also hope the future version of TensorKit.jl can provide an official one to fix this issue.

[Jutho]

Thanks for reporting this; this is definitely an oversight and unintentional. We will try to fix asap (and include it in our tests).

[Jutho]

@Qiaoyi-Li , could you possibly provide a more high-level example that illustrates where the call to similar arises, as it would be good to understand and possibly fix this also at that level? Thanks

[Qiaoyi-Li]

@Qiaoyi-Li , could you possibly provide a more high-level example that illustrates where the call to similar arises, as it would be good to understand and possibly fix this also at that level? Thanks

Sure.

using TensorKit
using TensorKit.TensorOperations: ManualAllocator

A = randn(Rep[U₁ × SU₂]((0, 0)=>1) ⊗ Rep[U₁ × SU₂]((0, 1/2)=>1, (1, 0)=>1, (-1, 0)=>1), Rep[U₁ × SU₂]((0, 1/2)=>1, (1, 0)=>1, (-1, 0)=>1) ⊗ Rep[U₁ × SU₂]((0, 0)=>1))

B = randn(Rep[U₁ × SU₂]((0, 0)=>1), Rep[U₁ × SU₂]((0, 0)=>1))
C = randn((Rep[U₁ × SU₂]((0, 0)=>1, (0, 1)=>1, (1, 1/2)=>2, (-1, 1/2)=>2) ⊗ Rep[U₁ × SU₂]((0, 1/2)=>1, (1, 0)=>1, (-1, 0)=>1)), Rep[U₁ × SU₂]((0, 1/2)=>1, (1, 0)=>1, (-1, 0)=>1))

@tensor allocator = ManualAllocator() D[b g f; h d] := ((A[b c d e] * B[e f]) * C[g h c])

This is the case that triggers this error in my code. A*B generates a temporary tensor with storagetype = PtrArray. Then, similar is called in a permute when contracting it with C.

[Jutho]

@Qiaoyi-Li, this should now be fixed in 0.14.2. Feel free to reopen or file more issues if you encounter more problems.