sqdlab.github.io

Stack Overview

This document presents all the layers and elements of SQDToolz, and explain the design philosophy behind them. It is important to read this document to get an idea of how to use these different layers/ elements of stack correctly. NOT using them in this way can lead to unexpected bugs and behavior!!, no support is available for this.

Layers:

The is divided into 3 key layers:

  1. Lab (Laboratory).
  2. HAL (Hardware abstraction layer)
    • Qcodes wrapper, and RL linking.
  3. RL (Runtime layer)
    • VARs, SPECs.
  4. IL (Interface layer)
    • Experiment, Experiment Config.

Lab (Laboratory):

Note that above mentioned components do not have strong inter-dependency, making it easier to debug. But for the layers to function together, a “supervisor” is required. This is called as Laboratory or (Lab) in the stack. In stack, it does not implements any types of checks, but is responsible for holding all elements on above mentioned layers for the entire jupyter notebook.

Following are the elements and use case for each layer:

HAL (Hardware abstraction layer)

This layer had 2 purpose:

Steps to creating a HAL object:

  1. Load Qcodes driver using RL object. This is done by running the load_instrument() function of the RL object.
  2. Use package object to create a HAL type object and link it to RL object and it’s qcodes driver. This is done by <pkg_obj>.<hal_type>(<hal_obj_name>,<rl_obj>,<qcodes_name>,<additional_params>). While linking, the HAL will register itself as an "active" instrument.

NOTE: Currently, this is a wrapper around qcodes driver. This is only part of the stack which dependency on qcodes library, so if you see an qcodes related error, it must have originated here.

RL (Runtime Layer)

This layer is the main component being used when performing different experiments. This layer has the following functionality:

File saving directory is passed as an argument when creating the RL object. The HAL object storage at the beginning only once.

Experiment parameters are the most important part of this layer, as they are the container that hold various type of information and data between different experiment. Following are the 2 type of RL containers:

  1. VAR
  2. SPEC

NOTE: Their functionality looks very similar on the surface, but their’ way intended way of usage is very different. Using them in improper manner can lead to data loss, data inconsistency or other unexpected behavior.

VARs (Variable property):

Instead of changing HAL parameters in loop or during runtime, we make VAR for it. These are then passed to run() function of lab object, which sets or sweep over them when actually “running” the experiment.

General structure:

('name':'value = HAL parameter')

General Usage:

These are temporary placeholder which may or may NOT belong to HAL object parameter. Ideally, you can create and add custom variable parameters or use existing ones. For example:

NOTE the following for HAL object related VARs:

SPECs (Specifications):

These can be thought of as “tempelate” or “collection” of information and parameters relevant to ths given experiment, or obtained after running the experiment or after processing the data obtained from it. Additionally it provide a certain level of automation, using the JSON templates.

General structure:

('key':'value',+(optional:target))

General usage:

Additionally, they have the following features:

Example: Creating base.json

Consider a case of Cavity and qubit spectroscopy. From each of them we obtain a frequency, power and decay time. You can have JSON with name “base” in the sqdtoolz/sqdtoolz/ExperimentSpecifications/ folder as follows

{
   "Frequency" : 5e9,
   "Power" : -30,
   "decay time": 1
}

This JSON file can be used to create SPEC(‘Qubit’) and SPEC(‘cavity’), in which later more parameters can be added specific to their own details. At the time of creation of SPECs, all the paramters mentioned in the JSON as automatically created and loaded with deafault values mentioned in the JSON file.

VARs vs SPECs:

VARs SPECs
* Structure * Structure
* Passed to run()` function of lab object. * Passed to ExperimentConfiguration.
* Change value during runtime * Retains “value” for given “key”.
* Created on the fly only * JSON automated or can be created on the fly.

IL (Interface layer).

This layer where the runtime parameters are actually executed, that is, the programming of the instruments, timing checks, data collection and data processing (depending upon the experiment object), takes place in this layer. This comprises of the following 2 key elements (classes):

  1. Experiment Configuration.
  2. Experiment.

Following are the functions of each component in detail:

Experiment Configuration (EC):

This takes the following inputs:

Basically it acts as a giant container for all the details relevant to the experiment it will be run in. Essentially, it contains functions for manipulating instruments which are called by the experiment.

Experiment:

This can be thought of as an intelligent manager of Experiment Config. It uses the EC’s built-in functions in a particular way ( as defined by the user) to:

Creation: These are supposed to be created by the user, when some particular insturments are handle in a specific way to get data, and for this sequence no other experiemnt exists.

This completes the Design and Use Philosophy of the entire stack.