ITensor Support Q&A - Recent questions and answers

Answered: Best way to create equal amplitude states

Tue, 08 Apr 2025 16:45:08 +0000

Hi Vadim,
We can help you with this, but could you please ask your question on our new forum? We only keep this one up for legacy purposes and might close it down soon.

Here is the link to the new forum:
https://itensor.discourse.group

Thanks,
Miles

Exponential of MPO

Fri, 23 Sep 2022 16:22:44 +0000

Hi,

So I've been trying to use this function: expHermitian(ITensor H, Cplx tau = 1)
but the operator that I want to exponentiate is the total Sz. Here is the code that I have so far:

auto ampo2 = AutoMPO(sites); for(auto k : range1(Nspins)) { ampo2 += "Sz",k; } auto proj = toMPO(ampo2); auto exp2H = expHermitian(proj,2);

but I get an error that the function expects an ITensor object as the first argument (as expected). Is it possible to somehow do what I am trying to do?

Thank you.

Answered: Adding a field to Hamiltonian to form gates

Wed, 24 Aug 2022 20:45:23 +0000

Just a reminder this forum is now closed, and we are leaving it here mainly so that people can search it for previous answers.

Thanks for realizing this, clanglett, and posting on the new forum.

You can see my response here:
https://itensor.discourse.group/t/adding-a-field-to-hamiltonian-for-tebd-gates/364/2

Answered: "No space left on device" error when using write_to_disk feature in Itensor Julia

Fri, 29 Jul 2022 00:39:37 +0000

It turns out that the intermediate tensors are by default stored in the "/tmp" directory, which in my case has small disk storage. To resolve the issue, I changed the environment variable TMPDIR to a location with a bigger storage.

about MixedSiteSet for electron and spin

Wed, 27 Jul 2022 23:59:53 +0000

Dear there,
I want to use dmrg to solve a Hamiltonian which has couplied spin 1/2 operator and electron operator on same site.
For example: H= a \sum{n} {Sx(n)C^dagup(n)Cup(n)} + b\sum{n} {Sz(n)}.

After some searching, I found I need use MixedSiteSet. But so far, I only find a previous example for a Holstein-type new site set , which is:
using Holstein = MixedSiteSet(ElectronSite,BosonSite);

And I saw in that answer, it mentions "the odd numbered sites will be electron sites and the even numbered sites will be boson sites". But in my case, I need electron and spin on same site. I'm not sure if this kind of MixedSiteSet already exits in Itensor or how could I construct this?

Thank you so much!!

Answered: Coupling a spin to heat bath

Tue, 24 May 2022 14:12:12 +0000

Hi, thanks for the question but

we have now created a new forum to replace this one (though we are leaving this one so people can search it). Here is the link to the new forum: https://itensor.discourse.group
when you post your question on the new forum, could you please clarify your question? Are you asking how to create a state which represents a kind of heat bath? If so, what mathematical model of this heat bath would you like to use? Or can you please provide a literature reference for what you are trying to do?

Thanks,
Miles

Answered: New Forum Launched!

Thu, 14 Apr 2022 21:49:16 +0000

(Replying just to give this question a blue badge.)

Answered: how to measure correlator of two point with 4 operators in two component bose-hubbard model(c++)

Tue, 12 Apr 2022 16:06:26 +0000

Hi Wang,
Thanks for the question. Yes, this kind of error means there is a mistake in your code, where you are trying to contract two ITensors that have a matching Index, but where the Index has the same arrow direction. As you may know, in order for two indices to contract, they have to have opposite arrows. Usually this kind of error results from not putting a "dag" somewhere in your code where it is needed. So please look for any places that you should need to take the Hermitian conjugate (or "dag") of an ITensor that may be missing.

Also it would be very helpful in this case to either use a debugger or a printing statement to identify which line of your code is causing the error to happen.

If you spend some more time looking for the error and can't find it, or have a question about how to work with dag and Index arrows, please just ask by posting a comment below.

Best regards,
Miles

Answered: [JULIA] Strange Error concerning my external file of S=2 spin system

Tue, 12 Apr 2022 16:02:39 +0000

Hi, thanks for the question and the kind words about ITensor!

Most likely the error you are getting comes from setting your ITensor first with an integer value, then afterward trying to set a floating point value. When you have a line of code like

