Question: MPO bond dimensions in the tri-block joint basis

Previously, we have tested the bi-block joint basis extensively, either (real + k) or (k + real). And now we extend to the tri-block case (real + k + real), but what we observe here is that the bond dimensions in the k-space block are larger than the real-space blocks. This behaviour didn't appear in the bi-block case.

Example

Consider the tight-binding model in the tri-block joint basis again, and the contacts are at bonds ( $\mu$ , $\mu + 1$ ) and ( $\nu - 1$ , $\nu$ ),

$$ W[i] = \begin{pmatrix} I_i & -t \cdot a_i^\dagger & -t \cdot a_i & -\mu \cdot n_i \ 0 & 0 & 0 & a_i \ 0 & 0 & 0 & a_i^\dagger \ 0 & 0 & 0 & I_i \ \end{pmatrix} , \text{for } i \leq \mu $$

$$ W[i = \mu + 1] = \begin{pmatrix} Ii & 0 & -t \cdot U{i\nu} \cdot ai^\dagger & 0 & -t \cdot U{i\nu} \cdot a_i & e(i) \cdot n_i \ 0 & Fi & 0 & 0 & 0 & U{i\mu} \cdot a_i \ 0 & 0 & 0 & Fi & 0 & U{i\mu} \cdot a_i^\dagger \ 0 & 0 & 0 & 0& 0& Ii \ \end{pmatrix}{4 \times 6} $$

$$ W[i] = \begin{pmatrix} Ii & -t \cdot U{i\nu} \cdot ai^\dagger & 0 & -t \cdot U{i\nu} \cdot a_i & 0 & e(i) \cdot n_i \ 0 & 0 & Fi & 0 & 0 & U{i\mu} \cdot a_i \ 0 & F_i & 0 & 0 & 0 & 0 \ 0 & 0 & 0 & 0 & Fi & U{i\mu} \cdot a_i^\dagger \ 0 & 0 & 0 & F_i & 0 & 0 \ 0 & 0 & 0 & 0 & 0 & Ii \ \end{pmatrix}{6 \times 6} , \text{for } \mu + 1 < i < \nu - 1 $$

$$ W[i = \nu - 1] = \begin{pmatrix} Ii & -t \cdot U{i\nu} \cdot ai^\dagger & -t \cdot U{i\nu} \cdot a_i & e(i) \cdot n_i \ 0 & Fi & 0 & 0 \ 0 & 0 & 0 & U{i\mu} \cdot a_i \ 0 & 0 & Fi & 0 \ 0 & 0 & 0 & U{i\mu} \cdot a_i^\dagger \ 0 & 0 & 0 & Ii \ \end{pmatrix}{6 \times 4} $$

$$ W[i = \nu] = \begin{pmatrix} I_i & -t \cdot a_i^\dagger & -t \cdot a_i & -\mu \cdot n_i \ 0 & 0 & 0 & \textcolor{red}{-} a_i \ 0 & 0 & 0 & a_i^\dagger \ 0 & 0 & 0 & I_i \ \end{pmatrix} $$

$$ W[i] = \begin{pmatrix} I_i & -t \cdot a_i^\dagger & -t \cdot a_i & -\mu \cdot n_i \ 0 & 0 & 0 & a_i \ 0 & 0 & 0 & a_i^\dagger \ 0 & 0 & 0 & I_i \ \end{pmatrix} , \text{for } i > \nu $$

Note:

There is an additional minus sign in $W[i = \nu]$, marked as red.
Here we didn't use the argument Exact for toMPO(), so the bond dimensions have already been compressed.
Actually, AutoMPO generates some additional phase factors in front of $F_i$. But as they will cancel out eventually, here we just ignore them (https://github.com/chiamin/HybridLeads/issues/12).
The order of rows and columns generated by AutoMPO is different from the present handwritten one.

Associated issue

DMRG raises an error for this MPO, probably because the bond dimension is not a constant?

root@4582573e116f:/home/tests# ./build/test_mpo_model.exe

dim(inds(phi.front())) = 4
A.size() = 8
From line 137, file /root/itensor/itensor/iterativesolvers.h

davidson: size of initial vector should match linear matrix size

davidson: size of initial vector should match linear matrix size

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test_mpo_model.exe is a Catch2 v3.2.0 host application.
Run with -? for options

-------------------------------------------------------------------------------
Check ground state energies are consistent
-------------------------------------------------------------------------------
/home/tests/hybridbasis/test_mpo_model.cpp:30
...............................................................................

/home/tests/hybridbasis/test_mpo_model.cpp:30: FAILED:
due to a fatal error condition:
  SIGABRT - Abort (abnormal termination) signal

===============================================================================
test cases: 1 | 1 failed
assertions: 1 | 1 failed

Aborted

Turns out the above DMRG issue is not related to the MPO bond dimensions, but rather an incorrect usage of ITensor API.

In short, when constructing InitState(sites), the SiteSet object should be exactly the same one used for AutoMPO construction.

Incorrect workflow (before)

In file: hybridbasis/mpo_model.h

MPO some_func() {
  auto sites = Fermion(N);
  auto ampo = AutoMPO(sites);

  // construct ampo whatever
  // ...

  auto H = toMPO(ampo);
  return H;
}

In file: tests/hybridbasis/test_mpo_model.h

#include "hybridbasis/mpo_model.h"

auto H0 = some_func();  // <------ from the above file

auto sites = Fermion(N);  // <------ Note that we reclaim the fermionic `SiteSet`
auto another_ampo = AutoMPO(sites);

// construct another_ampo whatever
// ...

auto H1 = toMPO(another_ampo);

// Init a random MPS
auto state = InitState(sites);  // <------ And use `sites` to generate the `state`
for (auto i : range1(n_tot)) {
  if (i % 2 == 1)
    state.set(i, "1");
  else
    state.set(i, "0");
}
auto psi0 = randomMPS(state);

// Compare GS energy for 2 MPO
auto sweeps = Sweeps(8);
sweeps.maxdim() = 10, 20, 100, 200, 200;
sweeps.cutoff() = 1E-10;
auto [energy, psi] = dmrg(H0, psi0, sweeps, {"Silent", true});  // <------ This is where the error raises
auto [expected_energy, expected_psi] =
    dmrg(expected_H1, psi0, sweeps, {"Silent", true});
CHECK(energy == Approx(expected_energy).epsilon(1e-8));

Note that H0 and state are generated with different SiteSet instances.

Correct workflow (after)

In file: hybridbasis/mpo_model.h

std::tuple<SiteSet, MPO> some_func() {
  auto sites = Fermion(N);
  auto ampo = AutoMPO(sites);

  // construct ampo whatever
  // ...

  auto H = toMPO(ampo);
  return {sites, H};
}

In file: tests/hybridbasis/test_mpo_model.h

#include "hybridbasis/mpo_model.h"

std::tie(sites, H0) = some_func();  // <------ from the above file

// the rests are the same
// ...

Not sure what happened in the underlying ITensor, but apparently even though it appears like reclaiming auto sites = Fermion(N); should not give any side effects, that's not what happened.

chiamin / HybridLeads