Add Ion dialect and pass for quantum to Ion lowering #1260
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
[sc-73704] |
paul0403
reviewed
Nov 13, 2024
### Before submitting Please complete the following checklist when submitting a PR: - [ ] All new functions and code must be clearly commented and documented. - [ ] Ensure that code is properly formatted by running `make format`. The latest version of black and `clang-format-14` are used in CI/CD to check formatting. - [ ] All new features must include a unit test. Integration and frontend tests should be added to [`frontend/test`](../frontend/test/), Quantum dialect and MLIR tests should be added to [`mlir/test`](../mlir/test/), and Runtime tests should be added to [`runtime/tests`](../runtime/tests/). When all the above are checked, delete everything above the dashed line and fill in the pull request template. ------------------------------------------------------------------------------------------------------------ **Context:** **Description of the Change:** **Benefits:** **Possible Drawbacks:** **Related GitHub Issues:**
rmoyard
changed the title
rmoyard
commented
Nov 29, 2024
joeycarter
added a commit
that referenced
this pull request
Dec 6, 2024
) **Context:** PR #1260 will introduce an MLIR dialect (the _Ion Dialect_) for Open Quantum Design (OQD) trapped-ion quantum devices and the means to lower quantum-dialect MLIR to the ion dialect. The ion dialect requires data specific to the target device in order to perform the lowering. For example, the compiler requires data for the ions used in the device, such as their species and energy levels, parameters determined from calibration runs, such as laser pulse frequencies and Rabi frequencies, and other parameters pertaining to the experimental apparatus. This PR creates these databases and the APIs to load and interact with them. **Description of the Change:** Three database objects have been created, contained in the module frontend/catalyst/third_party/oqd/oqd_database_managers.py: 1. `OQDDeviceDatabase`: for storing properties about the OQD device, such as hardware specification and parameters relating to the experimental apparatus. 2. `OQDQubitDatabase`: for storing properties about the physical qubits used in the trapped-ion device. These are generally physical constants of the ion species being used, such as their energy levels and transitions, and phonon parameters. 3. `OQDBeamDatabase`: for storing parameters about the laser beams used to interact with the qubits, such as the Rabi frequency, detuning, phase and polarization parameters for the given energy-level transition. These databases have been implemented using TOML configuration files for the time being for simplicity and ease-of-use. In the future, some of these parameters may be stored in a SQL database, particularly those determined in calibration runs (these parameters will thus be updated regularly). For the moment, we assume that there is the ability to extract the relevant parameters from the database and dump them into TOML format immediately before compilation. The database APIs listed above have been separated into three objects for this reason—to separate out parameters that are device constants (`OQDDeviceDatabase`), physical constants (`OQDQubitDatabase`), and parameters that require calibration and updating (`OQDBeamDatabase`). The implementation details of the OQD trapped-ion device are still being finalized, so the list of parameters and how they are organized is subject to change. This PR creates a template database on which we can build and start using to test drive the ion dialect. These changes are largely self-contained and should not interfere with regular Catalyst usage. ----- This PR also introduces the `toml_utils` module to extend the functionality of the TOML database files. It adds the `safe_eval` function, which allows inputting values as arithmetic expressions. For example, instead of writing ```toml x = 6283185307.179586 # 2 * pi * 1e9 ``` we can instead input this value directly as: ```toml x = "2 * math.pi * 1e9" ``` The main advantage of this approach is that it uses self-documenting values: it is clear what the origin of the value is without having to keep the comment in sync with the value itself. We define `safe_eval` to perform the expression evaluation rather than use Python's built-in `eval()` function, since `eval`'s ability to perform arbitrary code execution of a user's input makes it inherently unsafe. The functionality of `safe_eval` is deliberately limited to basic mathematical operations to prevent malicious code, intentional or not, from being evaluated. ----- [[sc-73706](https://app.shortcut.com/xanaduai/story/73706/create-a-list-of-hardware-info-calibration-data-necessary-for-the-compiler-0-5)], [[sc-73707](https://app.shortcut.com/xanaduai/story/73707/add-hardware-info-to-the-toml-json-specs-1-5)] --------- Co-authored-by: paul0403 <[email protected]>
Co-authored-by: Lee James O'Riordan <[email protected]>
The sign of the phonon energy in the expression already agrees with the formula in the spec, so not sure what this TODO item is about.
paul0403
reviewed
Dec 17, 2024
paul0403
reviewed
Dec 17, 2024
paul0403
reviewed
Dec 17, 2024
paul0403
reviewed
Dec 17, 2024
paul0403
reviewed
Dec 17, 2024
paul0403
reviewed
Dec 18, 2024
joeycarter
approved these changes
Dec 18, 2024
joeycarter
changed the title
paul0403
added a commit
that referenced
this pull request
Dec 18, 2024
**Context:** A big redesign of oqd ion dialect and the associated toml file format took place during #1260 . Therefore, the frontend oqd pytests (which performs some toml parsing) should be removed, since (a) they are interpreting against the old toml format, and (b) the toml parsing now happens in the mlir layer alongside the actual `--quantum-to-ion` pass, not at the frontend python layer as a standalone.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context:
Add MLIR support for pulse level ionic programs for OQD.
Description of the Change:
This PR adds:
[sc-73704, sc-73705]