Applying an operator to a WindowMPS

[ujjwalbasumatary]

Hi,

I am new to MPSKit and Julia in general and I am having great fun with your package. Thanks for creating and maintaining it. I wanted to ask about an issue that I have not been able to resolve for some time and I am unsure if what I am doing is the right thing.

I want to apply an operator to a single site in a WindowMPS. This operator need not be unitary therefore it can mess with the gauge. Since we are not allowed to modify AL or AR, I move the center to the site where I want to apply the operator and apply it there as follows

    # create a WindowMPS object from InfiniteMPS
    ψ_window = WindowMPS(ψ_gs, L)

    # apply the field operator
    mid = L ÷ 2
    @tensor excite_left[a, b; c] := ϕ[b, l] * ψ_window.AC[mid - offset][a, l; c]
    @tensor excite_right[a, b; c] := ϕ[b, l] * ψ_window.AC[mid + offset][a, l; c]
    ψ_window.AC[mid - offset] = excite_left
    ψ_window.AC[mid + offset] = excite_right

    # normalize after applying the excitations
    normalize!(ψ_window)

Doing this is leading to different physics that I expect. For example the expectation value of ϕ is not the same at the two sites. Could you let me know if there is a better way to do this?

Thanks in advance.

I am using
Julia v1.12.1
MPSKit v0.13.8
TensorKit v0.15.3

[lkdvos]

Hi, thank you for reaching out and the kind words about the package!

After having a quick look here, I think the problem might be resolved by simply changing the order of operations. In particular, I would guess that the following code reproduces the results you want:

# create a WindowMPS object from InfiniteMPS
ψ_window = WindowMPS(ψ_gs, L)

# apply the left field operator
mid = L ÷ 2
@tensor excite_left[a, b; c] := ϕ[b, l] * ψ_window.AC[mid - offset][a, l; c]
ψ_window.AC[mid - offset] = excite_left

# apply the right field operator
@tensor excite_right[a, b; c] := ϕ[b, l] * ψ_window.AC[mid + offset][a, l; c]
ψ_window.AC[mid + offset] = excite_right

# normalize after applying the excitations
normalize!(ψ_window)

The reason for this is that getting/setting the AC field is actually changing where the center is located behind the scenes, silently regauging the state such that you can apply the operator.
However, the center can't really be at two places at the same time, so by first accessing the left AC, then the right AC, and then updating the left AC, we created a state where the right AC we previously accessed is no longer synchronized, therefore producing wrong results.
Another way of thinking about this is that changing the left AC has a non-trivial effect on the right AC, so we have to make local updates sequentially, rather than "in parallel".

I have to admit that I did not check my results though, so please do let me know if anything still goes wrong and I will gladly take a closer look.

[ujjwalbasumatary]

Hey. Thanks for your reply.

What you said is correct. However, the issue I was encountering had been a Physics one as well. It has now been resolved. Before closing this ticket, could you let me know if is the only way to apply an operator to an MPS (other than just multiplying the MPO form of the operator in question)? Or would you do this operation in a different way?

Thanks again for your help.

[lkdvos]

Of course!

I think it depends slightly on the exact context you are working in, so let me try and cover some options and give the pros and cons:

If you are only interested in applying these operators sporadically, i.e. your workflow is not dominated by applications, I think the approach described here is perfectly fine. It won't necessarily be the absolute fastest, but it is the most general-purpose and simple.

If you have a case where you would be applying multiple onsite operators quite often, and you find that this starts to dominate the runtime (always profile first though!), there are some additional tricks you could play to speed this up.
The main idea is that if you aren't truncating the application, as is the case for onsite operators, in principle you don't have to be in the center gauge to apply the operators.
So, a workflow that involves many onsite applications might actually benefit from first extracting a consistent set of MPS tensors, then applying all of the onsite gates, and only then regauging.
Naively, you could just do something like [AL[1:end-1] AC[end]], and afterwards create a new MPS from the resulting tensors, but if you really care about maximal performance you probably want to start from something like [AL[1:center-1], AC[center], AR[center+1:end]], and try to reason about which tensors are still gauged after the application.
This would presumably be slightly more efficient, but a bit more work, since there are many edge cases to properly handle here.

As soon as longer range operators are involved, typically also some truncation is required to avoid exponential growth in the bond dimension. In that case the gauging is no longer optional and is really required for the truncation to be "optimal", so I can't immediately think of many better ways of achieving this.

If this isn't satisfactory or really does become a bottleneck for you, I'm happy to brainstorm a bit more about this but it would require a little more context for me to be able to provide additional insights.

[ujjwalbasumatary]

That answers my question, thank you! I am closing this thread.