Repository navigation
Add support for local expectation values of tensor product and MPO terms - #425
Conversation
|
I suppose this is exact contraction with CTMRG/BPEnv ? |
Yes, precisely that. The idea was to add support for alternative operator forms for situations that are very badly suited to our current dense-tensor-operator approach, while still being compatible with AD to use them in variational optimizations. In particular, the motivating cases are multi-site interactions that factor into a plain tensor product across sites (e.g. plaquette terms in gauge theories), and short-range two-site interactions for systems with a large physical dimension. Both of these are extremely expensive for our current approach, while simply storing the tensor product factors separately or storing the operator as a 2-site MPO of low bond dimension greatly reduces the cost. This is still very much a draft, but I already filed the PR to demonstrate how #423 allows to easily add support for exact evaluation of different operator types. In particular, the |
2e35ed7 to
f851709
Compare
23097ff to
2af2bb8
Compare
Adapt the draft MPO representation with ordered factors, physical-space and bond validation, scalar promotion, and safe scaling. Guard unsupported accumulation and real/imaginary operations, and add focused bookkeeping tests.
Yue-Zhengyuan
left a comment
Yue-Zhengyuan
left a comment
There was a problem hiding this comment.
Good to go for me. Let's merge this before #415 (which has already adopted MPOTerm, and is still blocked by MPSKit).
|
@kshyatt You may want to have a look on how should we handle the storage type for the tensor product terms and MPO terms in a LocalOperator. |
kshyatt
left a comment
kshyatt
left a comment
There was a problem hiding this comment.
Storage type handling looks ok to me, just a few stray comments elsewhere
Validate physical and bond spaces, preserve input containers, and support scalar promotion without losing tensor-product dispatch. Reject unsupported term accumulation and real/imaginary operations, and consolidate regression tests.
Add the missing single-layer MPO overload and document both PEPO evaluation forms. Cover tensor-product and MPO terms in single-layer and purified PEPOs with compact tests for trivial and fermionic symmetry.
Convert BP environments to CTMRG environments for MPO and tensor-product terms, with a TODO for native BP boundary contractions. Add regression comparisons against dense BP expectation values.
leburgel
changed the title
316ac10 to
a19fa5d
Compare
|
I circled back to this after getting very distracted, and added some timings that I was working on when I first filed this but then lost track of. One big caveat on the ability to scale these exact contractions is that the larger patches with MPO observables get completely stuck in the I think this has everything I had in mind, I'll circle back to having a look at #415 next. |
# Conflicts: # src/operators/localoperator.jl
There was a problem hiding this comment.
I made the following cleanups:
storagetypefor mixed real/complex terms is addressed in #475.- When adding an MPOTerm/TensorProductTerm to LocalOperator, explicitly convert each tensor in the vector to the same scalar type. Otherwise
scalartype(::LocalOperator)can fail. - Split
src/operators/localoperator.jl(which has become long and messy) into several smaller focused files.
I also notice that add_physical_charge hasn’t been generalized to support MPOTerm/TensorProductTerm, and I already have it implemented. But let me do it in a follow-up PR to not add more features here.
I'll not merge my own changes. @leburgel Please do it if there are no problems.
|
@leburgel Any more comments? |
|
This looks good to me! I just added some final related comments on QuantumKitHub/TensorKit.jl#593, but given the choice to promote scalar types that shouldn't affect this that much anymore. |
|
I'll proceed to merge and push new changes in #415. |
Two alternative representations for a
LocalOperatorterm, for cases the dense form handles badly, both contracted exactly and both AD-compatible:TensorProductTerm— one rank-2 operator per site, for interactions that factor across sites.MPOTerm— one tensor per site, linked by a bond of the term's Schmidt rank.Instead of leaving
2Nphysical legs open for a reduced density matrix, the factors go straight into the patch contraction, divided by the local norm of the same patch.Some bechmarks
All timings single-threaded with BLAS pinned to one thread, one measurement per process.
Large spatial support
X^{⊗n}on one patch, D = 2, χ = 8:TensorProductTermMPOTermLarge physical dimension
Two-site term, D = 2, χ = 8:
TensorProductTermMPOTermThe two axes compound. On a 2×3 patch:
TensorProductTermWhere the factored forms lose
Two-site terms at small
d, where the dense path is the hand-writtenreduced_densitymatrix1x2/2x1specialization rather than a generated contraction. At D = 3, χ = 20 the penalty is ~1.3× at d = 2 and gone by d = 3:TensorProductTermMPOTermSo dense is the better default only for nearest-neighbour terms at d = 2.
The penalty is small in context anyway. Differentiating through CTMRG at D = 3, χ = 20:
Time to first evaluation
The first call pays for both the
@autooptcontraction-order search and compiling theexpression it returns, and the search dominates. It grows steeply with the number of tensors
in the patch:
TensorProductTermMPOTermSo while all three forms do compile at nine sites, the MPO form just takes ~1.7 h to do it. This is a pre-existing property of the order search rather than something this PR introduces, and is worth a separate follow-up.
Notes for review
add_term!and+reject accumulating onto an existing MPO term rather than combining it, since a sum of MPOs of fixed bond dimension is not one of the same bond dimension. This esolves @Yue-Zhengyuan's comment, but by refusing rather than going through a dense intermediate — flagging in case that is not what you wanted.iacts on siteinds[i].TensorKit.storagetype(::LocalOperator)needed fixing: it promotes over the term values, which are vectors of factors rather than single tensors for both new term types, so it threw aMethodErrorfor any operator containing one. It now flattens the terms first, with regression tests in both term test files. Two pre-existing limitations are left alone, since they affect dense terms equally: mixed real/complex terms have no storage promotion rule in TensorKit, and an emptyLocalOperatorhas no terms to promote.