# Conversion of AutoMPO->IQMPO for PBC

+1 vote

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);


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 !

Samuel

+1 vote
answered Apr 18, 2017 by (19,870 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.

Miles

commented Apr 25, 2017 by (240 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

https://www.dropbox.com/sh/xulabc7qvmif3a7/AACO8BBCl99a1b8h5K-470_7a?dl=0

Best,

Samuel
commented May 17, 2017 by (19,870 points)
Hi Samuel, sorry for the slow reply. In the future if you have an urgent need for a response feel free to email me to remind me to get to your issue (I try to prioritize issues that are blocking people from completing their work).

Thanks for the very clear sample code. I just ran it, however, and got the same energy (of zero) for all of the cases enumerated by the code. Are you still getting different energies for one of the models?

Miles
commented May 19, 2017 by (240 points)
Hello Miles,
That's extremely strange ! I still obtain inconsistent results when I use an exact conversion from AutoMPO->IQMPO with periodic boundary conditions.
More precisely, I obtain a ground state energy=1.000... instead of 0 with the code given in the dropbox (link above still valid).

Samuel
commented May 19, 2017 by (19,870 points)
Hi Samuel,
I just ran it again and got energies equal to zero for every case. Are you using the very latest version of ITensor on the master branch? Also if it's relevant I am using Intel MKL for my BLAS/LAPACK distribution.

Miles
commented May 19, 2017 by (240 points)
Hello Miles,
Thanks for the details. I'm using the latest version of ITensor on the master branch. However, I'm using lapack (PLATFORM=lapack) with g++ 4.8.5 or 4.9.3.
Since it's the only difference, then this might be the issue. I'll try to change my distribution and come back to you for feedback.

Samuel
commented May 20, 2017 by (19,870 points)
Thanks, Samuel. It may not be the LAPACK but I have had occasional bugs come from there. Another check we could try would be to compute matrix elements of the Hamiltonian created by the AutoMPO system by taking overlaps of it between various product state MPS (created using the InitState feature). That would be a pretty definitive check of whether the Hamiltonian is ok or not. Then if it's ok, the bad energy would be most likely coming from a lack of convergence of DMRG.