• IBM Consulting

    DBA Consulting can help you with IBM BI and Web related work. Also IBM Linux is our portfolio.

  • Oracle Consulting

    For Oracle related consulting and Database work and support and Migration call DBA Consulting.

  • Novell/RedHat Consulting

    For all Novell Suse Linux and SAP on Suse Linux questions releated to OS and BI solutions. And offcourse also for the great RedHat products like RedHat Enterprise Server and JBoss middelware and BI on RedHat.

  • Microsoft Consulting

    For Microsoft Server 2012 onwards, Microsoft Client Windows 7 and higher, Microsoft Cloud Services (Azure,Office 365, etc.) related consulting services.

  • Citrix Consulting

    Citrix VDI in a box, Desktop Vertualizations and Citrix Netscaler security.

  • Web Development

    Web Development (Static Websites, CMS Websites (Drupal 7/8, WordPress, Joomla, Responsive Websites and Adaptive Websites).

13 December 2019

QISKit open source project

IBM's QISKit open source project

Qiskit is an open-source framework for working with quantum computers at the level of circuits, pulses, and algorithms.

"The Arrival of Quantum Computing" by Will Zeng

A central goal of Qiskit is to build a software stack that makes it easy for anyone to use quantum computers. However, Qiskit also aims to facilitate research on the most important open issues facing quantum computation today.

You can use Qiskit to easily design experiments and run them on simulators and real quantum computers.

Qiskit Quantum Computing tech talk

Qiskit consists of four foundational elements:

Qiskit Terra: Composing quantum programs at the level of circuits and pulses with the code foundation.

Qiskit Aer: Accelerating development via simulators, emulators, and debuggers

Qiskit Ignis: Addressing noise and errors

Qiskit Aqua: Building algorithms and applications

Introduction to Quantum Computer

The Qiskit Elements


Terra, the ‘earth’ element, is the foundation on which the rest of Qiskit lies. Terra provides a bedrock for composing quantum programs at the level of circuits and pulses, to optimize them for the constraints of a particular device, and to manage the execution of batches of experiments on remote-access devices. Terra defines the interfaces for a desirable end-user experience, as well as the efficient handling of layers of optimization, pulse scheduling and backend communication.

Using QISkit: The SDK for Quantum Computing

Qiskit Terra is organized in six main modules:

Circuit A quantum circuit is a model for quantum computing in which a computation is done by performing a sequence of quantum operations (usually gates) on a register of qubits. A quantum circuit usually starts with the qubits in the |0,…,0> state and these gates evolve the qubits to states that cannot be efficiently represented on a classical computer. To extract information on the state a quantum circuit must have a measurement which maps the outcomes (possible random due to the fundamental nature of quantum systems) to classical registers which can be efficiently represented.

Pulse A pulse schedule is set of pulses which are sent to a quantum experiment that are applied to a channel (experimental input line). This is a lower level than circuits and requires each gate in the circuit to be represented as a set of pulses. At this level the experiments can be designed to reduce errors (dynamical decoupling, error mitigation, and optimal pulse shapes).

Transpiler A major part of research on quantum computing is working out how to run a quantum circuits on real devices. In these devices, experimental errors and decoherence introduce errors during computation. Thus, to obtain a robust implementation it is essential to reduce the number of gates and the overall running time of the quantum circuit. The transpiler introduces the concept of a pass manager to allow users to explore optimization and find better quantum circuits for their given algorithm. We call it a transpiler as the end result is still a circuit.

The Arrival of Quantum Computing – Quantum Networks

Providers Once the user has made the circuits to run on the backend they need to have a convenient way of working with it. In Terra we do this using four parts:

A Provider is an entity that provides access to a group of different backends (for example, backends available through the IBM Q Experience). It interacts with those backends to, for example, find out which ones are available, or retrieve an instance of a particular backend.

Backend represent either a simulator or a real quantum computer and are responsible for running quantum circuits and returning results. They have a run method which takes in a qobj as input and returns a BaseJob object. This object allows asynchronous running of jobs for retrieving results from a backend when the job is completed.

Job instances can be thought of as the “ticket” for a submitted job. They find out the execution’s state at a given point in time (for example, if the job is queued, running, or has failed) and also allow control over the job.

Result. Once the job has finished Terra allows the results to be obtained from the remote backends using result = job.result(). This result object holds the quantum data and the most common way of interacting with it is by using result.get_counts(circuit). This method allows the user to get the raw counts from the quantum circuit and use them for more analysis with quantum information tools provided by Terra.

Quantum Information To perform more advanced algorithms and analysis of the circuits run on the quantum computer, it is important to have tools to implement simple quantum information tasks. These include methods to both estimate metrics and generate quantum states, operations, and channels.

IBM Q Quantum Computing

Visualization In Terra we have many tools to visualize a quantum circuit. This allows a quick inspection of the quantum circuit to make sure it is what the user wanted to implement. There is a text, python and latex version. Once the circuit has run it is important to be able to view the output. There is a simple function (plot_histogram) to plot the results from a quantum circuit including an interactive version. There is also a function plot_state and plot_bloch_vector that allow the plotting of a quantum state. These functions are usually only used when using the statevector_simulator backend but can also be used on real data after running state tomography experiments (Ignis).

Aer, the ‘air’ element, permeates all Qiskit elements. To really speed up development of quantum computers we need better simulators, emulators and debuggers. Aer helps us understand the limits of classical processors by demonstrating to what extent they can mimic quantum computation. Furthermore, we can use Aer to verify that current and near-future quantum computers function correctly. This can be done by stretching the limits of simulation, and by simulating the effects of realistic noise on the computation.

Aer provides a high performance simulator framework for quantum circuits using the Qiskit software stack. It contains optimized C++ simulator backends for executing circuits compiled in Terra. Aer also provides tools for constructing highly configurable noise models for performing realistic noisy simulations of the errors that occur during execution on real devices.

Quantum Computing: Technology, Market and Ecosystem Overview

Qiskit Aer includes three high performance simulator backends:

Qasm Simulator
Allows ideal and noisy multi-shot execution of qiskit circuits and returns counts or memory. There are multiple methods that can be used that simulate different cirucits more efficiently. These inlude:

statevector - Uses a dense statevector simulation.

stabilizer - Uses a Clifford stabilizer state simulator that is only valid for Clifford circuits and noise models.

extended_stabilizer - Uses an approximate simulator that decomposes circuits into stabilizer state terms, the number of which grows with the number of non-Clifford gates.

matrix_product_state - Uses a Matrix Product State (MPS) simulator.

Statevector Simulator
Allows ideal single-shot execution of qiskit circuits and returns the final statevector of the simulator after application.

Unitary Simulator
Allows ideal single-shot execution of qiskit circuits and returns the final unitary matrix of the circuit itself. Note that the circuit cannot contain measure or reset operations for this backend.

Ignis, the ‘fire’ element, is dedicated to fighting noise and errors and to forging a new path. This includes better characterization of errors, improving gates, and computing in the presence of noise. Ignis is meant for those who want to design quantum error correction codes, or who wish to study ways to characterize errors through methods such as tomography, or even to find a better way for using gates by exploring dynamical decoupling and optimal control.

Ignis provides code for users to easily generate circuits for specific experiments given a minimal set of user input parameters. Ignis code contains three fundamental building blocks:

The circuits module provides the code to generate the list of circuits for a particular Ignis experiment based on a minimal set of user parameters. These are then run on Terra or Aer.

The results of an Ignis experiment are passed to the Fitters module where they are analyzed and fit according to the physics model describing the experiment. Fitters can plot the data plus fit and output a list of parameters.

For certain Ignis experiments, the fitters can output a Filter object. Filters can be used to mitigate errors in other experiments using the calibration results of an Ignis experiment.

Qiskit Ignis is organized into three types of experiments that can be performed:

Characterization experiments are designed to measure parameters in the system such as noise parameters (T1, T2-star, T2), Hamiltonian parameters such as the ZZ interaction rate and control errors in the gates.

Verification experiments are designed to verify gate and small circuit performance. Verification includes state and process tomography, quantum volume and randomized benchmarking (RB). These experiments provide the information to determine performance metrics such as the gate fidelity.

Mitigation experiments run calibration circuits that are analyzed to generate mitigation routines that can be applied to arbitrary sets of results run on the same backend. Ignis code will generate a list of circuits that run calibration measurements. The results of these measurements will be processed by a Fitter and will output a Filter than can be used to apply mitigation to other results.

Aqua, the ‘water’ element, is the element of life. To make quantum computing live up to its expectations, we need to find real-world applications. Aqua is where algorithms for quantum computers are built. These algorithms can be used to build applications for quantum computing. Aqua is accessible to domain experts in chemistry, optimization, finance and AI, who want to explore the benefits of using quantum computers as accelerators for specific computational tasks.

Problems that may benefit from the power of quantum computing have been identified in numerous domains, such as Chemistry, Artificial Intelligence (AI), Optimization and Finance. Quantum computing, however, requires very specialized skills. To address the needs of the vast population of practitioners who want to use and contribute to quantum computing at various levels of the software stack, we have created Qiskit Aqua.

Programming Existing Quantum Computers

Development Strategy

We are going to look out 12 months to establish a set of goals we want to work towards. When planning, we typically look at potential work from the perspective of the elements.

Qiskit Terra
In 2018 we worked on formalizing the backends and user flow in Qiskit Terra. The basic idea is as follows: the user designs a quantum circuit and then, through a set of transpiler passes, rewrites the circuit to run on different backends with different optimizations. We also introduced the concept of a provider, whose role is to supply backends for the user to run quantum circuits on. The provider API we have defined at version one supplies a set of schemas to verify that the provider and its backends are Terra-compatible.

In 2019, we have many extensions planned. These include:

Add passes to the transpiler. The goal here is to be more efficient in circuit depth as well as adding passes that find approximate circuits and resource estimations.

Introduce a circuit foundry and circuit API. This has the goal of making sure that a user can easily build complex circuits from operations. Some of these include adding controls and power to operations, and inserting unitary matrices directly.

Provide an API for OpenPulse. Now that OpenPulse is defined, and the IBM Q provider can accept it, we plan to build out the pulse features. These will include a scheduler and tools for building experiments out of pulses. Also included will be tools for mapping between experiments with gates (QASM) to experiments with pulses.

Qiskit Aer
The first release of Qiskit Aer was made avaialble at the end of 2018. It included C++ implementations of QASM, statevector, and unitary simulators. These are the core to Qiskit Aer, and replace the simulators that existed in Terra. The QASM simulator includes a customizable general (Kraus) noise model, and all simulators include CPU parallelization through the OpenMP library.

In 2019, Aer will be extended in many ways:

Optimize simulators. We are going to start profiling the simulators and work on making them faster. This will include automatic settings for backend configuration and OpenMP parallelization configuration based on the input Qobj and available hardware.

Classical simulation algorithms for quantum computational supremacy experiments

Develop additional simulator backends. We will include several approximate simulator backends that are more efficient for specific subclasses of circuits, such as the T-gate simulator, which works on Clifford and T gates (with low T-depth), and a stabilizer simulator, which works just on Clifford gates.

Add noise approximation tools. We plan to add noise approximation tools to mapping general (Kraus) noise models to approximate noise model that may be implemented on an approximate backends (for example only mixed Clifford and reset errors in the noise model).

Qiskit Ignis
This year, we are going to release the first version of Qiskit Ignis. The goal of Ignis is to be a set of tools for characterization of errors, improving gates, and enhancing computation in the presence of noise. Examples of these tools include optimal control, dynamical decoupling, and error mitigation.

In 2019, Ignis will include tools for:

quantum state/process tomography

randomized benchmarking over different groups

optimal control (e.g., pulse shaping)

dynamical decoupling

circuit randomization

error mitigation (to improve results for quantum chemistry experiments)

Qiskit Aqua
Aqua is an open-source library of quantum algorithms and applications, introduced in June 2018. As a library of quantum algorithms, Aqua comes with a rich set of quantum algorithms of general applicability—such as VQE, QAOA, Grover’s Search, Amplitude Estimation and Phase Estimation—and domain-specific algorithms-such as the Support Vector Machine (SVM) Quantum Kernel and Variational algorithms, suitable for supervised learning. In addition, Aqua includes algorithm-supporting components, such as optimizers, variational forms, oracles, Quantum Fourier Transforms, feature maps, multiclass classification extension algorithms, uncertainty problems, and random distributions. As a framework for quantum applications, Aqua provides support for Chemistry (released separately as the Qiskit Chemistry component), as well as Artificial Intelligence (AI), Optimization and Finance. Aqua is extensible across multiple domains, and has been designed and structured as a framework that allows researchers to contribute their own implementations of new algorithms and algorithm-supporting components.

Over the course of 2019, we are planning to enrich Aqua as follows:

We will include several new quantum algorithms, such as Deutsch-Jozsa, Simon’s, Bernstein-Vazirani, and Harrow, Hassidim, and Lloyd (HHL).

We will improve the performance of quantum algorithms on top of both simulators and real hardware.

We will provide better support for execution on real quantum hardware.

We will increase the set of problems supported by the AI, Optimization and Finance applications of Aqua.


These are examples of just some of the work we will be focusing on in the next 12 months. We will continuously adapt the plan based on feedback. Please follow along and let us know what you think!

IBM Quantum Computing


The Qiskit project is made up of several elements each performing different functionality. Each is independently useful and can be used on their own, but for convenience we provide this repository and meta-package to provide a single entrypoint to install all the elements at once. This is to simplify the install process and provide a unified interface to end users. However, because each Qiskit element has it’s own releases and versions some care is needed when dealing with versions between the different repositories. This document outlines the guidelines for dealing with versions and releases of both Qiskit elements and the meta-package.

Quantum programming

For the rest of this guide the standard Semantic Versioning nomenclature will be used of: Major.Minor.Patch to refer to the different components of a version number. For example, if the version number was 0.7.1, then the major version is 0, the minor version 7, and the patch version 1.

Meta-package Version
The Qiskit meta-package version is an independent value that is determined by the releases of each of the elements being tracked. Each time we push a release to a tracked component (or add an element) the meta-package requirements, and version will need to be updated and a new release published. The timing should be coordinated with the release of elements to ensure that the meta-package releases track with element releases.

Adding New Elements
When a new Qiskit element is being added to the meta-package requirements, we need to increase the Minor version of the meta-package.

For example, if the meta-package is tracking 2 elements qiskit-aer and qiskit-terra and it’s version is 0.7.4. Then we release a new element qiskit-ignis that we intend to also have included in the meta-package. When we add the new element to the meta-package we increase the version to 0.8.0.

Patch Version Increases
When any Qiskit element that is being already tracked by the meta-package releases a patch version to fix bugs in a release we need also bump the requirement in the setup.py and then increase the patch version of the meta-package.

For example, if the meta-package is tracking 3 elements qiskit-terra==0.8.1, qiskit-aer==0.2.1, and qiskit-ignis==0.1.4 with the current version 0.9.6. When qiskit-terra release a new patch version to fix a bug 0.8.2 the meta-package will also need to increase it’s patch version and release, becoming 0.9.7.

Additionally, there are occasionally packaging or other bugs in the meta-package itself that need to be fixed by pushing new releases. When those are encountered we should increase the patch version to differentiate it from the broken release. Do not delete the broken or any old releases from pypi in any situation, instead just increase the patch version and upload a new release.

Minor Version Increases
Besides adding a new element to the meta-package the minor version of the meta-package should also be increased anytime a minor version is increased in a tracked element.

For example, if the meta-package is tracking 2 elements qiskit-terra==0.7.0 and qiskit-aer==0.1.1 and the current version is 0.7.5. When the qiskit-aer element releases 0.2.0 then we need to increase the meta-package version to be 0.8.0 to correspond to the new release.

Major Version Increases
The major version is different from the other version number components. Unlike the other version number components, which are updated in lock step with each tracked element, the major version is only increased when all tracked versions are bumped (at least before 1.0.0). Right now all the elements still have a major version number component of 0 and until each tracked element in the meta-repository is marked as stable by bumping the major version to be >=1 then the meta-package version should not increase the major version.

The behavior of the major version number component tracking after when all the elements are at >=1.0.0 has not been decided yet.

Qiskit Element Requirement Tracking
While not strictly related to the meta-package and Qiskit versioning how we track the element versions in the meta-package’s requirements list is important. Each element listed in the setup.py should be pinned to a single version. This means that each version of Qiskit should only install a single version for each tracked element. For example, the requirements list at any given point should look something like:

requirements = [
This is to aid in debugging, but also make tracking the versions across multiple elements more transparent.

It is also worth pointing out that the order we install the elements is critically important too. pip does not have a real dependency solver which means the installation order matters. So if there are overlapping requirements versions between elements or dependencies between elements we need to ensure that the order in the requirements list installs everything as expected. If the order needs to be change for some install time incompatibility it should be noted clearly.

Small quantum computers and big classical data

Module Status
Qiskit is developing so fast that is it is hard to keep all different parts of the API supported for various versions. We do our best and we use the rule that for one minor version update, for example 0.6 to 0.7, we will keep the API working with a deprecated warning. Please don’t ignore these warnings. Sometimes there are cases in which this can’t be done and for these in the release history we will outline these in great details.

This being said as we work towards Qiskit 1.0 there are some modules that have become stable and the table below is our attempt to label them


There are three providers that come with the default installation of Qiskit

Basic Aer Provider
This provider simulates ideal quantum circuits and has three backends. As Aer becomes more stable and can work on any operating system this provider will be removed.

Aer Provider
This is a more advance simulator that is written in C++. It runs faster than Basic Aer and also allows you to add noise to your circuits. This allow you to explore what happens to your circuits for realistic models of the experiments and design experiments that might be more resilient to the noise in today’s quantum computers.

IBM Q Provider
This provider gives you access to real experiments. You will need an IBM Q Experience account to use it. It also has an online HPC simulator that can be used. It is a hosted version of the Aer Provider.

Community Extensions
Qiskit has been designed with modularity in mind. It is extensible in many different ways; on the page, we highlight the ways in which the Qiskit community has engaged with Qiskit and developed extensions and packages on top of it.

The Qiskit base provider is an entity that provides access to a group of different backends (for example, backends available through IBM Q). It interacts with those backends to do many things: find out which ones are available, retrieve an instance of a particular backend, get backend properties and configurations, and handling running and working with jobs.

Additional providers
Decision diagram-based quantum simulator

- Organization: Johannes Kepler University, Linz, Austria (Alwin Zulehner and Robert Wille)
- Description: A local provider which allows Qiskit to use decision diagram-based quantum simulation
- Qiskit Version: 0.7
- More info: Webpage at JKU, Medium Blog and Github Repo
Quantum Inspire

- Organization: QuTech-Delft
- Description: A provider for the Quantum Inspire backend
- Qiskit Version: 0.7
- More info: Medium Blog and Github.
Circuit optimization is at the heart of making quantum computing feasible on actual hardware. A central component of Qiskit is the transpiler, which is a framework for manipulating quantum circuits according to certain transformations (known as transpiler passes). The transpiler enables users to create customized sets of passes, orchestrated by a pass manager, to transform the circuit according to the rules specified by the passes. In addition, the transpiler architecture is designed for modularity and extensibility, enabling Qiskit users to write their own passes, use them in the pass manager, and combine them with existing passes. In this way, the transpiler architecture opens up the door for research into aggressive optimization of quantum circuits.

Additional passes
t|ket〉 optimization & routing pass

- Organization: Cambridge Quantum Computing
- Description: Transpiler pass for circuit optimization and mapping to backend using CQC’s t|ket〉compiler.
- Qiskit Version: 0.7
- More info: Tutorial Notebook and Github.
Extending Qiskit with new tools and functionality is an important part of building a community. These tools can be new visualizations, slack integration, Juypter extensions and much more.

Project Highlight: Quantum Computing Meets Machine Learning

If learning is the first step towards intelligence, it’s no wonder we’re sending machines to school.
Machine learning, specifically, is the self-learning process by which machines use patterns to learn rather than (in the ideal case) asking humans for assistance. Seen as a subset of artificial intelligence, machine learning has been gaining traction in the development community as many frameworks are now available.

Quantum Programming A New Approach to Solve Complex Problems Francisco Gálvez Ramirez IBM Staff fjgramirez@es.ibm.com

And soon, you may have a machine learning framework available in your favorite quantum computing framework!

The winning project of 2019 Qiskit Camp Europe, QizGloria, is a hybrid quantum-classical machine learning interface with full Qiskit and PyTorch capabilities. PyTorch is a machine learning library that, like Qiskit, is free and open-source. By integrating Qiskit and PyTorch frameworks during the 24-hour hackathon, the QizGloria group demonstrated that you can use the best of the quantum and classical world for machine learning. The project is still ongoing modifications but may soon be integrated into Qiskit Aqua.
Below, we interview the four members of the QizGloria group about their project, their experiences, and their future outlook on the field. Interviews are edited for clarity.
Why did you think to combine Qiskit, a quantum-computing framework, with PyTorch, a machine-learning framework?

Controlling a Quantum Computer with Code

Karel Dumon: Classical machine learning is currently benefiting hugely from the open-source community, and this is something we want to leverage in quantum too. Our project focuses on the potential application of quantum computing for machine learning, but also on the use of machine learning to help progress quantum computing itself. Through our project, we hope to make it easier for machine learning developers to explore the quantum world.
Patrick Huembeli: To that effect, it makes Qiskit very accessible for people with a classical machine learning background — they can treat the quantum nodes just as another layer of their machine learning algorithm.

Amira Abbas: In that sense, this project bridges the gap between two communities, machine learning and quantum computing, whose research could seriously complement each other instead of diverging.
How do you think your integration will benefit the Qiskit community?

Dumon: There are a lot of open-source tools available for both quantum computing and machine learning, but those integrations do not provide the optimal synergy between the two worlds. What we tried to build is a tighter integration between Qiskit and PyTorch (an open-source machine learning framework from Facebook) that makes optimal use of the existing capabilities.

Isaac Turtletaub: In quantum computing, we commonly have circuits that need to be optimized with a classical computer. PyTorch is one of the largest machine learning libraries out there, and opens up the possibilities of using deep learning for optimizing quantum circuits.

Do you plan to continue working on this project?

Dumon: During the hackathon, we built the bridge between the two worlds, and showcased some possibilities — but we definitely believe that this is just the beginning of what is possible! While our Qiskit Camp submission was a proof-of-concept, we are currently working with the Qiskit team to include our work in the Qiskit Aqua codebase.

Turtletaub: I plan on continuing to work on this project by contributing to a generalized interface between PyTorch and Qiskit, allowing this to work on any variational quantum circuit. I hope collaborating with the IBM coaches will let all Qiskitters take advantage of our project.

Abbas: We also plan on writing a chapter on hybrid quantum-classical machine learning using PyTorch for the open-source Qiskit textbook and created an pull request for this on GitHub.
What is one of the more difficult challenges still ahead?

Huembeli: Getting the parameter binding of Qiskit right. This will be very important if we want to continue this project. This has to be thought through very well.
In what other ways could this project be expanded?
Turtletaub: This project could be expanded by not only opening up Qiskit to PyTorch, but to another machine learning library, such as TensorFlow.

Huembeli: And if we integrate it well into Qiskit, people will be able to add any nice classical machine learning feature to Qiskit. There is really no limit of applications.

Abbas: Since everything is open source, members of the community can contribute to the code (via pull requests) and add functionalities; make things more efficient, and even create more tutorials demonstrating new ideas or research.

Dumon: We hope that others start playing around with our code and help shape the idea further. This is at the core of the open-source spirit.

And on another topic — Qiskit Camp Europe — what was your favorite part?

Huembeli: The hackathon. It was amazing to see what you can get done in 24 hours.

Turtletaub: My favorite aspect was being able to meet people interested in quantum computing from all across the world and being able to collaborate with some of the top researchers and engineers at IBM.

Abbas: Hands down, my favourite aspect of the hackathon was the people. Coming from South Africa, I was really worried I wouldn’t fit in or be good enough because I’m just a master’s student from the University of KwaZulu-Natal with no undergraduate experience in physics. But as soon as I arrived, I realised that the intention of others at the camp wasn’t to undermine others’ capabilities or differences, but to highlight them and use them to build beautiful applications with Qiskit. There were people from all types of backgrounds with differing levels of experience, and all so helpful, open and keen to learn. I was blown away by the creativity of the projects and I am convinced that the world of quantum computing has a very bright future if these are some of the individuals contributing to it.

Quantum Programming A New Approach to Solve Complex Problems Francisco Gálvez Ramirez IBM Staff fjgramirez@es.ibm.com

More Information:








QISKit OPpenSource