Meta communication

System information from 2300 is divided over both request/reply and publish/subscribe. The messages below are published by 2300.

Get static

Get system information from 2300. This information is retrieved only once, normally at startup time for 2200.

Info

The schemas for validation inherit from the base schema and can be found in:

/schemas/get_static/request.schema.json
/schemas/get_static/reply_success.schema.json
/schemas/get_static/reply_failure.schema.json

Get static request payload

This message does not require any additional information in the payload section.

Get static request example

get_static_request.json
{
    "command": "get_static",
    "version": "0.2.0"
}

Get static reply payload

Key	Type	Value
`nqubits`	`int`	The number of qubits
`topology`	`array[tuple]`	List of the edges between the various qubits
`name`	`str`	Name of the system
`pgs`	`array[str]`	Supported primitive gates set of the system. Gate names as described in cQASM (in uppercase)
`starttime`	`float`	Timestamp of start-up of the system (return value of `time.time()`)
`default_compiler_config`	`object[str,array[object[str, Any]]]`	Compiler configurations for different stages.
`supports_raw_data`	`bool`	Default `False`. Whether the hardware backend supports `raw_data`. If `True`, the `include_raw_data` flag in the execute message should trigger the backend to store the measurements per shot in the raw_data field of the results.

Get static reply example

get_static_reply.json
{
    "status": "success",
    "payload": {
        "nqubits": 5,
        "topology": [
            [0, 2],
            [1, 2],
            [3, 2],
            [4, 2]
        ],
        "name": "Starmon-5",
        "pgs": [
            "X",
            "Y"
        ],
        "starttime": 1690061619.610174,
        "default_compiler_config": {
            "decomposition": [
                {
                    "path": "opensquirrel.decomposer.mckay_decomposer.McKayDecomposer",
                    "method": "decompose",
                    "arguments": {}
                }
            ]
        }
    },
    "version": "0.2.0"
}

Compiler configuration

The compiler configuration defines the pre-processing needed to convert the user-provided circuit into one that the backend can process. This comprises a list of steps that should be applied to the circuit using the Opensquirrel library. The config is represented as a dict and defines for each stage, a list of passes (ie preprocessing actions) that should be performed in the stage. Each pass includes settings such as the pass name, corresponding method invoked by opensquirrel and additional keyword arguments.

Currently, the following stages are supported:

decomposition:
path: opensquirrel.<path_to_decomposer_class>. See the decomposers listed in the opensquirrel docs.
method: decompose
arguments: arguments expected for the initialization of the decomposer class.

If no default_compiler_config is provided, there will be no pre-processing steps applied to the circuit. The backend will receive the cQASM string the same way it was provided by the user.

Get dynamic

Dynamic information is generated by 2300. This information can for example constitute calibration data like T1 and T2*. This dynamic metadata fetched on a status change from CALIBRATING/OFFLINE to IDLE or on startup of 2200.

Info

The schemas for validation inherit from the base schema and can be found in:

/schemas/get_dynamic/request.schema.json
/schemas/get_dynamic/reply_success.schema.json
/schemas/get_dynamic/reply_failure.schema.json

Get dynamic request payload

This message does not require any additional information in the payload section.

Get dynamic request example

get_dynamic_request.json
{
    "command": "get_dynamic",
    "version": "0.2.0"
}

Get dynamic reply payload

The payload for this message contains an overview of one or more (or zero) metrics that can be used in a monitoring stack. In the table below, the format of a single metric is described. Keys between angular brackets (<) are dynamic.

Key	Type	Value
`<metric_name>`	object	Description of a single metric. The key is used as the metric name in Prometheus/Grafana.
`__labels__`	array	The strings in this array are used as individual keys for labels in Prometheus/Grafana.
`<label_value>`	any	The value can either be an object for nested values (see example 2), or an `int` or `float` for a leaf. The value of the (recursive) key is mapped by index to the labels in `__labels__` (e.g. `key1=q1` and `key2=x1`). The tree is traversed until a leaf is found. This value is interpreted as the value for the metric. If there is no value for the specific instance `null` can be reported, or the branch can be ommitted.

The reason that these labels are this important has to do with the aggregation and filtering of metrics. By specifying one metric which is measured for different data point, the dashboard can easily reference this metric. However, if necessary panels in the dashboard or alerts can also reference values for individual data points.

Get dynamic reply example 1: No labels

get_dynamic_reply.json
{
    "status": "success",
    "payload": {
        "fridge_temperature_in_mk": 8.4
    },
    "version": "0.2.0"
}

This will be represented in Prometheus/Grafana as:

qi_fridge_temperature_in_mk 8.4

Get dynamic reply example 2: One label

get_dynamic_reply.json
{
    "status": "success",
    "payload": {
        "t1": {
            "__labels__": ["qubit"],
            "q0": 0.995,
            "q1": 0.988
        }
    },
    "version": "0.2.0"
}

This will be represented in Prometheus/Grafana as:

qi_t1{qubit=q0} 0.995
qi_t1{qubit=q1} 0.988

Get dynamic reply example 2: Multiple labels

get_dynamic_reply.json
{
    "status": "success",
    "payload": {
        "cnot_fidelity": {
            "__labels__": ["qubit1", "qubit2"],
            "q1": {
                "q0": 0.995
            }
        }
    },
    "version": "0.2.0"
}

This will be represented in Prometheus/Grafana as:

qi_cnot_fidelity{qubit1=q1, qubit2=q0} 0.995