Op[s'=>2,s=>1] = 2

as the first non-zero element to be set, the storage type inside the ITensor ends up being an array of integers, rather than floating point values. So then when you set the second element to be sqrt(6), it's causing an error.

This is a behavior we might change in the future, making the storage type switch automatically in a case like yours.

But for now, please just change the code to use explicit floating point values like this:

Op[s'=>2,s=>1] = 2.0

or you could put the lines with sqrt(6) as the first lines of code.

Best regards,
Miles

Answered: von Neumann entanglement entropy of 1D hubbard model (Julia)

Tue, 12 Apr 2022 15:48:57 +0000

Hi, so I found the issue and it's due to a bug in the entropy measuring function you were using. The bug is that the for loop should be written like this:

    for n in 1:dim(S, 1)

instead of writing for n in dim(S,1) as in the original code. As I think you can see, in the original buggy version, dim(S,1) is just a number, whereas a for loop should go over a range.

The function in the other question you linked to had that bug plus a second bug, so I went and edited that question reply to fix both bugs. Here is a corrected version of your implementation of it below:

function entropyvonneumann(psi::MPS, N::Int)
  s = siteinds(psi)
  SvN = fill(0.0, N)
  for b in 2:N-1
    orthogonalize!(psi, b)
    _,S = svd(psi[b], (linkind(psi, b-1), s[b]))
    for n in 1:dim(S, 1)
      p = S[n,n]^2
      SvN[b] -= p * log(p)
    end
    println("$(SvN[b])")
  end
  return SvN
end

Julia related error in purification.jl code

Tue, 12 Apr 2022 06:56:14 +0000

Hello,
I am getting the following error while running purification.jl, strangely, it is working in REPL "https://replit.com/@scin/EnragedJadedNasm#main.jl". Could you please help me out in this ?

β = 0.00 energy = 0.00000000
 ************
 ERROR:
 LoadError: MethodError: no method matching /(::MPO, ::Float64)
 Closest candidates are:
/(::StridedArray{P, N} where N, ::Real) where P<:Dates.Period at /buildworker    
/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/Dates  
/src/deprecated.jl:44
/(::Union{SparseArrays.SparseVector{Tv, Ti}, SubArray{Tv, 1, var"#s814",    
Tuple{Base.Slice{Base.OneTo{Int64}}, Int64}, false} where var"#s814"   
<:SparseArrays.AbstractSparseMatrixCSC{Tv, Ti}, SubArray{Tv, 1, var"#s814",    
Tuple{Base.Slice{Base.OneTo{Int64}}}, false} where var"#s814" 
<:SparseArrays.AbstractSparseVector{Tv, Ti}} where {Tv, Ti}, ::Number) at   
/buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.6/SparseArrays  
/src/sparsevector.jl:1450
/(::Complex, ::Real) at complex.jl:333
...
Stacktrace:
[ 1] main(; N::Int64, cutoff::Float64, δτ::Float64, beta_max::Float64)
 @ Main /media/test.jl:26
[2] main()
 @ Main /media/test.jl:11
 [3] top-level scope
 @ /media/test.jl:30
 in expression starting at /media/test.jl:30

Answered: Finite Temperature Properties of the Spin Systems

Wed, 06 Apr 2022 14:13:26 +0000

So as you likely know, the reason inner(psi,Mz,psi) gives the zero-temperature result is because psi is the ground state. In order to compute finite-temperature properties, you must compute the finite temperature state, either as a mixed state or as an average over a collection of pure states. There is an algorithm called the "ancilla algorithm" or "purification algorithm" for doing the first thing (mixed state), or an algorithm called minimally entangled typical thermal states (METTS) for the second thing (average over pure states).

Fortunately, I just added sample codes of how to do each to our examples folder! Here is the link:
https://github.com/ITensor/ITensors.jl/tree/main/examples/finite_temperature

Here are references for these two algorithms below also:

Purification or ancilla algorithm:
https://journals.aps.org/prb/abstract/10.1103/PhysRevB.72.220401

METTS algorithm:
https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.102.190601
https://iopscience.iop.org/article/10.1088/1367-2630/12/5/055026/meta

Answered: fail to reproduce results of 1D Bose-Hubbard model

Mon, 04 Apr 2022 20:17:49 +0000

Hi FJ,
Thanks for providing a short sample code to show what you were doing. I ran your code today to see what results I got, using t = 0.1, U=0.1, and mu=0.2 as you mentioned in your comments.

What I found was that I could get the density to be 0.99999 to many digits on L=24,48,64 if I just ran the DMRG calculation for long enough. I did 60 sweeps instead of the 40 that you reported doing, and I also made sure to ramp up the bond dimension very gradually, like this

auto sweeps = Sweeps(60);
sweeps.maxdim() = 10,10,10,10,20,20,20,20,40,40,40,40,100,100,200;

Slowly increasing the bond dimension can be a good technique for dealing with difficult systems, because you can do many sweeps without the initial sweeps taking a long time. Also I've found that increasing the bond dimension too soon can lead to DMRG getting "stuck" and having trouble finding the best basis to use for the ground state.

Best regards,
Miles

Unsuccesful TEBD for Time Independent Fermi-Hubbard Model

Tue, 29 Mar 2022 23:17:57 +0000

I have been trying to recreate the dynamics of a driven Fermi-Hubbard Hamiltonian in Julia:

$$
\hat{H}=-t_0 \sum_{j,\sigma}\left( e^{-i\Phi(t)}\hat{c}^{\dag}_{j,\sigma}\hat{c}{j+1,\sigma} + h.c. \right)+\sum_{j} \hat{n}_{j,\uparrow}\hat{n}{j,\downarrow}
$$
(don't know why this isn't formatting this is the Hamiltonian given by equation 12 in https://journals.aps.org/pra/abstract/10.1103/PhysRevA.101.053408 )

where @@ \sigma @@ is spin, but my first step is attempting this with @@\Phi(t)@@ set to 0, which results in an undriven, time independent model. I have successfully performed DMRG to obtain the ground state (which I know because I have compared energies to exact calculations in the QuSpin package), but I have been unsuccessful in using TEBD (and RK2 and RK4) to evolve the ground state using the time independent Hamiltonian. I know applying the time evolution operator as an exponential of the TI Hamiltonian to the ground state should preserve the ground state, but instead the energy of the state resulting from the application of the time evolution operator increases throughout the evolution. Though I have not tested dependence rigorously, the energy increase seems to be mostly independent of the time step even though it should be @@\mathcal{O}(\delta t)@@ according to https://www.sciencedirect.com/science/article/pii/S0003491619302532. I have implemented a dynamic time step as well, and tested a couple different maximum bond dimensions in DMRG, as well as decreasing the cutoff for both DMRG and the apply function. Any help is greatly appreciated, thanks in advance! My code is below:

"""
Use second order TEBD to evolve psi(t) to psi (t + dt)
"""
function TEBD(psi, dt, time, params, independent, cutoff)

    phi = phi_tl(time + dt / 2, params, independent)

    # odd gates (1,2),(3,4),(5,6),...
    ogates = ITensor[]
    # even gates (2,3),(4,5),(6,7),...
    egates = ITensor[]
    for j=1:params.nsites
        s1 = params.space[j]
        #periodic BC
        if j == params.nsites
            s2 = params.space[1]
        else
            s2 = params.space[j+1]
        end
        # we have to define the two site operator so contributions
        # of each site will be counted twice
        ul = ur = params.U / 2
        # exp(i phi(t)) and exp(-i phi(t))
        eiphi = exp(1.0im * phi)
        eiphiconj = conj(eiphi)
        # create operator (only scaled parameters are passed in so t is always 1)
        hj = -eiphiconj * op("Cdagup",s1) * op("Cup",s2) +
             -eiphiconj * op("Cdagdn",s1) * op("Cdn",s2) +
             -eiphi * op("Cdagup",s2) * op("Cup",s1) +
             -eiphi * op("Cdagdn",s2) * op("Cdn",s1) +
             ul * op("Nupdn", s1) * op("Id",s2) +
             ur * op("Id",s1) * op("Nupdn", s2)
        # odd gate
        if j % 2 == 1
            Gj = exp(-1.0im * dt * hj)
            push!(ogates, Gj)
        # even gate
        else
            Gj = exp(-1.0im * dt / 2 * hj)
            push!(egates, Gj)
        end
    end

    gates = ITensor[]
    append!(gates, egates)
    append!(gates, ogates)
    append!(gates, egates)

    return apply(gates, psi; cutoff=cutoff)

end

"""
Propogates ground from 0 to tf using method to propogate by an adaptive timestep
Parameters:
    ground - ground state (MPS)
    tf - final time
    method - the function used to propogate a wavefunction over single dt
    dti - initial guess for timestep
    epsilon - total change allowed in a single time step
    independent - boolean that is True if we are evolving with a time independent
              Hamiltonian, and False otherwise
"""
function propogation(ground::MPS, params, tf, method, dti, epsilon, independent, cutoff)
    # error measures (en is for current step, en1 is for previous step)
    en = en1 = 0.0
    time = 0.0
    # copy states
    psi = deepcopy(ground)
    # set dt and previous dt
    dt = pdt = dti

    # initialize vectors for saving times and expectation values
    times = [0]
    energies = [inner(ground, get_ham(0, params, independent), ground)]
    currents = [inner(ground, get_current(0, params, independent), ground)]

    # run for the entire time interval
    while time < tf

        # get the MPS at time + dt
        next_psi = method(psi, dt, time, params, independent, cutoff)

        # calculate difference between current and next psi
        en = difference(psi, next_psi)

        # run propogation while the difference is greater than acceptable error
        while en > epsilon
            # adjust time step
            dt *= epsilon / en
            # get the next MPS and calculate difference
            next_psi = method(psi, dt, time, params, independent, cutoff)
            en = difference(psi, next_psi)
        end

        # incremement time and add it to the array
        time += dt
        times = vcat(times, [time])

        # accept wavefunction
        psi = deepcopy(next_psi)

        # calculate expectations
        energies = vcat(energies, [inner(psi, get_ham(time, params, independent), psi)])
        currents = vcat(currents, [inner(psi, get_current(time, params, independent), psi)])

        en1 = (en1 > 0) ? en1 : en

        # adjust for next time step
        # https://www.sciencedirect.com/science/article/pii/S0377042705001123
        ndt = dt * ((epsilon^2 * dt)/ (en * en1 * pdt))^(1/12)

        # update values for next iteration e_{n-1} -> e_n, dt_{n-1} = dt_n,
        # dt_n -> dt_{n+1}
        en1 = en
        pdt = dt
        dt = ndt
    end
    return times, energies, currents
end

Answered: AutoMPO using operators with more arguments

Tue, 29 Mar 2022 19:44:15 +0000

Hi thanks for the question. So if the main parameter you are wanting to pass is the dimension of one of the Hilbert space types (the bosons representing the phonons) then the best way to do that is the idea you suggest at the end of your question: just by making your sites in a different way.

The "Boson" site type included in ITensors.jl recognizes a dim keyword argument whose default is 2, but can be increased to any number.

So then instead of using the siteinds function to make your sites, you can do the following for your case

dim = 3
s = [isodd(n) ? siteind("Fermion", n) : siteind("Boson", n; dim) for n in 1:N]

which will make an array of site indices and pass the dim keyword argument in the case that the site is a "Boson". (There is a Julia trick here where instead of writing dim=dim you can just write dim.)

Would that address the issue you're facing? You can also print out the array s of site indices afterward to verify that your "Boson" sites have the correct dimension.

Finally, when you then make operators for these sites, such as by using the OpSum/AutoMPO system, the correct operators will be made to match the dimension of the "Boson" sites that you make.

Happy to discuss more -

Miles

Answered: Infinite MPS TEBD in Julia

Fri, 25 Mar 2022 13:39:53 +0000

Hello Tianqi,

Good questions, the ITensorInfiniteMPS.jl package is more of a pre-release as we round out the features and finalize the interface, so it is not well documented right now but should be usable (the VUMPS code is already being used in a few research projects).

The tags "c=0", "c=1", etc. indicate which unit cell the MPS Index or tensor is in. If you have have a 3-site unit cell, the first tensor in the first unit is psi[1] and the first tensor of the second unit cell is psi[4], with the relationship that psi[4] = translatecell(psi[1], 1) (i.e. psi[1] shifted by one unit cell, which shifts the tags from "c=1" to "c=2"). It only ever actually stores the tensors of the first unit cell. If you set a new tensor outside of the first unit cell like psi[4] = T, it maps it to the first unit cell and overwrites the tensor of the first unit cell.

It wouldn't be too hard to implement iTEBD with the current code. As you say, you should only need to evolve with gates in the first unit cell, and when you update the tensors of the InfiniteMPS in the first unit cell it implicitly updates tensors in the rest of the unit cells. Of course, you will have to follow the details of Fig. 3 in https://arxiv.org/pdf/cond-mat/0605597.pdf to properly update the tensors of the state.

Alternatively, we already have a TDVP implementation in ITensorInfiniteMPS.jl which is an alternative time evolution method that in general has been found to work better for more complicated models. You just use the tdvp function instead of vumps, and specify a time step with the keyword argument time_step. You can see it tested here: https://github.com/ITensor/ITensorInfiniteMPS.jl/blob/main/test/test_vumps.jl

Please try the TDVP code and let us know if it works for your use case. If you write the iTEBD code, please consider contributing it to the ITensorInfiniteMPS.jl package, since it would also be nice to have.

Cheers,
Matt

Answered: [Julia]3-sites MPS Time Evolution

Thu, 24 Mar 2022 15:25:30 +0000

Hi, it's a good question, though could you please be more specific about what you changed in the code? Did you leave the original two site terms unchanged and then add these three site terms? Or do you only have the three site terms now?

Also when you say the time is much longer, how much longer is it?

I did my own tests of adding three-site terms, in addition to the previous two-site terms. In my case it is slower but by an amount that seems reasonable to me. For N=40 sites and setting conserve_qns=false, I found that the original code took about 4 seconds and the code with additional three-site terms took 12 seconds.

There are many reasons this extra time is reasonable. Here are the main ones:
1. there are just more gates, and there is a cost for acting each gate. If there are twice as many gates, then the code should generally take at least twice as long.
2. the extra gates could lead to the state becoming entangled more quickly, which would add further codes even when applying the two-site gates
3. the cost of applying a three-site gate is always higher than a two-site gate. This is because the code merges together three sites of the MPS, so there is one extra site making that step at least 2 times more expensive and more like 4 times more expensive. (If the site dimension is d then there is one step costing an additional factor of d and another one scaling with an additional d^2).

So for all those reasons I am not too surprised. In general if you are dealing with a very complicated Hamiltonian, then TDVP can be a better option for time evolution compared to Trotter or TEBD. We are actively working on a TDVP code for ITensor and it will be released soon.

Best regards,
Miles

Answered: How to add a constant term in Hamiltonian(julia)

Thu, 24 Mar 2022 15:07:07 +0000

No that's a pretty good question actually!

The short answer is that if you want an overall constant shift, you can do this:

ampo += -0.5/4,"Id",1

and importantly do that outside the loop so it's only a single shift. If you put that inside the loop if would be equivalent to adding a shift

ampo += -(N-1)*0.5/4,"Id',1

unless that's actually the behavior you want.

On a more big picture level, recall that a constant shift to a Hamiltonian really means a term which is the tensor product of the identity operator on every site. The way OpSum works when converting to an MPO is that any sites not included in a term are assumed to have the identity operator acting on them. So a term like "Sz",3 is really Id1 Id2 Sz3 Id4 Id_5 ....

We should add as a feature, though, the ability to just add a constant by itself as you tried. It's a nice suggestion and could be convenient in many cases.

Thanks,
Miles

Answered: Where can I find the proper syntax required to perform SVD in dmrg tutorial ?

Thu, 24 Mar 2022 01:22:25 +0000

Hi asing,
For the C++ version the interface of the svd function is described and some examples given in the documentation here:
http://itensor.org/docs.cgi?vers=cppv3&page=classes/decomp

Click on the the link halfway down the page that say "Click to Show Example" to see a nice example of the interface. The Synopsis at the top shows one too.

The basic idea is that, given an ITensor with indices i,j,k,l, you pass the ones you want to end up on U to the svd function, like svd(T,{i,k}) if you want i and k to be on U, with the remaining indices going onto V.

In the context of DMRG, you should also pass truncation parameters to control the cost of the DMRG algorithm, so you should also pass values for the "MaxDim" and "Cutoff' named arguments, so like svd(T,{i,k}, {"MaxDim=", maxdim, "Cutoff=", cutoff}); where maxdim is some integer and cutoff is a real number.

Hope that helps. Also we have fully working examples of using our DMRG code if you want to look at those, such as in the sample folder and in the Code Formulas section of the C++ documentation.

Best,
Miles

Answered: [C++] OMP vs. MKL parallelization

Tue, 22 Mar 2022 15:06:51 +0000

Hi Chia-Min,
Your understanding about the role of these two different environment variables is correct, assuming that the BLAS you are using is actually MKL. Of course for a user using a different BLAS, such as OpenBLAS, they would need to set OPENBLASNUMTHREADS instead of MKLNUMTHREADS.

To answer your last question, within ITensor the only explicit parallelization is over quantum number blocks, with the number of threads used for that controlled by OMPNUMTHREADS. However, that does not mean ITensor "only" supports that kind of multithreading. Since we use BLAS to do the tensor contractions, then if you turn on multithreading for your BLAS then calls to the BLAS by ITensor will also be multithreaded. In fact, it is something ITensor does not control itself and you just control by setting MKLNUMTHREADS or similar.

If you did not see any effect of setting MKLNUMTHREADS, this could be for a number of different reasons. A less likely one is that it's not properly set by your code or terminal. But more likely, it's one of two other things (or both):
1. there is a competition of resources happening between the multithreading over the blocks and the multithreading over the matrix data within BLAS
2. many of the blocks or tensors are just too small for the BLAS multithreading to have much of an effect

We have in general seen that BLAS multithreading does not often scale very well, and will just give something like a factor of 2 speedup even if more than two threads are used for it.

To be more precise about all these things, please see the benchmarks in the latest version of the ITensor paper, Section 12: https://arxiv.org/abs/2007.14822

Here is a link to the actual code that was used to obtain these benchmarks - I link here to the line that sets the MKLNUMTHREADS and OMPNUMTHREADS variables so you can see that is indeed how it is done:
https://github.com/ITensor/ITensorBenchmarks.jl/blob/12e3a1f0ff3e587fd026d22d79a00bf36668cb34/src/runbenchmarks.jl#L234

Of course if you have any followup questions please ask. Also I might ask Matt Fishman to weigh in since he did those benchmarks and wrote the block-sparse multithreading code.

Best regards,
Miles

Answered: C++ version, complex matrix-vector multiplication

Fri, 18 Mar 2022 03:18:26 +0000

After writing the comment above, I realized this feature could be added rather quickly so I just added it. Please see the following PR to see the lines of code that were changed (the important ones are in tensor/mat_impl.h) which I thought might interest you:
https://github.com/ITensor/ITensor/pull/409

Thanks for pointing this out -

Miles

Answered: Measure multi-point correlation in 2D lattice

Thu, 17 Mar 2022 19:03:30 +0000

Thanks for the interesting question. That is puzzling, because it looks like you are doing everything correctly and should get +1 in both cases, assuming that your MPS really does describe the same wavefunction.

I don't know the answer off the top of my head, because this is more in the category of like "numerical bugs" where one has to try out different things to resolve the mystery, but I could suggest some ideas.

1) you could try making the W operator using our AutoMPO tool and then taking the expected value of the resulting MPO. What answer do you get that way?

2) are there other properties, like two-point correlation functions, you can also compute to ensure that you really are getting the same wavefunction? Even though they have the same energy, because you are using two different 2D paths, it could be that DMRG is finding a different solution for each path, something like a funny superposition of ground states (assuming there is a ground state degeneracy, which I'm not sure is a correct assumption or not – you'd have to remind me)

3) could you try on a smaller ladder, with only one hexagon in the y-direction?

