# DMRG doesn't work with certain initial conditions in fermionic systems

Hello,

I am running some calculations on a 4-site square chain with a tight-binding Hamiltonian, and have found an issue when applying the DMRG function to my system. Depending on the state I initialize the system, the DMRG can either run normally and return the expected value for the energy, or almost instantly return a (wrong) value of 0 for the ground state energy. Here is a sample code to demonstrate the problem:

#include "itensor/all.h"

using namespace itensor;

int main()
{

int N = 4;
double t = 1.0;
int nsweeps = 5;
int maxm = 200;
double cutoff = 1E-15;
int niter = 2;
double noise = 0;

auto sites = Hubbard(N);

auto ampo = AutoMPO(sites);

ampo += -t,"Cdagup",1,"Cup",2;
ampo += -t,"Cdagup",2,"Cup",1;
ampo += -t,"Cdagdn",1,"Cdn",2;
ampo += -t,"Cdagdn",2,"Cdn",1;

ampo += -t,"Cdagup",1,"Cup",3;
ampo += -t,"Cdagup",3,"Cup",1;
ampo += -t,"Cdagdn",1,"Cdn",3;
ampo += -t,"Cdagdn",3,"Cdn",1;

ampo += -t,"Cdagup",2,"Cup",4;
ampo += -t,"Cdagup",4,"Cup",2;
ampo += -t,"Cdagdn",2,"Cdn",4;
ampo += -t,"Cdagdn",4,"Cdn",2;

ampo += -t,"Cdagup",3,"Cup",4;
ampo += -t,"Cdagup",4,"Cup",3;
ampo += -t,"Cdagdn",3,"Cdn",4;
ampo += -t,"Cdagdn",4,"Cdn",3;

//Use IQMPO or MPO to generate the hamiltonian
auto H = IQMPO(ampo);
Print(ampo);

//Define initial wavefunction MPS for IQMPS
auto state1 = InitState(sites);

state1.set(1,"Up");
state1.set(2,"Up");
state1.set(3,"0");
state1.set(4,"0");

//Create IQMPS
auto psi = IQMPS(state1);

//Overlap test
auto state2 = InitState(sites);
state2.set(1,"0");
state2.set(2,"Up");
state2.set(3,"Up");
state2.set(4,"0");
auto psi2 = IQMPS(state2);

println(overlap(psi2,H,psi));

//Define DMRG sweeps
auto sweeps = Sweeps(nsweeps);
sweeps.maxm() = maxm/20,maxm/10,maxm/2,maxm/2,maxm;
sweeps.cutoff() = cutoff;
sweeps.niter() = niter;
sweeps.noise() = noise;

auto energy = dmrg(psi,H,sweeps,{"Quiet",true});

return 0;
} //End of main


When I run this code exactly as it is, the DMRG returns a value of 0 for the ground state energy. The same happens if the two electrons are initialized in sites 3 and 4. However, if I change the initial conditions to initialize the electrons on other combinations of sites (for instance sites 1 and 3), I get the correct value for the energy (-2).

I've made some tests and found out this problem does not happen if I change the ordering of the sites to a cyclic chain, that is, with interactions 1-2, 2-3, 3-4, 4-1. However, since my goal is to work with larger chains, I figured I should number the sites the way I am doing in the sample code, as to avoid creating super-long-range interactions when working with more sites. Therefore, I think having a fix for this problem while still using my ordering would be ideal.

I believe the cause of this issue is the way the ITensor library handles the fermionic operators "Cdagup" and "Cup". Depending on the order they are applied when initializing the system and how many anticommutations are made when the Hamiltonian is applied, the final sign of the tight-binding interaction might become positive when it should be negative, thus "fooling" the DMRG algorithm into believing the system is already at the lowest energy level. To exemplify, if one calculates the overlap <0 Up Up 0| H |Up Up 0 0> in the sample code, instead of the expected result of -1 (given the sign of the hopping term), the code returns +1.

This overlap test made me think a simple change of signs on the Hamiltonian could solve everything. However, I discovered that changing the sign of the hopping term on the specific part of the Hamiltonian that annihilates one electron on the first site and creates it on the third site doesn't seem to completely fix the problem; although the overlap described above now returns a value of -1, the DMRG surprisingly still returns a value of 0 for the energy.

So, I wanted to ask if there is anyway I can have consistent (a.k.a. not dependent on the initial conditions) DMRG results for my system while keeping the ordering of the sites intact. I would appreciate any input into this. Thanks!

commented by (33.5k points)
Hi, so I'm not totally sure what the issue is fundamentally, whether just to do with a lack of convergence of DMRG (which can very much depend on initial conditions) or rather with a bug in ITensor having to do with fermion operator ordering.

My belief is that there is no bug in AutoMPO, and that it does make fermionic Hamiltonians correctly. Though it would be good to know if you are saying you have found a case where there is a bug? If that's what you are finding please follow up with a way to reproduce and I will fix the bug - thanks.

On the other hand, it sounds like the different outputs you are observing are most likely due to the general fact that the DMRG algorithm does not always converge to the global minimum, but can get "stuck" in local minima due to difficult Hamiltonians and various initial conditions which are too different from the ground state. This is a general issue with DMRG as an algorithm and not something we are able to completely fix in ITensor (nor in any code offering a DMRG algorithm, generally speaking). The main solution to this problem is to find a way to prepare a better initial state. Here are some possible strategies that could work for you:

1. use the fact that DMRG is working with a different path ordering to obtain an initial state at a modestly low bond dimension with that path, then use a sequence of local, fermionic swap gates to change the ordering of the sites of that MPS to match the ordering you want, then use this state as input to a second DMRG calculation with the ordering of the sites you want

2. use time evolution methods (such as Trotter gates) within the site ordering you want to use to very carefully evolve an initial state in imaginary time to make it more "typical" in its properties (i.e. non-zero particle density on every site) then use this as input for DMRG

I hope one of those methods works for you. Or if you do still suspect there is a bug in ITensor's AutoMPO feature then please suggest how I can reproduce this bug so I can take steps to fix - that would be most appreciated!

Best regards,
Miles