0 votes
asked by (1.1k points)

This is a question I probably should have asked a long time ago, but it didn't really occur to me until now.

For certain simple models, e.g. Ising spin models and J1-J2 models, there is a term (or multiple terms) in the Hamiltonian relating sites at the beginning and end of the chain. For example, the J1-J2 model on an N-site periodic chain has @@J1\vec{S}N\cdot\vec{S}1@@, @@J2\vec{S}{N-1}\cdot\vec{S}1@@, and @@J2\vec{S}N\cdot\vec{S}_2@@. However, when I add such terms in the Hamiltonian, no link is formed in the actual tensor network architecture, and the optimization works exactly as intended. Why is no such link needed when dealing with such terms in the Hamiltonian?

I'm kind of wondering the same thing for the terms that are just two sites apart, e.g. @@J2\vec{S}k\cdot\vec{S}_{k+2}@@, or for any distance for that matter. What's going on behind the scenes in how these terms are stored? For instance, is it true that the memory usage for a Hamiltonian term multiplying spins at two sites is larger the farther apart the two sites are?

When I use many such terms (e.g. putting a term between every pair of sites), then the code stops working and runs into memory errors, so I'm assuming that such terms do use more memory. But it seems to have no problem with a few terms of this form (as in the examples above with local interactions but periodic boundary conditions). Is this an accurate characterization?

commented by (70.1k points)
Hi Sujay, to better answer your question, are you asking about the MPO made by the AutoMPO system in ITensor? Or are you asking about the MPS resulting from a DMRG calculation with a certain Hamiltonian? (I ask this because you say "the tensor network architecture" but in a DMRG calculation there is both an MPO tensor network and an MPS tensor network.)

commented by (1.1k points)
Hi Miles, sorry for the late reply. I'm asking about the MPO made by the AutoMPO system in ITensor. In particular I'm asking about the Julia code, although I'm assuming the answer would be the same regardless of Julia/C++.

1 Answer

0 votes
answered by (70.1k points)

Hi Sujay,
The short version of the answer is that adding individual Hamiltonian terms in an MPO only require the bond dimension of the MPO to be increased by 1. Here by a "term" what is meant is a product of two local operators, such as Sz_1 Sz_7. The operator S+_1 S-_7 would be a different term.

On the other hand, translation-invariant terms such as \sum_j Sz_j Sz_j+1 also only require the MPO bond dimension to increase by 1, not by N-1 even though this sum contains N-1 terms for a length N system.

So if one starts out with an MPO encoding a sum of local terms, then wants to add the term Sz_1 Sz_N to it, the MPO dimension only has to increase by 1.

All of these comments above are referring to an MPO for an open-boundary, finite system.

Though one can in principle construct and talk about periodic MPOs, the ITensor AutoMPO system does not support making them and the ITensor DMRG code does not accept them as input. This is mostly because periodic MPS have a number of unsolved technical issues that makes them much less useful than either finite or infinite MPS.

For more reading about construction of Hamiltonian MPOs you can see the following papers:


commented by (1.1k points)
Sorry for the late reply. Thank you so much! This really clears up some of my prior confusion.
Welcome to ITensor Support Q&A, where you can ask questions and receive answers from other members of the community.

Formatting Tips:
  • To format code, indent by four spaces
  • To format inline LaTeX, surround it by @@ on both sides
  • To format LaTeX on its own line, surround it by $$ above and below
  • For LaTeX, it may be necessary to backslash-escape underscore characters to obtain proper formatting. So for example writing \sum\_i to represent a sum over i.
If you cannot register due to firewall issues (e.g. you cannot see the capcha box) please email Miles Stoudenmire to ask for an account.

To report ITensor bugs, please use the issue tracker.