Answered: Entanglement Entropy near phase transition in 1D

Thu, 17 Mar 2022 18:58:18 +0000

HI, thanks for the question.

I don't immediately know the answer, but I would like to know if the energy of the unentangled state you are getting is matching the expected ground state energy for the J > 0 case? In other words, is the product state (unentangled state) you are finding a valid ground state?

I ask because you mentioned Majorana physics but the Hamiltonian here is a spin model. I know of some cases, like the Kitaev chain, where the Majorana model is equivalent to a spin model but the ground state in the fermion language is more entangled, while in the spin language is has less entanglement. In fact, it is an equal superposition of the two spin ground states. Is something like that expected here?

Thanks,
Miles

Answered: Computing the transfer matrix for iDMRG

Thu, 17 Mar 2022 18:50:09 +0000

Hi Sylvain,
Thanks for your patience. I belive the iDMRG you are meaning is the code here: https://github.com/ITensor/iDMRG (just for reference of those reading).

At a high level, here is some key information about that code and what it returns. When the iDMRG finishes running, the MPS that is return describes just one unit cell, of course. A key thing to know is that the MPS tensors are in the "right orthogonal" gauge meaning each of the tensors psi(1), psi(2), ... will be right orthogonal.

There is a special tensor also returned as psi(0) which is the "center tensor" and it has no physical index, but lives on the link to the left of the first site.

