The Ireland Quantum SDK — Python, Qiskit interop, OpenQASM 3

Why we are shipping a Python-first SDK

Most working quantum researchers in 2025 live inside a Jupyter notebook. They import Qiskit, PennyLane, or Cirq; they prototype an ansatz; they run it on a simulator; eventually they queue it against a remote backend and wait. Asking that audience to learn a bespoke gate vocabulary or a proprietary submission format every time a new machine comes online is a tax on science, and we are not going to charge it.

The Ireland Quantum SDK is therefore deliberately conservative in scope. It is a Python package — installable from PyPI as iq100 — that exposes our 100-qubit transmon backend through the interfaces researchers already use. It compiles to OpenQASM 3. It registers as a BackendV2 for Qiskit. It exposes a PennyLane device for variational workflows, and a transpiler shim for Cirq users. The physical machine is sovereign and Irish; the programming model is the same one every quantum chemist already has muscle memory for.

Qiskit interop: BackendV2, primitives, and the transpiler

The integration point with Qiskit is qiskit.providers.BackendV2. When you instantiate IrelandQuantumProvider().get_backend("iq100") you receive a backend object that reports its real CouplingMap, its Target with calibrated single- and two-qubit gate durations, T1 and T2 coherence figures per qubit, and the current readout-error matrix. The Qiskit transpiler treats it like any other hardware backend: transpile(circuit, backend=iq100, optimization_level=3) will route, schedule, and SABRE-map your circuit onto our heavy-hex layout without you writing a line of vendor-specific code.

We support the Sampler and Estimator primitives directly. For variational workloads — VQE, QAOA, ADAPT-VQE — that means the inner expectation-value loop runs through the same EstimatorV2 contract you would use against any IBM-compatible system, with grouped Pauli measurement and shot-budget control. Pulse-level access via Qiskit's deprecated pulse module is not on our supported surface; for low-level control we expose our own pulse IR (see below) which is closer to the underlying OpenPulse semantics and avoids inheriting an interface its upstream maintainers are sunsetting.

Heavy-hex topology and what it means for your transpile

The 100-qubit chip uses a heavy-hexagonal connectivity graph — degree-3 data qubits with degree-2 ancilla connectors — chosen because it minimises frequency-collision risk in fixed-frequency transmons and because it is the topology the surface-code roadmap (and specifically the heavy-hex code) is best characterised on. In practical terms, your transpiled circuit will see SWAP overhead on dense all-to-all interactions; the SDK's iq100.layout.suggest() helper will pre-route common chemistry ansätze (UCCSD, k-UpCCGSD, hardware-efficient) onto the lattice with reasonable depth budgets so you are not fighting the router blind.

OpenQASM 3 as the wire format

Every circuit submitted to Ireland Quantum is serialised to OpenQASM 3 before it leaves the client. We picked QASM 3 over QASM 2 because the workloads we care about — variational chemistry, mid-circuit measurement, dynamic-circuit error mitigation — need its real features: classical control flow (if, while), duration and stretch for timing-aware scheduling, real-valued classical registers, and extern for calls into our calibrated gate library.

The SDK ships a round-trip-stable parser. You can write QASM 3 by hand, load it with iq100.qasm.load("circuit.qasm"), manipulate it as a Qiskit QuantumCircuit, and emit it back with dumps() without semantic drift. For groups standardising on QASM 3 as their lingua franca — and for journals that increasingly want a portable circuit artefact alongside a paper — that round-trip property matters more than any clever compiler optimisation we could bolt on top.

Pulse-level programs use a separate IR derived from OpenPulse grammar, expressed as QASM 3 cal and defcal blocks. Access is gated — uncalibrated pulse sequences can move qubits off-resonance and waste fridge time — but research collaborators with a justified need will get it.

PennyLane, Cirq, and the variational workflow

For users coming from the differentiable-programming side, the SDK registers a PennyLane device under the name iq100.qubit. It supports parameter-shift and finite-difference gradients out of the box, with adjoint differentiation available against our local statevector simulator for circuits up to 28 qubits — useful for debugging an ansatz before you spend wall-clock on the real device. The PennyLane device honours shots, diff_method, and the standard qml.expval / qml.probs measurement surface.

Cirq users get a one-shot transpiler: iq100.cirq.to_qasm3(cirq_circuit) emits a QASM 3 program our queue accepts directly. We are not maintaining a full Cirq Sampler wrapper — duplicating that surface area is not a good use of engineering time when the QASM 3 bridge is honest and lossless.

Job submission, queuing, and the local simulator

Submission is asynchronous and JWT-authenticated. backend.run(circuit, shots=8192) returns a JobV1 handle; results come back as a Qiskit Result with per-shot bitstrings, readout-error-mitigated counts (if requested), and a metadata block containing the actual gate-time budget consumed, the calibration epoch your circuit ran against, and the qubits it was mapped to. That metadata is not optional — reproducibility in NISQ-era chemistry depends on knowing exactly which physical qubits ran your VQE iteration and what their T1 looked like that morning.

The SDK ships with a noise-aware local simulator pre-loaded with the latest Ireland Quantum calibration snapshot. You can develop offline, get realistic shot statistics, and only burn fridge time when your ansatz has converged on the simulator. For the climate cohort — carbon-capture amine screens, perovskite photovoltaic candidates, battery cath