Multisite terms (>2)

[snirgaz]

Thanks for sharing this nice package!

Is it possible to define multisite terms beyond two sites?
For instance- Plaquette or star terms as in the Toric code model.
The currently available implementation only contains two site terms.

Thanks!

Snir

[lkdvos]

Hi Snir,

The multisite terms are implemented, similarly to how the twosite terms work:

operator = TensorMap(rand, ComplexF64, ComplexSpace(2)^4, ComplexSpace(2)^4)
H = @mpoham operator{i,i+1,i+2,i+3} for i in vertices(FiniteChain(20))

This should also work for the other lattice types. However, keep in mind that everything will get mapped back to an MPS, i.e. for a Toric code model on a torus this means that the interactions become long-ranged, so it might still become quite expensive.

Hope this helps!

[snirgaz]

Thanks for the quick reply!

With this approach, I would have to specify all tensor elements (right?).
Is there an equivalent (multisite) functionally to:

function S_xx(elt::Type{<:Number}, ::Type{Z2Irrep}; spin=1 // 2)
return contract_twosite(S_x(elt, Z2Irrep; spin=spin), S_x(elt, Z2Irrep; spin=spin))
end

to build the operator as a product over single site operators?

Thanks!

Snir

[lkdvos]

It depends a bit on the operator and the symmetries. It is always possible to join together factors that are symmetric by themselves, so in the trivial symmetry case you could just do:

S_xxxx = X \otimes X \otimes X \otimes X

For the case where you do have some symmetry, it becomes a bit more complicated, but if you can find separate factors that are symmetric, it more or less works the same:

S_xxxx = S_xx \otimes S_xx

This even works on the level of the operators as well:

H = @mpoham S_xx{i,j} * S_xx{k,l} [...]

---

the bottom line here is that the contract_twosite function is only necessary when there is a non-trivial charge involved for the single site operators, which then need an additional leg to compensate for this. The contract_twosite function then makes sure these get paired up correctly, such that the total operator is symmetric again.

[snirgaz]

Thanks for the quick and detailed reply!
One more question:
How is the MPO constructed? In particular, is there a notion of compression or other tricks for keeping the MPO size as small as possible?

Thanks!

[lkdvos]

This is currently not done. The only optimizations that are there are the following:

• The mpo is stored sparsely, i.e. only the non-zero terms are multiplied.
• The identity or scalar terms are stored separately, i.e. whenever you have a twosite term that acts on non-neighbouring sites, the transfer matrix is not computed by inserting a (braiding) identity tensor, but by implicitly leaving out that operator

You can play around a bit with the parallelization settings as well, there is a section in the documentation for this, where it allows parallelization over the different non-zero entries in the MPO

[lkdvos]

Can I close this? Are there any specific features you are missing?

[snirgaz]

Sure. Thanks again for your help!
It would be nice to have some automated compression of the MPO, but I guess it is too much to ask for :)

[lkdvos]

I agree, it is definitely somewhere on my list (although for now not too high up there ;))
In any case, this would definitely be a feature in MPSKit, so if you want to open an issue there as a reminder, that's definitely okay, but I will close this.

Out of curiosity, were you able to reproduce some results of the toric code?

[snirgaz]

Sorry for not getting back to you. I hope to get back to benchmarking the toric code soon and will keep you posted Snir בתאריך יום ה׳, 13 ביוני 2024, 08:21, מאת Lukas ***@***.***>:

…

I agree, it is definitely somewhere on my list (although for now not too high up there ;)) In any case, this would definitely be a feature in MPSKit, so if you want to open an issue there as a reminder, that's definitely okay, but I will close this. Out of curiosity, were you able to reproduce some results of the toric code? — Reply to this email directly, view it on GitHub <#17 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABUFVYON7OZ4JW76BRHXRKLZHET6PAVCNFSM6AAAAABICYGKOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRUGQYDINJWGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>