Challenges
Datasets
Workspaces
Papers
Discussions
Leaderboard
Log inSign up
Challenges
Datasets
Workspaces
Papers
Discussions
Leaderboard
Blog
Job Board
Q3AS

© 2026 Aqora Quantum S.A.S.

TermsPrivacyLegal Notice

arXiv:2111.13124

An Architecture for Meeting Quality-of-Service Requirements in Multi-User Quantum Networks

Matthew Skrzypczyk, Stephanie Wehner

Published Jun 21, 2021• 7 citations
arXivHTMLPDF

Abstract

Quantum Network Architecture Scheduling simulation data The .zip-files in this DataVerse contains data used in the paper: An Architecture for Meeting Quality-of-Service Requirements in Multi-User Quantum Networks General info All the raw-data can be found as JSON (.json) files. Simulation parameters used can be found in each .zip file in the folder config. For the simulations using the star, H, symmetric, and line topologies, we assume the following properties on each link: Distance: 5km Link Capabilities: [ (Fidelity=0.88, Rate=14.16 Hz), (Fidelity=0.83, Rate=20.84 Hz), (Fidelity=0.79, Rate=27.83 Hz), (Fidelity=0.75, Rate=33.98 Hz), (Fidelity=0.70, Rate=39.18 Hz), (Fidelity=0.66, Rate=45.6 Hz), (Fidelity=0.62, Rate=51.26 Hz), (Fidelity=0.57, Rate=57.73 Hz), ] For the simulations using the SURFnet topology, the link lengths are based on fiber data obtained from SURF while we assume each link has a single capability of (Fidelity=0.999, Rate=1.4kHz). All simulations were performed using a schedule slot size of 1ms. Data Format Each simulation JSON is formatted in the following way: { "date-key": { "fidelity-key": { "load-key": { "scheduler-key": { "jitter": (maximum jitter), "throughput": (achieved throughput), "wcrt": (maximum worst-case response time), "satisfied_demands": (list of string-encoded (S, D, F, R, ID) tuples), "unsatisfied_demands": (list of string-encoded (S, D, F, R, ID) tuples) }, ... }, ... }, ... }, } For the star, H, symmetric, and line topologies, we simulate minimum fidelity requirements from the set (0.55, 0.6, 0.65, 0.7, 0.75, 0.8, 0.85) while for the SURFnet topology we simulate minimum fidelity requirements from the set (0.98, 0.985, 0.99, 0.995, 0.997). For all topologies we simulate network loads from the set (0.5, 1, 2, 3, 4, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 60, 80, 100) ebit/s. Reproducing Plots The plots found in the paper may be reproduced using the analysis.py script located within the analysis.zip archive. Usage is as follows. For the Throughput vs. Load plots: python analysis.py <path/to/result/directory/> load --fidelities [space-separated set of fidelities] For the Throughput CDF plots: python analysis.py <path/to/result/directory/> cdf --fidelities [space-separated set of fidelities] --load [load] For the Throughput vs. Jitter plots: python analysis.py <path/to/result/directory/> jitter --fidelities [space-separated set of fidelities] --load [load] Other notes Here, we only simulate the scheduling of quantum repeater protocols, the execution of the protocols was not simulated. The estimated fidelity of each repeater protocol selected only considered fidelity increase/decrease due to entanglement distillation and entanglement swapping. Each entangled link is assumed to be stored perfectly between operations. Repeater protocols are constructed assuming that nodes may perform operations in parallel. Repeater protocols are constructed assuming any pair qubits at a network node can be used for entanglement swapping or entanglement distillation. Repeater protocols are constructed assuming any pair of communication qubits at two connected nodes can be used to create entanglement. Data The DataVerse contains the following zip files: analysis.zip - Contains the analysis.py script and a requirements.txt file for producing plots from simulation data. 20201125-012501-star_topology_simulations*.zip - Contains scheduling simulation data on the three-node star topology. 20201203-130920-H_topology_simulations*.zip - Contains scheduling simulation data on the H topology. 20210624-070333-symmetric_topology_simulations*.zip - Contains scheduling simulation data on the symmetric topology. 20201129-143606-line_topology_simulations*.zip - Contains scheduling simulation data on the line topology. 20210615-202940-surfnet_topology_simulations*.zip - Contains scheduling simulation data on the SURFnet topology. (2021-06-21)

DOI
10.34894/5eogaf

Related papers

Towards near-term quantum simulation of materials

Laura Clinton, Toby S. Cubitt, Brian Flynn +6 more

