Functionality to time evolve `WindowMPS`

[DaanMaertens]

Adds timestep/timestep! functions to time evolve a WindowMPS with a window Hamiltonian. WindowMPS now has two extra type parameters to indicate whether the left and/or right infinite part are variable with regards to time evolution. When both are fixed the time evolution is equivalent to the one already available for WindowMPS in MPSKit.

A new struct WindowEnvhas been added that keeps track of the environments for a WindowMPS. Whenever leftenv/rightenv is called, there is an automated check that the left and rightstart of the finite part are correct (i.e. from the infinite part).

[Gertian]

@DaanMaertens So what's the current status of this ? Is it possible to time evolve a finite window of perturbed GS inside a bath of GS. Does the current implementation correctly account for the phases picked up at the boundary or is this what you're trying to fix now ?

[DaanMaertens]

@Gertian Time evolving a finite window in a bath of the groundstate is already possible in MPSKit. This PR aims to extend the time evolution so that the infinite states can be evolved as well. As long as the tensors at the boundary of the finite window are the same as the ones from the infinite part (i.e. the dynamics have not yet reached the boundary of the finite window) there should not be any problem with phases.

[lkdvos]

@Gertian Time evolving a finite window in a bath of the groundstate is already possible in MPSKit. This PR aims to extend the time evolution so that the infinite states can be evolved as well. As long as the tensors at the boundary of the finite window are the same as the ones from the infinite part (i.e. the dynamics have not yet reached the boundary of the finite window) there should not be any problem with phases.

Wait, are you sure about this? Time evolving the groundstate should still give a phase factor, and I don't think the current implementation adds this?

[Gertian]

@lkdvos @DaanMaertens I remember that I was playing around with this years ago and that it was not entirely trivial to get these phases to work (even though it should be since you know exactly which tensor will pick up which phase, i.e. I was probably being a bit of a nooby...)

Either way as Lukas said, surely there will be phases since even an exact eigenstate evolves as |psi> -> exp( i E t) |psi> and this should be accounted for. If not at least there should be a good reason why not to do it...

For example, I could see that it drops out in all expectation values that one might compute but I'm not sure that this is enough.

[DaanMaertens]

I would think that it drops out everywhere (in expectation values, in effective hamiltonians like ∂∂AC), but I could be mistaken.

[lkdvos]

I would think that it drops out everywhere (in expectation values, in effective hamiltonians like ∂∂AC), but I could be mistaken.

It definitely does not drop out if you do things like lochsmidt echo, where you take overlaps at different times

[lkdvos]

Also Daan, van you run the formatter so we don't hit the GitHub limit ?

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 93.02326% with 18 lines in your changes are missing coverage. Please review.

Project coverage is 84.49%. Comparing base (f48a5ca) to head (142e409).

Files	Patch %	Lines
src/states/windowmps.jl	85.36%	6 Missing :warning:
src/environments/windowenv.jl	91.66%	4 Missing :warning:
src/utility/timedependence.jl	0.00%	4 Missing :warning:
src/states/window.jl	62.50%	3 Missing :warning:
src/algorithms/expval.jl	94.44%	1 Missing :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #122 +/- ## ========================================== + Coverage 82.79% 84.49% +1.69% ========================================== Files 72 75 +3 Lines 4308 4430 +122 ========================================== + Hits 3567 3743 +176 + Misses 741 687 -54 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.