Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

infsiteinds with QNs and arbitrary initial state #68

Closed
nbaldelli opened this issue Jan 11, 2023 · 6 comments
Closed

infsiteinds with QNs and arbitrary initial state #68

nbaldelli opened this issue Jan 11, 2023 · 6 comments

Comments

@nbaldelli
Copy link
Contributor

If I try to initialize an infiniteMPS with an arbitrary initial state, for example

N = 2 # Unit cell size
initstate(n) = isodd(n) ? "↑" : "0" #quarter filling
s = infsiteinds("Electron", N; initstate, conserve_qns = true)
ψ = InfMPS(s, initstate)

I get this error

ERROR: Dividing ITensors.QNVal(Nf, 1, -1) by 2, the resulting QN value is not an integer
Stacktrace:
  [1] error(s::String)
    @ Base ./error.jl:35
  [2] /(qnval::ITensors.QNVal, n::Int64)
    @ ITensorInfiniteMPS ~/.julia/packages/ITensorInfiniteMPS/Ogcvb/src/infinitecanonicalmps.jl:10
  [3] #103
    @ ~/.julia/packages/ITensorInfiniteMPS/Ogcvb/src/infinitecanonicalmps.jl:17 [inlined]
  [4] macro expansion
    @ ~/.julia/packages/StaticArrays/PUoe1/src/mapreduce.jl:75 [inlined]
  [5] _map
    @ ~/.julia/packages/StaticArrays/PUoe1/src/mapreduce.jl:40 [inlined]
  [6] map
    @ ~/.julia/packages/StaticArrays/PUoe1/src/mapreduce.jl:31 [inlined]
  [7] /
    @ ~/.julia/packages/ITensorInfiniteMPS/Ogcvb/src/infinitecanonicalmps.jl:17 [inlined]
  [8] shift_flux_to_zero(s::Vector{Index{Vector{Pair{QN, Int64}}}}, flux::QN)
    @ ITensorInfiniteMPS ~/.julia/packages/ITensorInfiniteMPS/Ogcvb/src/infinitecanonicalmps.jl:56
  [9] shift_flux_to_zero(s::Vector{Index{Vector{Pair{QN, Int64}}}}, initstate::Function)
    @ ITensorInfiniteMPS ~/.julia/packages/ITensorInfiniteMPS/Ogcvb/src/infinitecanonicalmps.jl:38
 [10] infsiteinds(site_tag::String, n::Int64; translator::Function, initstate::Function, kwargs::Base.Pairs{Symbol, Bool, Tuple{Symbol}, NamedTuple{(:conserve_qns,), Tuple{Bool}}})
    @ ITensorInfiniteMPS ~/.julia/packages/ITensorInfiniteMPS/Ogcvb/src/infinitecanonicalmps.jl:64

If I understand correctly, the idea is that to not accumulate a QN flux passing from on cell to the following, the total flux of the unit cell is set to zero by calling shift_flux_to_zero that reassigns the quantum numbers by removing the average defined as total flux / unit cell size. This works smoothly if the flux of all quantum numbers is a multiple of the unit cell size.

In my previous example the total charge flux = 1 is not a multiple of 2 and the shift_flux_to_zero returns that error.

Maybe to solve the issue one can just catch these cases, multiply every single quantum number by the size of the unit cell, apply the shift to construct the MPS and restore the "physical' QNs by dividing by the unit cell size when computing observables. Would that work?

@mtfishman
Copy link
Member

You may just have to use a larger unit cell for this case (e.g. N=4).

@nbaldelli
Copy link
Contributor Author

In that case I would have an average flux of "Nf" per tensor of 2 / 4 and indeed if I try to set N=4 I get the same error with

ERROR: Dividing ITensors.QNVal(Nf, 2, -1) by 4, the resulting QN value is not an integer

@nbaldelli
Copy link
Contributor Author

Keeping this open until #69 is successfully merged

@mingruyang
Copy link

#69 seems not work for me. After the fix, I still get "Flux not invariant under one unit cell translation, not implemented" error when calling InfMPS.

@mtfishman
Copy link
Member

@mingruyang could you share a minimal example with a stacktrace as a comment in #69?

@mtfishman
Copy link
Member

mtfishman commented Mar 28, 2023

I'll close for now since it should be fixed by #69, which is now merged into main. @nbaldelli, please try it out and report any issues you might come across in a new issue.

@mingruyang, I guess the issue you report is either fixed by #69 or actually related to subspace expansion, which is being tracked and discussed in #75? If you see another issue beyond the one being tracked in #75 please report it as a new issue with a minimal reproducible code example and stacktrace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants