---
title: Cross Platform Programming
tocdepth: 1
marimo-version: 0.24.0
width: medium
---
```python {.marimo}
import marimo as mo
```
## Cross-platform programming
One of the main reasons for building hybridlane was to unlock the ability to define a quantum circuit once, and then reuse its definition across multiple devices or backends. We'll demonstrate how to do this for a calibration circuit that we'll simulate and then cross-compile for an ion trap. The workflow works the same for other backends in principle.
We'll start by defining a quantum function for our circuit like usual, but we won't bind it to a particular device. This circuit realizes a loop in phase space with area $\beta^2$ whose orientation depends on the qubit state, and it effectively realizes an $R_X(-4\beta^2)$ gate on the qubit.
```python {.marimo}
import matplotlib.pyplot as plt
import numpy as np
import pennylane as qp
import hybridlane as hl
def cd_qfunc(beta):
qp.H("q")
hl.CD(beta, 0, wires=["q", "m"])
hl.D(beta, np.pi / 2, wires="m")
hl.CD(-beta, 0, wires=["q", "m"])
hl.D(-beta, np.pi / 2, wires="m")
qp.H("q")
return hl.expval(qp.Z("q"))
def _():
fig = plt.figure()
hl.draw_mpl(cd_qfunc, style="sketch", fig=fig)(2.0)
return fig
_()
```
## Simulation
To check that the circuit definition is correct, we'll simulate it using `default.hybrid` by binding the function into a `QNode` using a different syntax than the typical annotation. We can compare the output of the circuit against its analytical expected value, $\langle Z\rangle = \cos(4\beta^2)$.
```python {.marimo}
from hybridlane.devices import DefaultHybrid
# Bind the qfunc to `default.hybrid`
sim_qnode = qp.QNode(cd_qfunc, DefaultHybrid(fock_level=32))
# Test out different sampled values of beta
beta_sample = np.linspace(0, 2, 40)
expval = [sim_qnode(beta) for beta in beta_sample]
# Exact expression above
beta_exact = np.linspace(0, 2, 250)
expval_exact = np.cos(4 * beta_exact**2)
fig = plt.figure()
plt.plot(beta_exact, expval_exact, label=r"$\cos(4\beta^2)$")
plt.scatter(beta_sample, expval, label="Samples")
plt.xlabel(r"$\beta$")
plt.ylabel(r"$\langle Z\rangle$")
plt.legend()
fig
```
Our circuit matches the analytic result, so let's move on to compiling it for hardware.
## Cross-compiling
Now we'll use the `sandiaqscout.hybrid` device, which implements a compilation target for a trapped-ion platform. Again, it's worth mentioning that the workflow is the same for other devices and isn't restricted to this particular backend.
In the same way as before, let's bind the circuit definition to the hardware device.
```python {.marimo}
from hybridlane.devices.sandia_qscout import QscoutIonTrap
# Bind to qscout device, also setting the shots because the ion trap doesn't
# work in "analytic" mode.
hw_qnode = qp.set_shots(qp.QNode(cd_qfunc, QscoutIonTrap(n_qubits=6)), 1024)
```
This device's preprocessing transforms automatically take care of many transforms we'd have to do. We can use `hl.draw_mpl` to show the compiled circuit after it goes through all the preprocessing by using the `level="device"` parameter. Also, we'll need the graph decomposition system.
```python {.marimo}
qp.decomposition.enable_graph()
fig2 = plt.figure()
hl.draw_mpl(hw_qnode, level="device", style="sketch", fig=fig2)(2.0)
fig2
```
The compilation routine has performed many changes here
- The $D$ gates were realized through dynamic qubit allocation, and the resulting dynamic wires were converted back to normal wires with `resolve_dynamic_wires`.
- The gates were converted to the native gates of the trap. For example, the 4 $CD$ gates (after the above step) became $xCD$ gates with some single-qubit rotations.
- The algorithmic wire labels were mapped to hardware wire labels with a custom transform (e.g. mode `m -> m1i5`).
- Adjacent qubit rotations were fused with `merge_rotations`.
Alternatively, if you need the concrete `QuantumScript` after compilation, this can be obtained with `qp.workflow.construct_tape`:
```python {.marimo}
tape = qp.workflow.construct_tape(hw_qnode, level="device")(2.0)
tape.operations
```
['RZ(np.float64(6.283185307179586), wires=[5])',
'ConditionalXDisplacement(2.0, 0.0, wires=[5, Qumode(manifold=1, index=5)])',
'RZ(np.float64(6.283185307179586), wires=[5])',
'RZ(3.141592653589793, wires=[4])',
'RY(1.5707963267948966, wires=[4])',
'ConditionalXDisplacement(2.0, 1.5707963267948966, wires=[4, '
'Qumode(manifold=1, index=5)])',
'RZ(np.float64(6.283185307179586), wires=[4])',
'ConditionalXDisplacement(-2.0, 0.0, wires=[5, Qumode(manifold=1, index=5)])',
'RZ(np.float64(6.283185307179586), wires=[5])',
'ConditionalXDisplacement(-2.0, 1.5707963267948966, wires=[4, '
'Qumode(manifold=1, index=5)])',
'RZ(3.141592653589793, wires=[4])',
'RY(1.5707963267948966, wires=[4])',
'GlobalPhase(-25.132741228718352, wires=[])']
While this notebook doesn't actually run the resulting circuit on hardware, we've successfully replicated the workflow you find in mature qubit-based software. And if you're working on quantum hardware or a simulator, building a `Device` will let you integrate your project into hybridlane so that you can program it at a high level.
## OpenQASM
Suppose you need to serialize your circuit -- maybe you're building a device and have to send it over the network. hybridlane provides an intermediate representation (IR) based on OpenQASM 3.0 to facilitate this, with extensions to support CV-DV quantum programs.
As an example, we'll serialize the above compiled circuit with [hl.to_openqasm](https://pnnl.github.io/hybridlane/_autoapi/hybridlane/index.html#hybridlane.to_openqasm). The first step will be to teach hybridlane how to serialize the $xCD$ gate because it's not part of our standard library, which you can view [here](https://github.com/pnnl/hybridlane/blob/main/examples/cvstdgates.inc). The other gates are qubit gates that are part of the regular OpenQASM standard library.
To define a serializer for a gate, you register an implementation for `format_gate_as_qasm`. We'll reuse the definition for $CD$ and just change the op code:
```python {.marimo}
from typing import Any
from hybridlane.io.openqasm import format_gate_as_qasm
@format_gate_as_qasm.register
def _(op: hl.XCD, wire_to_str: dict[Any, str], precision: int | None = None) -> str:
if precision:
params = [f"{p:.{precision}f}" for p in op.parameters]
else:
params = list(map(str, op.parameters))
gate_name = "cv_xcd"
wires = [wire_to_str[w] for w in op.wires]
param_str = "(" + ", ".join(params) + ")" if params else ""
wire_str = ", ".join(wires)
gate_str = f"{gate_name}{param_str} {wire_str};"
return gate_str
```
The arguments to the implementation are:
- `op`: The operator that is being encoded.
- `wire_to_str`: A dictionary mapping the wires in the circuit to their OpenQASM labels (e.g. `m -> m[3]`).
- `precision`: An optional number of decimal places to use when writing out angle parameters.
Additionally, the implementation must follow the rules of [functools.singledispatch](https://docs.python.org/3/library/functools.html#functools.singledispatch) in order for it to work properly, for which you have two options:
- The primary format is to type-hint the variable `op: hl.XCD`. You can reuse an implementation for multiple gates by using a union type like `hl.XCD | hl.YCD`.
- You could choose to pass the operator type to the decorator instead like `@format_gate_as_qasm.register(hl.XCD)`, particularly if you're programmatically generating some implementations.
With this accomplised, let's encode our circuit. `hl.to_openqasm` uses the familiar functional style you've seen in many PennyLane functions like `qp.specs`.
```python {.marimo}
ir = hl.to_openqasm(hw_qnode, level="device", precision=5)(2.0)
print(ir)
```
OPENQASM 3.0;
include "stdgates.inc";
include "cvstdgates.inc";
qubit[2] q;
qumode[1] m;
def state_prep() {
reset q;
reset m;
rz(6.28319) q[0];
cv_xcd(2.00000, 0.00000) q[0], m[0];
rz(6.28319) q[0];
rz(3.14159) q[1];
ry(1.57080) q[1];
cv_xcd(2.00000, 1.57080) q[1], m[0];
rz(6.28319) q[1];
cv_xcd(-2.00000, 0.00000) q[0], m[0];
rz(6.28319) q[0];
cv_xcd(-2.00000, 1.57080) q[1], m[0];
rz(3.14159) q[1];
ry(1.57080) q[1];
gphase(-25.13274) ;
}
state_prep();
bit[1] c0;
c0[0] = measure q[0];
Evident from the above example, hybridlane's OpenQASM added a few modifications:
- It includes both the OpenQASM standard library of qubit gates (`stdgates.inc`) and our custom CV-DV standard library (`cvstdgates.inc`).
- The register definitions preserved the type information, with a dedicated qumode register `m`.
- Our non-standard $xCD$ gate was encoded as `cv_xcd` in the `state_prep()` routine.
Parsing this would require a modified OpenQASM parser, but that could be created relatively easily by adjusting the grammar definition.