Overview of data provided in support of Towards near-term quantum simulation of materials Contents of this folder: `analyse_materials_results.py`: script used to generate the summary tables and figures presented in the manuscript. `towards_quantum_simulation_data`: raw data used and produced when studying various 3D materials. `towards_quantum_simulation_analysis`: tables (in `.tex` format) and figures (as PDFs) presented in the manuscript. The contents of `towards_quantum_simulation_analysis` were generated by `analyse_materials_results.py`, i.e. the user need not run the script to produce the output files. Users can generate these analyses directly by running ```python analyse_materials_results.py```, though note the following packages will first need to be installed: `pandas >= 1.2.3` `numpy >= 1.23` `seaborn >= 0.11.1` `lfig >= 0.1.3` `matplotlib > 3.7.0` Included data Within `towards_quantum_simulation_data`, there are subfolders for each of the materials described in the manuscript, i.e. `SrVO3`, `GaAs`, `H3S`, `Si`, `Li2CuO2`. Within each material's folder are further subfolders for the `hamiltonian` and `encoding` used to represent the material, as well as subfolders for each of the `algorithms` studied. `hamiltonian`: files which specify the Hamiltonian for the material under study. There are a number of files `interactions.json` Hamiltonian terms in terms of Majorana monomials. `map_majorana_to_mode.json` keys are Majorana indices; values are the mode index to which they are associated. `map_mode_to_group.json` keys are mode indices; values are the group (or site) index to which they are associated. `map_group_to_position.json` keys are group indices; values are the corresponding 3D Cartesian coordinates of the lattice used to represent the material. `stage_data.json` contains key/value pairs of any other fields of interest. `encoding` files which specify the fermionic encoding which is customised for the material under study. `encoding.json` which details the edges of the hybrid compact encoding described in Section VI of the supplementary material. `precompiler.json` contains all the information which permits the encoding construction, including the Hamiltonian terms (`_interactions`) which match those in `hamiltonian/interactions.json`. The same mappings as present in the Hamiltonian data(a.g. `map_group_to_position`). `stage_data.json` contains key/value pairs of any other fields of interest. `algorithms` contains subfolders for each of the algorithms desribed in the manuscript Those explored for circuits depths: `TDSSplitTermsPriorityCircuitDepth` (TDS in the manuscript) `TDSSplitTermsPriorityCircuitDepthNoSwapNetwork` (TDS\*) `VQESplitTerms` (VQE) `VQESplitTermsNoSwapNetwork` (VQE*) each of which contain the files, inside the `circuitry` folder: `circuit_terms.csv`, which lists each individual term, together with their Pauli string and rotation angle, required to construct the corresponding quantum circuit `circuit_layers_to_implement.csv` groups the same terms into layers to achieve parallelism in the circuit. `stage_data.json` contains key/value pairs of any other fields of interest. and those used to compose measurement layers, as outlined in Section VII D of the supplementary material: `MeasurementCommutativity` `MeasurementNaiveQubitwise` `MeasurementNonCrossing` each of which contain the files, inside the `compilation` folder: `layers.csv` lists the terms which may be measured simultaneously to achieve the measurement strategies shown in Table S14. `stage_data.json` contains key/value pairs of any other fields of interest. CSV files In `towards_quantum_simulation_data`, there are unified CSV files containing the results of applying the procedures described in the manuscript to the target materials. `circuit_costs.csv`: results of running the circuit compiler described in the manuscript. `measurements.csv`: results of running the measurement compiler described in the manuscript. These CSVs are used in the analysis script `analyse_materials_results.py` to produce the figures and tables presented in the manuscript.

arXiv:2205.15256•May 30, 2022•8 citations

Design and Evaluation of Communication Protocols for Quantum Repeater Networks

Luciano Aparicio

When built, quantum repeater networks will require classical network protocols to control the quantum operations. However, existing work on repeaters has focused on the quantum operations themselves, with less attention paid to the contents, semantics, ordering and reliability of the classical control messages. In this work we define and describe our implementation of the classical control protocols. The state machines and packet sequences for the three protocol layers are presented, and operation confirmed by running the protocols over simulations of the physical network. We also show that proper management of the resources in a bottleneck link allows the aggregate throughput of two end-to-end flows to substantially exceed that of a single flow. Our layered architectural framework will support independent evolution of the separate protocol layers. Networks of quantum repeaters utilize three concepts to execute a distributed algorithm that creates entangled quantum states between nodes that are far apart: a basic entanglement mechanism which depends on the physical implementation, error management (in this work, we study a method known as purification), and finally a quantum state propagation layer (here we implement entanglement swapping, which builds multi-hop connections from single-hop connections). Some researchers are investigating approaches that are substantially different from entanglement swapping [30, 24, 19]. Here we focus on swapping, but the layered architecture approach is broadly applicable, allowing other implementations to replace only a single layer in the protocol stack. Previous work primarily focused on the physical and mathematical tools for building repeaters. Classical information is also needed to enable teleportation and swapping, as many quantum operations are not deterministic, and results of quantum measurements need to be reported to distant partners before further operations can proceed. Also, operations in the middle of the network must be coordinated to route and swap properly. This requires classical messages to make operations robust, but message propagation times penalize performance. Even though this delay is usually included in repeater simulations, prior work has not defined the protocols in detail, especially with respect to how all of the nodes make consistent decisions in a timely fashion. In this work, we introduce a protocol stack for networks of quantum repeaters that considers all the necessary classical messages and which can be easily adapted for different approaches at all three protocol layers. We run simulations of competing flows on a dumbbell topology in order to increase our confidence in the behavior of our network protocols. By adjusting the fidelity thresholds required for entanglement swapping, we show that some configurations boost the aggregate throughput for multiple flows significantly above the maximum for a single flow, taking advantage of resources that would otherwise sit idle. The operation of such complex networks and such delicate tuning of the system without formal protocol definitions would not be possible. Previous work has also concentrated almost exclusively on the dedicated use of a single line or chain of repeaters, delivering Bell pairs only to the two nodes at the ends of the chain. Networks, however, typically have more than two end points, and allow any pair of these end nodes to communicate. More topologically complex networks, with numerous end nodes, are obviously much more scalable than connecting every possible pair of nodes using a dedicated line of repeaters. we investigate how classical multiplexing schemes translate to the domain of quantum repeaters, in order to manage shared resources and active communication flows of data from different stations. We simulate four sharing protocols in a complex network with competing traffic. Circuit switching gives any individual flow the best performance, but makes poor use of the overall network and is inflexible. We use circuit switching as our baseline case to compare time division multiplexing, buffer space multiplexing, and statistical multiplexing, and show that all multiplexing schemes are better than circuit switching. For the particular network simulated, we find that statistical multiplexing outperforms time division multiplexing by 28% and buffer space multiplexing by 13%. We find that all three multiplexing schemes are fair; each flow is penalized a similar percentage of its throughput as the the total number of users in the network increases. Finally, statistical multiplexing requires no network-wide coordination of the use of quantum memory or channels, and is easier to implement than a robust, scalable scheme for the other protocols. Our current results suggest that the best strategy for quantum repeater networks is statistical multiplexing. (This is in fact the quantum analogue of the basis on which the Internet works.) However, our current simulations are done with no degradation of memory over time, using the assumption of quantum error-corrected memory at each repeater; inclusion of decoherence and a finite qubit lifetime remains as future work.

•Sep 27, 2011•2 citations

Engineered non-Gaussian Coherence as a Thermodynamic Resource for Quantum Batteries

Kingshuk Adhikary

This repository contains the numerical data and computational codes supporting the results presented in the manuscript: "Engineered non-Gaussian Coherence as a Thermodynamic Resource for Quantum Batteries". The archive (data_QB.zip) includes all datasets, Jupyter notebooks, and figure files required to reproduce the results reported in both the main text and the Supplemental Material. Each figure is organised in a separate directory containing the corresponding data (.txt), code (.ipynb), and generated plots (.png/.pdf). The provided materials are sufficient to reproduce all figures and results without restriction. Detailed instructions and directory structure are described in the accompanying README.txt file. This dataset is made openly available to ensure transparency and reproducibility of the reported results.

•Apr 11, 2026•0 citations

Supporting documents: Capturing Protein Free Energy Landscape using Efficient Quantum Encoding

Ashwini Kannan, Jaya Vasavi Pamidimukkala, Avinash Dakshinamoorthy +3 more

This record contains the code and input files for our research presented in the paper "Capturing Protein Free Energy Landscape using Efficient Quantum Encoding". Contents: MD_input_files.zip contains the initial structure for each peptides considered, GROMACS topologies and input parameters required to run Molecular dynamics simulations. script.zip folder contains codes used to run VQE simulator and hardware runs script for post MD and quantum simulation free energy landscape analyses

•Oct 16, 2026•0 citations

Sensing with discrete time crystals

Moon, Leo, Schindler, Paul, Smith, Ryan +4 more

# Sensing with discrete time crystals Data Repository This repository contains experimental data, simulation results, and analysis code for Discrete Time Crystal (DTC) sensing research. The data is organized by figure numbers corresponding to the main manuscript and supplementary materials. ## Repository Structure ``` DTC_sensing_Zenodo_Repo/ │ ├── data/ # All experimental and processed data │ ├── raw/ # Raw experimental data files │ │ ├── fig-1/ # Figure 1 raw data │ │ ├── fig-2/ # Figure 2 raw data (fig-2b, fig-2c) │ │ ├── fig-3/ # Figure 3 raw data (fig-3a, fig-3b, fig-3c) │ │ ├── fig-4/ # Figure 4 raw data │ │ └── fig-S1/ through fig-S18/ # Supplementary figures raw data │ │ │ └── processed/ # Processed and analyzed data │ ├── fig-3/ # Processed data for Figure 3 │ └── fig-S14/ # Processed data for Figure S14 │ ├── src_code/ # Source code for analysis and simulations │ ├── simulations/ # Simulation code │ │ ├── SingleToneDTC/ # Single-tone DTC simulations │ │ ├── TwoToneDTC/ # Two-tone DTC simulations │ │ ├── helper.py # Helper functions │ │ ├── setup_system.py # System setup utilities │ │ └── systems.yaml # System configuration parameters │ │ │ └── utils/ # Utility functions │ ├── plotting_utils.py # Plotting and visualization utilities │ └── simulation_utils.py # Simulation utilities │ └── visual_elements/ # Code and notebooks for figure generation ├── main/ # Main manuscript figures │ ├── fig-1/ # Figure 1 generation code │ ├── fig-2/ # Figure 2 generation code │ ├── fig-3/ # Figure 3 generation code │ └── fig-4/ # Figure 4 generation code │ └── supmat/ # Supplementary material figures └── fig-S1/ through fig-S18/ # Supplementary figure generation code ``` ## Data Description ### Raw Data (`data/raw/`) The raw data directory contains experimental measurements organized by figure number: - **File Formats:** - `.mat` files: MATLAB data files containing experimental measurements from the Proteus P9484M NMR spectrometer - `.csv` files: CSV files containing contour and magnetometer data (fig-S1) - `.hdf5` files: HDF5 files containing simulation results (fig-S13-S16) - `.npy` files: NumPy array files - **Data Organization:** - **Main Figures (fig-1 through fig-4):** Core experimental results - **Supplementary Figures (fig-S1 through fig-S18):** Additional experimental data, simulations, and analysis ### Processed Data (`data/processed/`) Processed data contains analyzed and pre-computed results: - **File Formats:** - `.npy` files: NumPy arrays containing processed experimental data - **Available Processed Data:** - `fig-3/`: Processed data for Figure 3 (fig-3a, fig-3b) - `fig-S14/`: Processed data for Figure S14 (AC phase scans, frequency scans, Vpp scans) ## Source Code ### Simulation Code (`src_code/simulations/`) - **SingleToneDTC/**: Code for single-tone DTC simulations - **TwoToneDTC/**: Code for two-tone DTC simulations - **systems.yaml**: Configuration file defining system parameters (N, rmin, rmax, gamma, theta, tau, etc.) - **helper.py**: Helper functions for simulations - **setup_system.py**: System setup and initialization utilities ### Utility Functions (`src_code/utils/`) - **plotting_utils.py**: Functions for data visualization, including matplotlib configuration and plotting routines - **simulation_utils.py**: Utilities for running and analyzing simulations ## Figure Generation ### Visualization Code (`visual_elements/`) Each figure directory contains: - **Jupyter notebooks** (`.ipynb`): Interactive notebooks for data analysis and figure generation OR - **Python scripts** (`.py`): Standalone scripts for figure generation - **Output files** (`.pdf`, `.svg`): Generated figure files ## Requirements All required Python packages are listed in `requirements.txt`. Key dependencies include: - **NumPy** (2.3.5): Numerical computations - **SciPy** (1.16.3): Scientific computing and data analysis - **Matplotlib** (3.10.7): Plotting and visualization - **h5py** (3.15.1): HDF5 file handling - **Pandas** (2.3.3): Data manipulation - **Jupyter/IPython**: Interactive notebooks - **PyYAML** (6.0.3): Configuration file parsing To install dependencies: ```bash pip install -r requirements.txt ``` ## Data Access ### Reading Raw Data Raw experimental data is stored in MATLAB `.mat` format. To read these files in Python: ```python from scipy.io import loadmat data_dict = loadmat('path/to/file.mat') ``` ## Usage 1. **Install dependencies**: `pip install -r requirements.txt` 2. **Navigate to figure directory**: Each figure has its own directory in `visual_elements/` 3. **Run analysis**: Open the Jupyter notebook (`.ipynb`) or Python script (`.py`) for the desired figure 4. **Data paths**: The code assumes data is in the `data/` directory relative to the repository root ## Notes - Raw data files are named with timestamps (e.g., `2024-06-06-125713_Proteus.mat`) indicating when measurements were taken - Some figures contain subdirectories (e.g., `fig-2b/`, `fig-2c/`) for different panels - The repository structure follows the organization of figures in the associated publication

