---
title: 'QuarterMap: Quantum Circuit Mapper'
url: https://www.emergentmind.com/topics/quartermap
type: topic
---

# QuarterMap: Quantum Circuit Mapper

Searching arXiv for "QuarterMap" and closely related terms to ground the article in current paper records.
Searching arXiv for "MQT QMAP", "Quarter sampling", and "quarter plane conformal map".
QuarterMap, in the toolkit context, refers to **MQT QMAP**, an **open-source quantum circuit mapping tool** in the **Munich Quantum Toolkit (MQT)**. Its purpose is to transform a circuit formulated on **logical/virtual qubits** into a circuit executable on a target device with **physical qubits** and a restricted **connectivity graph**, while keeping mapping overhead low. The tool is positioned as an **efficient, automated, and accessible** solution to the quantum circuit mapping problem and combines an **exact mapper** for optimal solutions on small instances with a **heuristic mapper** for larger instances [2301.11935].

## 1. Definition and problem domain

Quantum algorithms are commonly specified as gate sequences acting on abstract qubits, often under the implicit assumption that any pair of qubits can interact. Actual quantum hardware imposes two independent constraints. First, the circuit must be expressed in the device’s **native gate set**. Second, two-qubit gates must respect the hardware **topology / connectivity constraint**, meaning that such gates can only be applied to qubit pairs connected in the device’s **coupling map**. QuarterMap addresses the second problem directly by assigning logical qubits to physical qubits and inserting routing operations so that all required interactions become executable [2301.11935].

The problem is operationally centered on **qubit allocation / initial layout** and **routing**. Allocation determines where each logical qubit starts on the hardware. Routing then moves qubits indirectly, typically by inserting **SWAP gates**, until interacting qubits become adjacent or otherwise compatible with the architecture. Because present-day devices are highly error-sensitive, every additional operation affects execution quality. For that reason, QuarterMap treats mapping quality in terms of costs such as **(two-qubit) gate count**, **circuit depth**, and **expected fidelity**, with particular emphasis on the number of added SWAPs [2301.11935].

## 2. Optimization objective and hardware model

The quantum circuit mapping task is described as **NP-hard**. In practical terms, the optimization target is to satisfy connectivity constraints while minimizing added overhead, especially the routing overhead introduced during compilation. In the formulation highlighted by QuarterMap, this is closely approximated by
\[
\text{minimize mapping overhead} \quad \approx \quad \text{minimize added SWAP gates}.
\]
The **exact mapper** is explicitly characterized as producing **gate-optimal** solutions, i.e., solutions with the **minimal number of SWAP gates** [2301.11935].

The hardware model used by QuarterMap focuses mainly on **superconducting qubit architectures**, where sparse connectivity is a dominant systems constraint. Connectivity is represented by a **coupling graph / coupling map**, whose edges indicate which qubit pairs can participate in a two-qubit gate. The graph may be represented as directed, but the paper notes that it is often effectively undirected in practice. IBM devices are used as reference architectures, including **ibm_washington**, a **127-qubit device with sparse connectivity**, and **ibm_oslo**, a **7-qubit architecture** used in an example walkthrough. Sparse coupling is the core reason routing becomes necessary at all [2301.11935].

This hardware framing makes QuarterMap part of the compilation layer that mediates between algorithm-level circuit design and architecture-level execution constraints. A plausible implication is that its value lies less in altering circuit semantics than in controlling the compilation penalty induced by realistic machine topologies.

## 3. Mapping strategies

QuarterMap provides two principal algorithmic modes. One targets optimality on small instances; the other targets scalability on larger workloads. The distinction is fundamental to the tool’s design [2301.11935].

| Strategy | Core method | Scope |
|---|---|---|
| Exact mapping | **MaxSAT** encoding solved with **Z3** | **Minimal number of SWAP gates**; typically scalable only up to roughly **8 qubits** and around **1000 gates** |
| Heuristic mapping | **A\*** search | Circuits with **hundreds of qubits** and **hundreds of thousands of gates** |

The **exact mapper** encodes the mapping task as a **MaxSAT** instance and solves it with the **Z3 SMT solver**. Its defining property is optimality with respect to added SWAP count. This comes at substantial computational cost, so the method is suitable only for relatively small circuits. The paper identifies two search-space reduction ideas used internally: **restricting permutations before each layer**, so that only enough permutations are considered to make interacting qubits adjacent, and **restricting subarchitectures**, so that search is confined to viable hardware subgraphs rather than the full architecture [2301.11935].

The **heuristic mapper** is based on **A\*** search and is intended for cases where exact optimization is infeasible. It decomposes mapping into **initial layout** and **routing**, and supports three initial layout strategies: **identity layout**, where logical qubit \(q_i\) maps to physical qubit \(Q_i\); **static layout**, which inspects the first circuit layer and places interacting qubits on connected hardware qubits; and **dynamic layout**, which assigns qubits greedily on demand during mapping. The paper emphasizes that better initial layouts can materially improve routing quality [2301.11935].

A notable current limitation is that the heuristic mapper assumes the circuit’s two-qubit gates are **CNOTs**. The authors identify this as a limitation and a natural extension point for alternative hardware-native gate sets such as **CZ** [2301.11935].

## 4. Software architecture and workflows

QuarterMap is designed to be usable both from a research-user perspective and from a developer perspective. At the implementation level, the core is written in **C++**, exposed through **Python bindings**, and relies on **MQT QFR** for quantum functionality representation. Development requires **C++17**, **CMake 3.19+**, and **Z3 4.8.15+** for the exact mapper. The codebase also includes **unit tests**, **linting and formatting tools**, and **CI workflows across major operating systems** [2301.11935].

From the user side, the tool is intended to integrate naturally with Python-based quantum software stacks. Architectures can be specified either directly from a **Qiskit backend** or by constructing them from a **coupling map**. Input circuits can be provided using **Qiskit** or formats such as **OpenQASM**. Mapping is exposed as a one-line compile call, returning both the mapped circuit as a **Qiskit QuantumCircuit** and a result object containing statistics such as the number of added SWAPs and runtime. The documentation is listed at **mqtqmap.readthedocs.io**, and the software is publicly available as open source at **https://github.com/cda-tum/qmap** [2301.11935].

This dual orientation—research-grade algorithms with accessible packaging—explains the paper’s emphasis on QuarterMap as both an algorithmic contribution and a software-engineering artifact. It is meant to be installable, interoperable, and extensible, not merely a proof-of-concept mapper.

## 5. Example mapping results and trade-offs

The paper illustrates QuarterMap on a **5-qubit VQE-style circuit** mapped to the **7-qubit ibm_oslo architecture**. The example is used to compare naive compilation, exact mapping, and heuristic mapping under the same topology [2301.11935].

A **naive mapping** introduces **4 SWAP gates** and **1 additional qubit**. The **exact mapper** finds a solution with **0 SWAP gates** and **0 additional qubits**, but requires on the order of **seconds**. The **heuristic mapper** produces a solution with **2 SWAP gates** and **1 additional CNOT gate**, while running in **less than a millisecond**. The example therefore exhibits the principal design trade-off explicitly: **exact = better quality, slower**; **heuristic = slightly worse quality, much faster** [2301.11935].

The significance of this example is not limited to the specific circuit. It demonstrates that mapping quality can vary sharply even for modest instances, and that the cost function relevant to near-term hardware is not abstract asymptotic complexity alone. Extra SWAPs, extra CNOTs, and extra qubit usage translate directly into greater noise exposure and lower expected fidelity. QuarterMap therefore occupies a practical optimization layer where algorithmic solvability and physical executability meet.

The paper also notes unresolved structural issues in the exact approach. A brute-force treatment of subarchitectures remains expensive, **subarchitecture isomorphism is not fully exploited**, and **considering more qubits may sometimes yield better optimal mappings**. These observations show that even the “optimal” mode is optimal relative to a particular encoding and search strategy rather than a fully exhausted architectural meta-space [2301.11935].

## 6. Terminological scope and related usages

Within the supplied arXiv corpus, **QuarterMap** is most directly grounded as the toolkit-context name for **MQT QMAP**. The same corpus also shows that the label is not uniformly standardized across other research areas. In the paper on discrete and continuous polyharmonic functions in the quarter plane, there is **no symbol or named object “QuarterMap”**; instead, the structurally analogous object is a conformal map \(w\) used to solve quarter-plane boundary value problems [2211.11232]. In the paper on compander-aligned zeroth-order optimization, the authors likewise state that the paper **does not mention** the term, although it studies a quantizer-induced map
\[
Q=\phi^{-1}\circ U\circ \phi
\]
and a map-aware query rule [2605.10673].

This suggests that **QuarterMap** is best understood as a **toolkit-specific designation** rather than a cross-disciplinary technical term with a single established definition. In quantum compilation, it denotes a concrete software system for circuit mapping. In other areas, superficially similar expressions involving “quarter,” “map,” or mapping on quarter domains refer to unrelated analytic, geometric, or sensing constructions. Recognizing this distinction avoids a common misconception: QuarterMap is not, in the present usage, a generic quarter-plane conformal map, a quarter-sampling reconstruction method, or a quantizer-aware optimization map, even though those topics also involve mathematically meaningful mappings [2301.11935].

In that sense, QuarterMap belongs to the vocabulary of practical quantum compilation: a mapping tool that takes the abstract combinatorics of a circuit and reconciles them with the sparse connectivity and execution constraints of actual quantum hardware.

Source: https://www.emergentmind.com/topics/quartermap