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

Wildcard: allow running our notebooks with simulators? #1174

Closed
Eric-Arellano opened this issue Apr 12, 2024 · 2 comments · Fixed by #1184
Closed

Wildcard: allow running our notebooks with simulators? #1174

Eric-Arellano opened this issue Apr 12, 2024 · 2 comments · Fixed by #1184

Comments

@Eric-Arellano
Copy link
Collaborator

We are using more hardware rather than simulators in our notebooks. This is meant to help users by showing real-world workflows, where the emphasis is running on actual hardware rather than simulators.

We don't want to complicate the notebooks by showing both simulators and hardware.

However, that poses a challenge for our docs writing pipeline:

  1. We cannot easily test the jobs in every CI run (Test the safe parts of notebooks that run on hardware in every CI run #1173)
  2. It is harder for us to get sample output for the notebooks to show to the user

This issue is to explore the idea of allowing us to dynamically rewrite our notebooks to use simulators rather than hardware when using our tool nb-tester. It would, for example, rewrite the backend to use FakeManilaV2. We'd need to figure out the rewriting of the code, along with reckoning with simulators not working when the qubit count is too high.

@frankharkins
Copy link
Member

frankharkins commented Apr 15, 2024

@beckykd had the idea of overwriting the least_busy function to always return FakeManilaV2. I'm trying it out now with a patched fork and it seems to work pretty well bar a few quirks we can probably iron out.

  1. docs/start/hello-world.ipynb fails in the final cell with

    AttributeError: 'DataBin' object has no attribute 'ensemble_standard_error'

    Because the fake backend doesn't set that attribute. We could just avoid using this attribute as they're only used for error bars in the plot.

  2. tutorials/submitting-transpiled-circuits/notebook.ipynb fails when using Batch. It's possible this notebook is just broken anyway as there were some changes to batch mode recently.

    AttributeError: 'QiskitRuntimeLocalService' object has no attribute 'backend'
  3. This doesn't work for tutorials/build-repitition-codes/notebook.ipynb and tutorials/build-repitition-codes/notebook.ipynb as they use qiskit-ibm-provider. We probably want to switch them to runtime anyway.

Here's the patched function: https://github.com/frankharkins/qiskit-ibm-runtime/blob/fake-runtime/qiskit_ibm_runtime/qiskit_runtime_service.py#L1108-L1132


UPDATE: I tried this out on #1157 and it gets a bit hairier.

TranspilerError: "The control-flow construct 'if_else' is not supported by the backend."

Maybe we still run some notebooks in the fortnightly cron job, but the well-behaved notebooks can use the patched package?

@Eric-Arellano
Copy link
Collaborator Author

@frankharkins it may be desirable for us to always try to have the notebooks work without issue with local simulators, and even communicate to users that they can swap out .least_busy() with FakeManilaV2. That allows us to have hardware-first docs, but that are still accessible. So, when we have issues like the above, that means we should update the docs to work with simulators. The one fundamental barrier I see is if we need to use utility-scale # of qubits?

Re: implementation, we could maybe have nb-tester add a code block to "monkeypatch" Runtime .least_busy() for us, but hide it from users. Python is quite flexible like that:

>>> type(str("123"))
<class 'str'>

>>> str = int
>>> type(str("123"))
<class 'int'>

@frankharkins frankharkins linked a pull request Apr 16, 2024 that will close this issue
github-merge-queue bot pushed a commit that referenced this issue May 2, 2024
This uses the approach discussed in #1174 to test notebooks that submit
jobs to IBM Quantum.

The script behaviour has changed a bit:
* We now have a list of `notebooks_no_mock`, these could include
notebooks with large circuits or that demonstrate features not available
on the fake backend. Future work could partially test these using the
approach in
[#1173](#1173).
* By default, it runs all notebooks except `notebooks_no_mock`, with the
patched package.
* `--submit-jobs` will run **all** notebooks, without the patched
package.
* `--only-unmockable` will run only `notebooks_no_mock`, without the
patched package.

The following notebooks do **not** work with this patch, but some of
them might not have worked anyway.
* `tutorials/variational-quantum-eigensolver/notebook.ipynb`
* `tutorials/submitting-transpiled-circuits/notebook.ipynb`
* `tutorials/build-repitition-codes/notebook.ipynb`

---------

Co-authored-by: Eric Arellano <14852634+Eric-Arellano@users.noreply.github.com>
frankharkins added a commit to frankharkins/documentation that referenced this issue Jul 22, 2024
This uses the approach discussed in Qiskit#1174 to test notebooks that submit
jobs to IBM Quantum.

The script behaviour has changed a bit:
* We now have a list of `notebooks_no_mock`, these could include
notebooks with large circuits or that demonstrate features not available
on the fake backend. Future work could partially test these using the
approach in
[Qiskit#1173](Qiskit#1173).
* By default, it runs all notebooks except `notebooks_no_mock`, with the
patched package.
* `--submit-jobs` will run **all** notebooks, without the patched
package.
* `--only-unmockable` will run only `notebooks_no_mock`, without the
patched package.

The following notebooks do **not** work with this patch, but some of
them might not have worked anyway.
* `tutorials/variational-quantum-eigensolver/notebook.ipynb`
* `tutorials/submitting-transpiled-circuits/notebook.ipynb`
* `tutorials/build-repitition-codes/notebook.ipynb`

---------

Co-authored-by: Eric Arellano <14852634+Eric-Arellano@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants