b3cf64f49c
* Fix control-flow routing in StochasticSwap The `StochasticSwap` pass has some fairly complex hand-offs between different parts of its API, including in recursive calls and the regular hand-off between Python and Rust. In the course of adding the control-flow support, some of these became muddled, and the mapping between different virtual/physical/integer representations got mixed up, resulting in invalid swaps being output in the final circuit. This commit simplifies much of the internal mapping, removing many superfluous `DAGCircuit` creations and compositions. This also removes instances where two layouts were "chained"; this was not well typed (the output of a "virtual -> physical" mapping can't be the input for another "virtual -> physical" mapping), and in general was being used to "undo" some of compositions that were about to be applied. This fixes a tacit assumption in the original code that the initial layout was a trivial layout in the hand-off between Rust and Python. This worked until the recursive call added the `initial_layout` option, making this assumption invalid. Previously, virtual qubit bit instances were converted to integers (to allow them to be passed to Rust) using their indices into the original DAG, but the integer outputs were then converted _back_ using the `initial_layout`. In the old form, this worked anyway, but wasn't logically correct and consequently broke when the assumptions about `initial_layout` changed. For the recursive calls, we now ensure that the inner passes are essentially created with the same internal structure as the outer pass; the passed in `DAGCircuit` uses the same bit instances and same meaning of the virtual qubits as the outer circuit, and the `initial_layout` ensures that the inner passes start with at the same layout as the outer pass. This makes the inner passes more like a logical continuation of the current operation, rather than a completely separate entity that needs to have its virtual qubits remapped. The changes to the tests are twofold: - move the `CheckMap` calls earlier and apply them directly to the `StochasticSwap` output rather than the expected circuit, to improve the quality of failure error messages - use the same physical qubits inside the expected control-flow blocks; the new simpler form of doing the circuit rewriting internally in the pass ensures that the same bit objects are used all the way through the control-flow stack now, rather than creating new instances. * Add tests for stochastic swap valid output This commit adds full path transpile() tests for running with stochastic swap that validates a full path transpilation outputs a valid physical circuit. These tests are purposefully high level to provide some validation that stochastic swap is not creating invalid output by inserting incorrect swaps. It's not meant as a test of valid unitary equivalent output of the full transpilation. Co-authored-by: Jake Lishman <jake.lishman@ibm.com> Co-authored-by: Matthew Treinish <mtreinish@kortar.org> |
||
---|---|---|
.azure | ||
.binder | ||
.cargo | ||
.github | ||
docs | ||
examples | ||
qiskit | ||
releasenotes | ||
src | ||
test | ||
tools | ||
.editorconfig | ||
.git-blame-ignore-revs | ||
.gitignore | ||
.local-spellings | ||
.mailmap | ||
.mergify.yml | ||
.pylintrc | ||
.stestr.conf | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
Cargo.lock | ||
Cargo.toml | ||
LICENSE.txt | ||
MANIFEST.in | ||
Makefile | ||
README.md | ||
azure-pipelines.yml | ||
constraints.txt | ||
pyproject.toml | ||
qiskit_bot.yaml | ||
requirements-dev.txt | ||
requirements.txt | ||
setup.py | ||
tox.ini |
README.md
Qiskit Terra
Qiskit is an open-source framework for working with noisy quantum computers at the level of pulses, circuits, and algorithms.
Qiskit is made up of elements that work together to enable quantum computing. This element is Terra and is the foundation on which the rest of Qiskit is built.
Installation
We encourage installing Qiskit via the pip tool (a python package manager). The following command installs the core Qiskit components, including Terra.
pip install qiskit
Pip will handle all dependencies automatically and you will always install the latest (and well-tested) version.
To install from source, follow the instructions in the documentation.
Creating Your First Quantum Program in Qiskit Terra
Now that Qiskit is installed, it's time to begin working with Terra.
We are ready to try out a quantum circuit example, which is simulated locally using the Qiskit BasicAer element. This is a simple example that makes an entangled state.
$ python
>>> from qiskit import QuantumCircuit, transpile
>>> from qiskit.providers.basicaer import QasmSimulatorPy
>>> qc = QuantumCircuit(2, 2)
>>> qc.h(0)
>>> qc.cx(0, 1)
>>> qc.measure([0,1], [0,1])
>>> backend_sim = QasmSimulatorPy()
>>> transpiled_qc = transpile(qc, backend_sim)
>>> result = backend_sim.run(transpiled_qc).result()
>>> print(result.get_counts(qc))
In this case, the output will be:
{'00': 513, '11': 511}
A script is available here, where we also show how to run the same program on a real quantum computer via IBMQ.
Executing your code on a real quantum chip
You can also use Qiskit to execute your code on a real quantum chip. In order to do so, you need to configure Qiskit for using the credentials in your IBM Q account:
Configure your IBMQ credentials
-
Create an IBM Q > Account if you haven't already done so.
-
Get an API token from the IBM Q website under My Account > API Token.
-
Take your token from step 2, here called
MY_API_TOKEN
, and run:>>> from qiskit import IBMQ >>> IBMQ.save_account('MY_API_TOKEN')
After calling IBMQ.save_account()
, your credentials will be stored on disk.
Once they are stored, at any point in the future you can load and use them
in your program simply via:
>>> from qiskit import IBMQ
>>> IBMQ.load_account()
Those who do not want to save their credentials to disk should use instead:
>>> from qiskit import IBMQ
>>> IBMQ.enable_account('MY_API_TOKEN')
and the token will only be active for the session. For examples using Terra with real devices we have provided a set of examples in examples/python and we suggest starting with using_qiskit_terra_level_0.py and working up in the levels.
Contribution Guidelines
If you'd like to contribute to Qiskit Terra, please take a look at our contribution guidelines. This project adheres to Qiskit's code of conduct. By participating, you are expected to uphold this code.
We use GitHub issues for tracking requests and bugs. Please join the Qiskit Slack community and use our Qiskit Slack channel for discussion and simple questions. For questions that are more suited for a forum we use the Qiskit tag in the Stack Exchange.
Next Steps
Now you're set up and ready to check out some of the other examples from our Qiskit Tutorials repository.
Authors and Citation
Qiskit Terra is the work of many people who contribute to the project at different levels. If you use Qiskit, please cite as per the included BibTeX file.
Changelog and Release Notes
The changelog for a particular release is dynamically generated and gets
written to the release page on Github for each release. For example, you can
find the page for the 0.9.0
release here:
https://github.com/Qiskit/qiskit-terra/releases/tag/0.9.0
The changelog for the current release can be found in the releases tab: The changelog provides a quick overview of notable changes for a given release.
Additionally, as part of each release detailed release notes are written to
document in detail what has changed as part of a release. This includes any
documentation on potential breaking changes on upgrade and new features.
For example, You can find the release notes for the 0.9.0
release in the
Qiskit documentation here:
https://qiskit.org/documentation/release_notes.html#terra-0-9