Backends (qiskit_addon_mpf.backends)

Optional backends for the DynamicMPF algorithm.

Availability

Whether a certain backend can be used depends on the availability of the underlying tensor network library. This can easily be asserted at runtime using the following indicators:

HAS_QUIMB

Indicates whether the optional quimb dependency is installed.

HAS_TENPY

Indicates whether the optional tenpy dependency is installed.

Backends

Depending on the availability (see above), the following backends are available:

quimb_tebd	A quimb-based TEBD backend.
quimb_layers	A layer-wise time-evolution backend using quimb.
quimb_circuit	A circuit-based time-evolution backend using quimb.
tenpy_tebd	A tenpy-based TEBD backend.
tenpy_layers	A layer-wise time-evolution backend using tenpy.

Interface

The interface implemented by any one of these optional backends is made up of the following classes:

class Evolver

Bases: ABC

The interface for the time-evolution algorithms used within DynamicMPF.

This time-evolution interface is used by the DynamicMPF.lhs and DynamicMPF.rhs and should time-evolve a State object under its hood. The exact mechanism of the algorithm is described in more detail in DynamicMPF, State, and setup_dynamic_lse().

abstract property conjugate: bool

Returns whether this time-evolver instance acts on the right-hand side.

abstract property evolved_time: float

Returns the current evolution time.

abstract step()

Perform a single time step of this time-evolution algorithm.

This should act on the internally referenced State object (for which no name is prescribed by this interface). Whether this time-evolution algorithm instance should evolve the State from the left- or right-hand side, depends on the value of conjugate.

Return type:

None

class State

Bases: ABC

The interface for the DynamicMPF.evolution_state.

This time-evolution state is shared between the LHS and RHS Evolver instances of the DynamicMPF instance. In most cases where a concrete backend implementing this interface is based on tensor networks, this state will be a matrix product operator (MPO). This is because most time-evolution algorithms would normally evolve a matrix product state (MPS) as shown pictorially below, where time evolution blocks (U#) are successively applied to a 1-dimensional MPS (S#). Here, the tensor network grows towards the right as time goes on.

MPS Evolution

S0┄┄┲━━━━┱┄┄┄┄┄┄┄┄┲━━━━┱┄
│   ┃ U1 ┃        ┃ U5 ┃
S1┄┄┺━━━━┹┄┲━━━━┱┄┺━━━━┹┄
│          ┃ U3 ┃
S2┄┄┲━━━━┱┄┺━━━━┹┄┲━━━━┱┄ ...
│   ┃ U2 ┃        ┃ U6 ┃
S3┄┄┺━━━━┹┄┲━━━━┱┄┺━━━━┹┄
│          ┃ U4 ┃
S4┄┄┄┄┄┄┄┄┄┺━━━━┹┄┄┄┄┄┄┄┄

However, in our case, we want two time-evolution engines to share a single state. In order to achieve that, we can have one of them evolve the state from the right (just as before, U#), but have the second one evolve the state from the left (V#). This requires the state to also have bonds going of in that direction, rendering it a 2-dimensional MPO (M#) rather than the 1-dimensional MPS from before.

MPO Evolution

    ┄┲━━━━┱┄┄┄┄┄┄┄┄┲━━━━┱┄┄M0┄┄┲━━━━┱┄┄┄┄┄┄┄┄┲━━━━┱┄
     ┃ V5 ┃        ┃ V1 ┃  │   ┃ U1 ┃        ┃ U5 ┃
    ┄┺━━━━┹┄┲━━━━┱┄┺━━━━┹┄┄M1┄┄┺━━━━┹┄┲━━━━┱┄┺━━━━┹┄
            ┃ V3 ┃         │          ┃ U3 ┃
... ┄┲━━━━┱┄┺━━━━┹┄┲━━━━┱┄┄M2┄┄┲━━━━┱┄┺━━━━┹┄┲━━━━┱┄ ...
     ┃ V6 ┃        ┃ V2 ┃  │   ┃ U2 ┃        ┃ U6 ┃
    ┄┺━━━━┹┄┲━━━━┱┄┺━━━━┹┄┄M3┄┄┺━━━━┹┄┲━━━━┱┄┺━━━━┹┄
            ┃ V4 ┃         │          ┃ U4 ┃
    ┄┄┄┄┄┄┄┄┺━━━━┹┄┄┄┄┄┄┄┄┄M4┄┄┄┄┄┄┄┄┄┺━━━━┹┄┄┄┄┄┄┄┄

abstract overlap(initial_state)

Compute the overlap of this state with the provided initial state.

Warning

A concrete implementation of this method should raise a TypeError if the provided initial_state object is not supported by the implementing backend.

Parameters:

initial_state (Any) – the initial state with which to compute the overlap.

Raises:

TypeError – if the provided initial state has an incompatible type.

Returns:

The overlap of this state with the provided one.

Return type:

complex