Giter Club home page Giter Club logo

qiskit-ibmq-provider'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 quantum 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 them 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-ibmq-provider's People

Contributors

1ucian0 avatar ajavadia avatar atilag avatar cbjuan avatar cryoris avatar delapuente avatar diego-plan9 avatar eric-arellano avatar guillermo-mijares-vilarino avatar hugovk avatar jakelishman avatar jaygambetta avatar jmcelroy01 avatar jwoehr avatar jyu00 avatar kdk avatar kt474 avatar lgarc15 avatar max-reuter-2 avatar mmcelaney avatar mriedem avatar mtreinish avatar nonhermitian avatar rafal-pracht avatar rathishcholarajan avatar rcuz8 avatar taalexander avatar yeralin avatar yoshida-ryuhei avatar zachschoenfeld33 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  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  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

qiskit-ibmq-provider's Issues

QiskitBackendNotFoundError occurs if I registered both credentials of Q Experience and Q Console

Informations

  • Qiskit version: 0.7.2
  • Python version: 3.6.8
  • Operating system: macOS HighSierra

What is the current behavior?

I have both Q Experience and Q Console accounts and registered them to IBMQ. Then, because both systems have a backend with the same name "ibmq_qasm_simulator", QiskitBackendNotFoundError occurs.

Steps to reproduce the problem

$ python
>>> from qiskit import IBMQ
>>> IBMQ.load_accounts()
>>> print(IBMQ.backends())
[<IBMQBackend('ibmq_20_tokyo') from IBMQ(xxx, yyy, zzz)>,
 <IBMQBackend('ibmq_qasm_simulator') from IBMQ(xxx, yyy, zzz)>,
 <IBMQBackend('ibmqx4') from IBMQ()>,
 <IBMQBackend('ibmqx2') from IBMQ()>,
 <IBMQBackend('ibmq_16_melbourne') from IBMQ()>,
 <IBMQBackend('ibmq_qasm_simulator') from IBMQ()>]
>>> IBMQ.get_backend('ibmq_qasm_simulator')
QiskitBackendNotFoundError                Traceback (most recent call last)
----> 1 IBMQ.get_backend('ibmq_qasm_simulator')
~/envs/test/lib/python3.6/site-packages/qiskit/providers/baseprovider.py in get_backend(self, name, **kwargs)
     42         backends = self.backends(name, **kwargs)
     43         if len(backends) > 1:
---> 44             raise QiskitBackendNotFoundError('More than one backend matches the criteria')
     45         elif not backends:
     46             raise QiskitBackendNotFoundError('No backend matches the criteria')

QiskitBackendNotFoundError: 'More than one backend matches the criteria'

What is the expected behavior?

Users can choose "ibmq_qasm_simulator" on Q Experience or Q Console.

Suggested solutions

Change the backend name "ibmq_qasm_simulator" on Q Console.

CHANGELOG and contributing make md not rst

Information

  • Qiskit IBMQ Provider version:
  • Python version:
  • Operating system:

What is the current behavior?

Since we are not using Sphinx on these in this repo I would make them as to be consistent with the rest of the files in this repo.

Steps to reproduce the problem

What is the expected behavior?

Suggested solutions

Enable proxy support for new API

What is the expected behavior?

As part of the transition, support for the proxy configuration keys needs to be adjusted for the new API v2 - the basics are in place for the Session, but it needs to be enabled fully. Ideally, we should also include some tests for the feature, probably with the help of some lightweight proxy server in the CI.

On the wishlist, testing support for NTLM proxies would be high on the list - although it might not be technically feasible.

Define behaviour of retrieve_job() from another backend

What is the expected enhancement?

As noticed by @jaygambetta , currently IBMQBackend.retrieve(job_id) does not enforce that the job_id belongs to a job that has really been executed in that backend - it searches for that id among all the jobs that exists in the user account. This is prone to causing some confusion, and might make the user fetch jobs from other backends inadvertently.

Proposed solution

We should detect that situation, and the function should act accordingly, with the ultimate goal of making it easy for the users - I think the decision is mostly about how strict we want to be. It might be worth noticing that backend.jobs() does enforce a hard filter by backend, so I'd lean towards keeping raising a IBMQBackendError if the job does not belong to a backend, along with a warning so users can correct the situation (ie. by using the right backend). Any suggestions?

need to silence warnings about old format jobs in `backend.jobs()`

What is the expected behavior?

I consistently get a warning when using backend.jobs() for jobs in the old format.

/anaconda3/lib/python3.6/site-packages/qiskit/providers/ibmq/ibmqbackend.py:188: DeprecationWarning: Some jobs are in a no-longer supported format. Please send the job using Qiskit 0.8+. Old jobs:
 - 5c1569e0d463c70054fb1753

What is the utility of this warning? There isn't any way to actually resubmit that job, because one cannot even get a handle to old jobs (backend.retrieve_job() raises an error for old jobs).

IBMQBackendError: 'Failed to get job "5c1569e0d463c70054fb1753": job in pre-qobj format'

So one is stuck with some old format jobs in the database that always raise warnings.

I think we should silence the warning (the error makes sense, because at that point we are explicitly saying we want that particular job).

Revise multiple credentials handling for new api

What is the expected behavior?

In the new API, two new pieces (the authorization server, and the endpoint for listing the hubs of an user) allow for the user to pass only one set of credentials, and have the provider automatically discover all the hubs. We should take advantage of that, as it minimizes hassle for the end users.

There are backwards-compatibility concerns (some IBMQ methods might be rendered obsolete or require some changes), and internal design concerns (the concept of "account" is probably too bound to the classic API, where one set of credentials == one provider == one account). After evaluating, we should discuss the different options available.

Minor code polishing (not affecting current functionality)

Information

Minor things that don't change existing functionality, but would be nice to have in place before the initial release:

  • Exception definition - some exceptions don't inherit from QiskitError (most notably, connector.ApiError), and in general they are a bit wild at the moment (credentials not having a own exception, etc).
  • Remove underscores

Add license check for new API

What is the expected behavior?

Follow up to #78.

When using the new API through the authentication server, if the user did not accept the license, the error message is generic. For clarity, we should handle it as a special case and present the user with a clearer error message, similar to the classic API.

Cleanup websocket TODOs and details

What is the expected behavior?

After #100, there are some items that need confirming with the API team, and decide on the best course of action:

  • check whether the connection is always closed when a job reaches a final state. In #100, we explicitly close the connection, but might be unneeded. #100 (comment)
  • check whether a timeout during websockets (as in, the last response received from websocket did not contain a final state) can be reliable mapped to "the job is still in a final state". #100 (comment)
  • check the protocol for authenticating: as of #100, we rely on getting a specific response after trying to authenticate, and on the closing of the connection for determining that the token was invalid. It might be useful if we get an explicit reply when the token is invalid. #100 (comment)
  • check that unabilty to connect to the socket server (for example, due to using proxies) falls back in all cases to non-websocket status pooling

Remove possible race conditions on test_ibmqjob_states.py flow.

Informations

  • Qiskit Terra version: > 0.5
  • Python version: > 3.5
  • Operating system: All supported

What is the current behavior?

Tests on test_ibmqjob_states are meant to test state flow on jobs. As these jobs have asynchronous behavior, we need a way to avoid possible race conditions. There's some sort of sleep() mechanism to sync operations that is not very reliable.

Steps to reproduce the problem

Race conditions occur very rare, but the way to reproduce them is by launching the tests.

What is the expected behavior?

Tests should never fail because of race conditions

Suggested solutions

Haven't thought about it yet.

Review `error_message` in case of a total failure.

What is the expected behavior?

PR #48 deals with an error coming from a failed experiment but it could be cases in which the job fails globally. The current implementation does not cover this case. This issue is intended to track this possible corner case.

Revise importing of IBMQ in tests

Information

Currently some tests import IBMQ through qiskit:

from qiskit import IBMQ

For consistency and since it is a separate package, those tests should import from the package directly, as in:

from qiskit.providers.ibmq import IBMQ

(or instantiate an object directly)

Revise api_v2.rest.root ported functions

What is the expected behavior?

During #78, some sections of the classic API code were moved into qiskit.providers.ibmq.api_v2.rest directly (or nearly), aimed for compatibility. As noted during the review, some of these functions would benefit from a cleanup, as they have been growing organically and some code is still inherited from the original IBMQuantumExperience package.

We should revise at least the following items:

Remove pre-qobj functionality

What is the expected behavior?

