Giter VIP home page Giter VIP logo

qiskit-bot's Introduction

Qiskit

License Current Release Extended Support Release Downloads Coverage Status PyPI - Python Version Minimum rustc 1.70 Downloads DOI

Qiskit is an open-source SDK for working with quantum computers at the level of extended quantum circuits, operators, and primitives.

This library is the core component of Qiskit, which contains the building blocks for creating and working with quantum circuits, quantum operators, and primitive functions (Sampler and Estimator). It also contains a transpiler that supports optimizing quantum circuits, and a quantum information toolbox for creating advanced operators.

For more details on how to use Qiskit, refer to the documentation located here:

https://docs.quantum.ibm.com/

Installation

Warning

Do not try to upgrade an existing Qiskit 0.* environment to Qiskit 1.0 in-place. Read more.

We encourage installing Qiskit via pip:

pip install qiskit

Pip will handle all dependencies automatically and you will always install the latest (and well-tested) version.

To install from source, follow the instructions in the documentation.

Create your first quantum program in Qiskit

Now that Qiskit is installed, it's time to begin working with Qiskit. The essential parts of a quantum program are:

  1. Define and build a quantum circuit that represents the quantum state
  2. Define the classical output by measurements or a set of observable operators
  3. Depending on the output, use the primitive function sampler to sample outcomes or the estimator to estimate values.

Create an example quantum circuit using the QuantumCircuit class:

import numpy as np
from qiskit import QuantumCircuit

# 1. A quantum circuit for preparing the quantum state |000> + i |111>
qc_example = QuantumCircuit(3)
qc_example.h(0)          # generate superpostion
qc_example.p(np.pi/2,0)  # add quantum phase
qc_example.cx(0,1)       # 0th-qubit-Controlled-NOT gate on 1st qubit
qc_example.cx(0,2)       # 0th-qubit-Controlled-NOT gate on 2nd qubit

This simple example makes an entangled state known as a GHZ state $(|000\rangle + i|111\rangle)/\sqrt{2}$. It uses the standard quantum gates: Hadamard gate (h), Phase gate (p), and CNOT gate (cx).

Once you've made your first quantum circuit, choose which primitive function you will use. Starting with sampler, we use measure_all(inplace=False) to get a copy of the circuit in which all the qubits are measured:

# 2. Add the classical output in the form of measurement of all qubits
qc_measured = qc_example.measure_all(inplace=False)

# 3. Execute using the Sampler primitive
from qiskit.primitives.sampler import Sampler
sampler = Sampler()
job = sampler.run(qc_measured, shots=1000)
result = job.result()
print(f" > Quasi probability distribution: {result.quasi_dists}")

Running this will give an outcome similar to {0: 0.497, 7: 0.503} which is 000 50% of the time and 111 50% of the time up to statistical fluctuations. To illustrate the power of Estimator, we now use the quantum information toolbox to create the operator $XXY+XYX+YXX-YYY$ and pass it to the run() function, along with our quantum circuit. Note the Estimator requires a circuit without measurement, so we use the qc_example circuit we created earlier.

# 2. Define the observable to be measured 
from qiskit.quantum_info import SparsePauliOp
operator = SparsePauliOp.from_list([("XXY", 1), ("XYX", 1), ("YXX", 1), ("YYY", -1)])

# 3. Execute using the Estimator primitive
from qiskit.primitives import Estimator
estimator = Estimator()
job = estimator.run(qc_example, operator, shots=1000)
result = job.result()
print(f" > Expectation values: {result.values}")

Running this will give the outcome 4. For fun, try to assign a value of +/- 1 to each single-qubit operator X and Y and see if you can achieve this outcome. (Spoiler alert: this is not possible!)

Using the Qiskit-provided qiskit.primitives.Sampler and qiskit.primitives.Estimator will not take you very far. The power of quantum computing cannot be simulated on classical computers and you need to use real quantum hardware to scale to larger quantum circuits. However, running a quantum circuit on hardware requires rewriting to the basis gates and connectivity of the quantum hardware. The tool that does this is the transpiler, and Qiskit includes transpiler passes for synthesis, optimization, mapping, and scheduling. However, it also includes a default compiler, which works very well in most examples. The following code will map the example circuit to the basis_gates = ['cz', 'sx', 'rz'] and a linear chain of qubits $0 \rightarrow 1 \rightarrow 2$ with the coupling_map =[[0, 1], [1, 2]].

