Skip to content

Changes for non-CPU array support#375

Open
kshyatt wants to merge 4 commits intomainfrom
ksh/cu
Open

Changes for non-CPU array support#375
kshyatt wants to merge 4 commits intomainfrom
ksh/cu

Conversation

@kshyatt
Copy link
Member

@kshyatt kshyatt commented Feb 6, 2026

Mostly allowing passing an array type instead of just an element type to allow GPU arrays to back MPS tensors

@kshyatt kshyatt requested a review from lkdvos February 6, 2026 10:32
)
# left to middle
U = ones(scalartype(H), left_virtualspace(H, 1))
U = ones(storagetype(H), left_virtualspace(H, 1))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think here we should actually call removeunit instead of writing this as a contraction. This is both more efficient and avoids having to deal with storagetype altogether.
Let me know if you need help with this though

Comment on lines +41 to +42
TensorKit.storagetype(PA::PeriodicArray{T, N}) where {T, N} = storagetype(T)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little hesitant to adopt storagetype in such a general manner here in MPSKit, since I don't think this is even exported by TensorKit. If this function should exist, I think we would have to decide to use storagetype(A::AbstractArray) = storagetype(eltype(A)), but I'm not sure if that really is in the scope of that (somewhat internal) function

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, after thinking a bit about this: it is in fact an exported method, and I do agree that this is the one we want to use. This being said, I would like to avoid defining it on PeriodicArray directly, and reserve it for specific cases where actual tensors are involved. I am not sure if that makes sense to you or it just feels arbitrary, but I feel like PeriodicArray{Float64} is in principle a reasonable thing to have, and in that case the storagetype does not have to be storagetype(Float64).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's fair, I can try to remove this and work around any places it breaks things. Shouldn't be too hard to do, might just have to define a few more specializations (e.g. for InfiniteMPS)

@codecov
Copy link

codecov bot commented Feb 11, 2026

Codecov Report

❌ Patch coverage is 60.25641% with 31 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/states/infinitemps.jl 36.36% 7 Missing ⚠️
ext/MPSKitAdaptExt.jl 0.00% 6 Missing ⚠️
src/states/ortho.jl 0.00% 6 Missing ⚠️
src/states/abstractmps.jl 50.00% 5 Missing ⚠️
src/states/quasiparticle_state.jl 25.00% 3 Missing ⚠️
src/operators/jordanmpotensor.jl 88.88% 1 Missing ⚠️
src/operators/mpohamiltonian.jl 83.33% 1 Missing ⚠️
src/operators/multilinempo.jl 0.00% 1 Missing ⚠️
src/utility/periodicarray.jl 0.00% 1 Missing ⚠️
Files with missing lines Coverage Δ
src/environments/abstract_envs.jl 94.44% <100.00%> (+2.33%) ⬆️
src/utility/defaults.jl 100.00% <ø> (ø)
src/operators/jordanmpotensor.jl 83.87% <88.88%> (-0.25%) ⬇️
src/operators/mpohamiltonian.jl 89.87% <83.33%> (-0.32%) ⬇️
src/operators/multilinempo.jl 28.57% <0.00%> (-1.43%) ⬇️
src/utility/periodicarray.jl 78.12% <0.00%> (-2.53%) ⬇️
src/states/quasiparticle_state.jl 85.76% <25.00%> (-0.93%) ⬇️
src/states/abstractmps.jl 50.54% <50.00%> (-13.82%) ⬇️
ext/MPSKitAdaptExt.jl 0.00% <0.00%> (ø)
src/states/ortho.jl 79.08% <0.00%> (-3.23%) ⬇️
... and 1 more

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 11, 2026

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

@kshyatt kshyatt force-pushed the ksh/cu branch 3 times, most recently from 9890491 to 046f4d0 Compare February 11, 2026 13:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants