QubiCSV

An open-source data storage and visualization platform for collaborative qubit control

Research context and related work

QubiCSV supports the experimental work surrounding quantum computation: maintaining calibration settings, sharing them among collaborators, and inspecting the measurements produced with those settings. The paper concerns superconducting qubits controlled through the QubiC system at Lawrence Berkeley National Laboratory (LBNL), rather than visualization of a quantum algorithm's abstract state or circuit structure. QubiC uses classical control electronics to generate radio-frequency pulses and collect qubit readout, while frequent calibration and characterization help researchers respond to environmental drift and hardware imperfections. Figure 1 shows the physical setting, including control systems shared by researchers and a dilution refrigerator that houses the quantum processor.

Calibration and characterization describe different parts of this workflow. Calibration data specifies how the control system should operate, including qubit drive and readout frequencies and gate parameters such as amplitude, phase, pulse duration, and envelope. Characterization data records measured behavior, including preparation and readout quantities, single-qubit randomized-benchmarking infidelity, readout separation, and coherence times. The paper situates QubiC among contemporary commercial and open-source control systems and relates QubiCSV to VACSEN, QVis, and IBM's calibration-data facilities. Its argument is that noise and error inspection alone does not supply the shared storage, version tracking, and result exploration needed for a team's calibration workflow. This is the authors' motivation for a broader operational platform, rather than evidence of an exhaustive comparison of all prior tools.

Problem and design requirements

The underlying problem is familiar collaborative data management, specialized to experimental quantum control. Researchers previously kept local JSON calibration files and requested particular versions directly from the people who had created them. As experiments, qubits, and gates multiplied, it became harder to establish which settings belonged to which revision, recover earlier configurations, and share changes without losing track of individual work. Experimental result files such as chip_name.data.json also needed persistent storage and a way to compare measurements over time. The importance of the problem comes from the repeated, expensive experimental work represented by these files and the need to use shared hardware effectively.

The authors derive requirements from work with the LBNL team, whose roles included interns, postdoctoral researchers, control engineers, and staff physicists. The platform should support collaborative access, historical tracking, comparison of calibration settings and experimental outcomes, and both graphical and Python-based interaction. The Python interface preserves the team's established Jupyter Notebook workflow, while the web interface makes stored data and charts accessible without requiring users to write their own analysis code. The paper mentions a user study in its design rationale, but does not give a participant count, study protocol, or detailed analysis of user-study results.

Architecture and data versioning

QubiCSV combines a web application, a Python library, a REST API, and two databases in a Model-View-Controller-inspired architecture. Figure 3 separates the interfaces from the API controller and database model, while Figure 2 places this architecture within the quantum-control workflow. In that conceptual diagram, calibration configurations enter the compilation of quantum algorithms into pulse programs, the control electronics generate signals for the quantum processor, and measured results return through readout and post-processing. QubiCSV provides storage and visualization around this workflow; the diagram does not establish an automatic algorithm for finding an optimal calibration.

Calibration files are stored in Dolt, which provides Git-like versioning over SQL data. The schema in Figure 5 contains chip, qubit, and gate tables, with the chip identifier linking a chip to its qubits and gates. Qubit records hold frequency-related properties, while gate records retain fields such as destination, phase, start time, amplitude, duration, and JSON envelope data. The authors initially considered MySQL with timestamps and tags, but selected Dolt to avoid implementing custom branching and revision management around frequent calibration updates.

Users can create, copy, rename, and delete branches, upload calibration data, commit revisions with author information and messages, inspect history, compare commits, and merge branches. Figure 4 illustrates multiple researchers accessing shared branches and successive database versions; it is a workflow schematic rather than a measured collaboration trace. Dolt also requires users to resolve cell-level merge conflicts, with choices such as retaining one side or resolving a conflict manually. Figure 6 shows the implemented web dashboard: a branch list, commit history, qubit and gate tables, a commit-difference table, and a branch-creation dialog. These tables provide exact values and revision context alongside the plots, allowing a user to inspect a changed configuration rather than infer every difference visually.

Characterization results use MongoDB because the experimental JSON records are semi-structured and may grow over long-term monitoring. The described structure associates each qubit with an ExperimentData array, to which new characterization records are appended; chip information is obtained from the uploaded filename. The stored properties include prep0read1, prep1read0, rb1qinfidelity, separation, t1, t2ramsey, and t2spinecho. The first group concerns preparation, readout, gate quality, and readout-state separation, while $T_1$ describes energy relaxation and the two $T_2$ measurements concern dephasing under Ramsey and spin-echo experiments. The detailed implementation assigns branching and commit-based versioning to calibration data in Dolt and accumulated experimental records to MongoDB; it does not demonstrate identical version-control operations for both databases.

Visual encodings and interaction

The visualization interface is built with Vuetify and Plotly.js, with Flask handling backend processing and API requests. Calibration exploration begins by selecting a branch and chip. The by-commit view then presents the calibration state at one selected revision, while the by-property view follows an individual qubit or gate property across revisions. This distinction matters because differences among devices at one commit and changes to one device across commits answer different questions.

Figure 7 shows four aligned line charts for a single commit. The first three plot gate amplitude against categorical gate identifiers, separating readout, $X90$, and cross-resonance gates into groups, while the fourth plots frequency in GHz against qubit identifiers. Distinct colored lines distinguish the plotted amplitude series or drive, e-f transition, and readout frequency series. The commit hash, author, time, and message appear above the charts and establish which stored configuration is being viewed. The horizontal axis in these plots enumerates gates or qubits, so the connecting lines compare categories rather than show temporal evolution. The grouping makes similar gate parameters easier to inspect together, but the paper does not evaluate alternative visual encodings.

Figure 8 changes the horizontal axis to successive commits and shows two historical examples: the amplitude of the $Q1X90$ gate and the drive frequency of qubit $Q1$. The vertical axes retain the selected parameter's units or scale. These charts reveal where a setting changed or remained stable between revisions and help users identify a configuration to inspect further. They show a sequence of saved settings rather than a continuous record of hardware drift or evidence that a particular revision improved performance.

Characterization exploration begins with a chip selection and offers navigation by qubit or by property. The first route examines several measured properties of one qubit across experiments; the second examines a chosen property across the qubits and their experiments. Figure 9 shows the two selection dashboards and example time-based plots for $Q0$. The plots position measured values vertically against timestamps horizontally and include vertical error bars. The figure demonstrates the displayed uncertainty marks, but the paper does not explain their statistical definition, so they should not be interpreted as a specified confidence interval. The documented plot interactions include zooming, panning, automatic axis scaling, and screenshot export. Together, the filters, revision context, tabular views, and plots support manual comparison and anomaly inspection; automated diagnosis or calibration optimization is not demonstrated.

Implementation, performance, and evidence

The authors report that QubiCSV was implemented, deployed on a server, and integrated with QubiC. They provide repositories for the main application, deployment scripts, and Jupyter integration, together with a user manual and sample calibration and characterization files. The study uses data from the control workflow rather than an external benchmark dataset. Its strongest concrete evidence consists of the implemented interfaces, example stored data and plots, and a browser performance profile. The paper does not report a controlled comparison of analysis accuracy, collaboration efficiency, calibration time, or achieved qubit performance with and without QubiCSV. Consequently, claims about improved productivity and optimization describe intended or reported practical benefits rather than quantified experimental effects.

The paper reports API responses below 500 ms, without a detailed endpoint-specific latency distribution or concurrent-user benchmark. Its discussion of Dolt cites standard sysbench comparisons with MySQL rather than a controlled comparison of complete QubiCSV workflows. The performance section gives approximately $1.9\times$ overall latency, with $1.3\times$ for writes and $2.3\times$ for reads, while the methods section instead gives approximately $2\times$, $1.5\times$, and $2.5\times$ respectively. The paper does not reconcile these values; its consistent conclusion is that the authors accepted additional database latency in exchange for versioning. These historical figures should not be treated as current measurements of either database.

Figure 10 presents a Chrome Developer Tools trace described as a roughly 30-second run with a $4\times$ CPU slowdown. The screenshot itself totals 32,005 ms, including 5,349 ms of scripting, 3,442 ms of rendering, and 21,009 ms of idle time. The caption gives different scripting and rendering values, and the prose also slightly differs on idle time. The trace demonstrates the recorded browser workload, but substantial idle time alone does not establish responsiveness under all interactions or scalability to larger datasets. The paper's interpretation of efficient Plotly rendering should therefore be read as evidence from this example profile.

The retained image reproduces Figure 10, an application-performance profile, rather than a qubit-data visualization. Its screenshot and original caption contain the differing timing values discussed above.

Contributions, limitations, and future work

The main contribution is an implemented integration of collaborative calibration versioning, persistent characterization storage, and interactive plotting within a quantum-control team's existing workflow. The system connects familiar database and interface techniques to concrete experimental entities, including chips, qubits, gates, commits, and measurement histories. Its visualization contribution lies in making these records accessible through complementary snapshots, historical charts, and tables; the paper does not establish a new general visual encoding or a mathematically derived control method.

The authors explicitly identify the need to make the visualizations more intuitive and informative. They also propose collaboration with other research groups and adaptation to additional control systems, for which database schemas, API structures, and interfaces may need modification. The demonstrated deployment remains QubiC-specific, and the paper does not establish portability through deployments on multiple control platforms or validate large-scale performance under a stated workload. Future integration of machine learning for long-term characterization analysis, feedback, and mitigation of environmentally induced drift is proposed rather than implemented and evaluated in this work.