from qiskit import transpile
qc_transpiled = transpile(qc_example, basis_gates = ['cz', 'sx', 'rz'], coupling_map =[[0, 1], [1, 2]] , optimization_level=3)

Executing your code on real quantum hardware

Qiskit provides an abstraction layer that lets users run quantum circuits on hardware from any vendor that provides a compatible interface. The best way to use Qiskit is with a runtime environment that provides optimized implementations of sampler and estimator for a given hardware platform. This runtime may involve using pre- and post-processing, such as optimized transpiler passes with error suppression, error mitigation, and, eventually, error correction built in. A runtime implements qiskit.primitives.BaseSampler and qiskit.primitives.BaseEstimator interfaces. For example, some packages that provide implementations of a runtime primitive implementation are:

Qiskit also provides a lower-level abstract interface for describing quantum backends. This interface, located in qiskit.providers, defines an abstract BackendV2 class that providers can implement to represent their hardware or simulators to Qiskit. The backend class includes a common interface for executing circuits on the backends; however, in this interface each provider may perform different types of pre- and post-processing and return outcomes that are vendor-defined. Some examples of published provider packages that interface with real hardware are:

You can refer to the documentation of these packages for further instructions on how to get access and use these systems.

Contribution Guidelines

If you'd like to contribute to Qiskit, please take a look at our contribution guidelines. By participating, you are expected to uphold our code of conduct.

We use GitHub issues for tracking requests and bugs. Please join the Qiskit Slack community for discussion, comments, and questions. For questions related to running or using Qiskit, Stack Overflow has a qiskit. For questions on quantum computing with Qiskit, use the qiskit tag in the Quantum Computing Stack Exchange (please, read first the guidelines on how to ask in that forum).

Authors and Citation

Qiskit is the work of many people who contribute to the project at different levels. If you use Qiskit, please cite as per the included BibTeX file.

Changelog and Release Notes

The changelog for a particular release is dynamically generated and gets written to the release page on Github for each release. For example, you can find the page for the 0.46.0 release here:

https://github.com/Qiskit/qiskit/releases/tag/0.46.0

The changelog for the current release can be found in the releases tab: Releases The changelog provides a quick overview of notable changes for a given release.

Additionally, as part of each release, detailed release notes are written to document in detail what has changed as part of a release. This includes any documentation on potential breaking changes on upgrade and new features. See all release notes here.

Acknowledgements

We acknowledge partial support for Qiskit development from the DOE Office of Science National Quantum Information Science Research Centers, Co-design Center for Quantum Advantage (C2QA) under contract number DE-SC0012704.

License

Apache License 2.0

qiskit-bot's People

Contributors

1ucian0 avatar cryoris avatar eric-arellano avatar gaya3-mv avatar jakelishman avatar javabster avatar mtreinish avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

qiskit-bot's Issues

Add support for auto tagging and releasing meta package versions

Qiskit bot already watches the meta-package repo when it opens up a version bump pr like:

Qiskit/qiskit#802

so it can close it when the commit is finished. The next step of automation is that the bot should automatically create a release from the merged pr (which will trigger the travis job to upload the sdist). It also already has all the information for the release description with the updated versions since it uses that as the commit message. Right now this is a manual process and error prone and it should be automated.

Bump each element version after release

The only manual step that's still part of the release workflow (besides reviewing, approving, and merging PRs) is bumping the element version after a successful release. For example, see:

Qiskit/qiskit#3803

We should add support to the release automation path of qiskit-bot to do this automatically. This way it's less error prone and something we won't forget after pushing a release.

Change release trigger mechanism

Right now qiskit-bot's release automation is triggered by by an authorized contributor pushing a tag to a tracked repo which triggers the changelog generation, github release page creation, etc. However, in practice this has proven to be somewhat error prone, while mistakes in manually tagging aren't common they happen occasionally (typically either tagging the wrong branch or the wrong commit). These mistakes are avoidable though if we just have qiskit-bot do the tagging.

