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?
There was a problem hiding this comment.
It may be helpful to revisit the example in #283 (comment). I need to some time to better explain what's happening.
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!
lkdvos
left a comment
lkdvos
left a comment
There was a problem hiding this comment.
Happy to revisit the remaining comment about the twists in the other PR and get this merged as-is.
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.