Conversion of AutoMPO->IQMPO for PBC

+1 vote
asked Apr 13 by samuel (230 points)

Hello Miles,

I've encountered a strange convergence issue with DMRG using periodic boundary conditions, and conservation of total Sz (iqdmrg). The system is the simple spin-1 AKLT model (I know, we wouldn't need to run GS DMRG on it ... !). Anyway, it appears that the following commands

Args argsH = Args("Exact=",true);
IQMPO H = toMPO<IQTensor>(ampo,argsH);

lead to:
1) incorrect evaluation of the energy of the initial state,
2) no convergence of DMRG to the ground state.

I was using the two lines of code above instead of the simple

IQMPO H = toMPO<IQTensor>(ampo);

because the latter displays "Using approx/svd conversion of AutoMPO->IQMPO".

My questions are the following:
1) What is happening in the "exact" case ? How does toMPO<IQTensor> work in that case ?
2) In the "approx/svd conversion" case, is there a way to know how accurate is the compression of the Hamiltonian ? (in terms of singular values/truncation, for example)
3) Is there a way to set a precision to this compression ?
4) Why is the "exact" case not working on the AKLT Hamiltonian, but works fine for the Haldane chain ? Is it due to the additional biquadratic terms which make it hard to have an exact representation ? (the W-operator valued matrix (Schollwöck's notation) grows fast in this case, is that the reason ?)
5) Finally, why does this behavior occur only when using the QN-conserving code ? (running DMRG without symmetry works fine with the "exact" conversion to MPO, using MPO H = toMPO<ITensor>(ampo,argsH)).

Thanks a lot, and have a nice Easter holiday !


1 Answer

+1 vote
answered Apr 18 by miles (12,650 points)

Hi Samuel,
Thanks for the questions. Let me go through them here:

(1) By the "exact" conversion, what is meant is that every term you put into AutoMPO is translated into the MPO that is returned without any approximation (other than the floating point representation of numbers if you're being picky). The approx/svd case has the advantage that it can handle terms with operators on more than two sites, and it can find a smaller MPO dimension for certain complicated Hamiltonians. But for simple Hamiltonians with couplings of a significant size, both algorithms should give the same results basically. Internally they are very different engines for generating MPOs from AutoMPO data. If you're concerned about one or the other, and both apply to your case I'd recommend testing both on small systems to check. Please let me know any time you think you've found a bug.

(2-3) Right now there's not a way to get a report of the compression in the approx/svd case, but you can control the maximum truncation error by providing a "Cutoff" named arg like this:
auto H = toMPO(ampo,{"Cutoff=",1E-12});
Here I've assumed you want an IQMPO so I made the tensor type IQTensor, but you can make it ITensor too to get an MPO. Above you could experiment with different cutoff values to see how or if it affects your results. It should only matter if some of your Hamiltonian terms have very small coefficients or if you are wanting extremely high-accuracy results.

(4) I can't say why you aren't getting the results you expect for the AKLT Hamiltonian. But if the initial energy is wrong then perhaps the MPO returned from the toMPO function is being constructed incorrectly? Here it would help to have some sample code from you so I could test it. But also you can test the returned MPO yourself by using the "InitState" feature to create various product states and computing overlaps of these with the MPO (using the overlap(psi,H,psi) function to get matrix elements). That's the method I often use to double check the construction of MPOs.

(5) Not sure why the non-symmetric version works but not the symmetric version. My best guess is that either there is a convergence issue with the combination of QN conservation (which can cause DMRG to get stuck more easily) and periodic BC's (which can also cause DMRG to have worse convergence). Or perhaps there is a bug with AutoMPO. We don't use periodic boundary conditions much so it's conceivable.


commented 5 days ago by samuel (230 points)
Hello Miles,

Thanks a lot for your answers. I guess there is a bug in the conversion AutoMPO->IQMPO using Periodic Boundary Conditions. However this possible bug is "model dependent", which is even more bizarre ...
Here is a link to two files which exhibit the strange behavior of the conversion


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
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.