A workflow I've been thinking about since the aer 0.4.2/0.5.0 release (which was caused by an admin on aer at the time tagging 0.4.2 on master instead of the stable branch) is to trigger the release automation from the release prep PR somehow and let qiskit-bot do the tagging (either directly or via github's release api). The two trigger conditions I'm debating between are either a PR merge with a release tag, or a user comment like @qiskit-bot release on a merged PR. I'm leaning towards the latter because it enables us to limit the users via configuration on who are allowed to trigger a release (more users are allowed to tag a PR than just those with write permissions) and it's more explicit in behavior.

Assuming we go with a comment trigger the expected behavior here would be adding a config field to list the authorized usernames on a repo, then on each PR comment check for the expected trigger comment text (probably just @qiskit-bot release) that will then trigger the tag creation from the sha1 of the merged commit for the pr (merge_commit_sha in the PR details). The rest of the release workflow should be the same.

Don't post "Thank you for opening a new pull request" for frequent contributors

This automated comment is useless and noisy if the contributor has already made fifty PRs. (or five or maybe two).

Is there a way to check if the contributor has already made several PRs to the repo in question (eg. qiskit-terra) ?

Or even keep a static list of frequent contributors? I poked around in the code a bit. But I don't see where the github id that opened a PR is available.

Add enhancements for external contributor activity

It would be great if we could have the qiskit bot do certain tasks related to activity from external community members. There are a few different parts to this outlined below, any further comments welcome :)

Part 1 - when HW/GFI label is added to an issue

  1. create new webhook function for event_type=issues
  2. when GFI or HW labels are added to an issue (i.e. data['action']=labeled and data[label]=gfi or hw) do the following:
    • add that issue to contributor monitoring project (github org level project beta)

I don't think PyGithub has support yet for editing github projects (beta), but they are editable via the github graphql api, if we can add a python graphql library or something

useful docs:

