# four point correlation at same site

**URL:** <https://itensor.discourse.group/t/four-point-correlation-at-same-site/1007>\
**Category:** ITensor Julia Questions\
**Tags:** julia, mpo\
**Created:** [July 9, 2023, 2:04am UTC](https://itensor.discourse.group/t/four-point-correlation-at-same-site/1007 "2023-07-09T02:04:07Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![yang1](https://yyz2.discourse-cdn.com/free1/user_avatar/itensor.discourse.group/yang1/32/274_2.png) [@yang1](https://itensor.discourse.group/u/yang1)\
**Post date:** [July 9, 2023, 2:04am UTC](https://itensor.discourse.group/t/four-point-correlation-at-same-site/1007/1 "2023-07-09T02:04:07Z")

</div>

hello, I think I meet some troubles at four point MPO, this is a simple example code

```julia
using ITensors

let
    L = 4
    n_max = 2
    Np = 2
    sites = siteinds("Boson", L; dim=n_max, conserve_qns=true)
    state = ["0", "1", "0", "1"]
    psi = MPS(sites, state)
    sites = siteinds(psi)
    os = OpSum()
    os += "Adag", 1, "A", 2, "Adag", 1, "A", 2
    @show os
    op = MPO(os, sites)
    corr = inner(psi', op, psi)
    @show corr
end

```

for n\_max \> 2, it works well  
for n\_max = 2, os is not at same site, for example, os += “Adag”, 1, “A”, 2, “Adag”, 2, “A”, 3, it works well  
but for n\_max = 2, os is at same site, for example, 1, 2, 1, 2, it can not work and throw a error:  
ERROR: LoadError: Could not find block of QNIndex with matching QN  
how can I repair it? thanks

---

<div class="post-metadata">

**Author:** ![miles](https://yyz2.discourse-cdn.com/free1/user_avatar/itensor.discourse.group/miles/32/6_2.png) [@miles](https://itensor.discourse.group/u/miles)\
**Post date:** [July 9, 2023, 5:30pm UTC](https://itensor.discourse.group/t/four-point-correlation-at-same-site/1007/2 "2023-07-09T17:30:43Z")

</div>

I think, for this kind of thing, it’s best to keep the site indices (such as 1,2,1,2) from matching each other and then work out the cases where they do match by hand on paper, then write them as a separate piece of code.

I’m fairly sure the reason for the error you are getting is that the operator is turning out to be zero (because a^\dagger\_i a^\dagger\_i = 0 for dimension 2 bosons), but instead of the error reporting it as zero, it is saying that there are no blocks (i.e. no non-zero blocks, meaning the only blocks are zero).

---

<div class="post-metadata">

**Author:** ![yang1](https://yyz2.discourse-cdn.com/free1/user_avatar/itensor.discourse.group/yang1/32/274_2.png) [@yang1](https://itensor.discourse.group/u/yang1)\
**Post date:** [July 10, 2023, 12:47am UTC](https://itensor.discourse.group/t/four-point-correlation-at-same-site/1007/3 "2023-07-10T00:47:24Z")

</div>

> [@miles](#):
>
> I’m fairly sure the reason for the error you are getting is that the operator is turning out to be zero (because ai†ai†=0a^\dagger\_i a^\dagger\_i = 0ai†​ai†​=0 for dimension 2 bosons), but instead of the error reporting it as zero, it is saying that there are no blocks (i.e. no non-zero blocks, meaning the only blocks are zero).

Thanks , by your reply I’m absolutely sure where my mistake is, and I solved my problem by convert the QN psi to dense(psi)., it works well.

---

<div class="post-metadata">

**Author:** ![mtfishman](https://yyz2.discourse-cdn.com/free1/user_avatar/itensor.discourse.group/mtfishman/32/11_2.png) [@mtfishman](https://itensor.discourse.group/u/mtfishman)\
**Post date:** [July 10, 2023, 12:45pm UTC](https://itensor.discourse.group/t/four-point-correlation-at-same-site/1007/4 "2023-07-10T12:45:14Z")

</div>

@miles should we try to catch this kind of thing internally? I think it’s nice if it “just works” even if it is zero.

---

<div class="post-metadata">

**Author:** ![miles](https://yyz2.discourse-cdn.com/free1/user_avatar/itensor.discourse.group/miles/32/6_2.png) [@miles](https://itensor.discourse.group/u/miles)\
**Post date:** [July 10, 2023, 1:41pm UTC](https://itensor.discourse.group/t/four-point-correlation-at-same-site/1007/5 "2023-07-10T13:41:37Z")

</div>

Good point – I’ll look into it and create an issue. Glancing at the code just now (which is inside the qn\_svdMPO OpSum backend), it’s a somewhat tricky thing because it may require distinguishing inputs which give zero, as above, because they go outside the Hilbert space altogether, from inputs which do not respect the total QN flux of the operator, which should be treated as an erroneous input.