Make SUWeight axis order definite #315
Conversation
Codecov Report❌ Patch coverage is
🚀 New features to boost your workflow:
|
|
Hold on, just found a problem in |
|
Well, it turns out to be bugs in external code not relevant to contents in this PR... |
| # contract local ⟨t|t⟩ without virtual twists | ||
| @tensor ρ[k; b] := conj(t[b; n e s w]) * twistdual(t, 2:5)[k; n e s w] |
There was a problem hiding this comment.
| # contract local ⟨t|t⟩ without virtual twists | |
| @tensor ρ[k; b] := conj(t[b; n e s w]) * twistdual(t, 2:5)[k; n e s w] | |
| # contract local ⟨t|t⟩ without virtual twists | |
| @plansor ρ[k; b] := conj(t[b; n e s w]) * t[k; n e s w] |
But this is also just t' * t
There was a problem hiding this comment.
Well, it is not t' * t (this is contracting the physical legs), or t * t' (is this what you actually mean?). The reason is a bit subtle (and also related to discussions in #283 about why all reduced density matrices (RDMs) are normalized with supertraces).
The matrix element of an operator O x 1 between two states |bra>, |ket> (assuming all physical spaces are non-dual for simplicity) is <bra|O x 1|ket>, where O acts on a sub-system, while 1 acts on the other parts. PEPSKit constructs the RDM for O as O -> <bra|_ x 1|ket>, but then decides to permute (instead of transpose, because of the usage of @tensor) the ket axes to the front to follow the traditional axis order for RDMs.
Before the final permutation, the RDM is something like
But afterwards it becomes (for fermions) permute.
Therefore, the RDM should be ρ = twist(t * t', numout(t)). If you think this is better, please just go ahead to change it (I tested and it works).
There was a problem hiding this comment.
You are completely right, I overlooked that it really has to be t * t' to make the correct legs contracted, but I'm slightly lost again with what comes after.
In order for the leg order to be consistent, should it not be transpose(t * t'), which would be what the @plansor call evaluates to? Are you then suggesting we need an additional twist to compensate for the twist we will be adding in the normalization through the supertrace, or would this then not need a twist at all?
src/environments/suweight.jl
Outdated
|
|
||
| """ | ||
| SUWeight(Nspaces::M, [Espaces::M]) where {M<:AbstractMatrix{<:Union{Int,ElementarySpace}}} | ||
| SUWeight(Nspaces::M, [Espaces::M]; random::Bool=false) where {M<:AbstractMatrix{<:ElementarySpace}} |
There was a problem hiding this comment.
I'm not entirely convinced that the random keyword is appropriate for the constructor here. We could also just define rand!(::SUWeight) instead if this is useful functionality, rather than trying to fit everything in the constructor call?
I'm mostly saying this since it feels slightly arbitrary to include Inf-normalized uniformly distributed random elements as the only option, while we could also have randexp etc. Putting all of these configurations through keyword arguments usually ends up slightly messy
There was a problem hiding this comment.
I now introduced Random.rand! without normalization as you suggested.
lkdvos
left a comment
lkdvos
left a comment
There was a problem hiding this comment.
Sorry for taking a while, I left some minor comments but otherwise this looks good to go for me!
2 participants
This PR makes SUWeight axis order independent of the virtual arrow directions of the matching iPEPS/O. They are now always (west, east) or (south, north).
I managed to keep weight elements positive by requiring that the weights are absorbed into the site tensors without twists. It may be better now to mentally regard each weight as a tuple (bond space, SVD spectrum vector), only stored as a DiagonalTensorMap for convenience.
I still prefer saving the SUWeight as the environment of the bra-ket norm network, at the (very minor) cost that we need to take square roots when absorbing/removing weights from iPEPS/O tensors. In this way, the relation to CTMRGEnv and BP is most manifest.