Insert projectors to PEPS optimizations - #18
Conversation
|
This seems like a good way to go. |
sounds good, I will work on rrule for split_network on top of this. |
LinjianMa
changed the title
|
This PR is still in progress |
|
@mtfishman please take a look, note that for the rrule for split_networks, https://github.com/LinjianMa/ITensorNetworkAD.jl/blob/main/src/Optimizations/itensor_network.jl#L5, |
I thought you had already written a rule for |
| ITensors.prime(P::PEPS, n::Integer=1) = PEPS(map(x -> prime(x, n), P.data)) | ||
|
|
||
| # prime a PEPS with specified indices | ||
| function ITensors.prime(indices::Array{<:Index,1}, P::PEPS, n::Integer=1) |
There was a problem hiding this comment.
Would be nice to implement a more direct prime(siteinds, ::PEPS, ...) function to complement prime(linkinds, ::PEPS, ...). I'll add that as an issue.
|
Great to see this coming along. What kinds of system sizes have you tried so far? |
Currently, it still can't accelerate large system calculations, and the major reason is that using the greedy search algorithm to find the contraction path won't find the optimal one, and the path it generates will still have large intermediates. For other heuristics I've tried, such as dynamic programming, the contraction_path finding time is too long. I will next work on the constrained contraction path optimization that is implemented in AutoHOOT, and try to get that working with PEPS. |
|
Interesting to hear that the contraction path computation is the limiting factor. What systems sizes can you reach before the contraction path is too costly to compute? Probably you've considered this, but a simple optimization to do would be to precompute the contraction paths, since they will be the same every time the gradient is being computed. |
2 participants
I don't know if this's the best way to do it, so just put it here for discussion. Tests haven't been added yet.
Maybe the inv_op can be merged with those in the ITensorChainRules module.