+1 vote
asked by (170 points)
retagged by

Hi Miles,

I have got some problem with the convergence recently. I was doing Iqdmrg calculations with Kondo model. My ground state energy kept decreasing linearly (-0.03) after 8 sweeps to 30 and more, and the observables calculated were not as I expected . I believed there were two reasons. Maybe my initial state was not mixed (good?) enough for it to keep from stucking at the "local minimum" excited state, or it was not converged yet. I have tried using different initial states and putting a noise term, it did improve a little bit, so my question was,

How do I determine if it is converged? Besides the energy, I think it would be helpful if I could calculate correlation function or electron density at every step to see if those quantities are converged. I know how to calculate them with a given psi, but how do I calculate them at every step? I found a argument called "Debuglevel" and "Quiet = false" for information between sweeps, will that be useful for determining the convergence?

Also, In traditional DMRG algorithm there is a truncation error determined by the sum of the abandoned eigenvalues of the density matrix at each step, and that is what we use to determine the convergence. Is there a similar quantity in Itensor to do the same job?

There is another small question about creating the sweeping table. If I wanted 70 sweeps with Maxm=100, and then 10 sweeps with Maxm=500, is there any way simpler other than copying Maxm=100 seventy times? I know if I wanted the remaining sweeps parameter to be the same I would just leave it unfilled.

Thank you very much.


2 Answers

+2 votes
answered by (20.8k points)

Hi Yixuan,
Yes these are some important issues to think about and some good questions to ask.

First of all, you should take a look at this tutorial about choosing DMRG parameters if you haven't: http://itensor.org/docs.cgi?page=tutorials/dmrg_params
It doesn't answer most of your questions but could provide some helpful background information.

To answer your questions:

  1. carefully make sure that your Hamiltonian is Hermitian. Sometimes odd silent bugs can occur due to an error in defining a Hamiltonian improperly such that it fails to be Hermitian.

  2. yes a slow decrease in energy may be due to a poor initial state. It can also be a fundamental aspect of the particular Hamiltonian you are studying, such as if there are two or more widely separated energy scales in the problem, or if there is disorder or small gaps to excitations. Finally the slow convergence could be due to the sweeping/DMRG accuracy parameters you chose. For example if you raise maxm too quickly it can actually allow DMRG to keep a lot of states (Schmidt states) which poorly represent the ground state and can consume a lot of time without leading to better convergence.

  3. setting the "Quiet" parameter to false leads to seeing helpful information at each bond of the MPS during sweeping, not just once per sweep. So setting "Quiet=",false can be extremely helpful for understanding what's going on. Setting DebugLevel to a higher integer value also prints out more information from the Davidson algorithm but may only be helpful in more technical situations.

  4. there are multiple ways of increasing sophistication to check convergence. Here are some in increasing order of complexity and sophistication:
    3a. make sure the energy does not change by very much anymore after multiple sweeps with increasing maxm and decreasing cutoff
    3b. look at the truncation error printed after each step (with Quiet = false) or after each sweep (with Quiet = true) and make sure that it is both (a) small (<1E-5 is good, < 1E-8 is great) and (b) not changing by very much after more than one sweep with similar maxm and cutoff
    3c. observe properties such as local operators or correlation functions after each sweep (for how to do this see answer 4a and 4b below)
    3d. measure the energy variance after each sweep or after all the sweeps. For more information about a newer and cheaper related approach see this new paper by Hubig: https://arxiv.org/abs/1711.01104

  5. The "poor man's" way to measure properties after a certain number of sweeps is just to do fewer sweeps than you ultimately plan to do and measure the properties after DMRG finishes. You can always save the wavefunction either in your program or by writing/reading to/from the hard drive and use it to continue doing more sweeps.
    The fancier way to do measurements within DMRG is to use an "Observer" object. The way to do this is to copy the code in the file itensor/mps/DMRGObserver.h and make a similar object which inherits from DMRGObserver (Tensor=ITensor or IQTensor) and has a different name and implements the ::measure(Args) function. If you then do the following:
    auto obs = MyObserverClass(psi);
    then the dmrg function will call the .measure(args) method of your observer instead of the standard one. You can put any code you want into your observer's measure function such as code that measure correlation functions or local operators. Keep in mind that when .measure gets called, the MPS orthogonality center is on a particular site which you can determine by getting the "AtBond" and "HalfSweep" named parameters (see DMRGObserver::measure for how this works). I need to write some documentation on observers!

  6. Yes there is definitely a trunction error available in ITensor. It's defined in the way explained at the bottom of this page: http://itensor.org/docs.cgi?page=book/itensor_factorizing The truncation error at the center of the MPS gets reported by default by ITensor DMRG. If you set Quiet=false then the trunc err gets reported at each step. Also inside the observer you can get the truncation error. Finally, look at the documentation for the svd and diagHermitian functions to see how to get a "Spectrum" object returned from them and get the truncation error if you are doing your own SVD's.

  7. Finally, if you put fewer than "nsweep" lines in your sweeping table, the Sweeps object will still do nsweep sweeps, just repeating the parameters from the last sweep over and over until all of the sweeps are done. Do Print(sweeps); in your code to see ahead of time all of the sweeps that will be done.

Best regards,

commented by (170 points)
Hi Miles,
Thank you so much for your help. I really appreciate it. I think maybe I should add a tag of "Observer" to this question.

Best reagrds,
0 votes
answered by (610 points)

When I reached this point in my current research problem, I asked Miles the same thing but in an email, so I am glad it is now in a thread here for review.

My solution has three parts:

  1. Setup an observer object (as Miles suggests) that outputs relevant information after each sweep. Also, within your ITensor program, have it output the final wavefunction and siteset files and save them i.e. as psi1, siteset1.

  2. Create a set of input parameter files with a numeric ordering, i.e.
    so that each inputfile is used to produce each wavefunction i.e. psi1, psi2 etc.

  3. Create a shell script that calls your main ITensor program and tells it to input the appropriate inputfiles in order and to start with the wavefunction you tell it to -- start out with an appropriate initial MPS for the first set of sweeps, then use the result of this first sweep as the input wavefunction for the next set, and so on.

I found that by having this kind of a "stepping up" cycle I could more easily track convergence and at the same time store wavefunctions along the way in case there is an error during one of the steps. At each sweep, I output all of the convergence information (Energy, M, truncation error, and observables of interest to my research) and at each step up in the inputfiles (step up in M, step down in noise, step down in delta E) I'd output the wavefunction. Partly, I output the wavefunction only after each inputfile because it was easy to do so from within main{} using Miles' instructions on input/output of wavefunctions.

Good luck!

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.