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:
Evolver
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().
conjugate
abstract property
Type: bool
Returns whether this time-evolver instance acts on the right-hand side.
evolved_time
abstract property
Type: float
Returns the current evolution time.
step
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
State
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┄┄┄┄┄┄┄┄┄┺━━━━┹┄┄┄┄┄┄┄┄overlap
abstract overlap(initial_state)
Compute the overlap of this state with the provided initial state.
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