• View
• Edit
• Rename
• History
• Print
• Backlinks

Troubleshooting

Program crashes

• If you see an error "Deallocation munmap failed!: Cannot allocate memory", or "CHECK in file ../mptoolkit/pheap/bufferalloc.cpp at line 82 in function void BufferAllocator::deallocate(const unsigned char*): Ret == 0 is false" then the program has run out of virtual memory mappings. This only happens on big calculations that use a lot of memory. This is ultimately a weakness in the memory management that should be fixed, but meanwhile you can work around this by increasing vm.max_map_count. Eg, from a shell, type
  vm.max_map_count = 100000
  You probably need to be root to do this. (This is probably fixed now)
• If you see segfaults in specific programs (for example, the orthogalization at the end of an iDMRG run), then this might be caused by a library incompatibility. The toolkit uses the ARPACK library to find eigenvalues of sparse matrices in some specific parts of the code, and the ARPACK library in turn uses the low-level BLAS library for linear algebra subroutines. Unfortunately on x86 linux hardware the Fortran and C languages have different ways of handling complex numbers that are incompatible with each other. The toolkit can detect this and can manage with any kind of BLAS library, but ARPACK is usually compiled with the original Fortran convention, which then requires that the BLAS library also uses the Fortran (not C) convention. If you see persistent, reproducible Segmentation Fault errors running the iDMRG code, this is the most likely problem. See the Optimized BLAS libaries section at Installing.ConfigureCustomization for more information, and how to fix this.

Program locks up/errors in BLAS routines

• Versions of MKL prior to 2019.05 have bugs in the complex eigensolvers and SVD that can trigger problems in the toolkit. This is most noticable with TEBD, but it can also cause the program to freeze (infinite loop) in iDMRG, typically in between finding the 'left energy' and the 'right energy' at the start, or when orthogonalizing the wavefunction at the end. Don't use MKL versions prior to 2019.5. There is a related bug report here: https://software.intel.com/en-us/forums/intel-math-kernel-library/topic/831464 (this link is dead as of 2023)

Convergence problems

• There are lots of potential causes for convergence problems. It might be that you simply need to increase the number of states, but that should be the last resort; it is much better to to try less computationally intensive techniques first.
• Try to get a better initial state. If you know what phase the desired state is in (or have a small number of possible candidates), then try to get a starting state that is representative of the same phase, but using a Hamiltonian that is easier to converge. For example, if the groundstate has some translation symmetry breaking, eg dimerization, then you could start with an initial state that is a perfect dimer configuration by using a dimer pattern Hamiltonian. Once you have this as an initial state, then switch to the real Hamiltonian. You might need to do this in stages, eg as (1-alpha) * H_dimer + alpha * H_real, and slowly ramp alpha from 0 to 1.
• In some cases where there is more than one quantum number (eg {$U(1)\times U(1)$}), for some special choices of quantum numbers, constructing an initial random wavefunction can be very slow. You might have success with the --beta parameter using mp-random, which controls the effective temperature governing the simulated annealing procedure that is used to construct the random state. Or construct a state with different quantum numbers that is easier to obtain, and manipulate it with mp-apply (eg adding particles to a vacuum state). If the random state takes a long time to construct, verify that the quantum number sector you have chosen is actually possible. If you specify an impossible combination (eg, a half-odd integer spin state with an even number of spin-half particles) then the random state will never converge.