Green's function via method:apply(Jordan-wigner..."Cdagup"|0>)

ITensor Julia Questions
,
1

Hello there,

I was planning to compute greater and lesser Green’s functions for an tight binding model I was intereseted in. After some try and error, I noticed my implementation was lagging the Jordan Wigner string operators (JW) to respect the fermionic statistics. I did so in the following code

using ITensors, ItensorsMPW

function yield_proper_Cdag_(sites, j)


    JW_dagup_j = ITensor[]
    JW_up_j = ITensor[]
    JW_dagdn_j = ITensor[]
    JW_dn_j = ITensor[]

    push!(JW_dagup_j, op(sites, "Cdagup", j)) #creation
    push!(JW_dagdn_j, op(sites, "Cdagdn", j)) #creation

    push!(JW_dn_j, op(sites, "F", j)) #additional JW for creation spin_dn
    for k in 1:(j-1)
        push!(JW_up_j, op(sites, "F", k)) 
        push!(JW_dn_j, op(sites, "F", k)) 
        push!(JW_dagup_j, op(sites, "F", j-k)) #reversed order due to ^dagger
        push!(JW_dagdn_j, op(sites, "F", j-k)) #reversed order due to ^dagger
    end
    push!(JW_dn_j, op(sites, "F", j))  #additional JW for annihilation spin_dn

    push!(JW_up_j, op(sites, "Cup", j))
    push!(JW_dn_j, op(sites, "Cdn", j))

    
    return JW_dagup_j, JW_dagdn_j, JW_up_j, JW_dn_j
end

However, I was told, that there are implementation procedures, which already engage at least the local parity behavior. This would otherwise be fixed by adding an JW-Operator on the actual site, where an “Cdn” is added (that corresbosnds to the two push! statements right before and after my Code example).

My question is therefore:
Does the ITensor implementation already fix the local behaviour, or am I supposed to add the additional ones?

Note:
I am not using the MPO method, since I have to apply a “C(dag)” operator to perform time evolution for my calculation of Greens functions. I am also open for better suggestions to implement this too :).

2

This library should work with non QN conserving operators. Let me know how it goes.

3

Thank you for your responds.
If you are implying to use MPO_new to avoid manual wigner string handling by staying within the MPO enviroment, I have to report, that using this raises the same error as the usual MPO method:

Odd parity fermion terms not supported: OpID{Int64}[OpID{Int64}(2, 2), OpID{Int64}(0, 0)]

Would you expect other behaviour?

4

Oh my mistake. I forgot about the parity restriction. Let me think if I can add support for odd parity operators.

5

If you update ITensorMPOConstruction to the newly released v0.2.2, you should be able to create odd parity MPOs now. Let me know how it goes.

6

hm, the operator gets initialized and as simulations show, they handle the parity properly. However, this and the manual handling of the “Cdagup/dn” operators yield the same behaviour of creating ghost particles, which I would identify as another problem being not related to the Jordan-wigner string handling. I assumed this to be a problem related to the non fermionic operators, which is apparently not.

Since I want to use the ITensor library to run simulations for my thesis, I suppose I will switch to another MPS implementation. I did see too many weird things happening working with this library. I may write an report together with my supervisor soon.

But thank you anyway for your effort.