+1 vote
asked by (130 points)

I observe similar increases in energy as those seen here (http://itensor.org/support/576/ground-state-energy-increase-after-10th-sweep). The increases in energy I see also begin at order 10^(-10) even though my truncation cutoff is set to 10^(-12). I'm able to reproduce energies up to the order of 10^(-10) using ED so I'm confident that my Hamiltonian is set up correctly and suspect that there is some issue with the Davidson convergence/precision. Is there a default cutoff of 10^(-10) that I'm missing somewhere or should the supplied DMRG algorithm be capable of seeing energy convergence on the order of 10^(-12) and potentially lower for more stringent cutoffs (it looks like there might be a hard-coded cutoff of 10^(-12) in the Davidson algorithm)?

The answer to the referenced question suggests increasing the number of iterations, but I'm not sure if this addresses the root of the problem or not. Should I increase "niter" (the max number of Davidson iterations) to something like 6 so that the algorithm will exit automatically if convergence is reached and I just hope this is sufficient or should I play with "Errgoal" in the args for the algorithm? It looks like the default value for "Errgoal" is quite small at 10^(-4) so I'm not sure if this is the right approach and if I'm reading the code properly. I'm interested in calculating non-local observables whose errors should scale as the square root of the errors in energy so I'd like to have as high of precision as possible.

As a quick aside, I know that the error in energy should scale proportional to the truncation error, but in practice I find it is several orders of magnitude larger. What is the reason for this?


1 Answer

0 votes
answered by (70.1k points)

Hi Jordan,
The short answer to your question is "I don't know". I have not encountered many situations where I needed an accuracy this small so this could be a bug related to a hard-coded number somewhere as you suggest. Thanks for linking to the previous question also; that is helpful.

I have two thoughts about what could be going on:

  1. The particular number 1E-12 occurs because in practice that is often the most precision that can be reasonably expected when using double-precision floating point numbers. So at some point here you are really fighting against the floating point number system itself rather than the ITensor DMRG code.

If roundoff error might be the main culprit here then there isn't much that can be done within ITensor other that recompiling the library to use a higher precision floating point type than double, or doing a very detailed analysis of each step of the code and putting in possibly very specialized algorithms throughout.

  1. Your suggestion of just increasing niter in your DMRG sweeping parameters is definitely the first thing you should try.

But yes I am also suspicious of the ErrGoal parameter defined inside the Davidson algorithm on line 68 of itensor/eigensolver.h. You should be able to set this value like so:
to set it to a lower value. Indeed the Davidson algorithm could be exiting earlier than it should in your case.

So raising niter and lowering ErrGoal should cause the Davidson to do more iterations and possibly give you better results (i.e. hopefully prevent the energy rising issue you see).

Please give the suggestions in point #2 above a try and let me know if you see some improved behavior. Note that you can save your partially optimized wavefunction to disk and read it back in to keep from having to do all of your initial sweeps over again every time to test. Here is a little "code formula" page showing how to do that: http://itensor.org/docs.cgi?page=formulas/readwrite_mps . There is a function called fileExists("filename") you can also use to see if the file "psi" exists and if so read it in, otherwise making a new psi.


commented by (240 points)
Hi Miles,

Does "ErrGoal" control the accuracy of the eigenvalue? say that the exact eigenvalue lambda is: lambda_numerical-ErrGoal<=exact lama<=lambda_numerical. If that's the case, by setting ErrGoal to 10^(-4) for all davidson diagonalization will affect the eigenvalue to order 10^(-4) and then its' meaningless to keep 10-12 decimal places for the eigenvalue.
I understand that we don't need the davidson algorithm to converge to very high accuracy in the first several sweeps because the unconverted environment. But in the last several sweeps I'd like to set ErrGoal low and MaxIter high. How can I create a table (just like sweep table) to specify ErrGoal and MaxIter used in the Davidson algorithm in each sweep?
commented by (70.1k points)
Hi, sorry for the really slow reply. So from some tests I just did I think ErrGoal may indeed be the culprit. It hasn't caused many problems for me personally because I haven't been doing too many super high accuracy DMRG runs for my own projects. But using the test code in the other question from a while back that you linked to, changing the default ErrGoal in the davidson function seemed to fix the energy rise that other user reported.

I should say I still see a tiny rise in the energy on some of the later sweeps, but they are more like small fluctuations rather than a steady rise. I think they could be just as much due to floating point roundoff and truncation details just as much as the davidson.

So I'll push a new version of ITensor right now with the default ErrGoal set much lower. Please pull this new version and recompile ITensor as well as your code. Then please let me know if the issue persists for you - thanks.

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.