In this section, we go over the foundational components and concepts in C^3 with the
primary objective of understanding how the different sub-modules inside the c3-toolset
are structured, the purpose they serve and how to tie them together into a complete Automated
Quantum Device Bring-up workflow. For more detailed examples of how to use the c3-toolset
to perform a specific Quantum Control task, please check out the :doc:`two_qubits` or the
:doc:`Simulated_calibration` sections or refer to the :doc:`c3` for descriptions of
Classes and Functions.
There are three basic building blocks that form the foundation of all the modelling and calibration
tasks one can perform using c3-toolset, and depending on the use-case, some or all of these
blocks might be useful. These are the following:
A theoretical Physics-based model of the Quantum Processing Unit. This is encapsulated by the
Model class which consists of objects from the chip and tasks library.
chip contains Hamiltonian models of different kinds of qubit realisations, along with
their couplings while tasks let you perform common operations such as qubit initialisation or
readout. A typical Model object would contain objects encapsulating qubits along with their
interactions as drive lines and tasks, if any.
A digital twin of the electronic control stack associated with the Quantum Processing Unit. The
Generator class contains the required encapsulation in the form of devices which
help model the behaviour of the classical control electronics taking account of their imperfections and
physical realisations. The devices e.g, an LO or an AWG or a Mixer are wired together in the
Generator object to form a complete representation of accessory electronics.
Once there is a software model for the QPU and the control electronics, one would need to define
Instructions or operations to be perform on this device. For gate-based quantum computing , this is
in the form of gates and their underlying pulse operations. Pulse shapes are described through a
Envelope along with a Carrier, which are then wrapped up in the form of Instruction
objects. The sequence in which these gates are applied are not defined at this stage.
Warning
Components inside the c3/generator/ and c3/signal/ sub-modules will be restructured
in an upcoming release to be more consistent with how the Model class encapsulates smaller
blocks present in the c3/libraries sub-module.
The ParameterMap helps to obtain an optimizable vector of parameters from the various theoretical
models previously defined. This allows for a simple interface to the optimization algorithms which are tasked
with optimizing different sets of variables used to define some entity, e.g, optimizing pulse parameters by
calibrating on hardware or providing an optimal gate-set through model-based quantum control.
With the building blocks in place, we can bring them all together through an Experiment object that
encapsulates the device model, the control signals, the instructions and the parameter map. Note that depending on
the use only some of the blocks are essential when building the experiment.
At its core, c3-toolset is an optimization framework and all of the three steps - Open-Loop, Calibration and
Model Learning can be defined as a optimization task. The optimizers contain classes that provide
helpful encapsulation for these steps. These objects take as arguments the previously defined Experiment and
ParameterMap objects along with an algorithm e.g, CMA-eS or L-BFGS which performs
the iterative optimization steps.
The c3/libraries sub-module includes various helpful library of components that are used somewhat like lego
pieces when building the bigger blocks, e.g, hamiltonians for the chip present in the Model
or envelopes defining a control pulse. More details about these components are available in the
:doc:`c3.libraries` section.