Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update transpile() to convert BackendV1 inputs to BackendV2 with BackendV2Converter #11996

Merged
merged 4 commits into from
Apr 25, 2024

Conversation

ElePT
Copy link
Contributor

@ElePT ElePT commented Mar 12, 2024

Summary

This PR is a step forward in unifying the transpiler internals to use the target-base model, as specified in #9256.
I had to fix the behavior of transpile with custom scheduling constraints when given BackendV2 inputs, and extracted this into a separate PR, which should be merged before this one: #12042 [edit: merged]. Adding the on hold label again for this reason.

Details and comments

The conversion to the target-based model is hidden to the user but this PR includes a couple of small user-facing changes required for the pipeline to work:

  • a change in convert_to_target that now allows to process calibrations for instructions without registered InstructionProperties, instead of skipping these instructions (I believe that this was not the expected behavior)
  • a change in BackendV2Converter that now looks for num_qubits instead of the legacy n_qubits in the backend configuration
  • allowing backends with no description in BackendV2Converter

Note that BackendV2 does not have any internal tracking whether the backend is a simulator, so any "simulator-based test" now uses BasicSimulator directly (test/python/transpiler/test_1q.py).

In addition to this, some unit tests were using "loopholes" in the BackendV1 model that wouldn't (and shouldn't) translate to a target properly, such as giving a coupling map that didn't match the number of qubits of the backend (test/python/transpiler/test_preset_passmanagers.py) or an instruction schedule map that contained non registered basis gates (test/python/transpiler/test_pulse_gate_pass.py). These tests have been adapted to be coherent with the new model.

@coveralls
Copy link

coveralls commented Mar 12, 2024

Pull Request Test Coverage Report for Build 8347542982

Details

  • 16 of 16 (100.0%) changed or added relevant lines in 2 files are covered.
  • 20 unchanged lines in 3 files lost coverage.
  • Overall coverage increased (+0.06%) to 89.366%

Files with Coverage Reduction New Missed Lines %
qiskit/transpiler/target.py 1 93.74%
crates/qasm2/src/lex.rs 5 91.69%
qiskit/transpiler/passes/layout/dense_layout.py 14 81.37%
Totals Coverage Status
Change from base Build 8346401066: 0.06%
Covered Lines: 59824
Relevant Lines: 66943

💛 - Coveralls

@mtreinish mtreinish self-assigned this Mar 18, 2024
@ElePT ElePT removed the on hold Can not fix yet label Mar 19, 2024
@ElePT ElePT marked this pull request as ready for review March 19, 2024 15:09
@ElePT ElePT requested review from jyu00 and a team as code owners March 19, 2024 15:09
@qiskit-bot
Copy link
Collaborator

One or more of the the following people are requested to review this:

  • @Qiskit/terra-core
  • @nkanazawa1989

@ElePT ElePT force-pushed the convert-v2-transpile branch from 6e56f98 to e28a4d1 Compare March 19, 2024 17:29
@ElePT ElePT added the on hold Can not fix yet label Mar 19, 2024
ElePT added a commit to ElePT/qiskit that referenced this pull request Mar 21, 2024
@ElePT ElePT removed the on hold Can not fix yet label Mar 27, 2024
raynelfss
raynelfss previously approved these changes Apr 24, 2024
Copy link
Contributor

@raynelfss raynelfss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only have one question (which is just something trivial) about the way some tests are written. Other than that LGTM!

Copy link
Member

@mtreinish mtreinish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM, I have some very very mild concern in the tests that we might be dropping some coverage of the v1 path now. But I don't think it's a big deal if we are.

The only question I have before enqueuing for merge is do you think this warrants a release note? Or were you viewing this as an internal implementation detail only? I think either is fine, as either position seems equally valid, but I wanted to check first.

@@ -82,7 +82,7 @@ def convert_to_target(
"switch_case": SwitchCaseOp,
}

in_data = {"num_qubits": configuration.n_qubits}
in_data = {"num_qubits": configuration.num_qubits}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fwiw n_qubits is still valid, it's part of the backend configuration schema:

https://github.com/Qiskit/ibm-quantum-schemas/blob/0231221082ec722cc31db09c0b41a25f441ac338/schemas/backend_configuration_schema.json#L47

and it's why we never removed the n_qubits property. But using num_qubits here for consistency makes sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I just realized that the num_qubits attribute docs call out that you shouldn't use n_qubits, but we could never actually remove it because of the legacy heritage around matching the schema. I'll be very happy once we deprecate the V1 interface and the model objects for removal in 2.0.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I based this change off that comment, I was not aware of n_qubits being used in the schema so good to know.

@@ -32,7 +32,7 @@ def __init__(self):
configuration = BackendProperties(
backend_name="fake_1q",
backend_version="0.0.0",
n_qubits=1,
num_qubits=1,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually don't think either field is required in BackendProperties, this just gets added the payload as an extra field but afaict nothing actually will use this because it's not part of the schema.

@ElePT
Copy link
Contributor Author

ElePT commented Apr 25, 2024

Hmm we might be dropping some coverage but I would say that most of the V1 path was actually tested with loose constraints, so it would be a very small percentage (as you said). In this sense, #12185 is riskier. I thought of this change as a non user-facing one, but I guess a reno would also work, I could then extend it in #12185.

@mtreinish mtreinish added this pull request to the merge queue Apr 25, 2024
Merged via the queue into Qiskit:main with commit f04eaab Apr 25, 2024
12 checks passed
@sbrandhsn sbrandhsn added the Changelog: New Feature Include in the "Added" section of the changelog label May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelog: New Feature Include in the "Added" section of the changelog
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants