API documentation¶
Module for conversion between Rigetti pyQuil and tket primitives.
- class pytket.extensions.pyquil.ForestBackend(qc)[source]¶
Interface to a Rigetti device.
- classmethod available_devices(**kwargs)[source]¶
See
pytket.backends.Backend.available_devices().Supported kwargs: :rtype:
List[BackendInfo]qpus (bool, default True): whether to include QPUs in the list
qvms (bool, default False): whether to include QVMs in the list
timeout (float, default 10.0) time limit for request, in seconds
client_configuration (optional qcs_sdk.QCSClient, defaut None): optional client configuration; if None, a default one will be loaded.
- circuit_status(handle)[source]¶
Return a CircuitStatus reporting the status of the circuit execution corresponding to the ResultHandle.
This will throw an PyQuilJobStatusUnavailable exception if the results have not been retrieved yet, as pyQuil does not currently support asynchronous job status queries.
- Parameters:
handle (ResultHandle) – The handle to the submitted job.
- Return type:
- Returns:
The status of the submitted job.
- Raises:
PyQuilJobStatusUnavailable – Cannot retrieve job status.
CircuitNotRunError – The handle does not correspond to a valid job.
- default_compilation_pass(optimisation_level=2)[source]¶
A suggested compilation pass that will will, if possible, produce an equivalent circuit suitable for running on this backend.
At a minimum it will ensure that compatible gates are used and that all two- qubit interactions are compatible with the backend’s qubit architecture. At higher optimisation levels, further optimisations may be applied.
This is a an abstract method which is implemented in the backend itself, and so is tailored to the backend’s requirements.
- Parameters:
optimisation_level (int, optional) –
The level of optimisation to perform during compilation.
Level 0 does the minimum required to solves the device constraints, without any optimisation.
Level 1 additionally performs some light optimisations.
Level 2 (the default) adds more computationally intensive optimisations that should give the best results from execution.
- Returns:
Compilation pass guaranteeing required predicates.
- Return type:
BasePass
- get_result(handle, **kwargs)[source]¶
See
pytket.backends.Backend.get_result(). Supported kwargs: none.- Return type:
- process_circuits(circuits, n_shots=None, valid_check=True, **kwargs)[source]¶
See
pytket.backends.Backend.process_circuits().Supported kwargs: :rtype:
List[ResultHandle]seed
postprocess: apply end-of-circuit simplifications and classical postprocessing to improve fidelity of results (bool, default False)
simplify_initial: apply the pytket
SimplifyInitialpass to improve fidelity of results assuming all qubits initialized to zero (bool, default False)
- rebase_pass()[source]¶
A single compilation pass that when run converts all gates in a Circuit to an OpType supported by the Backend (ignoring architecture constraints).
- Returns:
Compilation pass that converts gates to primitives supported by Backend.
- Return type:
BasePass
- property backend_info: BackendInfo¶
Retrieve all Backend properties in a BackendInfo object, including device architecture, supported gate set, gate errors and other hardware-specific information.
- Returns:
The BackendInfo describing this backend if it exists.
- Return type:
Optional[BackendInfo]
- class pytket.extensions.pyquil.ForestStateBackend[source]¶
State based interface to a Rigetti device.
- circuit_status(handle)[source]¶
Return a CircuitStatus reporting the status of the circuit execution corresponding to the ResultHandle
- Return type:
- default_compilation_pass(optimisation_level=2)[source]¶
A suggested compilation pass that will will, if possible, produce an equivalent circuit suitable for running on this backend.
At a minimum it will ensure that compatible gates are used and that all two- qubit interactions are compatible with the backend’s qubit architecture. At higher optimisation levels, further optimisations may be applied.
This is a an abstract method which is implemented in the backend itself, and so is tailored to the backend’s requirements.
- Parameters:
optimisation_level (int, optional) –
The level of optimisation to perform during compilation.
Level 0 does the minimum required to solves the device constraints, without any optimisation.
Level 1 additionally performs some light optimisations.
Level 2 (the default) adds more computationally intensive optimisations that should give the best results from execution.
- Returns:
Compilation pass guaranteeing required predicates.
- Return type:
BasePass
- get_operator_expectation_value(state_circuit, operator)[source]¶
Calculates the expectation value of the given circuit with respect to the operator using the built-in QVM functionality
- Parameters:
state_circuit (Circuit) – Circuit that generates the desired state \(\left|\psi\right>\).
operator (QubitPauliOperator) – Operator \(H\).
- Returns:
\(\left<\psi | H | \psi \right>\)
- Return type:
- get_pauli_expectation_value(state_circuit, pauli)[source]¶
Calculates the expectation value of the given circuit using the built-in QVM functionality
- Parameters:
state_circuit (Circuit) – Circuit that generates the desired state \(\left|\psi\right>\).
pauli (QubitPauliString) – Pauli operator
- Returns:
\(\left<\psi | P | \psi \right>\)
- Return type:
- process_circuits(circuits, n_shots=None, valid_check=True, **kwargs)[source]¶
Submit circuits to the backend for running. The results will be stored in the backend’s result cache to be retrieved by the corresponding get_<data> method.
If the postprocess keyword argument is set to True, and the backend supports the feature (see
supports_contextual_optimisation()), then contextual optimisatioons are applied before running the circuit and retrieved results will have any necessary classical postprocessing applied. This is not enabled by default.Use keyword arguments to specify parameters to be used in submitting circuits See specific Backend derived class for available parameters, from the following list:
seed: RNG seed for simulators
postprocess: if True, apply contextual optimisations
Note: If a backend is reused many times, the in-memory results cache grows indefinitely. Therefore, when processing many circuits on a statevector or unitary backend (whose results may occupy significant amounts of memory), it is advisable to run
Backend.empty_cache()after each result is retrieved.- Parameters:
circuits (Sequence[Circuit]) – Circuits to process on the backend.
n_shots (Optional[Union[int, Iterable[int]], optional) – Number of shots to run per circuit. Optionally, this can be a list of shots specifying the number of shots for each circuit separately. None is to be used for state/unitary simulators. Defaults to None.
valid_check (bool, optional) – Explicitly check that all circuits satisfy all required predicates to run on the backend. Defaults to True
- Returns:
Handles to results for each input circuit, as an interable in the same order as the circuits.
- Return type:
List[ResultHandle]