With all the devices supporting Qobj, we can remove the classes and constructs that were used for helping with the transition from IBMQ.

error_message() does not work

running

job = backend.retrieve_job(ran_job.job_id())

on a previous job that had an error. Followed by

job.error_message() 

returns no message

Move changes from qiskit-api-sdk branch

Information

From 93, some items were not moved from the experimental qiskit-api-sdk branch (basically the unchecked boxes at Qiskit/qiskit#1175). We should port the following items to the IBMQ Provider (from the qiskit-api-sdk branch):

  • accepting include in get_job() and get_jobs(), from here
  • add job.properties() method, making use of the new connector method parameters
  • device name mangling, from here.

Refactor IBMQJob class

What is the expected behavior?

Over time, IBMQJob has grown in complexity, and in particular the logic has grown a bit convoluted - the amount of indirection (specially for methods around the status) and corner cases is probably above the recommended threshold.

It would be worth exploring a refactor of its internals post 0.3 release, focused on maintainability.

Update simulator noise model handling

What is the expected behavior?

In the upcoming aer release, the noise model can be converted to a serializable dict directly after Qiskit/qiskit-aer#165 . In turn, it means we can simplify utils.update_qobj_config(), removing the AerJSONEncoder class that was copied over and instead call .as_dict(serializable=True) directly.

Support new API v2 job states

What is the expected behavior?

Compared to the classic API, he new API can return new "states" for a job (ie. more than COMPLETED, CANCELLED, etc). As a temporary workaround while the two versions are supported, on some endpoints at the API end the states are "simplified" in order to return only classic states (since classic qiskit does not understand the new ones, and might fail ungracefully). However, we should make use of them eventually, as they provide more information.

For short term, we should:

  • verify with the API team that no endpoints are returning new states (classic + websockets)
  • compile a list of the new states

Longer term, we should be able to accommodate them in the Job class, and be able to manage their transitions accordingly. We might not be able to accommodate this change until the classic API is fully deprecated.

Move more tests from terra

Information

There might still be some individual tests or files in terra that are actually tests of ibmq features. We should do a round of looking for them and move them to this package if that is the case.

Increase coverage of IBMQClient tests

What is the expected behavior?

During #78 , the test_ibmq_client_v2.py was added in order to provide minimal testing for the new api, heavily inspired by the classic test_ibmq_connector.py.

We should ensure that the tests for IBMQClient are more comprehensive, as it is a key component for the provider and will become more relevant after the API 2 moves out of beta. In particular:

  • ensure that all public methods are covered by a test (potentially more for complex methods)
  • ensure that there are no skipped tests (might need action on the API side)
  • ensure the asserts are meaningful and relatively strong

Lower priority:

  • revise the requires_classic_api and requires_new_api_auth decorators_get_client` to see if we can make them more robust (ideally without making too many requests) (see #78 (comment), #100)
  • check if it makes sense to avoid compiling a circuit (loading the qobj directly from qasm or similar), or move it to an auxiliary function, for clarity and not coupling the test to the compilation

In the process, some oddities might be found - It might be cleaner to rewrite the tests from scratch instead of basing them on the previous ones.

Revise authentication parameters for connector methods

What is the expected behavior?

Currently, most of the methods of IBMQConnector that interact with and endpoint accept the credentials information (hub, group, user_id, etc) as parameters, and perform a similar set of operations at the beginning of the function:

        if access_token:
            self.req.credential.set_token(access_token)
        if user_id:
            self.req.credential.set_user_id(user_id)
        if not self.check_credentials():
            raise CredentialsError('credentials invalid')

However, the credentials information is already present in self.config, which makes the parameters and some checks redundant (and actually, the parameters are unused by the rest of the codebase). It seems a good candidate for simplification, by just removing the parameters and fetching the needed information from self.config directly.

Support gracefully connecting to the new api

What is the expected behavior?

The login and flow from the new API might have slight differences compared to the current one. As a cautionary measure, during the transition period we should make sure the 0.1 version of the provider is able to work with both versions as gracefully as possible (and eventually supporting only the new API).

In the readme contribution guidelines has some broken links

Information

  • Qiskit IBMQ Provider version:
  • Python version:
  • Operating system:

What is the current behavior?

We need to update part of the readme to correct links and the stack overflow should be stack exchange.

Steps to reproduce the problem

What is the expected behavior?

Suggested solutions

Publish first installable version

What is the expected behavior?

For helping with the transition (ie. between "removing the code from terra" and "releasing the next terra version"), having a pip-installable version of this package would make development and CI's life easier (in a similar way aer is installed manually, etc).

  • finalize setup.py and everything related to the release (versioning, dependencies, manifest, final tweaks)
  • set the version string (ideally marking as pre-release to reduce confusion).
  • make a release and upload to pip
  • notify/adjust terra accordingly

Cleaner detection of Circuit support

What is the expected behavior?

Currently, the detection of whether a user has access to Circuits functionality is brittle: an optimistic approach is taken, using the first new-api account as the basis for accessing Circuits, although it cannot be fully detected until an attempt to run a Circuit is made (interpreting the http response code and the error for trying to diagnose the cause).

Ideally, the API would provide some endpoint or information about whether the user has access to Circuits, to simplify the number of cases and ensure that the provider can be set up accordingly.

Complete websocket implementation

What is the expected behavior?

In #58 , the basis for supporting waiting for a job completion was introduced. It should be finalized and tested to ensure it is working as intended.

Handle partial success in jobs

What is the expected behavior?

A job can partially succeed if not all their experiments fail. The current implementation does not allow the user to retrieve the successful experiments. Instead, it raises an error when trying to get the results.

>> job.status()
<JobStatus.ERROR: 'job incurred error'>
>> job.result()
JobError: 'Invalid job state. The job should be DONE but it is JobStatus.ERROR'

We should be able to browse a partial success, even if the global status of the job is ERROR.

test/ibmq/test_registration.py not working due to interface changes in latest release

Informations

  • Qiskit version: terra 0.7.0
  • Python version: python 3.7.2
  • Operating system: macos mojave 10.14.2 (18C54)

What is the current behavior?

Test test/ibmq/test_registration.py not working.

Steps to reproduce the problem

LOG_LEVEL=INFO python -m unittest test/ibmq/test_registration.py

What is the expected behavior?

Run all tests OK

Suggested solutions

FIx code in test so it's up to date with latest release.

new copyright header required

What is the expected behavior?

The following copyright statement must replace the old one in all the files:

# This code is part of Qiskit.
#
# (C) Copyright IBM 2019.
#
# This code is licensed under the Apache License, Version 2.0. You may
# obtain a copy of this license in the LICENSE.txt file in the root directory
# of this source tree or at http://www.apache.org/licenses/LICENSE-2.0.
#
# Any modifications or derivative works of this code must retain this
# copyright notice, and modified files need to carry a notice indicating
# that they have been altered from the originals.

Revise IBMQJob._job_data

What is the expected enhancement?

As a follow-up to #1564, IBMQJob still converts a Qobj to an old-format dict in order to retrieve the values needed for populating self._job_data:

https://github.com/Qiskit/qiskit-terra/blob/32806c195d84bce4f2696147017d99ba06915729/qiskit/providers/ibmq/ibmqjob.py#L145-L153

However, this information is only used by IBMQJobPreQobj, and some bits have become obsolete (for example, the hpc parameter). It seems we should either revise _job_data (probably moving it a bit deeper and revising each key), or actually wait until Qobj is available in all devices - this would allow us to remove IBMQJobPreQobj entirely and a bunch of code along with it.

Revise test_qobj_headers_in_result_sims

What is the expected behavior?

After #86, the test_qobj_headers_in_result_sims was marked as expected failure, as passing object_header to assemble() no longer preserves the header pristine:

custom_qobj_header = {'x': 1, 'y': [1, 2, 3], 'z': {'a': 4}}
qobj_header = QobjHeader.from_dict(custom_qobj_header)
qobj = assemble(circuits, backend=backend, qobj_header=qobj_header)
> print(qobj.header.as_dict())
{'x': 1, 'backend_name': 'ibmq_qasm_simulator', 'backend_version': '0.1.547', 'y': [1, 2, 3], 'z': {'a': 4}}

We should revise if this is by design and adjust the test or terra accordingly (for the test, simply reverting the order and updating qobj.header directly after assemble() would work). test_qobj_headers_in_result_devices might need similar measures.

Check if connection exists before calling QX API

What is the expected enhancement?

As detailed in #954, it takes several minutes before the QX API reports an error in trying to connect to the QX servers if no connection can be established, and the error message is not very helpful. I have experienced this myself. Instead, it is possible to first check if a remote connection can be established, and then raise and exception with a more detailed error message. We actually already have, and use this functionality when calling utils._has_connection.

kwargs in backend.run()?

Informations

  • Qiskit version: 0.1
  • Python version:
  • Operating system:

The backend.run() method from IBMQProvider only accepts a qobj, and no other options. This is in contrast to the backend.run() method of Aer, which accepts noise_model and backend_options. Currently this prevents us from being able to easily switch between local/online simulator.

The following code should work (i.e. we have to be able to switch between local Aer and cloud Aer).

from qiskit import *
from qiskit.providers.aer import noise
IBMQ.load_accounts()
device = IBMQ.get_backend('ibmq_16_melbourne')
properties = device.properties()
coupling_map = device.configuration().coupling_map

# Construct quantum circuit
qr = QuantumRegister(3, 'qr')
cr = ClassicalRegister(3, 'cr')
circ = QuantumCircuit(qr, cr)
circ.h(qr[0])
circ.cx(qr[0], qr[1])
circ.cx(qr[1], qr[2])
circ.measure(qr, cr)

# Select the QasmSimulator from the Aer provider
simulator = Aer.get_backend('qasm_simulator')

# Execute and get counts
result = execute(circ, simulator).result()
counts = result.get_counts(circ)

gate_times = [
    ('u1', None, 0), ('u2', None, 100), ('u3', None, 200),
    ('cx', [1, 0], 678), ('cx', [1, 2], 547), ('cx', [2, 3], 721),
    ('cx', [4, 3], 733), ('cx', [4, 10], 721), ('cx', [5, 4], 800),
    ('cx', [5, 6], 800), ('cx', [5, 9], 895), ('cx', [6, 8], 895),
    ('cx', [7, 8], 640), ('cx', [9, 8], 895), ('cx', [9, 10], 800),
    ('cx', [11, 10], 721), ('cx', [11, 3], 634), ('cx', [12, 2], 773),
    ('cx', [13, 1], 2286), ('cx', [13, 12], 1504), ('cx', [], 800)
]

# Construct the noise model from backend properties
# and custom gate times
noise_model = noise.device.basic_device_noise_model(properties, gate_times=gate_times)

basis_gates = noise_model.basis_gates

# Select the simulators
local_sim = Aer.get_backend('qasm_simulator')
online_sim = IBMQ.get_backend('ibmq_qasm_simulator', hub=None)

# Execute noisy simulation and get counts
result_noise = execute(circ, online_sim,  # this fails, but local_sim works
                       noise_model=noise_model,
                       coupling_map=coupling_map,
                       basis_gates=basis_gates).result()

job.cancel() throws TypeError

Informations

  • Qiskit version: 0.1 (ibmq-provider)
  • Python version: 3.7.2
  • Operating system: macOS

What is the current behavior?

When calling job.cancel() on a job that has not yet finished, you get the following error:
TypeError: cancel_job() takes 2 positional arguments but 5 were given

Steps to reproduce the problem

Create any circuit. Transpile and assemble circuits. Run the job on any IBMQ backend, and call job.cancel() before it completes. You get this error and the job will run until it fails or successfully completes.

What is the expected behavior?

The job is cancelled and job.status() shows that the job was cancelled.

Suggested solutions

It looks like the error is being thrown because of the call to cancel_job() inside of job.cancel(). Inside of job.cancel() hub, group, and project are stored but never used. After looking through past commits it looks like these variables we used as input when calling cancel_job(), but that is no longer the case. I would guess that removing them from the cancel_job() call would fix the issue.

Avoid deprecation warnings coming from terra

What is the expected behavior?

The test suite currently emits several deprecation warnings, mostly due to the use of qiskit.compile(), which is to be deprecated in 0.9. We should move the tests to use the new transpilation workflow accordingly.

Adjust to specific BackendConfiguration models

What is the expected behavior?

After the merging of Qiskit/qiskit#2216, the BackendConfiguration model is now subclassed into QasmBackendConfiguration and PulseBackendConfiguration. We should update the IBMQSingleProvider accordingly so it creates the more specialized objects when instantiating the backends.

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.