So for example if you wanted to compute properties only within one unit cell of say size 2, then psi(0)*psi(1)*psi(2) would be the correct wavefunction of one unit cell. For two unit cells, conceptually psi(0)*psi(1)*psi(2)*psi(1)*psi(2) would be the wavefunction. That is, you only use the center tensor psi(0) once and keep "chaining" the other MPS tensors to make a basis for the infinite unit cells going off to the right.

From this background, you can see how the transfer matrix is schematically dag(psi(1))*psi(1)*dag(psi(2))*psi(2). I say schematically because there I am being very loose about the necessity to prime the link indices sticking out of the left and the right ends to make this contraction actually a matrix and not a scalar. Also you would never want to actually form the transfer matrix this way because it would cost the fourth power of the bond dimension of the MPS, which is a very high cost.

So finally to get the transfer matrix spectrum, which is what you want as you know for obtaining the correlation length, you can obtain it using the Arnoldi algorithm which uses iterative applications of the matrix to get only the dominant right-eigenvectors and their eigenvalues. You will need to code a custom C++ object that defines the method

void product(ITensor const& in, ITensor & out)

which, given an input ITensor "in", efficiently applies the transfer matrix to it one time and returns the resulting ITensor "out" so that it has the same collection of indices (including same prime levels) as the input ITensor. You can finally pass an instance of this custom object to the function arnoldi defined here:
https://github.com/ITensor/ITensor/blob/97f73cd7387b61420011ff36dbfd95ff87860990/itensor/iterativesolvers.h#L715