Part 2 - comments on HW/GFI issues from external contributors

  1. create new webhook function for event_type=issue_comment
  2. when a comment is left on an issue by a non-member (i.e. data['author_association'] != MEMBER) with GFI/HW (i.e. data['issue']['label']['name]=gfi or hw) do the following:
    • trigger notification for community-reviewers team

useful docs:

Changelog generation fails for versions >= 1.0.0

Since the release of qiskit 1.0.0 the changelog generation that runs as part of release process has been failing. Looking at the logs the git log command that's generated is not valid and getting confused by the concept of major versions (which to be fair for almost it's entire life weren't a thing). For example:

2024-05-16 20:02:49,238: 350 ERROR qiskit_bot.git [-] Failed to get git log
stdout:
b''
stderr:
b"fatal: ambiguous argument '1.1.0...0.0.0': unknown revision or path not in the working tree.\nUse '--' to separate paths from revisions, like this:\n'git <command> [<revision>...] -- [<file>...]'\n"
Traceback (most recent call last):
  File "/qiskit-bot/qiskit_bot/git.py", line 77, in get_git_log
    res = subprocess.run(['git', 'log', '--oneline', sha1],
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/subprocess.py", line 571, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['git', 'log', '--oneline', '1.1.0...0.0.0']' returned non-zero exit status 128.
Process Process-3:
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/multiprocessing/process.py", line 314, in _bootstrap
    self.run()
  File "/usr/local/lib/python3.11/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/qiskit-bot/qiskit_bot/release_process.py", line 259, in _finish_release__changelog_process
    create_github_release(repo, log_string, version_number,
  File "/qiskit-bot/qiskit_bot/release_process.py", line 213, in create_github_release
    changelog = _generate_changelog(repo, log_string, categories)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/qiskit-bot/qiskit_bot/release_process.py", line 142, in _generate_changelog
    git_log = git.get_git_log(repo, log_string).decode('utf8')
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'str' object has no attribute 'decode'

We should fix the release processing to correctly generate the git log from 1.1.0...1.0.0 as intended.

Drop metapackage handling

While an original motivating feature for the development of the qiskit-bot release automation was to handle the metapackage sync between all the qiskit elements and automate as much of that process as we could. With the release of qiskit 0.44.1 the use of the metapackage has been official retired. Moving forward all qiskit releases are from a single repository and we don't need all the complex logic involved with bumping version numbers and requirements files anymore. While it's not a strong priority right now, we should drop all the metapackage functionality from qiskit-bot to simplify the code base.

Make notifications varied so that people don't automatically ignore it

In private discussion with @mtreinish, we realize that people tend to ignore the qiskit-bot PR notification (for example: Qiskit/qiskit#8592 (comment)). A wild idea we have is to use some kind of AI service to generate the same message using different tones each time to make it more varied so that people will pay attention to it.

The simplest way to implement this is just to generate a bunch of these messages offline and store it in this repo and the bot randomly pick one version of it each time.

Add release notes link to changelog generation output

We should have an option to include a link to the hosted release notes in the generated changelog output. The changlog output is just a subset of the git history for the release and the full release notes contain all the details. To do this we likely need a config flag somewhere to give qiskit-bot a hint to the url for the release notes and then it can generate the version suffix for the url to link to it.

Change default_branch default value after qiskit migrates to use main

As pointed out in: #9 (review) a better forward looking default value for the default_branch config options added in #9 is main. Once the qiskit repos currently using qiskit-bot (qiskit/qiskit, terra, aer, ignis, aqua, nature, optimization, finance, and machine-learning) all migrate to use main for their default branch we should change the default value.

comment on visualization changes with binder for visualization testing

It would be great if the bot can comment when somebody modifies qiskit/visualization/ with the binder to test the visualization module: https://mybinder.org/v2/gh/<github_user>/<repo>/<branch>?urlpath=apps/test/ipynb/mpl_tester.ipynb and that can locally be run with jupyter notebook test/ipynb/mpl_tester.ipynb.

Add support for publishing pre-releases

Looking to future releases it would be good to support doing release candidate releases prior to publishing a final release. To support this qiskit-bot will need to be improved to recognize a prerelease tag (vs a real release flag). On a pre-release tag qiskit-bot should create the stable branch, and the changelog, but not update the metapackage. Then on subsequent release candidates from the stable branch we should only generate the changelog. Then on the full release we will treat it like a stable point release but for the changelog generation we will want the from the previous full release to the new one (not just the incremental from the last release candidate) and to update the metapackage. We also probably should add a config flag to say whether the project supports release candidates or not because it does influence stable branch creation.

Add support for marking PRs as explicitly not needing a changelog entry

For large releases, being able to tag a PR as explicitly not needing a changelog entry would be helpful in order to triage which PRs have and haven't yet had their changelog status reviewed. This could be from a label like 'Changelog: None' which exclude the labeled PR both from any of the changelog categories and from the ## No changelog entry list.

Add support for configurable notifications

Github doesn't natively give granular level of control for notifications on subdirectories. If an active contributor wants to get notified of open PR or issues that only effect a subset of the repo their only option right now is to subscribe to the whole project and get emails for every piece of activity. Using codeowners has been tried to solve this problem for those users who have write access to the repo, but it's not ideal because this couples conditional notifications with approval authority.

Adding a feature to qiskit-bot should not be hard to implement this, it already has all the capabilities to implement it. When qiskit-bot is configured to watch a repo it already knows how to read a local config file (for configurable tags) and it also gets events for every event. The missing piece is the step to take in PR and issue events and check them against the local_config_file for a configured element to see if a user should be notified. If there are users who need to be notified the bot can leave a mention for each configured user as a comment on the PR or issue. This will then generate a notification email for users with github's default notification settings.

False positive for "Community PR" tag

The bot tagged one of my Terra PRs (Qiskit/qiskit#8627) with "Community PR", even though I appear as a member of the Qiskit org. When I curl'd the API hook for that PR, my association appears as "CONTRIBUTOR", not "MEMBER" (what the bot checks for).

I think we might want to swap to making a second API request to the pr["user"]["organizations_url"] API point to ask if the user is part of Qiskit directly, rather than trying to infer it from the association, since contributor seems to take precedence over member.

cc: @javabster (since I couldn't assign you for some reason).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.