Skip to content

Computing observables

All emulators (backends) share a convenient way to define observables to be tracked during the simulation, as defined in pulser. The default available observables are listed below, together with examples for how to create them.

Example

How to use created observables to obtain results from an emulation is shown in the example notebooks for emu-sv and for emu-mps.

Warning

Please, take into account that, for performance reasons, individual emulators may overwrite the default implementation in pulser.

StateResult

Stores the quantum state at the evaluation times.

See Pulser documentation.

BitStrings

Stores bitstrings sampled from the state at the evaluation times.

See Pulser documentation.

Fidelity

Stores the fidelity with a pure state at the evaluation times.

See Pulser documentation.

Expectation

Stores the expectation of the given operator on the current state.

See Pulser documentation.

CorrelationMatrix

Stores the correlation matrix for the current state.

See Pulser documentation.

Occupation

Stores the occupation number of an eigenstate on each qudit.

See Pulser documentation.

Energy

Stores the energy of the system at the evaluation times.

See Pulser documentation.

EnergyVariance

Stores the variance of the Hamiltonian at the evaluation times.

See Pulser documentation.

SecondMomentOfEnergy

Stores the expectation value of H(t)² at the evaluation times.

See Pulser documentation.

Defining your own observable

Most commonly desired information can be obtained using the classes documented above

  • Arbitrary observables can be measured using Expectation(operator, ...) which requires providing a valid operator for the backend in use. Please check the tutorial for an example of an implementation.
  • Fidelities on arbitrary states can be computed using Fidelity(state, ...) which requires providing a valid state for the backend in use.
  • Information about the time dependent states and Hamiltonians is available via StateResult, Energy etc.

If additional behavior is desired (e.g. the kurtosis of the energy, or entanglement entropy), the user can subclass the Observable class to implement any behavior only depending on the parameters of its apply method (see here). Computation of the entanglement entropy, for example, cannot be done in a backend-independent manner, so it is unlikely to ever make it into the above default list. However, we do intend to define backend-specific callbacks in the future, which would belong to the API of a specific backend. Callbacks that can be implemented in a backend-independent manner can be added to the above list upon popular request.

Observables on remote backend

In heavy simulations, the entire quantum state can easily occupy few GBs while operators, might not even fit into the available memory. For this reason, only for remote backend execution on pasaqal-cloud, and when defining a state/operator :

Info

  • state in Fidelity(state, ...), besides being a proper state for the backend, must also be defined with its from_state_amplitudes() class method.
  • operator in Expectation(operator, ...), besides being a proper operator for the backend, must also be defined with its from_operator_repr() class method.

The methods above requires the user to locally install a backend to instantiate a state or an operator class. It might not be desirable in all cases since, for example, pulser-simulation will install qutip, while emu-mps/sv will install torch. To avoid such dependency, the classes StateRepr, OperatorRepr just implements the abstract representation of such objects.

Tip

If the full backend is not needed, state/operator in the observable can just be defined with their abstract representation

  • StateRepr.from_state_amplitudes()
  • OperatorRepr.from_operator_repr()

Moreover, the observable

Failure

StateResult is not supported in pasaqal-cloud remote backend emulators.