Given the right parameters, you can obtain the dominant eigenvalues of the transfer matrix efficiently that way.

Or you can use our new Julia ITensorInfiniteMPS package which includes a pre-written example code already of how to get the transfer matrix spectrum :^)
That example is located here:
https://github.com/ITensor/ITensorInfiniteMPS.jl/blob/main/examples/vumps/transfer_matrix_spectrum.jl
And we could help you get set up using that package (it has to be installed separately but only takes a second - very easy) if you are interested in that approach.

Best regards,
Miles

Answered: DMRG for 2D lattices with rotational symmetry

Thu, 17 Mar 2022 14:50:42 +0000

Hi Niccolò,

I think the short answer is that it would probably be technically possible, but either through some nontrivial modifications of the DMRG algorithm
(not just small modifications to the current DMRG code in ITensor) or by using a different optimization method like gradient optimization, where it is easier to implement optimizations with nontrivial constraints like that but would likely be slower than DMRG. My guess is that in the end it would be a lot of work and not really worth it.

It is a bit easier to do with infinite MPS algorithms like VUMPS, but I found that there were subtle numerical issues involved with actually getting it working (for example details about which particular matrix factorizations you use when orthogonalizing the effective wavefunction to maintain the symmetry properly). I also only tried it for 1 site unit cells where it is more obvious how to implement that kind of symmetry, I think it would be more subtle for multi-site unit cells.

In the end, you would at most get a factor of 2 speedup, which is ok but I think there are other strategies we are working on for real space parallelization and parallelizing over sums of Hamiltonians which would be more general, easier to implement, easier to maintain, and scale to speedups beyond a factor of 2. We are working on them now so hopefully they will be available to try out relatively soon!

Cheers,
Matt

Answered: Computing correlation function

Tue, 15 Mar 2022 20:26:57 +0000

Wow okay this is so embarrassing but the bug was in my plotting function all along. The code as described above works perfectly fine! Thank you to everyone who tried to help, and I am so sorry for wasting your time like this

SPIN-SPIN CORREALTION FOR A TWO LEG LADDER MODEL

Mon, 14 Mar 2022 19:02:11 +0000

Hii,

I am doing DMRG of a two leg ladder model in ITensor julia.

I have calculated the ground sate energy and spin-spin correlation in 1D Heisenberg model and 1D Hubbard model and it gives correct ground state energy and spin-spin(Total spin on each site) .

However, when i calculated DMRG for a two leg ladder model (for 48*2 sites) , it appears the ground state energy is correct, but the spin-spin correlation is antiferromagnetic while the actual correlation should be ferromagnetic.

Here is the Hamiltonian of the code with parameters

Nx=48

N= 2*Nx

sites=siteinds("Electron",N,conserve_qns=true,conserve_nf = true,conserve_sz=true,conserve_nfparity=false)



ampo =AutoMPO()

#intra-leg hopping
for j=1:2:(N-3)

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


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

end

#inter-leg hopping

p=1

for j =1:2:(N-1)

    ampo += Q(p),"Cdagup",j,"Cup",j+1
    ampo += conj(Q(p)),"Cdagup",j+1,"Cup",j
    ampo += Q(p),"Cdagdn",j,"Cdn",j+1
    ampo += conj(Q(p)),"Cdagdn",j+1,"Cdn",j
    p=p+1

end   





# On-site interaction       

for j=1:N

    ampo += U,"Nupdn",j


end

I kept the particle number fixed as i want to calculate ground sate energy at some particular electron density.

After performing the DMRG with the above Hamiltonian i calculate the spin-spin correlation in the following way

xxcorr = correlation_matrix(psi,"S+","S-")
yycorr = correlation_matrix(psi,"S-","S+")
zzcorr = correlation_matrix(psi,"Sz","Sz")
zz =  0.5* xxcorr + 0.5 * yycorr +  zzcorr

I calculate the spin-spin correlation for a reference site away from the boundary.

But as i mentioned i am not getting the correct spin-spin correlations(which is ferromagnetic for some given parameters).

So ,is there anything wrong in writing the Hamiltonian or in the correlation matrix ?

Thanks

Answered: [C++] Convert an MPS with quantum number to an MPS without quantum number

Mon, 14 Mar 2022 18:19:52 +0000

Hi Chiamin,
Yes, there is a function called removeQNs(MPS const& psi) that you can call on an MPS that will remove all of the quantum numbers and make the storage dense.

There isn't any function that will remove only some of the quantum numbers and not others, however.

I think for these more technical kinds of things, we would need help adding these features to ITensor which could be quite a project. It's something we might consider doing in the Julia version first if it would be used often, then porting back to the C++ version.

Best,
Miles

P.S. would you be able to do the application you want just with a regular dense MPS rather than having to keep the parity quantum numbers?

Answered: [Julia]using a periodic boundary condition

Sun, 13 Mar 2022 23:10:27 +0000

Hi, to answer your question, I just added a "Frequently Asked Question" FAQ entry here:
https://itensor.github.io/ITensors.jl/dev/faq/DMRG.html#How-to-do-periodic-boundary-condition-DMRG

since it's something I get asked from time to time.

Please let me know if that FAQ doesn't answer your question & we could discuss it more.

Miles

Answered: Time dependent correlations

Fri, 11 Mar 2022 03:25:41 +0000

Hi, so I think the way to figure this out is to look at the expression

<Sz1(t) Sz4(0)> = exp(i E0 t) <0| Sz4 exp(-iHt) Sz1 |0>

