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 and migrate Qiskit Terra fake backends #26

Open
HuangJunye opened this issue Mar 17, 2023 · 6 comments
Open

Update and migrate Qiskit Terra fake backends #26

HuangJunye opened this issue Mar 17, 2023 · 6 comments

Comments

@HuangJunye
Copy link

HuangJunye commented Mar 17, 2023

Description

This project proposal aims to address Qiskit/qiskit#9553.

Qiskit Terra has a fake provider module that contains a number of fake backends with device properties snapshots of IBM Quantum Systems. These fake backends primarily have two purposes (quoted from Qiskit/qiskit#9553):

  1. For terra developers who use as the fake backends to test Qiskit specific functionality in the transpiler, visualization, pulse, etc. modules (e.g. using FakeSherbrooke to exercise compilation to ECR gates)
  2. For end users who, following the model of how the fake backends are used in release notes, documentation, Qiskit textbook, want to use the fake backends as as snapshots of IBM devices

These differ mainly in that the first use case doesn't want to couple strongly to provider-specific behavior like the use of custom properties (to avoid mixing vendor- or provider-specific behavior with base terra testing and implementations) while the second explicitly does want a strong coupling between fake and real backends (to avoid having to write special case handling for the fake backends, or complicate using them to test and validate code before sending to real devices).

We plan to address this issue in the following steps:

  1. Update existing test usage to remove IBM-derived fake backends in favor of case-specific fake backend construction (e.g. test-local fake backends to exercise specific cases) and a collection of vendor-agnostic fake backends for common cases, named for what property they help exercise (e.g. Fake500Qubits, FakeWithISwap, ...)
  2. Migrate the existing IBM-derived fake backends (and the associated tooling) from their location in qiskit.providers.fake_provider to the qiskit_ibm_provider package
  3. Update fake backend usage in documentation to reference new location
  4. Deprecate IBM-derived fake backends from qiskit.providers.fake_provider

Deliverables

Each of the step of the plan will involve one or multiple pull requests to the relevant github repos (qiskit-terra and qiskit-ibm-provider. The PRs will contain documentation content (api reference, how-to guides, etc.) as well as code changes.

Mentors details

  • Mentor 1
    • Name: Junye Huang
    • GitHub ID: @HuangJunye
    • What they do: Quantum Developer Advocate

Number of mentees

2 1

Type of mentees

This project can be split into two parts. One mentee can work on step 1 for updating fake backends and another mentee can work on step 2 migrating fake backends to qiskit-ibm-provider. These two projects can be done relatively independently. I think step 1 is a bit easier to do than step 2 so it's more friendly for beginners. We ended up choosing only one mentee due to time zone constrains.

  • Mentee 1 (@MozammilQ)
    • Required:
      • Familiar with Python development
    • Nice to have:
      • Experience in contributing to Qiskit

- Mentee 2
- Required:
- Familiar with Python development
- Nice to have:
- Experience in contributing to Qiskit

@faraimazh
Copy link

I am interested in working on the second part of this project.

@HuangJunye
Copy link
Author

I am interested in working on the second part of this project.

Thanks for your interest for the project, Farai! I have selected another mentee for the project. Hope you can find another mentor!

@HuangJunye
Copy link
Author

@MozammilQ Can you please comment on this issue so that I can assign you? Thanks!

@MozammilQ
Copy link

@HuangJunye , I am here :)

@MozammilQ
Copy link

@GemmaDawson GemmaDawson moved this to Checkpoint 1 Submitted in QAMP Spring 23 May 22, 2023
@MozammilQ
Copy link

MozammilQ commented Jun 5, 2023

The way we have FakeBackends like FakeSherbrooke, FakeManila, FakeJakarta, etc, something called FakeGeneric will be made, why so? That is because when we want to test some Terra functionality which needs a backend, we have to arbitrarily use a backend which suits our need, the very first limitation of using the snapshots of the real IBM backends is that we need to know certain specifications of the backend like number of qubits, basis gates, pulse support, etc beforehand, and then we decide which backend to import in. Now, in a FakeGeneric backend we can pass in the needs for example number of qubits, basis gates, supports dynamic etc and the FakeBackend will return a BackendV2 object, this backend will NOT be a snapshot of the original IBM Backend but it will contain the properties of the backend that suits the need of the test and backend itself is created only for that specific purpose.

Idea:
The Fake Device backends are the snapshots of the real IBM Quantum Computers. The configuration/properties of the processor/controls are in json files saved on disk. A Fake Backend of the real one just loads the json and which makes the backend object mimic the behavior/noise of the processor.
So, my idea was to generate that json with some arbitrary (reasonable) values and then load that json into a new BackendV2 subclass backend called FakeGeneric.
Now, there are problems to be considered here, first, this process becomes tough and one could ask to write tests just to test if the backend is created correctly. I mean if the json is generated with reasonable values.
So, my mentor suggested a better solution, I was told to use the inbuilt terra functions which can be used to make an entirely new subclass of BackendV2 from scratch.
(one will be able to start in the direction if this is checked out: https://qiskit.org/documentation/apidoc/providers.html#id2 )

See, the key is to understand the implementation of the BackendV2, post this, just make your own backend which will be the subclass of the BacekndV2 most of the functionalities will be available in the new backend, one just has to tweak it according to their needs.
For example, one could just pass in the basis_gates, num_qubits, etc to the constructor of this new subclass, in the constructor import different gates, make a Target and add the instructions to the Target. Different properties like T1, T2, error, etc could have arbitrary values ( very important is not to have any random values but to have values which could be the real values if one tries to make a new processor from scratch, meaning, the values should be bounded between two extreme values).

Bonus learning outcome for the reader:
While writing the code one should keep in mind the oldest version of python supported by the current version of qiskit-terra. Don’t get tempted to add any new python functionality which is present in the latest version of python supported by qiskit-terra because the one who happens to use the oldest version of python supported by current qiskit-terra will beak the new code written on that particular system.

Here is a screenshot of my current progress:
checkpoint_2_photo

One can checkout the code of FakeGeneric here:
[WIP] https://github.com/MozammilQ/qiskit-terra/tree/add_FakeGeneric_and_modify_tests/qiskit/providers/fake_provider/backends/generic

@GemmaDawson GemmaDawson moved this from Checkpoint 1 Submitted to Final Showcase Submitted in QAMP Spring 23 Jul 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Final Showcase Submitted
Development

No branches or pull requests

3 participants