•Nov 28, 2025•1 citation

Quality of Service in Quantum Networks

Claudio Cicconetti, Marco Conti, Andrea Passarella

In the coming years, quantum networks will allow quantum applications to thrive thanks to the new opportunities offered by end-to-end entanglement of qubits on remote hosts via quantum repeaters. On a geographical scale, this will lead to the dawn of the quantum internet. While a fullblown deployment is yet to come, the research community is already working on a variety of individual enabling technologies and solutions. In this article, with the guidance of extensive simulations, we take a broader view and investigate the problems of quality of service (QoS) and provisioning in the context of quantum networks, which are very different from their counterparts in classical data networks due to some of their fundamental properties. Our work leads the way toward a new class of studies that will allow the research community to better understand the challenges of quantum networks and their potential commercial exploitation.

arXiv:2204.09538•IEEE Network•Sep 1, 2022•9 citations
Quantum Network Architecture Scheduling simulation data The .zip-files in this DataVerse contains data used in the paper: An Architecture for Meeting Quality-of-Service Requirements in Multi-User Quantum Networks General info All the raw-data can be found as JSON (.json) files. Simulation parameters used can be found in each .zip file in the folder config. For the simulations using the star, H, symmetric, and line topologies, we assume the following properties on each link: Distance: 5km Link Capabilities: [ (Fidelity=0.88, Rate=14.16 Hz), (Fidelity=0.83, Rate=20.84 Hz), (Fidelity=0.79, Rate=27.83 Hz), (Fidelity=0.75, Rate=33.98 Hz), (Fidelity=0.70, Rate=39.18 Hz), (Fidelity=0.66, Rate=45.6 Hz), (Fidelity=0.62, Rate=51.26 Hz), (Fidelity=0.57, Rate=57.73 Hz), ] For the simulations using the SURFnet topology, the link lengths are based on fiber data obtained from SURF while we assume each link has a single capability of (Fidelity=0.999, Rate=1.4kHz). All simulations were performed using a schedule slot size of 1ms. Data Format Each simulation JSON is formatted in the following way: { "date-key": { "fidelity-key": { "load-key": { "scheduler-key": { "jitter": (maximum jitter), "throughput": (achieved throughput), "wcrt": (maximum worst-case response time), "satisfied_demands": (list of string-encoded (S, D, F, R, ID) tuples), "unsatisfied_demands": (list of string-encoded (S, D, F, R, ID) tuples) }, ... }, ... }, ... }, } For the star, H, symmetric, and line topologies, we simulate minimum fidelity requirements from the set (0.55, 0.6, 0.65, 0.7, 0.75, 0.8, 0.85) while for the SURFnet topology we simulate minimum fidelity requirements from the set (0.98, 0.985, 0.99, 0.995, 0.997). For all topologies we simulate network loads from the set (0.5, 1, 2, 3, 4, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 60, 80, 100) ebit/s. Reproducing Plots The plots found in the paper may be reproduced using the analysis.py script located within the analysis.zip archive. Usage is as follows. For the Throughput vs. Load plots: python analysis.py <path/to/result/directory/> load --fidelities [space-separated set of fidelities] For the Throughput CDF plots: python analysis.py <path/to/result/directory/> cdf --fidelities [space-separated set of fidelities] --load [load] For the Throughput vs. Jitter plots: python analysis.py <path/to/result/directory/> jitter --fidelities [space-separated set of fidelities] --load [load] Other notes Here, we only simulate the scheduling of quantum repeater protocols, the execution of the protocols was not simulated. The estimated fidelity of each repeater protocol selected only considered fidelity increase/decrease due to entanglement distillation and entanglement swapping. Each entangled link is assumed to be stored perfectly between operations. Repeater protocols are constructed assuming that nodes may perform operations in parallel. Repeater protocols are constructed assuming any pair qubits at a network node can be used for entanglement swapping or entanglement distillation. Repeater protocols are constructed assuming any pair of communication qubits at two connected nodes can be used to create entanglement. Data The DataVerse contains the following zip files: analysis.zip - Contains the analysis.py script and a requirements.txt file for producing plots from simulation data. 20201125-012501-star_topology_simulations*.zip - Contains scheduling simulation data on the three-node star topology. 20201203-130920-H_topology_simulations*.zip - Contains scheduling simulation data on the H topology. 20210624-070333-symmetric_topology_simulations*.zip - Contains scheduling simulation data on the symmetric topology. 20201129-143606-line_topology_simulations*.zip - Contains scheduling simulation data on the line topology. 20210615-202940-surfnet_topology_simulations*.zip - Contains scheduling simulation data on the SURFnet topology. (2021-06-21)
Overview of data provided in support of Towards near-term quantum simulation of materials Contents of this folder: `analyse_materials_results.py`: script used to generate the summary tables and figures presented in the manuscript. `towards_quantum_simulation_data`: raw data used and produced when studying various 3D materials. `towards_quantum_simulation_analysis`: tables (in `.tex` format) and figures (as PDFs) presented in the manuscript. The contents of `towards_quantum_simulation_analysis` were generated by `analyse_materials_results.py`, i.e. the user need not run the script to produce the output files. Users can generate these analyses directly by running ```python analyse_materials_results.py```, though note the following packages will first need to be installed: `pandas >= 1.2.3` `numpy >= 1.23` `seaborn >= 0.11.1` `lfig >= 0.1.3` `matplotlib > 3.7.0` Included data Within `towards_quantum_simulation_data`, there are subfolders for each of the materials described in the manuscript, i.e. `SrVO3`, `GaAs`, `H3S`, `Si`, `Li2CuO2`. Within each material's folder are further subfolders for the `hamiltonian` and `encoding` used to represent the material, as well as subfolders for each of the `algorithms` studied. `hamiltonian`: files which specify the Hamiltonian for the material under study. There are a number of files `interactions.json` Hamiltonian terms in terms of Majorana monomials. `map_majorana_to_mode.json` keys are Majorana indices; values are the mode index to which they are associated. `map_mode_to_group.json` keys are mode indices; values are the group (or site) index to which they are associated. `map_group_to_position.json` keys are group indices; values are the corresponding 3D Cartesian coordinates of the lattice used to represent the material. `stage_data.json` contains key/value pairs of any other fields of interest. `encoding` files which specify the fermionic encoding which is customised for the material under study. `encoding.json` which details the edges of the hybrid compact encoding described in Section VI of the supplementary material. `precompiler.json` contains all the information which permits the encoding construction, including the Hamiltonian terms (`_interactions`) which match those in `hamiltonian/interactions.json`. The same mappings as present in the Hamiltonian data(a.g. `map_group_to_position`). `stage_data.json` contains key/value pairs of any other fields of interest. `algorithms` contains subfolders for each of the algorithms desribed in the manuscript Those explored for circuits depths: `TDSSplitTermsPriorityCircuitDepth` (TDS in the manuscript) `TDSSplitTermsPriorityCircuitDepthNoSwapNetwork` (TDS\*) `VQESplitTerms` (VQE) `VQESplitTermsNoSwapNetwork` (VQE*) each of which contain the files, inside the `circuitry` folder: `circuit_terms.csv`, which lists each individual term, together with their Pauli string and rotation angle, required to construct the corresponding quantum circuit `circuit_layers_to_implement.csv` groups the same terms into layers to achieve parallelism in the circuit. `stage_data.json` contains key/value pairs of any other fields of interest. and those used to compose measurement layers, as outlined in Section VII D of the supplementary material: `MeasurementCommutativity` `MeasurementNaiveQubitwise` `MeasurementNonCrossing` each of which contain the files, inside the `compilation` folder: `layers.csv` lists the terms which may be measured simultaneously to achieve the measurement strategies shown in Table S14. `stage_data.json` contains key/value pairs of any other fields of interest. CSV files In `towards_quantum_simulation_data`, there are unified CSV files containing the results of applying the procedures described in the manuscript to the target materials. `circuit_costs.csv`: results of running the circuit compiler described in the manuscript. `measurements.csv`: results of running the measurement compiler described in the manuscript. These CSVs are used in the analysis script `analyse_materials_results.py` to produce the figures and tables presented in the manuscript.
When built, quantum repeater networks will require classical network protocols to control the quantum operations. However, existing work on repeaters has focused on the quantum operations themselves, with less attention paid to the contents, semantics, ordering and reliability of the classical control messages. In this work we define and describe our implementation of the classical control protocols. The state machines and packet sequences for the three protocol layers are presented, and operation confirmed by running the protocols over simulations of the physical network. We also show that proper management of the resources in a bottleneck link allows the aggregate throughput of two end-to-end flows to substantially exceed that of a single flow. Our layered architectural framework will support independent evolution of the separate protocol layers. Networks of quantum repeaters utilize three concepts to execute a distributed algorithm that creates entangled quantum states between nodes that are far apart: a basic entanglement mechanism which depends on the physical implementation, error management (in this work, we study a method known as purification), and finally a quantum state propagation layer (here we implement entanglement swapping, which builds multi-hop connections from single-hop connections). Some researchers are investigating approaches that are substantially different from entanglement swapping [30, 24, 19]. Here we focus on swapping, but the layered architecture approach is broadly applicable, allowing other implementations to replace only a single layer in the protocol stack. Previous work primarily focused on the physical and mathematical tools for building repeaters. Classical information is also needed to enable teleportation and swapping, as many quantum operations are not deterministic, and results of quantum measurements need to be reported to distant partners before further operations can proceed. Also, operations in the middle of the network must be coordinated to route and swap properly. This requires classical messages to make operations robust, but message propagation times penalize performance. Even though this delay is usually included in repeater simulations, prior work has not defined the protocols in detail, especially with respect to how all of the nodes make consistent decisions in a timely fashion. In this work, we introduce a protocol stack for networks of quantum repeaters that considers all the necessary classical messages and which can be easily adapted for different approaches at all three protocol layers. We run simulations of competing flows on a dumbbell topology in order to increase our confidence in the behavior of our network protocols. By adjusting the fidelity thresholds required for entanglement swapping, we show that some configurations boost the aggregate throughput for multiple flows significantly above the maximum for a single flow, taking advantage of resources that would otherwise sit idle. The operation of such complex networks and such delicate tuning of the system without formal protocol definitions would not be possible. Previous work has also concentrated almost exclusively on the dedicated use of a single line or chain of repeaters, delivering Bell pairs only to the two nodes at the ends of the chain. Networks, however, typically have more than two end points, and allow any pair of these end nodes to communicate. More topologically complex networks, with numerous end nodes, are obviously much more scalable than connecting every possible pair of nodes using a dedicated line of repeaters. we investigate how classical multiplexing schemes translate to the domain of quantum repeaters, in order to manage shared resources and active communication flows of data from different stations. We simulate four sharing protocols in a complex network with competing traffic. Circuit switching gives any individual flow the best performance, but makes poor use of the overall network and is inflexible. We use circuit switching as our baseline case to compare time division multiplexing, buffer space multiplexing, and statistical multiplexing, and show that all multiplexing schemes are better than circuit switching. For the particular network simulated, we find that statistical multiplexing outperforms time division multiplexing by 28% and buffer space multiplexing by 13%. We find that all three multiplexing schemes are fair; each flow is penalized a similar percentage of its throughput as the the total number of users in the network increases. Finally, statistical multiplexing requires no network-wide coordination of the use of quantum memory or channels, and is easier to implement than a robust, scalable scheme for the other protocols. Our current results suggest that the best strategy for quantum repeater networks is statistical multiplexing. (This is in fact the quantum analogue of the basis on which the Internet works.) However, our current simulations are done with no degradation of memory over time, using the assumption of quantum error-corrected memory at each repeater; inclusion of decoherence and a finite qubit lifetime remains as future work.
This repository contains the numerical data and computational codes supporting the results presented in the manuscript: "Engineered non-Gaussian Coherence as a Thermodynamic Resource for Quantum Batteries". The archive (data_QB.zip) includes all datasets, Jupyter notebooks, and figure files required to reproduce the results reported in both the main text and the Supplemental Material. Each figure is organised in a separate directory containing the corresponding data (.txt), code (.ipynb), and generated plots (.png/.pdf). The provided materials are sufficient to reproduce all figures and results without restriction. Detailed instructions and directory structure are described in the accompanying README.txt file. This dataset is made openly available to ensure transparency and reproducibility of the reported results.
# Sensing with discrete time crystals Data Repository This repository contains experimental data, simulation results, and analysis code for Discrete Time Crystal (DTC) sensing research. The data is organized by figure numbers corresponding to the main manuscript and supplementary materials. ## Repository Structure ``` DTC_sensing_Zenodo_Repo/ │ ├── data/ # All experimental and processed data │ ├── raw/ # Raw experimental data files │ │ ├── fig-1/ # Figure 1 raw data │ │ ├── fig-2/ # Figure 2 raw data (fig-2b, fig-2c) │ │ ├── fig-3/ # Figure 3 raw data (fig-3a, fig-3b, fig-3c) │ │ ├── fig-4/ # Figure 4 raw data │ │ └── fig-S1/ through fig-S18/ # Supplementary figures raw data │ │ │ └── processed/ # Processed and analyzed data │ ├── fig-3/ # Processed data for Figure 3 │ └── fig-S14/ # Processed data for Figure S14 │ ├── src_code/ # Source code for analysis and simulations │ ├── simulations/ # Simulation code │ │ ├── SingleToneDTC/ # Single-tone DTC simulations │ │ ├── TwoToneDTC/ # Two-tone DTC simulations │ │ ├── helper.py # Helper functions │ │ ├── setup_system.py # System setup utilities │ │ └── systems.yaml # System configuration parameters │ │ │ └── utils/ # Utility functions │ ├── plotting_utils.py # Plotting and visualization utilities │ └── simulation_utils.py # Simulation utilities │ └── visual_elements/ # Code and notebooks for figure generation ├── main/ # Main manuscript figures │ ├── fig-1/ # Figure 1 generation code │ ├── fig-2/ # Figure 2 generation code │ ├── fig-3/ # Figure 3 generation code │ └── fig-4/ # Figure 4 generation code │ └── supmat/ # Supplementary material figures └── fig-S1/ through fig-S18/ # Supplementary figure generation code ``` ## Data Description ### Raw Data (`data/raw/`) The raw data directory contains experimental measurements organized by figure number: - **File Formats:** - `.mat` files: MATLAB data files containing experimental measurements from the Proteus P9484M NMR spectrometer - `.csv` files: CSV files containing contour and magnetometer data (fig-S1) - `.hdf5` files: HDF5 files containing simulation results (fig-S13-S16) - `.npy` files: NumPy array files - **Data Organization:** - **Main Figures (fig-1 through fig-4):** Core experimental results - **Supplementary Figures (fig-S1 through fig-S18):** Additional experimental data, simulations, and analysis ### Processed Data (`data/processed/`) Processed data contains analyzed and pre-computed results: - **File Formats:** - `.npy` files: NumPy arrays containing processed experimental data - **Available Processed Data:** - `fig-3/`: Processed data for Figure 3 (fig-3a, fig-3b) - `fig-S14/`: Processed data for Figure S14 (AC phase scans, frequency scans, Vpp scans) ## Source Code ### Simulation Code (`src_code/simulations/`) - **SingleToneDTC/**: Code for single-tone DTC simulations - **TwoToneDTC/**: Code for two-tone DTC simulations - **systems.yaml**: Configuration file defining system parameters (N, rmin, rmax, gamma, theta, tau, etc.) - **helper.py**: Helper functions for simulations - **setup_system.py**: System setup and initialization utilities ### Utility Functions (`src_code/utils/`) - **plotting_utils.py**: Functions for data visualization, including matplotlib configuration and plotting routines - **simulation_utils.py**: Utilities for running and analyzing simulations ## Figure Generation ### Visualization Code (`visual_elements/`) Each figure directory contains: - **Jupyter notebooks** (`.ipynb`): Interactive notebooks for data analysis and figure generation OR - **Python scripts** (`.py`): Standalone scripts for figure generation - **Output files** (`.pdf`, `.svg`): Generated figure files ## Requirements All required Python packages are listed in `requirements.txt`. Key dependencies include: - **NumPy** (2.3.5): Numerical computations - **SciPy** (1.16.3): Scientific computing and data analysis - **Matplotlib** (3.10.7): Plotting and visualization - **h5py** (3.15.1): HDF5 file handling - **Pandas** (2.3.3): Data manipulation - **Jupyter/IPython**: Interactive notebooks - **PyYAML** (6.0.3): Configuration file parsing To install dependencies: ```bash pip install -r requirements.txt ``` ## Data Access ### Reading Raw Data Raw experimental data is stored in MATLAB `.mat` format. To read these files in Python: ```python from scipy.io import loadmat data_dict = loadmat('path/to/file.mat') ``` ## Usage 1. **Install dependencies**: `pip install -r requirements.txt` 2. **Navigate to figure directory**: Each figure has its own directory in `visual_elements/` 3. **Run analysis**: Open the Jupyter notebook (`.ipynb`) or Python script (`.py`) for the desired figure 4. **Data paths**: The code assumes data is in the `data/` directory relative to the repository root ## Notes - Raw data files are named with timestamps (e.g., `2024-06-06-125713_Proteus.mat`) indicating when measurements were taken - Some figures contain subdirectories (e.g., `fig-2b/`, `fig-2c/`) for different panels - The repository structure follows the organization of figures in the associated publication
In the coming years, quantum networks will allow quantum applications to thrive thanks to the new opportunities offered by end-to-end entanglement of qubits on remote hosts via quantum repeaters. On a geographical scale, this will lead to the dawn of the quantum internet. While a fullblown deployment is yet to come, the research community is already working on a variety of individual enabling technologies and solutions. In this article, with the guidance of extensive simulations, we take a broader view and investigate the problems of quality of service (QoS) and provisioning in the context of quantum networks, which are very different from their counterparts in classical data networks due to some of their fundamental properties. Our work leads the way toward a new class of studies that will allow the research community to better understand the challenges of quantum networks and their potential commercial exploitation.