which is what I believe you want to compute. Then reading it from right to left as a sequence of operations, they are:
1. compute the ground state |0>
2. act on the ground state with Sz1 before doing any time evolution
3. take the resulting state and time evolve it for a time t
4. act on that state with Sz4
5. take the overlap with the ground state ket <0| and multiply by exp(i E0 t) where E0 is the ground state energy

A trick that can be done to make this more efficient is to break up exp(-i H t) as exp(-i H t/2) exp(-i H t/2) then act the first one of those time-evolution operators to the left. When you take the dagger this actually means an evolution of the ket Sz_4|0> by an opposite-sign time evolution of exp(+i H t/2). But before trying this trick you may want to follow the simpler prescription above to get some reference results.

Hope that helps –

Miles

Answered: [Julia]define the state in different Hilbert space

Thu, 10 Mar 2022 16:02:47 +0000

Hi, it's a good question as we have not documented this, and need to!

For now, a good way to learn how to define these kind of state definitions, such as "Up" and "Dn" for spin systems, is to look at how it is done in our source code, because the code you would need to write is the same. (Of course reading about it in the documentation will be even better once we document it!)

Here is a link to the spinone.jl file where we create the states using the function ITensors.state:

https://github.com/ITensor/ITensors.jl/blob/main/src/physics/site_types/spinone.jl

For the 3/2 example, you would do something like this:

ITensors.state(::StateName"Up", ::SiteType"S=1") = [1.0, 0.0, 0.0, 0.0]

So the key points are:
- you define a function named ITensors.state taking a StateName and SiteTyp
- it returns a vector which can be anything you want, and does not have to have only 1 and 0 entries
- once you define this function, you can immediately use your new states in the productMPS function and elsewhere

Hope that helps and please let us know if you run into any issues.

Miles

Answered: Time evolution under periodic Hamiltoian

Tue, 08 Mar 2022 15:44:16 +0000

Hi, thanks for the question. I think there are two considerations here:

1) the AutoMPO, MPO-based method for time evolution has turned out to not always be reliable. It is not due to a bug, but more of a limitation of the method used to exponentiate the Hamiltonian there. So I would instead recommend you use the TDVP method for time evolution. We have a code for that method here: https://github.com/ITensor/TDVP and it includes a sample code. The sample code does imaginary time evolution but you can change t to t*Complex_i to do real-time evolution. I have updated the ITensor "Code Formula" about the MPO method to note that it's better to use TDVP.

2) regarding periodic systems (I think when you say closed boundary conditions you are referring to periodic boundary conditions?) it has long been a limitation of MPS that the techniques for doing periodic systems are not as well developed. However, you can still input a periodic Hamiltonian to AutoMPO to use within TDVP. What AutoMPO does is it makes an open-boundary MPO but with a "long bond" connecting the first and last site inside the MPO.

This approach of using open-boundary MPO and MPS for periodic Hamiltonians is technically correct and works well for small system sizes. For larger systems it can lead to large bond dimensions of the MPS and can be hard to converge well.

So I think a key question is: do you really need periodic boundaries for the system you are studying? Although they are "standard" in theoretical calculations, they are often not the best choice for MPS numerics. I have more to say about that here: https://itensor.github.io/ITensors.jl/stable/faq/DMRG.html#What-boundary-conditions-should-I-choose:-open,-periodic,-or-infinite?

Best regards,
Miles

Answered: The principle of calculating excited states using DMRG

Wed, 23 Feb 2022 03:58:49 +0000

Hi, you can see section III.C. on page 7 of this paper for a discussion about the technique we have made available to compute excited states: https://arxiv.org/pdf/1105.1374

There is a discussion of this feature in the Julia documentation:
https://itensor.github.io/ITensors.jl/stable/examples/DMRG.html#Compute-excited-states-with-DMRG

It's an idea which is used in other numerical methods too, just to change the objective of the code to require the state being computed to be orthogonal to a previous state.

Thanks for the kind words about ITensor!

Best regards,
Miles

Answered: Spontaneous symmetry breaking and ground state

Wed, 23 Feb 2022 03:56:06 +0000

Hi Ajit,
As mentioned above please do view the other discussion which Navya linked which goes into more detail.

A short answer is that the true ground state of a symmetric system which breaks a symmetry is a symmetric linear combination of the symmetry-broken (quasi-) ground states. But this true ground state is only lower in energy by a very tiny amount than the symmetry-broken states, and has higher entanglement in general. So in practice on moderate to large system sizes DMRG will return a symmetry broken state. It can be a helpful technique to actually force this to happen by applying "pinning" fields on the edge sites to go ahead and select one of the symmetry breaking scenarios.

Regarding the Weight parameter, I don't know a clear theory about how it should be chosen, but I believe it should be larger than the gap between the ground and first excited states. (Otherwise the energy penalty, which the weight adjusts, may not be strong enough for the returned state to be orthogonal.) So I'd recommend proceeding by guessing a moderately large value for the weight, then checking afterward that the returned state is really orthogonal to the previous ones. If you have any problem with convergence, try lowering the weight.

Test this all out on small system sizes, and it's always a good idea to plot real-space properties of your states, especially for excited states which often need many more sweeps to converge fully.

Best,
Miles

Answered: DMRG FOR TWO LEG LADDER MODEL

Tue, 15 Feb 2022 23:22:19 +0000

Hi Paban,
Thanks for the good questions.

a) for the filling you have two options: the main one is to use our quantum number (QN) conservation system, which works as you guessed: if you use site indices (calling the siteinds function) with the conserve_qns=true, then when you prepare the initial state for DMRG, the number of particles in that initial state will remain unchanged by our DMRG code.

If you turn off or do not conserve particle number, then you would have to add a chemical potential term to your Hamiltonian or otherwise tune your Hamiltonian to get the density that you want.

