You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Description
This PR aims to provide python bindings for the state preparation for
neutral atoms part of qmap.
## Checklist:
<!---
This checklist serves as a reminder of a couple of things that ensure
your pull request will be merged swiftly.
-->
- [x] The pull request only contains commits that are related to it.
- [x] I have added appropriate tests and documentation.
- [x] I have made sure that all CI jobs on GitHub pass.
- [x] The pull request introduces no new warnings and follows the
project's style guidelines.
Copy file name to clipboardExpand all lines: docs/DevelopmentGuide.rst
+25-50Lines changed: 25 additions & 50 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -179,27 +179,23 @@ Furthermore, they provide a command to automatically format your code according
179
179
Working on the Python module
180
180
############################
181
181
182
-
`Pybind11 <https://pybind11.readthedocs.io/>`_ is used for providing bindings of the C++ core library to Python.
182
+
`Pybind11 <https://pybind11.readthedocs.io/en/stable/>`_ is used for providing bindings of the C++ core library to Python.
183
183
This allows to keep the performance critical parts of the code in C++ while providing a convenient interface for Python users.
184
-
All of the bindings code as well as the Python module itself is contained in the :code:`mqt/qmap` directory.
184
+
All of the bindings code is contained in the :code:`src/python` directory.
185
+
The Python package itself lives in the :code:`src/mqt/qmap` directory.
185
186
186
187
Building the Python module
187
188
--------------------------
188
189
189
-
The recommended way of building the Python module is to perform an editable install using `pip <https://pip.pypa.io/en/stable/>`_.
190
+
It is usually most efficient to install the build dependencies in your environment once and use the following command that avoids a costly creation of a new virtual environment at every compilation:
The :code:`--editable` flag ensures that changes in the Python code are instantly available without re-running the command.
196
-
The :code:`[dev]` extra makes sure that all dependencies for running the Python tests and building the documentation are available.
197
-
198
-
.. note::
199
-
When using the :code:`zsh` shell it might be necessary to add double quotes around the :code:`.[dev]` part of the command.
200
-
201
-
.. warning::
202
-
Do not forget to run the above command again after any changes to the C++ core library or bindings to make the changes available in the Python module.
197
+
You may optionally add :code:`-Ceditable.rebuild=true` to auto-rebuild when the package is imported.
198
+
Otherwise, you need to re-run the above after editing C++ files.
203
199
204
200
Running Python Tests
205
201
--------------------
@@ -210,15 +206,9 @@ A :code:`nox` session is provided to conveniently run the Python tests.
210
206
211
207
.. code-block:: console
212
208
213
-
(venv) $ nox -rs tests
209
+
(venv) $ nox -s tests
214
210
215
211
This installs all dependencies for running the tests in an isolated environment, builds the Python package, and then runs the tests.
216
-
The :code:`-r` flag ensures that the environment is reused for subsequent runs.
217
-
To speed up subsequent runs, the installation step can be skipped by adding the :code:`skip-install` flag.
218
-
219
-
.. code-block:: console
220
-
221
-
(venv) $ nox -rs tests -- skip-install
222
212
223
213
.. note::
224
214
If you don't want to use :code:`nox`, you can also run the tests directly using :code:`pytest`.
@@ -233,36 +223,33 @@ Python Code Formatting and Linting
233
223
The Python code is formatted and linted using a collection of `pre-commit hooks <https://pre-commit.com/>`_.
234
224
This collection includes:
235
225
236
-
- `black <https://black.readthedocs.io/en/stable/>`_ -- a code formatter that automatically formats Python code according to the `PEP 8 style guide <https://www.python.org/dev/peps/pep-0008/>`_
237
-
- `flake8 <https://flake8.pycqa.org/en/latest/>`_ -- a linter that checks for common mistakes in Python code
238
-
- `isort <https://pycqa.github.io/isort/>`_ -- a tool that automatically sorts Python imports according to the `PEP 8 style guide <https://www.python.org/dev/peps/pep-0008/>`_
239
-
- `mypy <http://mypy-lang.org/>`_ -- a static type checker for Python code
240
-
- `pyupgrade <https://github.com/asottile/pyupgrade>`_ -- a tool that automatically upgrades Python syntax to a newer version
226
+
- `ruff <https://docs.astral.sh/ruff/>`_ -- an extremely fast Python linter and formatter, written in Rust.
227
+
- `mypy <https://mypy-lang.org/>`_ -- a static type checker for Python code
241
228
242
229
There are two ways of using these hooks:
243
230
244
-
- You can install the hooks manually by running :code:`pre-commit install` in the project root directory.
231
+
- You can install the hooks manually by running
232
+
233
+
.. code-block:: console
234
+
235
+
(venv) $ pre-commit install
236
+
237
+
in the project root directory.
245
238
This will install the hooks in the :code:`.git/hooks` directory of the repository.
246
239
The hooks will then be executed automatically when committing changes.
240
+
247
241
- You can use the :code:`nox` session :code:`lint` to run the hooks manually.
248
242
249
243
.. code-block:: console
250
244
251
-
(venv) $ nox -rs lint
245
+
(venv) $ nox -s lint
252
246
253
247
.. note::
254
248
If you don't want to use :code:`nox`, you can also run the hooks directly using :code:`pre-commit`.
255
249
256
-
.. code-block:: console
257
-
258
-
(venv) $ pre-commit run --all-files
259
-
260
-
In addition to the pre-commit hooks, the Python code is also type checked by `mypy <http://mypy-lang.org/>`_.
261
-
This is done by the :code:`nox` session :code:`mypy`.
262
-
263
250
.. code-block:: console
264
251
265
-
(venv) $ nox -rs mypy
252
+
(venv) $ pre-commit run --all-files
266
253
267
254
Working on the Documentation
268
255
############################
@@ -273,31 +260,19 @@ You can build the documentation using the :code:`nox` session :code:`docs`.
273
260
274
261
.. code-block:: console
275
262
276
-
(venv) $ nox -rs docs
263
+
(venv) $ nox -s docs
277
264
278
265
.. note::
279
266
In order to properly build the jupyter notebooks in the documentation, you need to have :code:`pandoc` installed. See `the pandoc documentation <https://pandoc.org/installing.html>`_ for installation instructions.
280
267
281
268
This will install all dependencies for building the documentation in an isolated environment, build the Python package, and then build the documentation.
282
-
The session also provides a convenient option to automatically serve the docs on a local web server. Running
283
-
284
-
.. code-block:: console
285
-
286
-
(venv) $ nox -rs docs -- serve
287
-
288
-
will start a local web server on port 8000 and provide a link to open the documentation in your browser.
289
-
290
-
To build the documentation without (re-)installing the Python package, you can use the :code:`skip-install` flag.
291
-
292
-
.. code-block:: console
293
-
294
-
(venv) $ nox -rs docs -- skip-install
269
+
Additionally, the session will automatically serve the docs on a local web server.
295
270
296
271
.. note::
297
272
If you don't want to use :code:`nox`, you can also build the documentation directly using :code:`sphinx-build`.
298
273
299
274
.. code-block:: console
300
275
301
-
(venv) $ sphinx-build -b html docs/source docs/build
276
+
(venv) $ sphinx-build -b html docs/ docs/_build
302
277
303
-
The docs can then be found in the :code:`docs/build` directory.
278
+
The docs can then be found in the :code:`docs/_build` directory.
"<style>.widget-subarea{display:none;} /*hide widgets as they do not work with sphinx*/</style>\n",
8
+
"\n",
9
+
"# Neutral Atom Logical State Preparation\n",
10
+
"\n",
11
+
"All quantum computers are prone to errors.\n",
12
+
"This is the motivation of employing error correction during a quantum computation.\n",
13
+
"To this end, a (logical) qubit on the algorithmic level is encoded into a shared and highly entangled state of multiple physical qubits.\n",
14
+
"Before the actual computation can start, those physical qubits need to be prepared in a state that represents the logical zero state.\n",
15
+
"\n",
16
+
"For that, we provide tool that takes a state preparation circuit and generates an optimal sequence of operations tailored to the zoned neutral atom architecture.\n",
17
+
"Thereby, the circuit consists of one initial layer of Hadamard gates on all qubits that initialize the physical qubits in the plus state.\n",
18
+
"Those are followed by a set of entangling (CZ) gates that generate a so-called graph state.\n",
19
+
"The final logical state is achieved by applying additional Hadamard gates on selected qubits.\n",
20
+
"\n",
21
+
"Below we demonstrate how the optimal schedule can be retrieved for the Steane-code, the smallest 2D color code.\n",
22
+
"First, we create the state preparation circuit for the Steane-code as a `qiskit.QuantumCircuit`."
23
+
]
24
+
},
25
+
{
26
+
"cell_type": "code",
27
+
"execution_count": null,
28
+
"metadata": {},
29
+
"outputs": [],
30
+
"source": [
31
+
"from qiskit import QuantumCircuit\n",
32
+
"\n",
33
+
"qc = QuantumCircuit(7)\n",
34
+
"qc.h(range(7))\n",
35
+
"qc.cz(0, 3)\n",
36
+
"qc.cz(0, 4)\n",
37
+
"qc.cz(1, 2)\n",
38
+
"qc.cz(1, 5)\n",
39
+
"qc.cz(1, 6)\n",
40
+
"qc.cz(2, 3)\n",
41
+
"qc.cz(2, 4)\n",
42
+
"qc.cz(3, 5)\n",
43
+
"qc.cz(4, 6)\n",
44
+
"qc.h(0)\n",
45
+
"qc.h(2)\n",
46
+
"qc.h(5)\n",
47
+
"qc.h(6)\n",
48
+
"\n",
49
+
"qc.draw(output=\"mpl\")"
50
+
]
51
+
},
52
+
{
53
+
"cell_type": "markdown",
54
+
"metadata": {},
55
+
"source": [
56
+
"We solve the problem of optimal state preparation with an SMT solver (Z3).\n",
57
+
"Therefore, we encode the problem into an SMT-model.\n",
58
+
"To construct the SMT model, the solver takes the entangling operations (CZ) as a list of qubit pairs."
59
+
]
60
+
},
61
+
{
62
+
"cell_type": "code",
63
+
"execution_count": null,
64
+
"metadata": {},
65
+
"outputs": [],
66
+
"source": [
67
+
"from mqt.qmap.na import get_ops_for_solver\n",
68
+
"\n",
69
+
"ops = get_ops_for_solver(qc, \"z\", 1) # We extract the 'Z' gates with '1' control, i.e., CZ gates\n",
70
+
"ops"
71
+
]
72
+
},
73
+
{
74
+
"cell_type": "markdown",
75
+
"metadata": {},
76
+
"source": [
77
+
"Now, we are ready to initialize the solver and to generate the optimal sequence of operations.\n",
78
+
"The parameters of the solver describe an architecture with two storage zones with each two rows, one zone above the entangling zone and one below.\n",
79
+
"The entangling zone itself consists of three rows and the architecture model has three columns.\n",
80
+
"Within each interaction site, atoms can be offset by two sites in every direction.\n",
81
+
"The considered architecture offers two AOD columns and three AOD rows.\n",
82
+
"\n",
83
+
"We instruct the solver to generate a sequence consisting of four stages.\n",
84
+
"Thereby, we do not fix the number of transfer stages.\n",
85
+
"The last two boolean arguments, specify that the solver needs not to maintain the order of operations and must shield idling qubits in the storage zone.\n",
86
+
"For further details on the employed abstraction of the 2D plane in the solver, please refer to the corresponding article :cite:labelpar:`stadeOptimalStatePreparation2024`."
Copy file name to clipboardExpand all lines: docs/Publications.rst
+31-2Lines changed: 31 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,13 +3,42 @@ Publications
3
3
4
4
*QMAP* is academic software. Thus, many of its built-in algorithms have been published as scientific papers.
5
5
See :cite:labelpar:`wille2023qmap` for a general overview of *QMAP* and its features.
6
+
If you want to cite this article, please use the following BibTeX entry:
7
+
8
+
.. code-block:: bibtex
9
+
10
+
@inproceedings{qmap,
11
+
title = {{QMAP: A Quantum Circuit Mapping Tool}},
12
+
booktitle = {International Symp. on Physical Design},
13
+
author = {Wille, Robert and Burgholzer, Lukas},
14
+
year = {2023}
15
+
}
16
+
17
+
*QMAP* is part of the Munich Quantum Toolkit, which is described in :cite:labelpar:`willeMQTHandbookSummary2024`.
18
+
If you want cite the Munich Quantum Toolkit, please use the following BibTeX entry:
19
+
20
+
.. code-block:: bibtex
21
+
22
+
@inproceedings{mqt,
23
+
title = {The {{MQT}} Handbook: {{A}} Summary of Design Automation Tools and Software for Quantum Computing},
24
+
shorttitle = {{The MQT Handbook}},
25
+
booktitle = {IEEE International Conference on Quantum Software (QSW)},
26
+
author = {Wille, Robert and Berent, Lucas and Forster, Tobias and Kunasaikaran, Jagatheesan and Mato, Kevin and Peham, Tom and Quetschlich, Nils and Rovara, Damian and Sander, Aaron and Schmid, Ludwig and Schoenberger, Daniel and Stade, Yannick and Burgholzer, Lukas},
27
+
date = {2024},
28
+
doi = {10.1109/QSW62656.2024.00013},
29
+
eprint = {2405.17543},
30
+
eprinttype = {arxiv},
31
+
addendum = {A live version of this document is available at \url{https://mqt.readthedocs.io}}
32
+
}
6
33
7
34
If you use *QMAP* in your work, we would appreciate if you cited
8
35
9
36
- :cite:labelpar:`zulehnerEfficientMethodologyMapping2019` when using the heuristic mapper,
10
37
- :cite:labelpar:`willeMappingQuantumCircuits2019` when using the exact mapper,
11
-
- :cite:labelpar:`peham2023DepthOptimalSynthesis` when using the Clifford circuit synthesis approach, and
12
-
- :cite:labelpar:`schmid2024HybridCircuitMapping` when using the hybrid mapper for neutral atom quantum computers.
38
+
- :cite:labelpar:`peham2023DepthOptimalSynthesis` when using the Clifford circuit synthesis approach,
39
+
- :cite:labelpar:`schmid2024HybridCircuitMapping` when using the hybrid mapper for neutral atom quantum computers,
40
+
- :cite:labelpar:`stadeAbstractModelEfficient2024` when using the neutral atom logical array compiler (NALAC), and
41
+
- :cite:labelpar:`stadeOptimalStatePreparation2024` when using the optimal state preparation for neutral atoms (NASP).
13
42
14
43
Furthermore, if you use any of the particular algorithms such as
This module provides functionality to generate an optimal operation sequence for zoned neutral atom architectures.
5
+
The input must be a circuit of single-qubit gates, followed by a set of entangling gates (CZ) and finally single-qubit gates on selected qubits.
6
+
Those circuits arise in the realm of error correction when the initial logical state must be prepared.
7
+
8
+
The process is divided into three steps:
9
+
1. Extract a list of qubit pairs from the circuit that represents the entangling gates with :code:`get_ops_for_solver`
10
+
11
+
.. currentmodule:: mqt.qmap.na
12
+
.. autofunction:: get_ops_for_solver
13
+
14
+
2. Supply the list of entangling operations to the solver and generate the optimal operation sequence with the :code:`NAStatePreparationSolver`.
15
+
For further details on the employed abstraction of the 2D plane in the solver, please refer to the corresponding article :cite:labelpar:`stadeOptimalStatePreparation2024`.
16
+
17
+
.. currentmodule:: mqt.qmap.na
18
+
.. autoclass:: NAStatePreparationSolver
19
+
20
+
3. Generate code from the solver's result with :code:`generate_code`
0 commit comments