Generalize InfinitePartitionFunction observable evaluation
#117
Conversation
Codecov ReportAttention: Patch coverage is
|
|
I have added an initial sketch of what I was talking about yesterday in #111. Operators that act on While I do think that this is functional, I'm not sure about a few things. For example, to compute the denominator in Overall, I'd be okay with having an interface like this since you can readily evaluate correlation functions or arbitrary operator strings and it is kind of similar to what we have with |
|
The thing I don't like about this approach is that it is fully biased towards non-symmetric tensors, and does not generalize. For example, even in the Ising model, inserting a single flip in a symmetric partition function does not work with the Z2 symmetry, and really what you need is an auxiliary leg to carry that charge, which connects the other flip, in order to obtain a non-zero result. In that sense, this is not really a clean generalization of the quantum case, where you can insert pairs of spin flips at 2 locations because they are represented by a single operator. Additionally, the syntax in terms of ntuples doesn't provide enough information, because even if we would give each tensor an additional leg, you now also need to specify how to pair them up in the case where Given these constraints, I would maybe suggest that we don't try to push two-point correlators into the same formalism, given that there is not really that much shared code anyways. In MPSKit.jl, there is a function """
correlator(ψ, O1, O2, i, j)
correlator(ψ, O12, i, j)
Compute the 2-point correlator <ψ|O1[i]O2[j]|ψ> for inserting `O1` at `i` and `O2` at `j`.
Also accepts ranges for `j`.
"""while I don't think the second syntax makes sense here, I would be more tempted to add the first. This is a more intuitive syntax for what we're trying to compute anyways, and does not need to include the generic case of |
|
Indeed, I forgot about symmetric tensors. Then let's forget about the
|
|
It's definitely not necessary for both to be adjacent, and I have no problem also supporting the case without an additional leg. The bigger question is whether the implementation via a full contraction is the correct one. Keep in mind that this code is written for evaluating local expectation values, ie nearest-neighbour, next-nearest neighbour etc, and really does not scale very well. On the one hand, if the correlator would be in a vertical or horizontal line, you really would not want to hand off this entire contraction to |
|
Well, you have a point. Probably the best way to go forward is to wait until someone actually needs to evaluate correlators and then implement it (well who could have thought :P). Since I'm short on time and really need to get some other stuff done, I'll probably let the PR sleep for a while or someone else implements this. |
|
The day that someone needs this has come. I am interested in implementing the expectation value of a LocalOperator of a Additionally, I would like to look at the case where we calculate the correlation function on a horizontal or vertical patch. As mentioned above, this can be calculated much more efficiently than just contracting the full tensor contraction by doing something similar to how it's defined in |
|
After thinking about it a bit more, I would propose that instead of a Tuple of Pairs of indices and operators, we could generalise this to the situation where multiple (possibly excited) partition functions are inserted. We would then need a way to denote which excited partition functions should be contracted with each other and how. To this end, we could change the input argument from Any suggestions on this are very welcome. It should be relatively straightforward to change the current code to the more general case, and I'll look into this when we have settled on a convention. As mentioned above, I think that additional functionality like the expectation value of a LocalOperator of an InfinitePartitionFunction and horizontal/vertical correlation functions should be postponed to a later PR. |
|
I'm not entirely sure I'm following what you are saying. It seems to me that trying to reduce the expectation value for finite temperature things to this case would reintroduce the problems discussed before, and then we have an interface where you would have to provide the partially contracted operator with the density matrix instead of simply giving the operator and the density matrix. What I mean is this, say we do some finite temperature calculations to construct |
|
No, I mean it exactly like you said, and would like to keep the interface I mean that internally, if we want to calculate that expression, we would need to sum over the different gates in H (I don't think there is a way around that if it is a |
|
Why do you think this can be avoided in the PEPO case, but not the PEPS case? I agree that there are some parts of the contractions that can be reused in general, and we might invest some time in optimizing this for specific examples, but I don't see why this would be different for pepos than for peps. Unless I'm missing something, I would say that the finite temperature case can really just be understood as a superstate with two physical legs, and the local operators then act on only one of them, implemented slightly more efficiently. Is that incorrect? |
|
I meant that It's different to evaluate |
Based on PR QuantumKitHub#117 of PEPSKit, this generalizes the expectation value for InfinitePEPOs and InfinitePartitionFunctions
lkdvos
force-pushed
the
master
branch
2 times, most recently
from
ad4945f to
37ace4c
Compare
This PR will add generic contractions which allow us to use multi-site operators in
expectation_value(pf::InfinitePartitionFunction, ...). Here, we will try to reuse the local operator contraction mechanism which automatically constructs the correct enlarged environment and inserts states/operators based on the suppliedinds.