b) for making custom measurements or other behaviors during a DMRG calculation, we have a very powerful system called the "Observer System" where you define a custom type and a function called measure! for it that will be called throughout the DMRG code (if you pass your observer type to the dmrg function). Then in your measure! function you can put any code you want, such as measuring local observables, calling the expect function to measure every site (I would do this only once per sweep, since it's a global measurement), write data to files, and anything else. Please let us know if you have any questions about how to use it.

Best regards,
Miles

Answered: Time evolution of local green function using two applyMPO for spinless-fermions.

Mon, 14 Feb 2022 16:43:50 +0000

Hi, thanks for the good question and your patience with a slow reply.

While I'm not sure why you getting the value of zero on every other time step, I think there are a few major improvements to your approach which you should consider anyway, and after you make them this problem may disappear in the process of changing your code.

Here are the improvements or fixes:
1. since one of the exp(-i Ht) operators acts on the ground state of H, you can rigorously replace it by a scalar exp(-i E0 t) where E0 is the ground state energy <psi0|H|psi0> and so skip that step

a much better choice for doing the time evolution would be the TDVP algorithm, for which a high-quality implementation in ITensor is now available here:
https://github.com/ITensor/TDVP
including a helpful sample code

Especially #2 above might eliminate the zeros because I and others have found that unfortunately the MPO method (based on toExpH) has not turned out to be as accurate as originally hoped (I mean as an algorithm - not that there is anything buggy about how it is implemented by ITensor). TDVP is basically just a superior method in almost every way, with one caveat that one has to be careful about growing or adapting the MPS basis within TDVP. The 2-site TDVP method does this automatically but is somewhat less accurate than the 1-site TDVP method. For the 1-site TDVP method, the basis adaptation isn't automatic but can be achieved through a basis extension method (the addBasis function) shown in the TDVP code example.

Or, last but very much not least, you can just use the Trotter gate or TEBD method for your time evolution. For your model which is short ranged and 1D, TEBD is a great method. It is efficient and automatically adapts the bond dimension in a very 'foolproof' and reliable way. The only advantage of TDVP over Trotter/TEBD for you model would be that TDVP allows larger time steps, basically. If I were in your shoes, I would implement both and use one as a check on the other, and not use the toExpH method.

Best regards,
Miles

Answered: [C++ ITensor 3] MPO time evolution does not work for large interactions

Sun, 13 Feb 2022 04:04:15 +0000

Hi Jin,
I believe JR is correct that a smaller tau could help here, but of course it would be nice if you can use a method that allows a larger tau.

Have you thought about using the TDVP method instead? It has all the advantages of the MPO approach you are using, but over the last handful of years has turned out to be much superior in terms of accuracy and ability to reliably use larger time steps.

There is a high-quality TDVP code available for ITensor through this code repository:
https://github.com/ITensor/TDVP
and it also includes a sample code to help you get started.

There's one caution about TDVP, as you may know, that it historically has trouble 'adapting' the bond dimension automatically, either in the sense that it doesn't do so at all (1-site TDVP) or in the sense that it does it in a sub-optimal way (2-site TDVP). But the code linked above includes a novel 'basis expansion' method which you'll see used in the sample that improves the MPS basis to alleviate problems with the growth of the bond dimension in a proper way.

As with any time evolution code, I'd recommend comparing to exact results either for small systems or in limits where an exact solution may be available.

Best regards,
Miles

Answered: [julia] TEBD gates involving fermions

Thu, 10 Feb 2022 13:46:50 +0000

Hi Junsen,

Good question. If you switch to using operators like "Cdag" and "C", the evolution should just work. In practice, the fermion sign is handled with fermionic swap gates. If you apply local gates, there are no extra signs needed beyond those that might be within the operators themselves, and if you apply nonlocal gates, our fermionic swap system should handle the signs properly.

Please try it out and let us know if you come across any issues.

Cheers,
Matt

Answered: Possible bug in on-site terms - AutoMPO (C++)

Wed, 09 Feb 2022 17:59:09 +0000

Hi, so I checked some more on this. I think the code is working properly. It's hard (actually, impossible) to see from just looking at the first MPO tensor whether the MPO is correct because what operator is made by the MPO depends on all the MPO tensors.

Here is a check you can do to tell whether in this case the MPO returned equals the requested operator:

auto N2_1 = mapPrime( op(sites,"N",1)*prime(op(sites,"N",1)) ,2,1);
auto N2_2 = mapPrime( op(sites,"N",2)*prime(op(sites,"N",2)) ,2,1);
auto Id_1 = op(sites,"Id",1);
auto Id_2 = op(sites,"Id",2);

printfln("Norm difference = %.12f",norm(H(1)*H(2)-N2_1*Id_2-Id_1*N2_2));

The first two lines make the operator N^2 on each site. Then the last line subtracts (N^21 + N^22) from the operator defined by the MPO, which can be obtained by contracting all the MPO tensors together. When I run a code with your AutoMPO input at the top and this check at the end I find that the Norm difference as printed above is zero.

Please let me know if that doesn't answer your question or if you have a follow-up question.

Thanks,
Miles

Answered: Customising the 'Custom SiteSet' in the Site set class ?

Wed, 09 Feb 2022 14:07:31 +0000

Hi Eliem,
It’s a good question. You can do this, however the typical outcome will be that DMRG and related algorithms will run more slowly than if you used separate sites for your various degrees of freedom. This is because MPS algorithms scale linearly in the number of sites, whereas they scale polynomially in the site dimension, and the site dimension itself grows exponentially as you group more degrees of freedom together onto one site.

However it can in some cases be a good idea to group d.o.f. depending on the Hamiltonian.

The way to define such a site type is just enumerate all the possible states it can be in, and make that the dimension of the site Index and assign the corresponding quantum numbers (QN’s) if applicable and if you plan to use that feature.

If you do want to do this and need help, please let me know more details about your system. Thanks.

Miles

Answered: Spatial parity inversion of MPS using SWAP gates

Mon, 07 Feb 2022 00:13:07 +0000

(Please see above discussion.)

Answered: Exponential of non-hermitian operator

Mon, 07 Feb 2022 00:12:18 +0000

Thanks for the question. Yes the example code you linked to (involving the BondGate class) ought to work well for non-Hermitian operators. I think the Trotter expansion itself would still be justified in this case and the part of the code which does the exponentiation, which is inside the BondGate class itself, uses a general enough algorithm that it should handle exponentiating any type of operator. (Internally, BondGate sums a very high order Taylor series to exponentiate the local operator.)

Regarding part (2) of your question, there is a built-in function to exponentiate local Hermitian operators, which is called expHermitian, but only for that case. However, as mentioned above the code you linked to uses the BondGate class which does the exponentiation internally using a different (high-order Taylor) algorithm. So that may be all you need for your use case.

But we have not written tests for the non-Hermitian case, so I'd say please proceed with some case. Please test some exactly solvable or known limits of your problem such as small system sizes where you could do everything exactly with matrix methods. This is a good practice anyway even when using fully supported and tested cases such as Hermitian time evolution, because every new physical system presents its own challenges.

Please let us know if you don't get the results you expect when doing those initial checks.

Best regards,
Miles

Answered: Stopping a DMRG Run "Gracefully"

Sun, 06 Feb 2022 08:01:24 +0000

Hi Leandro,

Yes, there is a detailed and nice doc on how to stop early in Julia, using the so-called observer system. I personally have customized my own observer based on this post : )

