Technical glossary
On this page, you can find descriptions of the key technical terms used in QruiseOS and the Qruise Dashboard.
!!!Tip:
For
QruiseOS terms
Measurement backend
A measurement backend provides a QPU target similar to a qiskit backend. The basic service it provides is to run jobs and send back results.
Knowledge base
The purpose of the knowledge base is to act as a single source of truth for saved data. In particular, the data can be :
- the QPU configuration
- raw outputs from experiment and workflow execution
- analysis output that contributes to the knowledge about QPU
The knowledge base can be viewed both as a data backend and as an interface to read and write data (in a structured way). It is also where the data is fetched from. For example, executing a new QPU job requires reading and knowing the latest QPU configuration parameters.
Measurement
When referring to a measurement in this documentation, we're using it as a synonym for a job that can be run on the QPU. In QruiseOS, a measurement is structured as a class so that it can be easily instantiated with different configurations. The measurement class also has a data formatting method so that users know where to look to check or modify what is actually done when going from raw measurements to nicely-shaped datasets. This makes maintenance of code easier in the long run.
Analysis
The output of a measurement is generally analysed through the fit of a function or more sophisticated processes. In QruiseOS, as for measurements, an analysis is a class.
Experiment task
An Experiment task is a central concept in QruiseOS. It completes a mere measurement with all necessary context and processes to transition to a manageable unit.
Experiment tasks in QruiseOS aggregate the measurement, analysis and data persistence (i.e. saving to Knowledge base) in a single notebook.
Experiments can be run standalone or as part of a workflow.
Workflow
A workflow or workflow definition specifies a sequence of tasks to be performed and which qubit these tasks should be performed on.
A workflow run is a particular instance of a workflow.
Schema
The schema provides structure and fixes the semantics of the QPU knowledge. This is required to ensure normalization and a shared vocabulary of the data that is commited to the knowledge base.
Experiment context
An experiment context is an interface to the knowledge base to update and/or commit data like the raw measurements or the output of an analysis within an experiment task.
Dashboard terms
The Qruise dashboard is the quickest way to monitor QPUs, delve into experiment outputs, and interact with workflow runs.
Task (Node)
A task (or node) in the Qruise dashboard is a single unit of work that is part of a workflow (for example, a measurement counts as one task). Tasks can be executed in parallel or sequentially, depending on their dependencies. Each task has a unique ID and is associated with a specific workflow. The task contains information about its status, the result of its execution, and any dependencies it has on other tasks.
Typically tasks are defined as part of workflows in a Jupyter notebook or a simple Python script.
Workflow run
A workflow run is a single execution of a workflow. It is a collection of tasks that are executed in a specific order. Each run has a unique ID and is associated with a specific workflow. The run contains information about the tasks that were executed, their status, and the results of the run.
Progress
This is simply the progress of a workflow run, specifically the number of tasks that have been executed in a run.
Experiment Viewer
The Experiment Viewer is an interface for inspecting and analysing the results of previously run experiment tasks. It provides in-app plotting for diagrams, and links to the respective Jupyter notebook for further analysis.