Structure

Programming interface

The qiskit directory is the main Python module and contains the programming interface objects QuantumProgram, QuantumRegister, ClassicalRegister, and QuantumCircuit.

At the highest level, users construct a QuantumProgram to create, modify, compile, and execute a collection of quantum circuits. Each QuantumCircuit has a set of data registers, each of type QuantumRegister or ClassicalRegister. Methods of these objects are used to apply instructions that define the circuit. The QuantumCircuit can then generate OpenQASM code that can flow through other components in the qiskit directory.

The extensions directory extends quantum circuits as needed to support other gate sets and algorithms. Currently there is a standard extension defining some typical quantum gates, and two additional extensions: qasm_simulator_cpp and quantum_initializer.

Internal modules

The directory also contains internal modules that are still under development:

  • a qasm module for parsing OpenQASM circuits
  • an unroll module to interpret and “unroll” OpenQASM to a target gate basis (expanding gate subroutines and loops as needed)
  • a dagcircuit module for working with circuits as graphs
  • a mapper module for mapping all-to-all circuits to run on devices with fixed couplings
  • a backends module contains quantum circuit simulators
  • a tools directory contains methods for applications, analysis, and visualization

Quantum circuits flow through the components as follows. The programming interface is used to generate OpenQASM circuits, as text or QuantumCircuit objects. OpenQASM source, as a file or string, is passed into a Qasm object, whose parse method produces an abstract syntax tree (AST). The AST is passed to an Unroller that is attached to an UnrollerBackend. There is a PrinterBackend for outputting text, a JsonBackend for producing input to simulator and experiment backends, a DAGBackend for constructing DAGCircuit objects, and a CircuitBackend for producing QuantumCircuit objects. The DAGCircuit object represents an “unrolled” OpenQASM circuit as a directed acyclic graph (DAG). The DAGCircuit provides methods for representing, transforming, and computing properties of a circuit and outputting the results again as OpenQASM. The whole flow is used by the mapper module to rewrite a circuit to execute on a device with fixed couplings given by a CouplingGraph. The structure of these components is subject to change.

The circuit representations and how they are currently transformed into each other are summarized in this figure:

_images/circuit_representations.png

Several unroller backends and their outputs are summarized here:

_images/unroller_backends.png

Logging

The SDK uses the standard Python “logging” library for emitting several messages using the family of “qiskit.*” loggers, and abides by the standard convention for the log levels:

Level When it’s used
DEBUG Detailed information, typically of interest only when diagnosing problems.
INFO Confirmation that things are working as expected.
WARNING An indication that something unexpected happened, or indicative of some problem in the near future (e.g. ‘disk space low’). The software is still working as expected.
ERROR Due to a more serious problem, the software has not been able to perform some function.
CRITICAL A serious error, indicating that the program itself may be unable to continue running.

For convenience, QuantumProgram provides two convenience methods (enable_logs() and disable_logs()) that modify the handlers and the level of the qiskit logger. Using these methods might interfere with the global logging setup of your environment - please take it into consideration if developing an application on top of the SDK.

The convention for emitting log messages is declare a global variable in the module named logger, which contains the logger with that module’s __name__, and use it for emitting the messages. For example, if the module is qiskit/some/module.py:

import logging

logger = logging.getLogger(__name__)  # logger for "qiskit.some.module"
...
logger.info("This is an info message)

Testing

The SDK uses the standard Pyton “unittest” framework for the testing of the different components and functionality.

As our build system is based on CMake, we need to perform what is called an “out-of-source” build before running the tests. This is as simple as executing these commands:

Linux and Mac:

$ mkdir out
$ cd out
out$ cmake ..
out$ make

Windows:

C:\..\> mkdir out
C:\..\> cd out
C:\..\out> cmake -DUSER_LIB_PATH=C:\path\to\mingw64\lib\libpthreads.a -G "MinGW Makefiles" ..
C:\..\out> make

This will generate all needed binaries for your specific platform.

For executing the tests, a make test target is available. The execution of the tests (both via the make target and during manual invocation) takes into account the LOG_LEVEL environment variable. If present, a .log file will be created on the test directory with the output of the log calls, which will also be printed to stdout. You can adjust the verbosity via the content of that variable, for example:

Linux and Mac:

$ cd out
out$ LOG_LEVEL="DEBUG" ARGS="-V" make test

Windows:

$ cd out
C:\..\out> set LOG_LEVEL="DEBUG"
C:\..\out> set ARGS="-V"
C:\..\out> make test

For executing a simple python test manually, we don’t need to change the directory to out, just run this command:

Linux and Mac:

$ LOG_LEVEL=INFO python -m unittest test/python/test_apps.py

Windows:

C:\..\> set LOG_LEVEL="INFO"
C:\..\> python -m unittest test/python/test_apps.py

Additionally, an environment variable SKIP_ONLINE_TESTS can be used for toggling the execution of the tests that require network access to the API and SKIP_SLOW_TESTS can be used to toggling execution of tests that are particularly slow (default is True).