Best,
Junsen

Answered: How to create a random state with definite fermion parity?

Sat, 05 Feb 2022 02:15:25 +0000

Hi Navya,

This is not an answer to your question. Just provide some information.

In my case, when using the following site type

sites = [
if mod(n,3) == 2
    Index([QN()=>2]; tags="S=1/2, Site, n=$n")
else
    siteind("Fermion", n;conserve_qns=true)
end
for n = 1:3*ns
    ]

and randomMPS(sites,state,10), I obtain the following warning:

Warning: MPS center bond dimension is less than requested (you requested 10, but in practice it is 1. This is likely due to technicalities of truncating quantum number sectors.

And I find the fermion number distribution is the same as given, i.e., there is no randomness in the fermion sector. However, the spin sector is indeed random.

Instead, if I use the following site type

sites = [
    if mod(n,3) == 2
        Index([QN()=>2]; tags="S=1/2, Site, n=$n")
    else
        siteind("Fermion", n;conserve_nfparity=true)
    end
    for n = 1:3*ns
        ]

The good news is that now the fermion sector also becomes random (by checking the fermion number distribution), however, it seems that the fermion parity is not conserved! In fact the total number of fermion is found to be a non-integer.

Note, in my own project, the first site type and an essentially non-random (in the fermion sector) state randomMPS(sites,state) are used, and it is so far so good :)

Best,
Junsen

Answered: [julia] how to create local identity operator

Thu, 03 Feb 2022 15:01:37 +0000

Hi Junsen,
You can use the operator name "Id" to do this. So like op("Id",sites,j) or alternatively op("Id",ind) where ind is a Index object.

This particular operator ("Id") is actually defined for all indices, not just ones carrying special tags.

Hope that is the answer you need -

Miles

Answered: Symmetry breaking in the transverse field Ising model/ Kitaev chain

Mon, 31 Jan 2022 02:53:29 +0000

Hi Navya,
That's a lot of questions :^) But they are good ones. I will answer the ones I'm most confident about, then please comment below to remind me to try to answer the others as soon as I can or if my answer here is enough already.

Yes this is partly right. But a more key and simple reason this happens is that the energy of the cat state is only a little smaller than a non-cat state, and this difference goes exponentially to zero with system size. You can think of DMRG as always making a trade-off between energy and entanglement, so it's as if DMRG doesn't "think it's worth it" to spend a whole lot more entanglement to gain only a very tiny bit of energy. More rigorously, I think what is happening is that DMRG is technically slightly stuck in a (barely) excited state and just can't 'find' the cat state which is the true ground state.
The last part of my answer to (1) is the answer to this. The part about spending entanglement is more of a non-rigorous intuition. Really DMRG is a dynamical process where the MPS "environment" gets built from some initial state and then is used to project the Hamiltonian into a small part of the Hilbert space. This projected Hamiltonian and not the full one is used in the core step of DMRG to update the previous MPS basis on one site and then slide to the next site. So if one does not already start with an initial MPS that is a cat state, then the projection built from the non-cat initial state probably keeps DMRG from "seeing" that a cat solution exists. I think even a small deviation from a perfect cat initial state is probably unstable to a non-cat final state of DMRG for related reasons (how the MPS basis gets built and updated dynamically within DMRG).
I don't think there's a simple way to force DMRG to find cat states other than to maybe start already in a perfect cat state and carefully design a flavor of DMRG to preserve that property. Maybe there is some kind of internal MPS symmetry or gauge that can be enforced but it's not immediately obvious to me.
I have not found that DMRG makes a superposition of even and odd parity states for the Kitaev chain, and I studied a closely related system with DMRG in a paper of mine. I would say that in some philosophical sense you aren't really studying fermions if you don't enforce parity quantum number conservation. Or at least you can always choose to conserve this for a closed fermionic system. So I would make sure to use ITensor's QN DMRG mode and enforce fermion parity. Then you can just start off in a state of definite parity and our DMRG code will rigorously always stay in that parity sector. Then by how the mapping of the Kitaev chain works relative to the Ising chain, you will necessarily be in a cat state because the fermion parity conservation will enforce that.

For 5 & 6 I would suggest revisiting these questions in light of the idea of using QN conservation to enforce even or odd parity as discussed above.

Miles

Answered: DMRG for phase transitions

Mon, 31 Jan 2022 02:34:53 +0000

Hi, I would say that – yes DMRG can certainly be used very well to study critical systems and phase transitions, especially of 1d systems.

So it seems that the core of your issue is that for certain values of lambda, or perhaps certain initial states you happened to use for those values (it may be less about lambda itself, hard to be sure from what I know) that you are likely getting stuck into a state which is not the ground state. As you know that can happen easily with DMRG for some systems. It's good to see you are using the noise term which can help a lot with sticking.

Did you rerun your calculation for the (possibly) troublesome values of lambda, such as lambda=0.26 here, again for a second or third time with different initial states? Is there a local property you can plot to visualize the states DMRG reaches at the end to inspect whether they look similar to each other for nearby lambda or very different? Those are the first two steps I would try. I would also try on very small system sizes first to see if the sticking can be avoided then work my way up to larger system sizes gradually.

Hope that helps a bit –

Miles

Answered: How to calculate string operator in ITensor-3 C version

Mon, 24 Jan 2022 16:29:59 +0000

Hi, good question. So I think in this case because the operators inside and outside the exponential are all commuting, you can just write the exponential of the sum as a product of exponentials and then just locally exponentiate each Sz_k operator (this can just be done on paper even, ahead of time). So then to measure such a string operator which is now a product of local operators, you can either make an MPO which just has a bond dimension of 1 (product MPO) or just apply each operator to one of the MPS in the expectation value and finally compute the overlap with the other MPS.

Hope that helps you find the answer you need - if not please comment below.

Miles

Answered: toExpH in Julia

Mon, 24 Jan 2022 16:26:50 +0000

Hi Andreas,
It’s a good question. It’s one of the few features of the C++ version we have not implemented in Julia yet. We may do it, however there are two reasons why it’s less urgent than it might seem:
1. it’s been found that the MPO exponentiation method used for that is not as accurate for time evolution as other methods like Trotter gates or TDVP
2. we should have a TDVP code available in Julia sometime this spring, and TDVP has all of the benefits of MPO time evolution plus many other benefits so it’s basically a superior method

What system are you studying that you need toExpH for? Does it have long-range interactios?

Miles

Answered: [julia] Out of memory problem

Wed, 19 Jan 2022 17:59:47 +0000

(Please see discussion above.)